[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AD review for: draft-ietf-netconf-prot-07.txt
Here is my complete review comments/questions.
Looking forward to the comments from the authors
(and any other comments people may have).
Bert
AD review: draft-ietf-netconf-prot-07.txt
- I believe we discussed that netconf over ssh was going
to be mandatory to implement. But I cannot find a statement
about that. Neither in this doc, not in the protocol doc.
- on page 15, I think the rpc-reply needs a message-id.
do I understand that correctly?
- the example in 6.2.2 uses
<t:top xmlns:t="http://example.com/schema/1.2/stats";>
but then the text following that on top of page 19 says:
Only nodes in the 'http://example.com/schema/1.2/config'
which to me seems in conflict with the example,
or am I missing something?
- what is the real difference between the examples
in sections 6.2.3 and 6.2.4?
I think I understand the differences between containment
and seclection nodes, but the examples confuse me instead
of helping me, because they are exactly the same and
even the descritive text directly following each example
is exactly the same.
--- new questions
- I believe that it is probably better to use a 192.0.2.4
address (i.e. in range 192.0.2.0/24 as per RFC 3330)
in the sample on page 39 (instead of 1.2.3.4).
Part of ID-Checklist
- same for the 192.168.0.1 addresses on page 40 and 41.
please check whole doc if there are other occurences.
- on page 41 at the bottom I read:
A device may choose not to support the <running/> configuration
datastore as the <target> parameter of a <copy-config> operation.
and I wonder what you mean there. In sect 8.2, you specify that
(I guess) by default there is no write-running support and that
such is a capability. Is that what you mean with the "may choose not
to". Or do you mean that it is indeed under control of a published
capability? If the latter, pls be clearer. If the former, probably
need to be clearer too.
- page 44 talks about an RPC <kill-session> msg to break a lock.
Should you maybe add some text to say what happens to the
modifications that have been made by the owner of the lock up
to the time of when the lock gets killed/broken?
I see in section 7.9 that that any "operations in progress will
be aborted", but that does not help me understand what happens
if a set of changes were already made in earlier operations during
that session. Or am I worry-ing to much?
- not sure I understand (1st para sect 8) what "must be able to
process and ignore..." means. Maybe you can explain to me, maybe
it needs clarfication?
- When reading Sect 8.1 I think it states that a client must
also send its capabilities. But I am not sure I got that right.
Clarification might help.
- sect 8.9.5.1 example
Am I missing something? I do not understand "top" in that
example. Could be me.
- sect 10. IANA Considerations.
I see just: TBD
Well I think there are IANA considerations.
Like a description of the registries (namespaces) to
be created and to be maintained by IANA. Also rules about how
new entries/assignments can be made (see RFC2434).
Further I think that this document makes a set of registartions
and so they should be listed here for IANA as the initial set
of registrations to be administered/recorded.
- I do not understand why reference [4] is normative
The citation os from a "For example.." sentence, so that
does not sound normative to me.
- Same question as to why reference [7] has to be normative.
- I think I would change "Author's Address" into "Editor's Address"
on page 68. Specifically cause I get the impression that Rob is editor
and that there are quite a set of contributing authors, which you
have listed separately (good).
- Has the XML Schema been validated for correct SYNTAX?
Can you tell me which tool you used to do so?
typos/nits (for whenever you do a new rev)
- page 18, 1st para sect 6.2.1
s/elements to selected/elements to be selected/
- page 20, sect 6.2.5 6th bullet
s/will interpreted/will be interpreted/
- page 44 1st para
I think I would do:
s/(SNMP and CLI scripts)/(e.g. SNMP and CLI scripts)
- page 53, sect 8.3.1 3rd line
s/can manipulated/can be manipulated/
- As a comment I note that was confused a few times (or put on the
wrong leg) when I read about a "create operation". In fact that is
the operation-attribute of the protocol operation edit-config.
Not saying anything needs to be done about it, just that I would
not be surprised if novice readers run into the same problem.
Bert
--
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/>