RE: on <close-session>

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

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