ietf
[Top] [All Lists]

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

2010-09-08 11:34:13
Hello Ben,

thank you for the review, my comments are inline.

Ladislav

On Tue, 7 Sep 2010 16:04:57 -0500, Ben Campbell <ben(_at_)estacado(_dot_)net> 
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>