![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi Balazs,
I reviewed the draft "Partial Lock RPC for NETCONF".
Please find my comments below.
General comments:
- The document looks good. Do you think we should bring it with
an updated version to WGLC after the IETF meeting?
- Are we going to register the XML Schema at IANA as we did for
RFC 5277? In any case I would suggest to have the Schema as
self-explaining.
Comments per chapter:
2.1. Overview
- "The system MUST ensure . . ."
I don't know how to ensure this if it is a non-NETCONF management system.
The statement sounds like a normative statement but it does not cover
any standard-relevant definition. It is actually a generic statement and
I would suggest to find another formulation than "MUST".
- I would split the 3rd paragraph into two sentences for more clarity:
"The duration of the partial lock is defined as beginning when the
partial lock is granted. The partial lock lasts until either the corresponding
<partial-unlock> operation succeeds or the NETCONF session terminates."
2.2. Dependencies
s/in Section 2.4.1/in Section 2.4.1./
2.4.1. <partial-lock>
- I would indicate the beginning of the description part of the <partial-lock>
operation with: <Description:>
- I would suggest to indicate that the the "portion of the data store" is a
"coherent set of nodes".
- 6th paragraph: "If a top level node of a locked subtree is deleted, . . ."
Why is it necessary to keep the lock with a "nil scope" present?
I would expect that a lock with a nil scope is not needed and should not
be kept.
- s/A partial lock MUST fail/A partial lock operation MUST fail/
- 2nd bullet: " o Any part of the scope to be locked is already locked . . ."
I think we should have a note here to explain why we think that a partial
lock can be also introduced by a non-NETCONF management system and
how this could be realized.
I agree with an earlier comment that Netconf locking (both global and partial)
is creating new requirements for SNMP and other protocols. I would propose
to explain the impact on other management protocols in this note.
- s/If the select expressions return/If the select _expression_ returns/
2.5. Modifications to Existing Operations
I would reorganize the first sentence for more clarity, e.g.:
"A granted partial-lock will cause operations to fail, if it wants to modify
the already locked area and is executed in a NETCONF session other
than the one that owns the lock."
3. Security Considerations
Do the two sub-paragraphs below belong into the security considerations
or should they be put to the end of the paragraph 2.4.2. <partial-unlock>?
They have at least to do with releasing of locks.
"The partial-lock is automatically released when . . .
The <kill-session> operation allows terminating other users . . ."
5. Appendix A - XML Schema for Partial Locking (normative)
Please add the element descriptions in the YANG module also into the XML
Schema as documentation to get it self-explaining.
Cheers,
Mehmet
_______________________________________________ Netconf mailing list Netconf at ietf.org https://www.ietf.org/mailman/listinfo/netconf