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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Jun 2009 09:56:43 +0200

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, June 24, 2009 1:03 AM
To: General Area Review Team;
[email-masked]
Subject: Gen-ART review of draft-ietf-netconf-partial-lock-08.txt

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 13:54:58 +0200

fyi

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