[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to PROT I-D Issues List
Hi,
The attached list contains the previous issues list with my suggested resolutions.
Since the WG has not commented on this list, there seems little consensus
to make many requested changed.
The status values are:
** CLOSED ** - change not accepted or no concrete change requested
** CLOSED ** CHANGE REQUIRED ** - all or part of change accepted;
change considered a clarification
** OPEN ** - no resolution yet
Please review this list and send comments to the WG mailing list ASAP.
The editor needs to finalize the changes for the -05 version before
the ID cutoff.
thanks,
Andy
I001)
Locking) 4 emails supporting requirement to allow get and get-config
even if the confitg is locked.
** CLOSED **
No Change; lock does not prevent reads. An app should
lock the dB even for reading if concerned it may change during the
read transactions.
--------------------------
I002)
Session ID) How is this conveyed to the client?
** OPEN **
Doesn't seem to be a mechanism for an app to know its
own session ID.
--------------------------
I003)
1.1: "MUST support at least one, and MAY support more than one." For
security I'd really rather see the MAY be a SHOULD in that sentence.
** CLOSED ** CHANGE REQUIRED **
Change MAY to SHOULD in PROT:sec1.1:p2:s2
--------------------------
I004)
4.5: pipelining: "<rpc> request are processed serially" This should
be a MUST. Doing otherwise leads to indeterminate results.
** CLOSED ** CHANGE REQUIRED **
Clarification/consistency
Change PROT:sec4.5:p1:s1
OLD:
NETCONF <rpc> requests are processed serially by the managed device.
NEW:
NETCONF <rpc> requests MUST be processed serially by the managed device.
---------------------------
I005)
section 6: I don't think this section is ready to go to the IESG yet.
It needs more review and editing.
** CLOSED **
Consider adding some examples in sec 6.2 - 6.7.
Hard to go back and forth between 6.8 and rest of section.
---------------------------
I006)
section 6: I have a few concerns about the filtering as defined.
1) I find it confusing that there is a subtle difference between
selection of a particular set of values vs selecting a particular
value. The difference between:
<user>
<name/>
<user>
and
<user>
<name>John</name>
<user>
Is very very subtle. Definable, certainly, but subtle as well.
This means people will get it wrong and get confused (especially
for more complex examples).
** CLOSED **
No change;
This is explained in the text and examples
(6.6 selection nodes and 6.5 content match nodes)
2) I don't think it's possible using the current filter system to
select empty values. IE, this:
<user>
<name><name/>
<user>
Will select all user's names, not a user with a blank name.
(please don't tell me you're going to distinguish between <name/>
and <name></name>)
** CLOSED ** CHANGE REQUIRED **
Need to add clarification to sec6.1 that explicit selection of
empty content (in a content match node) is not supported.
(Should not count on XML parser distinguishing between long
and short form of an empty node).
3) logical and vs logical or in selections
In the document this example:
<user>
<name>root</name>
<company-info/>
</user>
<user>
<name>fred</name>
<company-info>
<id/>
</company-info>
</user>
<user>
<name>barney</name>
<type>superuser</type>
<company-info>
<dept/>
</company-info>
</user>
Indicates that there is an implicit logical OR between the
<user> tags and an implicit logical AND between the sub-tags
(name/type in the third user selection).
This is, again, subtle and subject to poor understanding by
users which will lead to errors.
One solution to some of these problems would be to separate the
selected nodes from the value matched nodes using different
groups. Or add an attribute or something. Anything that makes it
more obvious what is going on and is desired.
** CLOSED **
No change; Sections 6.1 - 6.7 document the rules for sub-tree
filter processing. The example above isn't confusing. It is
clear from the processing rules and the example that each
top-level sub-tree processed will yield its own results (e.g.,
OR expression).
-----------------------
I007)
7.2: default-operation: none... "as well allowing a simple existence
test for configuration data". This statement should be stricken,
IMHO. If you want an existence test, you should write one into
the protocol (get-config will do this now). I don't think you
should cobble in a feature this way. It may be that it exists
and can be used this way, but I don't think documenting it this
way so it becomes officially supported practice is wise.
** CLOSED ** CHANGE REQUIRED **
PROT:sec7.2:Parameters:default-operation:none
OLD:
Using "none" allows operations like "delete" to avoid
unintentionally creating the parent hierarchy of the element
to be deleted, as well allowing a simple existence test for
configuration data.
NEW:
Using "none" allows operations like "delete" to avoid
unintentionally creating the parent hierarchy of the element
to be deleted.
-------------------------
I008)
7.2 and others: Is it legal to specify config for non-existent
devices. IE, can I upload a config for a interface which I
haven't physically inserted yet? Or is this going to be
implementation specific? It should be at least mentioned one way
or another.
** CLOSED **
Data modeling issue
Not NETCONF protocol issue to distinguish between config and
pre-provisioning high-level operations
--------------------------
I009)
7.2: I fail to see how these operations are going to work in some
cases which I'm sure will come up in the future. I'm going to use the
examples enclosed in the section, but I don't think they're
necessarily the right ones to use. But you'll get the idea.
The problem comes from the assumption of the data model that I'm not
convinced will be true. Take the case of messing with an interface.
The examples all show various operations working on an interface named
"Ethernet0/0", and only in the sentences above is it sort-of-mentioned
in English text that the index when searching for things to modify are
going to be based on the name. There is no mention of this actually
in the protocol. Sure, in this particular case it is likely this may
be the only selectable method in the resulting data model and that is
yet to be determined and out of scope. However, I think it is highly
likely that we will end up with a data model(s) that will allow for
separate indexes. So, for the purposes of example, lets say that you
could select an interface by address as well (very conceivable). Is
this legal for a replace:
<top xmlns="http://example.com/schema/1.2/config";>
<interface xc:operation="replace">
<mtu>1500</mtu>
<address>
<name>1.2.3.4</name>
</address>
</interface>
</top>
Would that allow you to replace the MTU just as you would if you
specified the name? Or are you going to restrict data models in the
future to only one set of unique indexes? Can I set the MTU of all
interfaces which are up using something like:
<top xmlns="http://example.com/schema/1.2/config";>
<interface xc:operation="replace">
<status>up</status>
<mtu>1500</mtu>
</interface>
</top>
This is a solvable problem, obviously. My only concern is that no
where is this type of usage of the protocol discussed. It does have
implications on the resulting data models that are allowed to be
defined.
Fundamentally, this results from data to change and selectors being
intermixed, which technically I think is a mistake (they should be
marked by attributes or in a special section of the tree. I'm sure
that concept will die a horrible death and I'll get flamed for
mentioning it. So, let me just end by repeating: it needs
discussion regardless if you don't want to explicitly talk about how
to select particular values.
** CLOSED **
No change;
Data modeling issue
No specific changes requested
--------------------
I010)
7.2 replace: what happens if you replace a container with a set of
elements (say A, B, and C) but the original object also contained
a D element. Does the new one get D as well, or is that nuked (I
think is the case) if operation=replace is put on the high level
object (as opposed to each element for A B and C).
** CLOSED **
D would get nuked because that's the operation that was requested,
or the operation will fail because D was required but not specified.
--------------------
I011)
7.3 copy from remote to remote is a "may choose not to support". I
think this is fundamentally a bad thing to ever allow. netconf
should not be a file transfer protocol. The security issues
surrounding such a notion haven't been discussed. You can't
easily specify access control rights for when you're allowed to do
so. It essentially lets any firewall implementing netconf (that
implements URL to URL copying and has access to both an internal
and external network) to be used as a transfer hole in a security
domain. I really think you should say that implementations MUST
NOT support this. It is well beyond the scope of what netconf
should do. It is highly suspect from a security point of view and
will only add more work in the future as you'll have to write
access control rights for when this is acceptable and when it is
not and by what users.
** CLOSED **
No change;
Not a shared concern; WG would rather add usage restrictions
later, and only if operational experience shows this is warranted.
--------------------
I012)
7.3 example shows the use of ftp. Can we use something more secure in
the example please?
** CLOSED **
No change; no suggested replacement text provided
--------------------
I013)
7.4: #url allows a url to appear as a delete. doing remote file
management using netconf is questionable at best. From a security
point of view, it makes me cringe.
** CLOSED **
No change; no suggested replacement text provided
--------------------
I014)
8.8.5.1: so with #url capability supporting ftp I can force a netconf
client to remote edit files? Is this really wise?
** CLOSED **
No change; no suggested replacement text provided
--------------------
I015)
url summary: there are two types of urls: local and remote. Some
operations make sense for some of those, some for others. Some
operations, IMHO, should not be allowed on remote types.
** CLOSED **
No change; no suggested replacement text provided
--------------------
I016)
9: Implementators SHOULD also provide a well thought out authorization
scheme with NETCONF. => MUST
** CLOSED **
No change; no WG consensus for this change; subjective what "well
thought out" means; consider removing this phrase.
--------------------
I017)
9: you need to discuss that global operations MUST disallow the
changing of information that an individual does not have authorization
to perform. EG, if a user U is not allowed to configure an IP address
on an interface but someone else has configured an IP address for an
interface within the <candidate>, then the user U must not be allowed
to perform a copy-config or commit from <candidate> to <running>.
** CLOSED ** CHANGE REQUIRED **
Add a paragraph at the end of PROT:sec9 based on this suggested text.
--------------------
I018)
9: Similarly, you need to discuss what happens if you don't use a
lock. Specifically, if user U1 modifies the candidate config in a way
that user U2 is not allowed to, and since U1 MUST NOT be able to
commit those changes then not using a lock could leave a system in a
state where neither U1 nor U2 can commit their changes to running.
** CLOSED **
No change; U1 cannot be aware of U2 (Un) and it is up to the agent
to check access control during the <commit> and disallow unauthorized
changes. There is already text that if locks are not implemented
correctly then improper results may occur.
--------------------
I019) Commit operation atomicity
[PROT, missing section number]
Proposed change:
If the device is unable to commit all of the changes in the candidate
configuration datastore, then the running configuration must
remain unchanged.
Response:
Capital "'MUST' remain unchanged" and I'm happy with the wording.
** CLOSED ** CHANGE REQUIRED **
Edit accepted
--------------------
I020)
d) The description of the error-info states that vendor specific
elements may only be added at the end of the sequence. I do not
really see the need for this rule since namespaces should be used
anyway. I would prefer to not introduce such rules, the
specification should instead spell out that any
extensions/additions must have their own namespace.
** CLOSED ** CHANGE REQUIRED **
Edit accepted; CLR should be removed
--------------------
I021)
g) I had some trouble to figure out what RPC responses can
contain. Section 4.4 says that an <ok> element is sent in
<rpc-reply> messages if no error occurred. Looking at the examples
shown later on, it looks like <ok> is only present if the RPC
was successful and no other result data was returned. I am not
sure why this <ok> is needed at all.
Things get a bit more irritating if I look at the <rpc-error>
elements. Such an element is used to signal an error or a warning.
This raises the question whether a warning can be returned even
though the RPC succeeds. Will I then get <ok> or <something>
followed by an <rpc-error> signalling a warning? Or will the
warning come first? If the RPC does not abort on error, I would
suggest that I can get multiple errors. But this does not seem to
be the case (according to the NETCONF RelaxNG spec.) The RelaxNG
spec (did not check the xsd) requires the element to be <data>
while section 4.2 shows an example which shows <some-content>.
If the idea is indeed that RPC results always show up in a <data>
element, then why not replace <ok> with an empty <data/> element?
I recall some discussion that errors/warnings may actually be
generated while an operation is processed and that they were even
supposed at some point to interleave the data portion. So I assume
there is something missing here. Perhaps the examples used later in
the document focus too much on the no error cases.
** CLOSED **
No change; Not all operations have a <data> element (e.g., <lock>)
--------------------
I022)
r) Section 7.1 IMHO misses text which explain how overlapping operation
attributes are handled. What for example happens if I have:
<... operation="delete">
<... operation="merge"/>
</...>
There might be more interesting combinations. I would prefer to
have well defined rules so that all implementors do the same thing
here. If there are nested operation attribute value combinations
that do not make sense, I think it would be fair to request that
such things are checked before starting the execution of the merge.
** CLOSED **
No change; This depends on the data model and common sense.
We don't need CLRs that say the agent MUST or MUST NOT merge
sub-tree X before deleting it and its parent in the same <edit-config>.
--------------------
I023)
t) After reading the <edit-config> part of the spec, I felt that there
is in general a need to have more elements of the procedure spelled
out. I think it would help implementors tremendously if it were
spelled out which tests have to be performed, what the error codes
are that can be generated and so on. At the moment, the document
leaves it to the implementor to figure out what needs to be
checked, in which order, before are while processing an edit-config
and so on. I believe it would help interoperability if some more
guidance would be given here.
** CLOSED **
No change; Could be a companion document after some implementation
experience gained.
--------------------
I024)
E) Section 8.8.3 says shows the following urn format:
urn:ietf:params:xml:ns:netconf:base:1.0#url?protocol={protocol-name,...}
It is unclear what are meta characters here. I guess '{' and '}' are
meta characters if I look at the subsequent examples. Anyway, the
more general comment here is that you identity URI schemes and not
protocols. So perhaps the example should be:
urn:ietf:params:xml:ns:netconf:base:1.0#url?schemes=http,ftp,file
Perhaps life would be even easier if the schemes were announce as
separate capabilities:
urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=http
urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=ftp
urn:ietf:params:xml:ns:netconf:base:1.0#url?scheme=file
Perhaps a general discussion how to deal with parameters in
capabilties would be useful. The later version has the advantage
that I do not have to parse the full scheme to check whether the
'file' scheme is supported - a simle string match is good enough.
(But parsing this on the other hand does not seem overly complex
either).
** CLOSED **
No change; No consensus to change the #url capability syntax