Subject: [Netconf] comment from monitoring draft, may require update in partial lock draft

From: "Mark Scott" <[email-masked]>
Date: Thu, 19 Mar 2009 16:11:32 -0400

Hi Balazs,

One of the comments raised for 'draft-ietf-netconf-monitoring-v04' may
require an update in raft-partial-lock as well.

The comment:  "A description of lockId is needed to make it clear that
it is the value returned by <partial-lock> and the partial locking draft
must be clarified that the lock id is globally unique within a NETCONF
server so that it can actually serve as a key here without having to
scope it by the sessionId."

I have addressed the first concern in the monitoring draft  (v-04) in
the model documentation.

I could not find anything in the partial locking draft (v-07) that
addresses the second concern though.  I.e. no indication of the
uniqueness of the lock-id.

Can you comment on this point?

Thank you,

Mark

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 20 Mar 2009 11:29:15 +0100

Hello,
I will add to the partial-lock draft, that the lock-id is unique for the Netconf server and not 
just for sessions. + see below.

Balazs

WashamFan wrote:
> How to handle lockId=0 which represents a lock acquired buy non-NETCONF client?
> I mean, all non-NETCONF locks would share the same lockId.

BALAZS: Where did you see lock-id=0 in the draft?
Session-id zero has a special meaning, but not the lock-id=0.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 20 Mar 2009 16:23:27 +0100

WashamFan wrote:
> Yes, you're right, I made a mistake.
> But I still want to ask, is there any intention to monitor non-NETCONF
> locks which share the same sessionId and no lockId?
> 
As I see the use-case:
I try to modify something, but I get back a message: write denied due to locking. The next 
logical step is to check who or what locked it. I am interested in all entities that can lock 
the datastore, because my work is blocked both if the lock is owned by a Netconf session or if 
is owned by the CLI. If in 50% of the cases I do not get information about existing locks, the 
functionality is unreliable (unusable?).
Rfc4741 speaks about multi-protocol locks, so the data model about locks should also handle 
locks from all protocols.

I think that non-Netconf locks SHOULD definitely be listed in the monitoring schema.

IMO non-netconf locks should also have a non-zero lock-id. Why is that a difficult problem? 
What is the reason not to provide one?

I also think non-netconf session SHOULD also be listed (with an Id) in the monitoring schema. 
What is the reason to omit them? Obviously the user is interested.

Balazs

---

From: WashamFan <[email-masked]>
Date: Fri, 20 Mar 2009 21:10:02 +0800

washam

---

From: WashamFan <[email-masked]>
Date: Fri, 20 Mar 2009 15:53:54 +0800

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

---

From: WashamFan <[email-masked]>
Date: Sat, 21 Mar 2009 12:12:10 +0800

Hi,

I also think it is helpful to monitor all locks supported by a device.
Actually, we did a effort to address this concern by defining a
portion of MIB.
http://tools.ietf.org/html/draft-meng-fan-lock-mib-00

Well, I am not sure if NETCONF WG is a suitable place to 
accommodate the draft.

washam

> WashamFan wrote:
> >>>>  The comment:  "A description of lockId is needed to make it 
> clear 
> >> that
> >>>>  it is the value returned by <partial-lock> and the partial 
> locking 
> >> draft
> >>>>  server so that it can actually serve as a key here without 
> having 
> >> to

---

From: WashamFan <[email-masked]>
Date: Fri, 20 Mar 2009 11:43:46 +0800

washam