Subject: Re: on <close-session>

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Oct 2004 14:23:35 +0200

David B Harrington wrote:
> Hi Eliot,
> 
> What is the reasoning behind the following rule?
>  - an agent MUST cease processing <RPC>s if it determines that it has
>     lost communications with the manager, and release all state
>     associated with the session, including locks.
> 
> I view MUST as a requirement for interoperable on-the-wire behavior.
> Is this really a MUST, or a SHOULD, or a MAY, and why?

The theory goes that the reason you had the additional RPCs in the first 
place was that you are pipelining, and pipelining is an optimization so 
that you don't have to wait for a response.  However, there is no way to 
report an error once the communication channel is gone, so why continue 
processing?  At worst then you've lost a single RPC response.  I would 
argue that it is an interoperability argument in as much as you've lost 
the ability to report state to the other end.  Does that fail the test 
of MUST?

I'm not religious about it, so I could be convinced the other way.  In 
fact here's an argument for the other way- suppose one RPC is 
intentionally disruptive and the next is meant to heal.  The catch in 
doing it this way is that you have no guarantee of the 2nd RPC getting 
to the device before it go boom on the 1st RPC.

Eliot

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Oct 2004 14:27:54 +0200

Just to add one point to respond to Dave...

Yes, I do think you complete the existing RPC in order to remain as 
consistent as possible, given the possibility that the RPC itself could 
contain a temporarily disruptive change that is corrected in the same RPC.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 1 Oct 2004 09:43:47 -0400

Hi Eliot,

I haven't been following netconf closely so I may have missed some
changes, and may make some dated assumptions. Feel free to point out
that my assumptions are based on an outdated understanding of netconf
design.

Let me say that I'm probing around the edge cases because I want to
understand whether this rule is really required for interoperability.
I don't really have an opinion about this rule. As a MIB Doctor, there
are a few things I watch for: we should avoid using MUST/SHOULD
language where it isn't warranted, and we want to avoid developing
crappy little rules (tm) that are unnecessary constraints on
implementors. 

This rule has three requirements - cease processing, release locks,
and release other session state. I'll focus on the "cease processing"
requirement for now.

"cease processing" and interoperabiity:
Once we lose the communications channel, the manager loses the ability
to receive responses of any kind from that session, error or success.
Whether the agent ceases processing is immaterial, right? So I
question whether "MUST cease processing RPCs" impacts on-the wire
interoperability; the on-the-wire behavior isn't impacted as far as
the manager is concerned. 

"cease processing" and the manager -
A pipelining manager, with knowledge of an agent that buffers RPCs,
MAY deliberately send RPCs to get buffered, and then close down the
comm channel because it doesn't care what the reposnses are. I don't
think this is a great design choice, but I cannot foresee all the
factors that might lead to such a choice, and we shouldn't have CLRs
that constrain application design unnecessarily. 

"cease processing" and the agent -
If an agent sends responses after it has determined the comm channel
is lost, it is knowingly wasting bandwidth. Does this mean it should
not process the RPCs it has buffered, or merely that it shouldn't send
a response? If the pipelining manager doesn't care about the
responses, closing the channel might be a thoughtful optimization. If
the use case of a manager that doesn't care about responses is real,
maybe we should just add an optional flag to each RPC that says "don't
bother responding". How real is this use case? Should we write a CLR
that says this use case is illegal? The current proposed rule seems to
be that CLR.

Does an implementor have the resonsibility to check whether the
response channel still exists before it starts to process any buffered
RPC? This rule seems to require that. Why is it a MUST, rather than a
MAY or a SHOULD?

Other interoperability concerns - 
It may impact interoperability if the manager cannot regain control
using a new session because the lock exists, or the other session
state exists, or the other processing is still ongoing. Are there real
cases where this could be a problem, that are not already addressed by
netconf? 

SNMP was designed to be able to work in an unstable network,
specifically to stay operating well enough in a war environment to
deliver commands, even if it cannot maintain session. Think terrorist
attack. If a manager can send RPCs to a device to configure a security
mechanism, but the agent buffers the RPC, and the terrorist then
disrupts the communications, then the security RPC that has been
successsfully delivered has to be re-delivered, possibly after
determining through get-state that it didn't take effect the first
time. Does requiring the discard of successfully-received RPCs make
netconf less robust when under attack?

David Harrington
[email-masked]

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Friday, October 01, 2004 8:24 AM
To: [email-masked]
Cc: 'netconf'; 'Margaret Wasserman'
Subject: Re: on <close-session>

> Is this really a MUST, or a SHOULD, or a MAY, and why?

The theory goes that the reason you had the additional RPCs in the
first place was that you are pipelining, and pipelining is an
optimization so that you don't have to wait for a response.  However,
there is no way to report an error once the communication channel is
gone, so why continue processing?  At worst then you've lost a single
RPC response.  I would argue that it is an interoperability argument
in as much as you've lost the ability to report state to the other
end.  Does that fail the test of MUST?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Oct 2004 15:59:43 +0200

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

David B Harrington wrote:
>> - an agent MUST cease processing <RPC>s if it determines that it
> 
> has
>

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 1 Oct 2004 10:27:16 -0400

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
[email-masked]

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Friday, October 01, 2004 10:00 AM
To: [email-masked]
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...

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Oct 2004 18:09:50 +0200

I'm not sure if this is an argument for SHOULD or what, but here's one 
additional thought..

If the agent loses touch with the manager it could be for one or two 
reasons.  Either the manager intended to drop the connection or it 
didn't.  The key here is that the agent can't tell which is the case, 
and so even *if* the manager wanted to see status it couldn't.

Under the "be conservative" principle we should assume that the manager 
wanted status, and so that argues for stopping when you realize there's 
a problem.

How's that for long and circuitous?

Eliot

---

From: Simon Leinen <[email-masked]>
Date: Fri, 01 Oct 2004 21:28:15 +0200

Eliot Lear writes:
> I'm not sure if this is an argument for SHOULD or what, but here's
> one additional thought..

> didn't.  The key here is that the agent can't tell which is the
> case, and so even *if* the manager wanted to see status it couldn't.

> Under the "be conservative" principle we should assume that the
> manager wanted status, and so that argues for stopping when you
> realize there's a problem.

But maybe what the manager really WANTED was for the agent to perform
the request, and the manager merely WISHED to be informed about the
status.  In that case it would be better for the agent to continue
serving requests even though it cannot send back any status.

My gut feeling is that as a manager, I would normally prefer my
commands being executed even when I cannot receive status because the
channel breaks during the session.

Of course this is less true when the requests are really only about
getting information, i.e. "show" commands.  But for requests with side
effects, typically the side effects are more important to me than the
status response.
-- 
Simon.

---

From: Simon Leinen <[email-masked]>
Date: Fri, 01 Oct 2004 21:37:38 +0200

> manager not waiting for a response is not expected, then to be a
> good Internet citizen, one SHOULD cease processing.

Actually, since all our mappings use TCP at the lowest level, there
wouldn't even be loss of bandwidth, because the agent's TCP would
refuse to send TCP segments when it has detected that the connection
is broken.
-- 
Simon.