Subject: kill-session: editorial mistake

From: Lei Zhang <[email-masked]>
Date: Wed, 21 Dec 2005 14:27:48 -0800

In draft 10:

7.9.  <kill-session>

   Description:

      Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session and
      close any associated connections.

      ... ...

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

And:

8.3.5.1.  <lock> and <unlock>

   ... ... To facilitate easy
   recovery, any outstanding changes are discarded when the lock is
   released, whether explicitly with the <unlock> operation or
   implicitly from session failure.

The two sections conflict with each other. The 'otherwise' paragraph of 
<kill-session>
seems to be misplaced right?

Thanks,
Lei

--
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: Thu, 22 Dec 2005 07:56:06 -0800

Lei Zhang wrote:

> The two sections conflict with each other. The 'otherwise' paragraph 
> of <kill-session>

No.

Sec. 7.9 is referring to changes that have been commited from <candidate>
to <running>.  If the <kill-session> occurs after the first <commit> but 
before
the second <commit>, then the agent treats the <kill-session> the same
as a dropped session, and reverts the <running> config.

Sec. 8.3.5.1 is referring to any edits pending in the <candidate> which 
have not
been committed yet. 

That sentence you highlighted says that a <discard-changes> is implicitly
performed by the agent whenever a lock on <candidate> is released.

> Lei

Andy

---

From: Lei Zhang <[email-masked]>
Date: Thu, 22 Dec 2005 09:01:01 -0800

Andy Bierman wrote:

> to <running>.  If the <kill-session> occurs after the first <commit> 
> but before

ok that sounds reasonable. The text sure can use some rewrite to clarify 
things up.

Thanks,
Lei