RE: on <close-session>

["David B Harrington" <dbharrington@comcast.net>]

From RFC2119:
SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

What implications would there be from not implementing to discard RPCs
upon detection of a lost connection?

One implication is the waste of bandwidth. If the use case of a
manager not waiting for a response is not expected, then to be a good
Internet citizen, one SHOULD cease processing.

David Harrington
dbharrington@comcast.net



-----Original Message-----
From: Eliot Lear [mailto:lear@cisco.com] 
Sent: Friday, October 01, 2004 10:00 AM
To: dbharrington@comcast.net
Cc: 'netconf'
Subject: Re: on <close-session>

Hi Dave,

I guess my one question is this: I can't realistically imagine a case
where the device config is to be changed and the manager would not
want to receive confirmation of the change.  But Glenn is correct that
it's unenforceable, and the logic flows as follows:

So I as the agent send back an <OK> for a previous <RPC> and it gets
buffered somewhere in the TCP stack about to time out.  I'm not
blocking on it, however, and so I continue to process the next <RPC>
and even THAT completes before I get hit with a timeout...

If you don't behave this way you would be defeating the purpose of
pipelining.  As I said we could go either way on this.  What do people
think?  SHOULD or nothing?  It came up because there is no text.

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