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

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

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. 

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
>