[Netconf] FW: Gen-ART review of draft-ietf-netconf-partial-lock-08.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 

-----Original Message-----
From: Suresh Krishnan [mailto:suresh.krishnan at ericsson.com] 
Sent: Wednesday, June 24, 2009 1:03 AM
To: General Area Review Team;
draft-ietf-netconf-partial-lock.all at tools.ietf.org
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






Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.