Re: on <close-session>

[Eliot Lear <lear@cisco.com>]

There are four cases to discuss:

 - manager initiates normal close
 In this case, nobody should close the underlying communication path
 until the agent has responded to all outstanding <RPC>s.
 - agent initiates normal close
 In this case, the agent SHOULD NOT initiate a close until it has
 processed all outstanding RPCs.
 - manager realizes it's lost the communication channel
 Error condition.  Stop sending until you've dealt with the error ;-)
 - agent realizes it's lost the connection
 Complete any RPC that is currently being executed and then stop
 so that the manager can deal with the error...

Additional comments below:


jayaprakash.kulkarni@wipro.com wrote:
> Eliot Lear wrote:
>
>
> > - 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.
>
>
> Is this para concerned with a normal termination using close-session
> command?

NO.

> If yes, is it a expected behaviour that manager will terminate a session
> immediately on sending a close-session OR should it wait until it
> recieves a <ok> reply from the manager?
>
> IMO, manager should not terminate a session immediately at the end of a
> close-session command and should wait until it recieves a <ok> reply.

Right.  transport should remain intact under normal circumstances until 
<OK> is received.  Then transport mapping dictates close procedures.

> All the commands should be pipelined, so the close-session would get
> executed only at the end of the commit operation.

Yah.

Eliot
ps: I'm not sure what it means to see a confidentiality notice on a 
public mailing list...

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