Re: little problem with <close-session>

[Eliot Lear <lear@cisco.com>]

Hi,

I'd like to put a new draft out, but I can't right now because I'm 
blocked on <close-session>.  As it stands right now, we are blocked 
because Margaret is concerned about CLOSE_WAIT state consuming resources 
on the manager.  This concern arises from the case where one will want 
to make a change across a large number of devices in a short period of 
time.  The concern is mitigated by <close-session> because this forces 
the CLOSE_WAIT state to the agent.

On the other hand, <close-session> cannot currently be used by the agent 
because the agent doesn't send commands.  So, what's a poor agent to do 
when it wants to gracefully shutdown the connection?

Our options are as follows:

 - simply close the connection.  There's no pretty symmetry there but it
   will do the job.  However, it poses a problem for BEEP in as much as
   I would have to violate the BEEP->TCP transport mapping.

 - Remove <close-session> from the base protocol and deal with this
   level of signaling in the mapping below.

 - Retain <close-session> *AND* do something in the mapping below to
   allow the agent to close the connection.  Not pretty because we're
   actually now beyond MAPPING.  If we did this we should have some
   text in the base protocol about this possibility such as the
   following:

	"The agent may initiate session termination in a way specified
         by the appropriate application mapping."

Comments?

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