Re: little problem with <close-session>

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Eliot Lear" <lear@cisco.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "netconf" <netconf@ops.ietf.org>
> Sent: Friday, August 20, 2004 1:25 PM
> Subject: Re: little problem with <close-session>
...
> > The concern is independent of whether command processing
> > is synchronous.  The protocol (section 3.6) does not require
> > the manager to wait for a response before sending the next command.
> > The question is about what the agent should do with buffered commands
> > if an attempt to send a response fails because the other side
> > (in "fire and forget" mode) has closed the connection.  Regardless of
> > whether the protocol has a "close" PDU, the behaviour needs to be
> > defined.  (I.e., are commands processed after the manager initiates
> > a transport layer close?)
>
> My answer is NO.  If you send a close and then send an additional
> command, you've gone nuts.

That's not the case we were worried about.
The scenario is where a manager sends one
or more commands, and then closes the connection
without waiting for the response(s).  The agent will
be able to read the (buffered) commands, but will
get an error when it tries to send the responses on
the closed connection.  Regardless of whether we think
this is a smart thing to do, we need to define what happens.

> But this is only half the problem- the other
> half is that the agent cannot initiate the close, and it should be able
> to.  Consider the very basic case of a reconfiguration requiring a
> re-authentication.  The only way to do that is to close the connection.
>   We need an orderly way to do that.
...

I think we're in violent agreement on this point.

Randy



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