Re: [netmod] AD review of draft-ietf-netmod-dsdl-map

["Romascanu, Dan (Dan)" <[e-mail]>]

No problem for me with this change of wording. 

Dan



> -----Original Message-----
> From: Ladislav Lhotka [mailto:[e-mail]] 
> Sent: Monday, August 23, 2010 11:18 AM
> To: Romascanu, Dan (Dan); NETMOD Working Group
> Subject: RE: [netmod] AD review of draft-ietf-netmod-dsdl-map
> 
> On Sun, 22 Aug 2010 17:10:58 +0200, "Romascanu, Dan (Dan)" 
> <[e-mail]> wrote:
> > Hi Lada,
> > 
> > Thank you for your answers. All the changes proposed by you in this 
> > mail are fine with me with the exception of the change in 
> answer to my 
> > comment T2. In that case I would suggest that you make the change 
> > proposed by Juergen.
> 
> I'd also like to communicate the fact that NETMOD not only 
> was chartered to deliver but indeed delivered the language. I 
> propose the following reformulation of Juergen's text:
> 
>     The NETMOD Working Group was chartered to design a 
> modeling language
>     defining the semantics of operational data, configuration data,
>     event notifications and operations, with focus on
>     "human-friendliness", i.e., readability and ease of use. 
> The result
>     is the YANG data modeling language [YANG], which now 
> serves for the
>     normative description of NETCONF data models.
> 
> Is this wording acceptable?
> 
> Thanks, Lada
> 
> > 
> > Thanks and Regards,
> > 
> > Dan
> >  
> > 
> > > -----Original Message-----
> > > From: Ladislav Lhotka [mailto:[e-mail]]
> > > Sent: Thursday, August 19, 2010 10:28 PM
> > > To: Romascanu, Dan (Dan); NETMOD Working Group
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-dsdl-map
> > > 
> > > Hi Dan,
> > > 
> > > thank you for the review, I'll roll out the -07 revision soon. 
> > > Please see my responses and suggested changes inline.
> > > 
> > > Lada
> > > 
> > > On Thu, 19 Aug 2010 18:56:55 +0200, "Romascanu, Dan (Dan)" 
> > > <[e-mail]> wrote:
> > > > Please find below my AD review for
> > > draft-ietf-netmod-dsdl-map-06.txt. 
> > > > I believe that a revised I-D is needed before proceeding to
> > > IETF Last
> > > > Call. Also, you need to answer issue T1 either by moving
> > > the reference
> > > > to 5013 to Informational, or by specifying the downref 
> in the IETF 
> > > > Last Call.
> > > > 
> > > > The comments are divided into Technical and Editorial. 
> > > > 
> > > > 
> > > > T1. There is a normative reference to RFC 5013 which is
> > > Informational.
> > > > This is a downref. If this reference must be normative, the 
> > > > downref must be explicitly mentioned in the IETF Last Call. Is 
> > > > this
> > > the intention?
> > > 
> > > This reference can be moved to Informational. I just 
> wasn't aware of 
> > > this downref issue.
> > > 
> > > > 
> > > > T2. Introduction
> > > > 
> > > > The NETMOD Working Group was chartered to address this 
> problem by 
> > > > defining a new human-friendly modeling language based on SMIng 
> > > > [RFC3216] and called YANG [YANG].
> > > > 
> > > > I do not believe that this statement is true. There was no
> > > requirement
> > > > in the charter to base the YANG on SMIng.
> > > 
> > > Is this better? (I hope the text will eventually refer to 
> the YANG 
> > > RFC).
> > > 
> > > OLD:
> > > 
> > > The NETMOD Working Group was chartered to address this problem by 
> > > defining a new human-friendly modeling language based on SMIng 
> > > [RFC3216] and called YANG [YANG].
> > > 
> > > NEW:
> > > 
> > > The NETMOD Working Group was chartered to address this problem by 
> > > defining a new human-friendly data modeling language called YANG. 
> > > The definition of YANG version 1 was published recently 
> [YANG]. Its 
> > > syntax is loosely based on SMIng [RFC3216].
> > > 
> > > Alternatively, the last sentence can be removed.
> > > 
> > > > 
> > > > T3. Section 8.4: 
> > > > 
> > > > > Each embedded <rng:grammar> element must declare the 
> namespace 
> > > > > of
> > > >        the corresponding module using the @ns attribute.
> > > > 
> > > > Use capitalized MUST. 
> > > 
> > > OK
> > > 
> > > > 
> > > > T4. Section 10.13
> > > > 
> > > > This statement MAY be ignored.  Otherwise, it is mapped 
> to the DTD 
> > > > compatibility element <a:documentation> and ARGUMENT
> > > becomes its text.
> > > > 
> > > > What does the second sentence mean? What to do when mapping or 
> > > > what not to do?
> > > 
> > > OLD
> > > 
> > > This statement MAY be ignored.  Otherwise, it is mapped 
> to the DTD 
> > > compatibility element <a:documentation> and ARGUMENT becomes its 
> > > text.
> > > 
> > > NEW
> > > 
> > > This statement is mapped to the DTD compatibility element 
> > > <a:documentation> and ARGUMENT becomes its text.
> > >  
> > > > 
> > > > T5. Same question as above for 10.47
> > > > 
> > > 
> > > The same change, mutatis mutandis.
> > > 
> > > > T6. Section 10.56: 
> > > > 
> > > > > Implementations MAY ignore this statement.
> > > > 
> > > > Why?
> > > 
> > > You are right, I'll remove this sentence.
> > > 
> > > > 
> > > > T7. Section 10.60: 
> > > > 
> > > > This statement is not mapped to the output schema.  However, an 
> > > > implementation SHOULD check that it is compatible with the YANG 
> > > > version declared by the statement (currently version 1).
> > > > 
> > > > What should an implementation do if the yang-version is not
> > > compatible?
> > > > (which may happen in the future)
> > > 
> > > OLD:
> > > 
> > > This statement is not mapped to the output schema.  However, an 
> > > implementation SHOULD check that it is compatible with the YANG 
> > > version declared by the statement (currently version 1).
> > > 
> > > NEW:
> > > 
> > > This statement is not mapped to the output schema.  However, an 
> > > implementation SHOULD check that it is compatible with the YANG 
> > > version declared by the statement (currently version 1).
> > > In the case of a mismatch, the implementation SHOULD 
> report an error 
> > > and terminate.
> > > 
> > > > 
> > > > T8. Section 11:
> > > > 
> > > > In general, the second mapping step has to accomplish the 
> > > > following three tasks:
> > > > 
> > > > What does 'In general' mean here? Are there exceptions? 
> Which ones? 
> > > > 
> > > 
> > > OLD:
> > > 
> > > In general, the second mapping step has to accomplish the 
> following 
> > > three tasks:
> > > 
> > > NEW:
> > > 
> > > The second mapping step has to accomplish the following three 
> > > general
> > > tasks:
> > > 
> > > > 
> > > > E1. Introduction: s/SNMP Management Information Bases 
> (MIBs)/SNMP 
> > > > Management Information Base (MIB) modules/
> > > 
> > > OK
> > > 
> > > > 
> > > > E2. Expand acronyms at the first occurrence: DSRL, etc.
> > > 
> > > Will do.
> > > 
> > > > 
> > > > E3.In section 3: s/the inverse mapping from DSDL to YANG beyond 
> > > > the scope of this document/the inverse mapping from DSDL to
> > > YANG is beyond
> > > > the scope of this document/
> > > 
> > > OK
> > > 
> > > > 
> > > > E4. Section 4 - reference for ISO/IEC 19757, RelaxNG,
> > > Schematron, DSRL
> > > > are desirable in the introduction part of the section.
> > > 
> > > I will put them there.
> > >  
> > > > 
> > > > E5. I see no reason to list the URIs separately and format them 
> > > > separately then the rest of the Informative references.
> > > Actually [XSD]
> > > > is also referenced by an URI, although included with the other 
> > > > references.
> > > 
> > > This is how xml2rfc handles hyperlinks (<eref>). I don't like it 
> > > either, so I will change them to standard informational 
> references.
> > >  
> > > > 
> > > > E6. In section 8.2 s/SNMP MIBs/SNMP MIB modules/
> > > 
> > > OK
> > > 
> > > > 
> > > > E7. The non-usage of quotation marks in the titles of
> > > subsections in
> > > > 10 is confusing. For example should not 10.11 be The 
> 'container' 
> > > > Statement rather than The container statement - so that the
> > > use of the
> > > > noun container in the text can be differentiated from the
> > > name of the
> > > > statement? Or in 10.12 we have The default Statement as the
> > > title of
> > > > the subsection while the text of the section speaks about
> > > the 'default'
> > > > statement.
> > > 
> > > I actually thought about this in an early stage but then 
> decided to 
> > > follow the suit of the YANG draft where the
> > > (double) quotes are omited in section titles, too. I will add the 
> > > single quotes to titles.
> > > 
> > > > 
> > > > E8. Section 12: s/we will denote CONTELEM/we will call CONTELEM/
> > > 
> > > I suggest this:
> > > 
> > > OLD:
> > > 
> > > In the rest of this section, we will denote CONTELEM the name of 
> > > this context element properly qualified with its namespace prefix.
> > > 
> > > NEW:
> > > 
> > > In the rest of this section, CONTELEM will denote the 
> name of this 
> > > context element properly qualified with its namespace prefix.
> > > 
> > > > 
> > > > E9. The IANA considerations section mentions registering three 
> > > > namespace URIs, but then lists only two.
> > > 
> > > I got rid of one between -05 and -06 and forgot to update 
> the count.
> > > 
> > > > 
> > > > E10. Make explicit that Appendix D will be removed at document 
> > > > publication.
> > > 
> > > OK, I will add an instruction to the RFC Editor.
> > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > --
> > > Ladislav Lhotka, CESNET
> > > PGP Key ID: E74E8C0C
> > > 
> 
> --
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C
>