> 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: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Chisholm, Sharon (CAR:ZZ00)
> Sent: Wednesday, December 05, 2007 12:45 PM
> To: netconf@ops.ietf.org
> 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 netconf-request@ops.ietf.org 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 netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>>