[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
End WG Last Call: draft-ietf-netconf-prot-04.txt
Hi,
The first WG Last Call for the NETCONF Configuration Protocol
document is now concluded. I'd like to thank the numerous WG
members who reviewed the document and sent comments to the mailing
list. The WGLC for the application mappings documents will
remain open a bit longer since they have not been widely reviewed
yet.
A number of issues and clarifications were raised during the
review period. The following lists identify these issues (Innn)
and clarifications (Cnnn) for further comment. The WG must
now resolve any remaining issues on the WG mailing list, so
an updated draft can be finished ASAP. [ed. - The lists have
not been scrubbed or entered into an issue tracking system yet.]
Please send separate emails for each issue, and use the
issue (or clarification) ID number in the subject line.
thanks,
Andy
I001)
Locking) 4 emails supporting requirement to allow get and get-config
even if the confitg is locked.
--------------------------
I002)
Session ID) How is this conveyed to the client?
--------------------------
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.
--------------------------
I004)
4.5: pipelining: "<rpc> request are processed serially" This should
be a MUST. Doing otherwise leads to indeterminate results.
---------------------------
I005)
section 6: I don't think this section is ready to go to the IESG yet.
It needs more review and editing.
---------------------------
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).
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>)
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.
-----------------------
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.
-------------------------
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.
--------------------------
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.
--------------------
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).
--------------------
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.
--------------------
I012)
7.3 example shows the use of ftp. Can we use something more secure in
the example please?
--------------------
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.
--------------------
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?
--------------------
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.
--------------------
I016)
9: Implementators SHOULD also provide a well thought out authorization
scheme with NETCONF. => MUST
--------------------
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>.
--------------------
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.
--------------------
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.
--------------------
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.
--------------------
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.
--------------------
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.
--------------------
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.
--------------------
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).
-----------------------
C001)
BEEP, sec. 2.5 BEEP Profile for NETCONF
There are three commands in the BEEP profile. <rpc> and <rpc-reply>.
s/three/two
--------------------------
C002)
PROT, new sec.
add deferred features list appendix
-----------------------------
C003)
PROT, remove sec.
remove the netconf-state data model and all references to it
---------------------------
C004)
PROT, sec. 9
9. Security Considerations
This standard does not specify an authorization scheme, as such a
I think it is better to say
This document does not specify ....
---------------------------
C005)
1.1: "during any session" -> "during any authorized session"
---------------------------
C006)
1.1: "Session specific attributes affect only the session in which they
are changed."
It'll likely be possible to change attributes of a "target"
session? (kill-session is almost changing attributes, but I could
see other more true changes being allowed in the future).
---------------------------
C007)
1.1: for the application stack diagram, it'd be helpful if you added
the stack numbers in the left hand box to match the numbers
below. The first time I looked at it, it took a sec to realize
the numbered list below was counting bottom up.
---------------------------
C008)
1.2: "These capabilities must" -> MUST? (actually this sentence is
somewhat redundant with the first, but I'm not complaining)
---------------------------
C009)
1.2: "The capability URI" -> "A capability URI"
---------------------------
C010)
1.3: The document in general discusses configuration and state.
Discussions within the IETF in the last number of years has included
"control" objects as well. I'd at least mention them, even if you are
either excluding them or lumping them in to the other category.
---------------------------
C011)
1.3: "file would be too large" -> remove "too". subjective. Maybe
"unnecessarily" would be a better choice.
---------------------------
C012)
1.3: "Note that the NETCONF protocol is concerned only with information
required to get the system software into its desired running state."
This is not true. state information retrieval has already been
defined (and even contracts earlier sentences about "state").
---------------------------
C013)
1.3: "If a local database of user authentication..." I'd say this
sentence is beyond scope of the document. You're talking about the
data model here.
---------------------------
C014)
2.1: last p: reference the future "lock" section near the lock word.
---------------------------
C015)
2.2: Security and Privacy is an indeterminate title. How about
"Security, Authentication and Integrity" instead?
---------------------------
C016)
2.3: Authentication: "...entity can be trusted." -> "identity has been
sufficiently proven". Trust is not implied at all by merely
authentication.
---------------------------
C017)
2.3: "should use RADIUS" -> "should allow the use of RADIUS"
---------------------------
C018)
2.3: "whose permissions and capabilities are know" -> "whose
permissions are known". Authentication has nothing to do with
capability negotiation. I actually think better wording could be used
in this paragraph in general. Something that says based on the
authentication it should be possible to determine the authorization
level of the incoming session (it's 5:30AM. I can't think of better
wording at the moment)
---------------------------
C019)
somewhere: A brief intro on http vs urn's in the xmlns tags should be
mentioned somewhere so the reader understands why one is used in some
places and not in others.
---------------------------
C020)
4.1, last example: "example.net/house" -> "example.net/world"
---------------------------
C021)
4.3 "The <rpc-error> includes" should this be a MUST?
---------------------------
C022)
4.3 error-tag: ... See list below for allowed values -> see appendix A
---------------------------
C023)
4.3: error-message: "the error condition." -> "the error condition
intended for human consumption." (IE, don't expect it to be machine
parsible).
---------------------------
C024)
4.3: error-info: the list below -> the list in appendex A
---------------------------
C025)
5.1: I'd be tempted to say that though some netconf operations work on
things like state, they're not considered to be part of the
configuration datastore
---------------------------
C026)
5.1: Section 8.3 and Section 8.7 -> "Capability sections 8.3 and 8.7"
for clarity.
---------------------------
C027)
6.1-6.3: various parts of 6.2 and 6.3 are very redundant with 6.1.
EG: last P in 6.2 is same as 4th in 6.1, 6.3 is the 5th P in 6.1...
Most of the text could use a bit of clean-up. It doesn't read as well
as the rest of the document (which is very well written, so my
expectations have come to be a bit high at this point).
---------------------------
C028)
6 general: A diagram to help match terminology against parameters
would be helpful up front. By the end of the section, my head was
spinning with all the terms regarding matching nodes vs leaves vs ....
---------------------------
C029)
6.1 last p: "or modified or acted upon?" somewhere for operations that
don't just "select"?
---------------------------
C030)
6.5: "the only the content match nodes, plus"... remove "only"
---------------------------
C031)
6.6: This section probably needs to be rewritten. I could barely grok
it after staring at it for a while.
---------------------------
C032)
6.7: agent -> server. (I don't think the rest of the doc talks about
"agent"s much. I may be wrong).
---------------------------
C033)
6.8.2: type=subtree should be mentioned above somewhere first ideally
(I know it's mentioned later)
---------------------------
C034)
6.8.3: The <top> node used in the examples worries me. Is each
standard/company going to define its own "top"?
---------------------------
C035)
6.8.6: siibling -> sibling
---------------------------
C036)
6.8.8: schema/2.0 -> schema/1.2
---------------------------
C037)
6.8.8: "same results" -> "similar results". The results won't be
exactly identical, right?
---------------------------
C038)
7: move the "get" operation up the list under the "get-config"
operation for better grouping.
---------------------------
C039)
7: is "operation not supported" allowed even for the netconf core
operations? I'm not sure there is requirements anywhere (MUST/SHOULD)
for the operational sets that are required to be implemented (simply
defining them doesn't state requirement for implementing them).
---------------------------
C040)
7.1: get-config requires? the source parameter. If so, many of the
(previous, eg) examples don't contain it.
---------------------------
C041)
7.1: positive response: says element returned is contained within
<config> but many of the examples fail to meet this (frequently they
use "data" including in the example in this section!)
---------------------------
C042)
7.2: "The target configuration is not simply" -> "... not necessarily simply"
---------------------------
C043)
7.2: should probably mention that the operation tag is allowed to be
used repeatedly in the tree? It's only sort "sort of" obvious.
---------------------------
C044)
7.2 replace/create: It would be useful to explicitly talk about how
"containers" (eg users) vs "objects" (a user) is treated with
this. IE, if operation=replace is specified at the users level,
then *all* the users are replaced. If specified at the user
level, then just a single user is replaced. This is important for
the reader to understand.
---------------------------
C045)
7 general: it would be useful if potential error codes were specified in
the operation lists... Right now its sort of open in many places.
---------------------------
C046)
7.2 delete: what happens if you do this:
<users>
<user>
<name operation="delete">Fred</name>
</user>
</users>
That'll just delete the name, technically, not the user. Is that
legal? This is where a protocol without a data-model usage case
runs into problems. The concept of containers is important when
talking about operations that affect instances of those containers.
---------------------------
C047)
7.2 replace: Can I do a name change on the search index? IE, if the
interface name is configurable can I change it? There is no
operation to support this thus I must do a delete and create (or
equivelent), right?
---------------------------
C048)
7.2 delete: can I delete all interfaces with MTU of 1500? Does
multiple matches in a data model that may not have defined MTU as
a unique index allowed within the protocol?
---------------------------
C049)
7.2 "Delete the interface" -> "Delete the configuration for the interface".
---------------------------
C050)
7.3 "Otherwise, a new one is created" -> "Otherwise, a new one is
created if allowed."
---------------------------
C051)
7.3 "A device may choose not to support remote to remote copy
operations" -> add "(URL to URL)". (though see my other message
on the concern with this first).
---------------------------
C052)
7.5 "human users" -> "console users"
---------------------------
C053)
7.5: delete "lack of network connectivity". Let the transport deal
with that. If the transport looses it, thats a valid signal. I don't
think netconf should be directly tied to a lower level than the
transport.
---------------------------
C054)
7.5: "If the lock is already held, the <error-tag> element will be
LOCK_DENIED": It'd be better to distinguish between denied due
to access not allowed vs denied vs in-use by someone else.
---------------------------
C055)
7.5: most of the other examples have wording separation between them.
This section doesn't so I'd recommend adding "Example showing an
error when a lock is already in use:" in between the two examples
for better readability.
---------------------------
C056)
7.7: examples don't contain the <top> node that others do. This is
inconsistent throughout the doc. I just wrote it down here.
---------------------------
C057)
7.8: need to mention that replies to previous queries are still sent.
(processing is mentioned, but not the replies to those operations)
---------------------------
C058)
8: "... standards bodies or published as proprietary by vendors" ->
add "etc, ..." or something at the end. Current wording is too
limiting to the types of organizations that are likely to publish
specs.
---------------------------
C059)
8: it is not clear from the sentences why you specified two urns (one
with an embedded xml:ns tag and one without).
---------------------------
C060)
8: "each peer needs to understand only those capabilities that it
might use..." This is not entirely true for #validate. It affects
the results of the on-error parameter if available. In some cases
you'll potentially get errors back and in others not. Sort of
requires that you understand if the capability is there so you can
prepare for or expect errors back. Not sure you want to change
anything though.
---------------------------
C061)
8.3.1: "creating a manipulating" -> creating and manipulating
---------------------------
C062)
8.3.1: I'd use a specific example operation in the example for
"operation" rather than the generic term. It doesn't match the rest
of the examples in the document by making it generic.
---------------------------
C063)
8.3.1: for example, through another capability: Add "EG, lock")
---------------------------
C064)
8.3.4.1: why doesn't the text refer to "<running>" here? A commit is
really a copy-config from <candidate> to <running> even if
#writable-running isn't available and thus I'd make that statement so
the understanding is clear.
---------------------------
C065)
8.3.4.2: I'd state that discard-changes is essentially a copy from
running to candidate.
---------------------------
C066)
8.4.5.1: confirmed-timeout: please please please at least use seconds
rather than minutes here. You're making an assumption about
operational environments. seconds allows for rapid decisions, but
still allows for longer time periods as well (2^32 seconds is a long
time).
---------------------------
C067)
8.5.1: "to be inadvertently altered or removed": This isn't true is
it? Isn't the roll back only applied to the current operation? IE, a
single edit-config in which case it is only rolled back to the start
of the edit-config and has nothing to do with what other people have
done either before or after the current operation?
---------------------------
C068)
8.6.1: "at least for syntax errors". So the exact operation results
are indeterminate? Some devices do something things with this
capability and others do others.
---------------------------
C069)
8.7.1: if startup == running in the rest of the document without this
capability, it should probably be mentioned before this point when
first discussing running.
---------------------------
C070)
8.9.5.1: example needs top too?
---------------------------
C071)
7.7: get should explicitly specify that it only works on running?
---------------------------
C072)
7.5: second bullet: committed -> committed or rolled back
---------------------------
C073)
1. The Abstract section includes acronyms that would better be
expanded (XML, RPC)
---------------------------
C074)
2. Section 1.3 - ' Note that the NETCONF protocol is concerned
only with information required to get the system software into
its desired running state.' Isn't this too limiting?
Are other aspects of device configuration really excluded, or
should we rather say
' Note that the NETCONF protocol is concerned only with information
required to get the device behavior into its desired state (for
example getting the system software into its desired running state).'?
Response:
What about changing "system software" to "device" in this sentence
(I agree with you but want a shorter sentence):
Note that the NETCONF protocol is concerned only with information
required to get the device into its desired running state.
---------------------------
C075)
3. No DTDs - The introduction says 'The contents of both the request
and the response are fully described in XML DTDs or XML schemas,
or both, allowing both parties to recognize the syntax constraints
imposed on the exchange. while secttion 3.2 dully specifies that '
Document type declarations (DTDs) are not permitted to appear in
NETCONF content.' Is not this a contradiction?
Response:
The "No DTDs" restriction means that DTDs are not allowed to
be embedded directly inside NETCONF content. Embedded DTDs are
an official feature of XML that nobody seems to use these days,
as they are awkward and not useful or desirable in NETCONF (we
don't want to require a NETCONF entity to be able to parse DTDs,
for one thing).
The use of DTDs themselves to describe XML content that could
be used with NETCONF is fine.
---------------------------
C076)
4. Section 7.5 - what is an 'Expect script'?
From http://expect.nist.gov/ -
"Expect is a tool for automating interactive applications such as
telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really makes
this stuff trivial. Expect is also useful for testing these same
applications. [...]"
Proposed terminology change: Expect scripts -> CLI scripts
---------------------------
C077)
5. Section 9, second paragraph - what means 'unbnownest'?
This appears to be a misspelling of the word "unbeknownst",
a dictionary entry for which appears below.
---------------------------
C078)
a) The introduction makes the promise that "applications can access
both the syntactic and semantic content of the device's native user
interface" via NETCONF. I think this promise is a bit too strong.
---------------------------
C079)
b) I never liked the replacement of "transport protocol" with
"application protocol" - I think the later term is even more
confusing as the original term "transport protocol". Note that I
found a few places where the document still refers to the
"transport" (just search for it). (Transport is used in the error
reporting mechanism, see the ErrorType definition. Replacing
transport here with application would clearly cause confusion.)
As said above, I prefer the reintroduction of the term "transport"
or even "NETCONF transport" with an explanation in section 1 that
transport in this document refers to the NETCONF transport, which
is not the same as a transport layer protocol.
---------------------------
C080)
c) Section 4.3, error-tag description should refer to appendix A as
follows:
error-tag: String identifying the error condition. See Appendix A
for allowed values.
---------------------------
C081)
e) I prefer "implementor" over "vendor", "implementation-specific"
over "vendor-specific" and so on. This affects several places (just
search for vendor).
---------------------------
C082)
f) Is there any reason why error tags are ALL_CAPS and use underscores
while the other XML elements all use hyphens and lowercase?
---------------------------
C083)
h) page 15: replace "an XSD" with "a schema".
---------------------------
C084)
i) page 17: "...containment nodes the element hierarchy..." ->
"...containment nodes of the element hierarchy..."
---------------------------
C085)
j) page 18: "...get request..." -> "...get operation..."
---------------------------
C086)
k) page 19: "...the filter This..." -> "...the filter. This..."
---------------------------
C087)
l) page 22: "...siibling..." -> "...sibling..."
---------------------------
C088)
m) The title of section 6.8.8 should be changed to "Elements with
attribute naming" or something similar since NETCONF does not deal
with tables.
---------------------------
C089)
n) The first paragraph in section 6.8.8 refers to 'schema/2.0' while
the example uses 'schema/1.2'.
---------------------------
C090)
o) Section 7.1 says under "Positive Response" that the reply contains
a <config> element which I think must be a <data> element.
---------------------------
C091)
p) The description of test-option in section 7.2 says it can take two
values while the xsd says it can take three values.
---------------------------
C092)
q) Section 7.1 on page describes rollback-on-error which is however not
mentioned in the xsd.
---------------------------
C093)
s) Example on page 32: I suggest to replace <mask>255.0.0.0</mask>
with <prefix>24</prefix> as this seems to be the more general
concept.
---------------------------
C094)
u) Section 7.3 says: "The source and target parameters cannot identify
the same URL or configuration datastore." Why not say which error
code is being returned in this case and that it when this must be
checked? [This is kind of an example for comment t) shown above.]
---------------------------
C095)
v) page 36: "...Expect scripts..." -> "...CLI scripts..."
---------------------------
C096)
w) Section 7.5, star bullet two on page 37: Does this only apply if
the commit capability is present?
---------------------------
C097)
x) There are several XML lines which exceed the allowed column number
are require some re-formatting.
---------------------------
C098)
y) Section 7.7 refers to configuration and state data without saying
which configuration source is meant here. I assume it is the
<running> configuration data set. Perhaps this should be made clear
somewhere.
---------------------------
C099)
y) Section 7.9 refers to a 'Bad Value' error, which does not seem to
exist.
---------------------------
C100)
z) page 44: "...proprietary vendors." -> "...proprietary extensions."
---------------------------
C101)
A) Section 8.3.4.1: I assume it copies to <running> - perhaps this
should be spelled out.
---------------------------
C102)
B) I was wondering what the difference is between the #candidate and
just a named file://candidate scratch buffer, e.g.
lock running
lock file://candidate
copy running file://candidate
edit file://candidate ...
copy file://candidate running
unlock file://candidate
unlock running
Perhaps it is the locking? In the example in Appendix D, only the
<running> is locked - does that imply a lock on candidate as well
as it is somehow magically tied to <running>? (And is it magically
tied to <running>?)
Some more explanation might be worthwhile (perhaps in the
appendix). I would find it useful to know whether there are any
real differences here. If there are no real differences, why do we
have two different ways to achieve the same thing?
---------------------------
C103)
C) Section 8.4.5.1 talks about "a confirming commit" without really
saying what that is. I think the example should be extended to show
a confirming commit. (Right now, one has to look into the appendix
where you can find an example. It looks like the confirming commit
is a plain commit without the <commit> element. This raises the
question if it is possible to extend a confirmed commit by just
sending another confirmed commit before the timer goes off.
---------------------------
C104)
D) Section 8.6.4.1 uses the <candidate> datastore to illustrate the
<validate> operation. Since <candidate> is an optional feature,
would it not make more sense to choose a data store that is always
present? Or does #validate not make sense if there is no #startup,
no #candidate and no #url capability?
---------------------------
C105)
F) page 56: "...SHOULD also provide..." -> "...SHOULD provide..."
---------------------------
C106)
G) page 56: "...incompatable." -> "...incompatible."
---------------------------
C107)
H) page 57: "...person in the middle..." -> "...eavesdropping..."
(I don't think you have to be in the middle of the communication
to simply listed to the conversation.)
---------------------------
C108)
I) Section 10 needs to spell out the registration rules for the urn
namespace that netconf is using I think.
---------------------------
C109)
J) Reference [4] is not cited so it can't be normative.
---------------------------
C110)
K) References [9], [10] and [11] are not cited.
---------------------------
C111)
L) Appendix D assumes that either #candidate or #url?scheme=file is
present. Does it meant without these capabilities, you are
seriously restricted in the sense that you can't have a robust
scheme to configure multiple devices? If yes, this probably needs
to be spelled out somewhere clearly so that implementors understand
which capabilities are important and for what reason.
---------------------------
C112)
M) page 72: incomplete sentence "...unrelated changes while."
---------------------------
C113)
N) page 77: "...the first class of allows..." -> "...the first class
allows..."