Re: on <close-session>

[Eliot Lear <lear@cisco.com>]

Just to add one point to respond to Dave...

Yes, I do think you complete the existing RPC in order to remain as 
consistent as possible, given the possibility that the RPC itself could 
contain a temporarily disruptive change that is corrected in the same RPC.

Eliot

Eliot Lear wrote:
> 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/>

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