Subject: Comments on Partial Locking -01

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Dec 2007 12:44:48 -0500

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/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Dec 2007 16:27:24 -0500

Hi

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

Sharon 

-----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

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/>

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Fri, 7 Dec 2007 05:53:56 +0800

To second some of Sharons items, the impression I got from the document
was that
 configuration seems to be the only way resources on the box are
created.
We need to also consider hot insertion and removal of hardware.
E.g. I lock an ethernet interface to get get exclusivity on the
interface
but someone physically removes the card. Is my lock persisted ?
If that card is pushed back in what happens ? If a similar card is put
in ?
(e.g I pull out a 4 port card and put in an 8 port card)

I also support Phil's concerns. Can I "read" a config when someone has
locked
a subtree ? The risk for me is I could extract a config which is in
an intermediate state. We need some rules on reading such that I can
only
read a config which is in a know stable state (i.e. not locked)

James.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Wednesday, 5 December 2007 9:45 AM
> To: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2007 23:42:46 +0100 (CET)

Hi,

> (e.g I pull out a 4 port card and put in an 8 port card)

I don't think this is different from how the global lock works.  If I
lock the entire datastore, and someone removes a card, will the config
be altered?

> read a config which is in a know stable state (i.e. not locked)

The way it works right now is that you get what you ask for.  If you
lock /foo, then read from /bar and change /foo according to what you
just read, then you may end up in an inconsistent state.  If you want
to do this consistently, either grab the global lock, or lock /foo and
/bar.

/martin

---

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

Hello Sharon,
See below!
Balazs

> Another comment, we may want to say that a partial lock can cause a full
[BALAZS]: From the main Netconf RFC chapter 7.5:
       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.

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 11 Dec 2007 16:50:47 +0100

Hello,
See answers below:

> should also be mentioned in the third paragraph of section 2.1?
[BALAZS]: No, the lock is still there. The idea is that the lock is created using XPATH. But 
the XPATH is only used at creation. Later the lock is maintained as a set of locked nodes. If 
you delete all the locked nodes, the lock is still present, but it does not cover anything 
anymore.
> what the access model will be and these could be separate attributes.
[BALAZS]: read is just an example. "at least some basic access rights, e.g., read rights"
> don't, they don't get this optional capability.
[BALAZS]: We don't want to mandate full XPATH support. What I heard from people not all devices 
will support full XPATH. However IMHO we must have at least this simplified XPATH otherwise 
there is no way to describe the scope. Then if a device wants to support full XPATH, so be it.
> 6. Partial locks should be included in the NETCONF monitoring draft.
[BALAZS]: I attached an incomplete YANG model for it, but this is really a comment to Mark.
> at times might be locking other people out unnecessarily.
[BALAZS]: Yes locking a parent might disturb others. So should we allow locking non-existing 
objects?
> Sharon Chisholm
list locks {
	config false;
	key lockId;
    	leaf lockId { type uint32; }
    	leaf sessionId  {
        	description "The Id of the session owning the lock.";
        	type uint32;                                                // this should be a keyref really
    	}
    	leaf datastore {
          type enumeration {
          	enum running;
             	enum candidate;
             	enum startup;
         }
    	}
    	leaf isGlobalLock { type boolean; }
    	leaf-list originalLockScopeAsXpath {
        	description "The XPATH expression used to request the lock, omitted for global locks.";
        	type string;
    	}