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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

OK, looking forward to new revision

> -----Original Message-----
> From: Rob Enns [mailto:rpe@juniper.net]
> Sent: Wednesday, August 31, 2005 13:46
> To: Wijnen, Bert (Bert)
> Cc: Netconf (E-mail)
> Subject: RE: AD review for: draft-ietf-netconf-prot-07.txt
> 
> 
> Thank you for the thorough review, Bert. Unless otherwise noted, all
> edits and clarifications you raise have been made to the 
> protocol draft.
> 
> 
> > - 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.
> 
> I agree, it doesn't help much as currently written. Given that 
> the filtering rules and role of the containment, selection, and 
> content match nodes are laid out in detail in section 6.2.5, and 
> 6.3, I think we can clean this up a little by trimming section 
> 6.2.3 down and limiting it to defining what a containment 
> node is. The descriptive text for the example in 6.2.3 is a 
> bit misleading, because the selection node also controls what 
> is included in the output, and that's not discussed until 6.2.4 
> and 6.2.5. I will clean this up. 
> 
> > - 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?
> 
> The peer should ignore capabilities it does not understand.
> I think it would be clearer to rewrite this as "... and MUST
> ignore any capability received from the other peer that it 
> does not require or does not understand."
>  
> > - sect 8.9.5.1 example
> >   Am I missing something? I do not understand "top" in that
> >   example. Could be me.
> 
> In the fictional data model used in the draft, "top" is the
> uppermost (or outermost) element.
> 
> > - 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 will post proposed text for the IANA Considerations section 
> to the WG
> list.
> 
> > - 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).
> 
> Agreed, although I haven't yet figured out how to make 
> xml2rfc do this.
> 
> > - Has the XML Schema been validated for correct SYNTAX?
> >   Can you tell me which tool you used to do so?
> 
> XMLSpy (http://www.altova.com) was used to validate the schema
> and all examples against the schema.
> 
> thanks,
>  Rob
> 

--
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/>