Subject: [Netconf] 4741bis, issue 18: lock and commit

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Dec 2009 08:37:00 -0800

Hi,

There is an open issue regarding how the <commit>
operation behaves if the candidate is locked by
another session.

There seems to be consensus that a lock on the
running config by another session will cause
the <commit> operation to fail.

Since the contents of running will be the same as
candidate (it it succeeds), it is not clear if
this operation can ignore a lock on candidate or not.

The WG needs to decide what to do here:

 A) Add text to sec. 8.3.4.1 saying the commit MUST
    fail if the candidate is locked by a different session

 B) Add text to sec. 8.3.4.1 saying it is implementation-specific
    whether the commit will be affected by a lock on candidate

 C) Add text to sec. 8.3.4.1 saying the commit MUST NOT
    fail because the candidate is locked by a different session

 D) Don't add any text; declare this to be a non-issue

 E) ???

[ed. opinion: this seems like an artificial corner-case
due to poor lock usage, so if this is implementation-specific,
it will not really harm interoperability. favor choice (B)]

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Dec 2009 21:44:41 +0100 (CET)

>     fail if the candidate is locked by a different session

I prefer A.  This is what at least 3 implementations do (see the
thread starting at
http://www.ietf.org/mail-archive/web/netconf/current/msg04841.html)

/martin

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>