Subject: AD review for: draft-ietf-netconf-prot-07.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 29 Jul 2005 21:19:28 +0200

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