[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: little problem with <close-session>
Hi Eliot,
Maybe you are right, but I have some thoughts...
At 9:47 AM -0700 8/18/04, Eliot Lear wrote:
The manager is meant to issue a <close-session> element to initiate
a close. For BEEP this is a bad idea, and it's probably a bad idea
for everyone else as well. The problem is that either side should
be able to initiate a close. This is particularly necessary for
orderly shutdown of the device running the agent.
<close-session> is really a way that the manager can ask the agent to
close the session. Its existence does not, necessarily, stop the
agent from closing the session at other times, I suppose. There are
two reasons why I think that this is cleaner than having the manager
simply shut down the connection
when it is finished:
(1) The <close-session> command will be processed in-band, like any
other command and the agent can close the session when it is finish
processing all commands, freeing all locks, etc. This avoids any
ambiguous cases where (for instance) the manager finishes and closes
down before the agent has finished processing all of the commands.
After receiving an error when trying to respond to one command,
should the agent continue to read from the connection and process
subsequent commands from the manager?
(2) For TCP-based session-layer protocols, it is (IMO) highly
desirable for the manager to be the one that initiates the TCP-level
close, so that the TIME-WAIT state ends-up on the agent side. A
manager may manage a very large number of devices and need to connect
to all of those devices in rapid succession, while it seems less
likely that an individual device will be reconfigured as often.
This argues *strongly* for the removal of <close-session> and
returning this function to the application mappings. If we need to
add some meta-thing into SSH, so be it, but the agent needs to
initiate the close - somehow.
If we put this in the application mapping, how would you suggest that
would work?
Margaret
--
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/>