Errata and clarifications: netconf-prot-03

[Andy Bierman <abierman@cisco.com>]

- pg 5, para 5:

  move [7] reference to first occurrence of XSLT (ln 9 -> ln 5)

- pg 14, <rpc-reply> example

  The request is missing the message-id attribute, so the reply
  should not have it either.  Currently has message-id="102".

- pg 17, para 2, filter parameter

  This parameter needs some more explanation.  The concept
  of retrieval filtering needs to be explicitly introduced 
  before this section (5.1).  At least mention where filtering
  is defined.

  The larger issues related to filtering need to be resolved
  before this new section can be written.

- pg 20, para 1, <edit-config> operation parameter

  I think the WG agreed to this list:
    - merge, replace, create, modify, delete
  The modify value is missing.  See separate email on this issue.

- pg 27, para 3, bullet 2

  This is very 'candidate model' centric.  If the "changes have
  not been committed" does not apply if the #candidate capability
  is not supported.  There are also "implicit locking" issues that 
  need to be resolved by the WG (not in this email).

- pg 27, para 3, bullet 3

  remove bullet -- lock capability has been removed

- pg 27, para 7, negative response

  mention that the LOCK_DENIED error response (defined in appendix A)
  is returned.

- pg 28, footer

  this seems to go over to the next page on my printer; check the
  page formatting

- pg 31, para 1

  Mention that all subsequent <rpc> requests received after the
  <close-session> will be ignored by the agent.  

- pg 33, onward

  Include the actual URI for each capability.  Include multiple
  examples for capabilities that have parameter values.

- pg 33, para 6

  2 sentences mention "NETCONF channel".  Remove this obsolete
  references

- pg 34, para 1

  reformat indentation on XML example; line wrap occurring

- pg 37, para 5

  The default target for <lock> cannot be <candidate> on one 
  platform and <running> on another.  This isn't represented 
  in the XSD (don't know if it can be represented).  This also
  doesn't seem consistent with the defaults for some other
  operations.  This gives lots of ammo to the people that
  want to take out defaults from the protocol operations altogether.


Andy



                 

  


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>