RE: on <close-session>

[Andy Bierman <abierman@cisco.com>]

At 04:55 AM 10/1/2004, 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'm not sure either...but let me try to restate the problem
with <close-session>:

Start with an queue of RPC requests on the agent (R1 .. Rn).
Let's say Ri is a <close-session> command.
Desired outcome:
  - R1 .. Ri-1 operations are completed and the corresponding
    <rpc-reply> messages are received by the manager
  - Ri executed: session/connection closed 
  - Ri+1 .. Rn operations are never processed

The document text should clarify this behavior, and
also the behavior in the related case of a lost connection.


>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? 
>
>It seems to me that you end up with potentially inconsistent state
>either way, and either resultant state might preclude establishing a
>new communicatioins session.

good point


>If it has started processing an RPC, MUST it abort that operation, or
>can it wait until the next RPC to cease processing? 

good question -- I would say SHOULD, but there aren't any
specific requirements to detect connection loss during
the RPC processing, so how useful is this rule to abort the RPC?

>If it has buffered RPCs, it apparently must discard the buffered RPCs.
>Where is the point at which interoperability would be impacted if ti
>continued processing its buffered RPCs?

It is a manager error to send RPCs after a <close-session>.
If the agent has an NV error logging facility, it may choose
to log the error after closing the session.


>dbh

Andy


>-----Original Message-----
>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
>On Behalf Of Eliot Lear
>Sent: Friday, October 01, 2004 4:04 AM
>To: netconf; Margaret Wasserman
>Subject: on <close-session>
>
>A few of us discussed this yesterday.  Please comment on the following
>idea:
>
>Leave <close-session> in the base document for when the manager wants
>to close a session.
>
>The method for an agent closing a session shall be specified in the
>mapping specification.
>
>Other tidbits:
>
>  - a manager MUST NOT send <RPC>s after a <close-session>
>  - 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.
>
>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/>
>
>
>
>--
>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/> 


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