Subject: on <close-session>

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Oct 2004 10:03:34 +0200

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

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 1 Oct 2004 07:55:53 -0400

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? 

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.

If it has started processing an RPC, MUST it abort that operation, or
can it wait until the next RPC to cease processing? 
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?

dbh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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.

Other tidbits:

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: Andy Bierman <[email-masked]>
Date: Fri, 01 Oct 2004 07:30:16 -0700

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

>new communicatioins session.

good point

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

>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