[Netconf] additional netconf (4741bis) issues

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

Hi,

I have a file where I collected some additional 4741bis issues. Its
getting time to get it on the table (and I am happy to do the edits if
people agree on the issues).

* clarify:

  copy-config('running', 'candidate') == commit()
  copy-config('candidate', 'running') == discard-changes()

* clarify

  any changes to 'running' must fail (check which error applies) while
  a commit is in progress

* clarify

  The handling of default data is implementation specific. Some
  implementations may choose to suppress default data while others may
  choose to always report default data while yet some other
  implementations may suppress default data as long as it was not
  explicitely set. A NETCONF extension allows to work with these
  implementation differences.

* clarify examples

  Make sure the message-id is in a proper namespace in all the
  examples. Note that attributes are not in the default namespace, so
  one has to be explicit:

    <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    </rpc>

  vs.

    <nc:rpc nc:message-id="101"
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    </nc:rpc>

* incorporate capabilities text from the netconf-monitoring draft

   The
   capabilities of a NETCONF server may change over time.  However, once
   a NETCONF server has announced its capabilities in the <hello>
   message, the capabilities for that session MUST NOT change.  A server
   MUST reply with a 'capabilities-changed' error if the client sends a
   request which is affected by a modified capability.  A server MAY
   choose to send 'capabilities-changed' as the response to any request
   other than <close-session> if its capabilities has changed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>