Subject: RE: Comments on Partial Locking -01

From: Mehmet Ersue <[email-masked]>
Date: Wed, 5 Dec 2007 22:18:13 +0000 (GMT)

> Another comment, we may want to say that a partial lock can 
> cause a full lock to fail.
> 
> Sharon 

I wouldn't mind if the full lock does not fail when both of the locks have been initiated by the same session. 
Then the question is whether the partial lock should survive which seems to be useful.

Cheers,
Mehmet
 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On
> Behalf Of Chisholm, Sharon (CAR:ZZ00)
> Sent: Wednesday, December 05, 2007 12:45 PM
> To: [email-masked]
> Subject: Comments on Partial Locking -01
> 
> Hi
> 
> I assume since the new charter has been approved, this list is now the
> correct place to discuss the drafts proposing to address those items.
> Here are my comments on the latest partial locking draft.
> 
> I continue to like the general approach.
> 
> 1. Section 2.1, last paragraph, I assume multiple partial locks is
> achieved via multiple partial locking commands. This should be
> clarified.
> 
> 2. Section 2.4.1, second paragraph, I assume the discussion of the
> partial lock not picking up new stuff to lock is done for 
> simplicity? I
> am not sure it is what the user would want. I'd also be 
> interested in an
> example of how new stuff get created if there is a lock.
> 
> 3. Section 2.4.1, forth paragraph, is this defining a third way a
> partial lock can terminate (when what it is locking gets deleted) that
> should also be mentioned in the third paragraph of section 2.1?
> 
> 4. Section 2.4.1, where it discusses that a partial lock will fail due
> to access rights, isn't that all we should say. "The lock will fail if
> the user does not have sufficient privileges ..." I don't think we
> should be talking about having enough privileges to read. We 
> don't know
> what the access model will be and these could be separate attributes.
> 
> 5. Section 2.4.1, where it talks about supporting XPATH when 
> XPATH isn't
> supported. Do we really want this? Wouldn't it just be simpler to
> require XPATH. It seems people are supporting it anyway and if they
> don't, they don't get this optional capability.
> 
> 6. Partial locks should be included in the NETCONF monitoring draft.
> 
> 7. Section 5.1 (Open Issues), if I can't lock the thing I am about to
> create, then don't I need to lock its parent? This might be 
> simpler, but
> at times might be locking other people out unnecessarily.
> 
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
> 
> --
> 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/>
> 
> --
> 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/>
> 

      Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 11 Dec 2007 18:15:14 +0100

Hello Mehmet,
We could propose to allow a global lock after a partial lock by the same session, it is even 
logical in a way.

However the main NETCONF standard says:
"      An attempt to lock the configuration MUST fail if an existing
       session or other entity holds a lock on any portion of the lock
       target."
This means we can not allow the global lock. I think what you propose does not violate the 
spirit of the RFC4741, but it does violate the exact rule in the RFC.

Also we would have to deal with some tricky cases:
1) session A issues partial-lock-A
2) session A issues global-lock
- Should the partial-lock still be kept, or does this automatically remove all partial locks 
for session-A for the specified datastore? (propose YES)
- after the successful global lock should it be possible to use a partial lock for the same 
datastore by the same session ? (propose NO)
3) session-A issues global-unlock
- should the partial locks stay alive ? (propose NO)

regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2007 08:26:33 -0800

Balazs Lengyel wrote:
> Hello Mehmet,
> We could propose to allow a global lock after a partial lock by the same 
> session, it is even logical in a way.
> 
> This means we can not allow the global lock. I think what you propose 
> does not violate the spirit of the RFC4741, but it does violate the 
> exact rule in the RFC.
> 

If you change the way global locks work, then RFC 4741 needs to be
obsoleted and a new RFC published to replace it.

The WG decided way back when <lock> was designed that it
is usually a bug when a session locks the same thing twice,
so the text above forces the agent to grant and release a lock
just once per lock usage.

This 'feature' implies over-lapping partial locks, which seems complicated,
and not as likely to be inter-operable as non-overlapping partial locks,
granted and released once per usage.

> - Should the partial-lock still be kept, or does this automatically 
> remove all partial locks for session-A for the specified datastore? 
> (propose YES)
> - after the successful global lock should it be possible to use a 
> partial lock for the same datastore by the same session ? (propose NO)

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 11 Dec 2007 18:48:48 +0100

Hello,
This would not allow overlapping partial-locks (I agree that would be nasty), just the single 
case, that a number of disjunct partial locks are replaced by one global lock. I don't see big 
complications.

However I don't see this as important, so it is up to Mehmet to fight for it. For the time 
being I will not add it to the draft.
Balazs

Andy Bierman wrote:
> Balazs Lengyel wrote:
>> Hello Mehmet,
>> We could propose to allow a global lock after a partial lock by the 
>> same session, it is even logical in a way.
>>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2007 21:09:50 +0100 (CET)

> obsoleted and a new RFC published to replace it.

I agree that we should not change RFC 4741 b/c of this.

> granted and released once per usage.

That was my initial thought as well.  But then a reviewer of the draft
commented that there is a use case for allowing overlapping partial
locks, and that is modular code at the manager.  Suppose you write a
routine that grabs a lock of /foo/bar/baz, does something and then
releases the lock.  Later, you might call this routine from code that
already have /foo/bar locked (or /foo/bar/baz/xxx/yyy).  Thus one can
argue that the code on the manager will get more complicated if we
don't allow overlapping locks.

I will also argue that the code in the agent does not necessarily
become more complicated with overlapping locks (we have implemented
overlapping locks actually).  But maybe that wasn't your point.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Dec 2007 09:06:25 +0100

I don't want to change RFC 4741 b/c of this, but I am sure, the intent of locking is to protect 
a session from other sessions/interfaces/protocols, and not to decide what the session itself 
should do. It is not the job of a protocol designer to tell management application designers 
how to work.
This it why I think overlapping locks by the same session might go against the word of the RFC, 
but not against the spirit.

Balazs