[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: review of partial-lock-01
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 netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>