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

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

fyi

Suresh Krishnan wrote:
> 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?

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.

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

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.

> * 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.
(AFAIK an URN is an URI as well.)
> - 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.
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.

> Thanks
> Suresh

--
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel at ericsson.com