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 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.
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
not mentioned.
I got this <users> straight from Section 7-Appendix C. If you say this
is not correct, then appendix C needs to be fixed :-).
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.
Sounds good.
* 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.
Sounds good.
Thanks
Suresh
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
