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