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

[Ladislav Lhotka <[e-mail]>]

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