Subject: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Mon, 21 Jul 2008 10:17:46 +0200

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
<http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02#section-2
.4.1> /in Section 2.4.1
<http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02#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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf