Subject: Re: review of partial-lock-01

From: Balazs Lengyel <[email-masked]>
Date: Tue, 04 Mar 2008 09:34:28 +0100

Hello Dave,
Thanks for your comments. I answered a number of them. I will continue later.
Balazs

David Harrington wrote:
> Hi,
> 
> section 2.1. 
> paragraph 2 - I think this should start "The system MUST ensure". You
> will have interoperability problems if everybody doesn't follow the
> same rules on this.
OK wording will be changed
> 
> paragraph 4 - "one or more datastores" This is the first mention of
> multiple datastores in this document, and I think it would be good to
> make sure readers know you are referring to running, startup,
> candidate, etc. I can think of other types of datastores, such as the
> datastores for blade 1 and for blade 2 in a chassis, and it is
> important that standards are clear and unambiguous. The global lock
> seems to only work on one target datastore per command.
OK
> 
> paragraph 4 - if the XPath will be applied to multiple datastores,
> must the datastores be in the same naming space? Can XPath span
> multiple datastores in different naming spaces?
Only one datastore can be modified with one operation. The datastore is specified with a
separate element, it is not part of the XPATH expression. I will try to clarify this better.
> 
> section 2.2 This and elsewhere in the document needs to be tightened
> by using the RFC2119 language to promote interoperability between
> multiple clients and multiple servers. "Partial locking uses only
> restricted XPath to describe the lock's scope ... [and] optionally can
> utilize any XPath ...". Well, which is the base standard that is
> mandatory to implement to claim compliance to this spec? 
OK
> 
> The support for a full XPath expression is not necessarily
> interoperable, and it should probably be moved to a different
> paragraph, identified as an optional extension   to the standard, and
> contain discussion of the problems one should expect if a client tries
> to rely on full XPath support in the servers.
I don't really understand the comment.
> 
> section 2.4.1 - the security considerations section should have
> discussion of how doing the evaluation only once can have security
> implications. I recommend that such discussion include an example of
> how a data model to configure a security protocol might be impacted
> (or not).
What issues do you have in mind?
> 
> The bullet on access rights says if the user must have "at least some
> basic access rights, e.g., read rights, ...", but later you say "when
> a partial lock is executed you get what you asked for: a set of nodes
> that are locked for writing." So shouldn't the "at least basic access
> rights" be authorization to write the data? And, again, this should
> probably be converted to RFC2119 language.
We cant assume anything about what kind of access control the device has. The only thing we can
say is that:
If there is access control, it  defines some rights; we know nothing about what kind of rights
that means. Maybe just access/no-access.
So I will rather modify the second section:
"when a partial lock is executed you get what you asked for: a set of nodes that are protected
from modification."
> 
> "There are some other issues that are intentionally not addressed for
> the sake of simplicity." Since you know some issues are not addressed,
> then some issues must have already been identified. What are those
> known issues that are not addressed?
Wrong wording. The following bullets contain the issues that were considered. It should be:
"For the sake of simplicity the following  was decided:"
(not the best wording :-) Help!
> 
> (By this time, I wish you had more subsections, so it was easier for
> me to identify where I am in the text for you.)
OK, will try to do something.
> 
> s/does not effect/does not affect/
OK
> 
> "An operator is allowed to edit the configuration both inside and
> outside the scope of a lock." Can you give an example to show why this
> is part of the proposed design?
Some people were concerned what happens if you lock e.g. the interfaces only, then you realize 
that you must edit the access control lists as well? Can you do it ? Is it not a risk to lock 
just part of the data ?
The answer is, yes you can edit outside the lock, but you should lock everything you really
need, otherwise there is a risk of inconsistency.
> 
> "   Note: The <partial-lock> operation does not modify the global
> <lock>
>    operation defined in the base NETCONF Protocol [RFC4741].  If part
> of
>    a datastore is already locked by <partial-lock>, then a global lock
>    for that datastore fails even if the global lock is attempted by
> the
>    same NETCONF session which owns the partial-lock."
> Will a global unlock command unlock one or more partial locks?
No. It is not possible to have both partial and global locks at the same time. Whichever
lock is attempted later (global or partial) will fail.
> 
> "The select expressions MUST return a node set." I suggest adding ",
> which MAY be empty."
No this should be an error, see section negative results.
> 
> s/instances.]/instances./
OK
> 
> "If any select expression returns anything but a node set, the
> <error-tag> shall be 'invalid-value'." Since it is non-compliant to
> return anything other than a node set, what makes you think the
> non-compliant implementation will return the correct error-tag?
The reason of the problem is that the  manager/client sent a non-compliant XPath, so the
netconf agent/server should still work properly.
> 
> "invalid value" is returned for both (not a node set) and (:xpath not
> supported). Shouldn't these be different error codes? The non-node-set
> is always invalid, but the lack of :xpath is not invalid.
What would you propose? We can specify an error-app-tag
"XPath does not return a nodeset"
":xpath capability not supported"
> 
> section 3 Security Considerations is inadequate. There are potential
> security vulnerabilities caused by partial locking that are not
> described in the netconf base protocol. 
What vulnerabilities are you thinking of?
> 
> To make things easier for IANA, the IANA Considerations should point
> to the existing IANA registry
> http://www.iana.org/assignments/netconf-capability-urns and how it
> should be changed rather than making them look up this information in
> the Netconf RFC. 
OK
> 
> I recommend making the Open Issues a separate section from the Change
> Log.
OK
> 
> If we do not allow lock multiple datastores in one operation, maybe we
> should recommend locking them in a particular order, which could help
> prevent deadlocks.
Good idea (although this was not done for global locking).
> 
> I recommend showing the latest changes first. That's fairly typical in
> my experience.
OK
> 
> Appendix B - I have a real issue with using a DML to define new
> operations. The IETF Management Framework has deliberate;y kept
> protocol definitions and data model definitions separate for fifteen
> years, and I don't think the Netconf WG alone can reverse that design
> decision. That level of change should be discussed before the whole
> IETF. In addition, this violates the architectural layering in the
> Netconf architecture, which separates content and RPCs (operations).
The notification draft already describes both data and operations (protocol). I think it is a
basic idea in NETCONF that some things can be changed/configured with basic get/edit-config
operations while for some we will make custom RPCs/operations/actions.
> s/modul/module/
OK
> 
> The YANG spec doesn't identify which version of YANG is used. This
> info is available in an SMIvx MIB module or an XSD schema.
In YANG version 1 is default. If anything else would be used that would be stated.
> 
> Does the revision clause refer to urn:...:partial-lock:1.0? What if
> these get out of sync? 
By definition all revision statements are valid for this module and the urn defined here, so
they can not get out of sync. However YANG versioning rules (as YANG itself are not finalized.
> 
> Appendix C.
> Should the XSD include organization amnd contact?
> It would probably be good to annotate the fact that "nc:config-name"
> provides a choice.
OK
> 
> 
> Do operators need to take the same desired configuration and have a
> version of their XML (or YANG or ...) configuration document that only
> supports the base protocol, another that supports partial locking
> without :xpath, and a third that supports :partial-locking with
> :xpath? Or should they write their configuration using conditional
> language constructs? 
No why would they? It was agreed as a DML requiremetn that the DML must support partial locking.
> 
> I can see complexity in supporting multiple versions for partial
> locking. What happens to an operator's configuration designs when
> there are a lot more capabilities, each with their own optional
> extensions or combinations of capabilities, like here? Can we reduce
> the number of options in the partial-locking proposal?
I don't see the need for multiple versions.
> 
> Operational considerations might also address how partial locking will
> affect other services in the network. Netconf locking (both global and
> partial) is creating new requirements for SNMP, CLI, and other
> protocols. The impact on other NM protocols should be documented.
Are there any new impacts compared to global-locking?
Generally the only capability needed is that all protocols must be able to refuse an operation,
however that must already be implemented as there are many other reasons to refuse an
operations: access control, unavailable system resources, etc.
IMHO how the lock and it's scope is registered internally is an implementation issue.
> 
> SNMP response times may get worse if partial locking prevents SNMP
> from performing a SET to an object. A Netconf lock might prevent an
> existing SNMP application that is used to "tweak" a system's
> configuration to maintain or improve performance or correct for a
> detected fault may not work as quickly if there are Netconf locks in
> place. in fact, an operator may not be able to fix a time-critical
> problem via SNMP or CLI. This impact should be spelled out in the
> document.
If something is locked that the SNMP application wants to change then the SNMP application will
not slow down, it will fail. And that is what we want.
It is stated that the system will prevent modification by other interfaces, protocols.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>