no netconf-state model needed after all

[Andy Bierman <abierman@cisco.com>]

Hi,

We can simply remove the entire netconf-state model from
the protocol document.  The application gets the session-id
of the lock owner in the <rpc-error> element when the <lock>
operation fails.  We should make sure a session has a way
of knowing its own session-id through the protocol.  Other than
that, I see no reason why we need the netconf-state model
in NETCONF 1.0.

From section 7.5:

 Negative Response:

      An <rpc-error> element is included in the <rpc-reply> if the
      request cannot be completed for any reason.

      If the lock is already held, the <error-tag> element will be
      LOCK_DENIED and the <error-info> element will include the
      <session-id> of the lock owner.  If the lock is held by a
      non-NETCONF entity, a session-id of 0 (zero) is included.  Note
      that any other entity performing a lock on even a partial piece of
      a target will prevent a NETCONF lock (which is global) from being
      obtained on that target.


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/>