Subject: [Gen-art] Gen-ART review of draft-ietf-netconf-partial-lock-08.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Jun 2009 18:03:06 -0400

I am the assigned Gen-ART reviewer for
draft-ietf-netconf-partial-lock-08.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is almost ready for publication as Proposed Standard 
but I have a couple of comments.

Major
=====

* Section 2.4.1 page 7 paragraph 3 "Let's say ..."

The following text is confusing

"If someone later creates a new user, this new user will not be included 
in the locked-nodes list created previously, the new user will not be 
locked."

It is unclear how this is even possible given there is a partial lock on 
all the users that was obtained using the following select parameter

        <select xmlns:usr="http://example.com/users">
          /usr:top/usr:users
        </select>

Can you please clarify what you mean here?

Minor
=====

* Section 2.1.1.3

The scenario described here does not really describe a deadlock as 
deadlock requires two competing actions waiting for each other to 
finish. I do not know what to call it but this is certainly not a 
deadlock :-) and the deadlock avoidance measures described in section 
2.4.1.2 will not fix this problem.

* IANA considerations

- The section states that "This document registers two URIs..." but it 
only registers one. Either another URI is missing or this text needs to 
be changed.

- It is also not clear where the :partial-lock capability is being 
allocated from. I guess it is coming from the NETCONF Capability URNs 
registry.

Thanks
Suresh

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 25 Jun 2009 12:16:12 +0200

> Can you please clarify what you mean here?

BALAZS:
(Examples without namespaces and with some simplifications)
Lets assume we have the following model

container top {
   list user {
     key name;
     // data about individual user
   }
}

with  management data like

<top>
   <user>
     <name>Paul</name>
   </user>
   <user>
     <name>Suresh</name>
   </user>
</top>

The case mentioned in the paragraph is if the XPath is
<select>
    /usr:top/usr:user
</select>

The above expression will select every individual user at the time of locking (Paul, Suresh). 
However if we use

<edit-config>
   <config>
     <top>
       <user>
         <name>Joe</name>
       </user>
     </top>
   </config>
</edit-config>

A new user Joe is added. Joe is not locked in this case.

The text mentions the "list of 'user' nodes". A node called "userS" is not mentioned.

> 2.4.1.2 will not fix this problem.

BALAZS: Is the following wording better/OK?

When multiple managers use the candidate configuration in parallel,
there is a risk that the interaction of access control (which is still
implementation specific at the time of this writing) and the commit
operation ___ might result in a manager becoming unable both to commit
or discard changes___, as illustrated by the following sequence.

> only registers one. Either another URI is missing or this text needs to 
(AFAIK an URN is an URI as well.)
> allocated from. I guess it is coming from the NETCONF Capability URNs 
So is the following modification OK?

This document registers one capability identifier URN from the NETCONF Capability URNs 
registry, and one URI for the NETCONF XML namespace in the
IETF XML registry [RFC3688].  Note that the capability URN is
compliant to [NETCONF] section 10.3.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 26 Jun 2009 18:36:34 -0400

Hi Balazs,
   Thanks for your quick response. I agree with most of your proposed 
changes. I still have an issue with the locking example. Please find 
comments inline.

On 09-06-25 06:16 AM, Balazs Lengyel wrote:
<snip>
> The above expression will select every individual user at the time of 
> locking (Paul, Suresh). However if we use
> 
> <edit-config>
>   <config>
>     <top>
>       <user>
>         <name>Joe</name>
>       </user>
>     </top>
>   </config>
> </edit-config>
> 

My question is that since I locked the top level user node, how can a 
new user be added while I am holding a lock?

> The text mentions the "list of 'user' nodes". A node called "userS" is 

I got this <users> straight from Section 7-Appendix C. If you say this 
is not correct, then appendix C needs to be fixed :-).

> or discard changes___, as illustrated by the following sequence.

Sounds good.

>> only registers one. Either another URI is missing or this text needs 
>> to be changed.
> This document registers one capability identifier URN from the NETCONF 
> Capability URNs registry, and one URI for the NETCONF XML namespace in the

Sounds good.

Thanks
Suresh