Re: Comments on Partial Locking -01

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Hello,
See answers below:

Sharon Chisholm wrote:
> 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?
[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.
> 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.
[BALAZS]: read is just an example. "at least some basic access rights, e.g., read rights"
> 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.
[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.
> 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.
[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;
    	}