Re: little problem with <close-session>

[Eliot Lear <lear@cisco.com>]

Hi,

Margaret Wasserman wrote:
> These are all interesting questions, and I would like to know the 
> answers (but I don't).  I do know that there were real-life problems 
> with this in the mid-1990s, but I have no more recent data.

Fair enough, but I would like the transport concern to be handled in the 
mapping document.

> The other reason that I cited for wanting a <close-session> command is 
> that it removes any ambiguity about when the session has been cleanly 
> closed on both sides, so that all resources and state can be freed.  
> This is really a question of whether we want any concept of a session to 
> exist at the NETCONF layer, or whether we want NETCONF to assume that 
> the graceful close of a lower layer session indicates that the NETCONF 
> session completed successfully.

The state of a session is something that needs to be determined in the 
mapping document.  In some cases it will need to be explicit and in 
other cases explicit.  Nothing prevents the ends from communicating 
session state - in a combined L4/L5 view of the world that happens all 
the time with TCP.

> I don't have religion about this, so if no one else sees any advantages 
> to having a <close-session> command, please just remove it.  If that is 
> the choice of the WG, I will put a caveat in the SSH mapping about 
> connections being left in TIME-WAIT state on the manger, and we can move 
> on...

Again, I'm not suggesting that it be removed entirely but that it be 
moved into the mappings (of the alternative that's my favorite).

One way or the other, you need to update your draft.

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