Re: on <close-session>

[Eliot Lear <lear@cisco.com>]

David B Harrington wrote:
> Hi Eliot,
>
> What is the reasoning behind the following rule?
>  - an agent MUST cease processing <RPC>s if it determines that it has
>     lost communications with the manager, and release all state
>     associated with the session, including locks.
>
> I view MUST as a requirement for interoperable on-the-wire behavior.
> Is this really a MUST, or a SHOULD, or a MAY, and why?

The theory goes that the reason you had the additional RPCs in the first 
place was that you are pipelining, and pipelining is an optimization so 
that you don't have to wait for a response.  However, there is no way to 
report an error once the communication channel is gone, so why continue 
processing?  At worst then you've lost a single RPC response.  I would 
argue that it is an interoperability argument in as much as you've lost 
the ability to report state to the other end.  Does that fail the test 
of MUST?

I'm not religious about it, so I could be convinced the other way.  In 
fact here's an argument for the other way- suppose one RPC is 
intentionally disruptive and the next is meant to heal.  The catch in 
doing it this way is that you have no guarantee of the 2nd RPC getting 
to the device before it go boom on the 1st RPC.

Eliot

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