Re: Gen-ART LC Review of draft-ietf-netmod-dsdl-map-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Ben,

thank you for the review, my comments are inline.

Ladislav

On Tue, 7 Sep 2010 16:04:57 -0500, Ben Campbell <ben@xxxxxxxxxxxx> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-netmod-dsdl-map-07
> Reviewer: Ben Campbell
> Review Date: 2010-09-07
> IETF LC End Date: 2010-09-07
> IESG Telechat date: (if known)
> 
> Summary: The draft is basically ready for publication as a proposed
> standard. I have a few editorial comments and nits that should be
> considered if there is another revision.
> 
> Note: This draft delves deeply into XML esoterica, and I am far from
> an XML expert. I assume the authors and work group feel this has had
> sufficient review from XML experts (and as far as I know, they _are_
> the experts). I also assume the schemas, etc, have been mechanically
> verified. If not, I suggest this be done as much as practical.

Apart from WG members, the document was reviewed by an external XML
expert Jirka Kosek.

> 
> Major issues:
> 
> None
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> -- Idnits complains about a number of normative references to external
> documents. I don't know if that's a problem--I merely point it out for
> consideration. It looks like it's mostly ISO docs, so I doubt there's
> an issue

ISO standards are used as normative references e.g. in RFC 3688, I
believe W3C Recommendations should be acceptable as normative, too.

> 
> -- There are a number of acronyms that should be expanded on first
> use. E.g. YANG, RELAX NG, XLST, etc.

I fixed this for XSLT and RELAX NG, but YANG is not an acronym (as far
as I know).

> 
> -- section 2.1, definition of "implicit node"
> 
> Can a node be considered implicit if it is _not_ missing? If not, then
> the "if missing" condition is non-contraining.

I made the definition more precise:

OLD

   o  implicit node: A node that, if missing, may be added to the
      information set of an XML document (configuration, RPC input or
      output, notification) without changing the meaning of that XML
      document.

NEW

   o  implicit node: A data node that, if it is not instantiated in a
      data tree, may be added to the information set of that data tree
      (configuration, RPC input or output, notification) without
      changing the semantics of the data tree.

The term "data node" is defined in [YANG] (and referred to in sec. 2 of
this I-D) to mean "a node in the schema tree". So the "implicitness" is
a property of data nodes in a schema tree, independently of any instance
XML documents (data trees).

> 
> -- section 3, 1st sentence:
> 
> s/by/with

Changed.

> 
> -- section 9.1.1:
> 
> Is it explicitly illegal for a mandatory node to have a default?

Yes, a mandatory leaf must not have a default [YANG, sec. 7.9.3].

> 
> -- section 9.1.1, third paragraph from the end:
> 
> "...and only if..." seems non-constraining in context.

The sentence attempts to define "optional" as the complement to
"mandatory". Is the following formulation better?

OLD

   A node is optional if and only if it is not mandatory.

NEW

   A node which is not mandatory is said to be optional.

> 
> -- section 13
> 
> This looks sort of light, when compared with the template in 3688. I'm
> not exactly sure how to apply that to a namespace, since I guess there
> is no XML to include, but it probably at least needs a registrant
> contact for each URL.

Yes, this was already pointed out in the IANA review, I added two
templates as required by RFC 3688.

> 
> -- Author's addresses:
> 
> Is Rohan's affiliation current?

The co-authors are no more active in the workgroup, I have asked both of
them for an update of their affilation and email address.

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]