Subject: minor <lock> ambiguity

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Apr 2006 10:21:05 -0700

Hi,

prot-12:sec. 7.5, para 2 says a lock request must fail
if "an existing session" hold the lock.

para 6, bullet 2 says a lock must not be granted
if "another NETCONF session" holds the locks.

Issue:  Does the agent need to check for the corner-case
where the manager is calling lock multiple times,
or is the agent strict and treat this as an error?

I remember we discussed this issue in the past, but I
don't remember making a decision:

Is it an error if a session call <lock> on a config
that it already locked?  This is probably a programming
error on the NMS, so IMO a lock-denied error should always be
returned if any attempt is made to lock an already locked config.

Therefore, para. 2 is correct and para. 6 is incorrect.

Can we agree on this interpretation so managers can expect
a consistent API?

thanks,
Andy

--
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: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Apr 2006 19:57:21 +0200 (CEST)

> Can we agree on this interpretation so managers can expect

I think this is very reasonable.  (The description of lock-denied also
says "another entity".)

BTW, this is the way our agent behaves; i.e. it sends a lock-denied
error if the same session tries to grab a lock twice.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Apr 2006 11:25:37 -0700

> error if the same session tries to grab a lock twice.

Mine too.

Also, an operation-failed error will be returned
if attempt to unlock a config that is not locked is made.
This is explicitly stated in sec. 7.6.
It would be inconsistent to treat this as an error,
but not the similar case for <lock>.

Andy