Hi.After completing my review, I realized that there was a further minor issue
related to the possible values of tag prefixes, possible values of standardized
prefixes and behaviour of implementations in the face of tag prefixes or values
that are not in the relevant registries.I think that the text in s2 should be
reinforced to emphasise that the only prefixes that should be expected are
those in the IANA registry defined in s7.1.Either a new section or possibly in
s3 text should be added to define the behaviour of YANG implementations that
encounter tags with prefixes that are not in the s7.1 registry and tags with
prefix ietf: that are not in the s7.2 registry.Regards,Elwyn Davies Sent
from Samsung tablet.
-------- Original message --------From: Datatracker on behalf of Elwyn Davies
<[email protected]> Date: 06/03/2019 00:26 (GMT+00:00) To:
[email protected] Cc: [email protected], [email protected],
[email protected] Subject: [Gen-art] Genart last call review of
draft-ietf-netmod-module-tags-06 Reviewer: Elwyn DaviesReview result: Almost
ReadyI am the assigned Gen-ART reviewer for this draft. The General AreaReview
Team (Gen-ART) reviews all IETF documents being processedby the IESG for the
IETF Chair. Please treat these comments justlike any other last call
comments.For more information, please see the FAQ
at<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.Document:
draft-ietf-netmod-module-tags-06Reviewer: Elwyn DaviesReview Date:
2019-03-05IETF LC End Date: 2019-03-03IESG Telechat date: Not scheduled for a
telechatSummary:Almost ready. There are a couple of minor issues and a small
number of nits. Apologies for the slightly late delivery of the review.Major
issues:NoneMinor issues:Abstract/s1: I would judge that RFC 8407 ought to be
normative since it isupdated.S4.2: using the Netmod working group as contact
point for the module is notfuture proof. I am not sure what the correct
contact ought to be: IESG?S7.2: [This is a thought that occurred to me...]
ought there to be an ietf:security tag?S9: I would consider RFCs 8199, 8340,
8342 and 8407 to be normativeNits/editorial comments:Abstract:
s/modules/module's/Abstract:OLD:This document also provides guidance to future
model writers, as such, thisdocument updates RFC8407.NEW:This document also
provides guidance to future model writers; as such, thisdocument updates
RFC8407.ENDSS1.1, title: s/use cases of/use cases for/S1.1, para 1: s/documents
progression/document's development/S1.1, paras 2, 3 and 5: Suggest s/E.g./For
example/S1.1, para 4: s/e.g./e.g.,/S2, para 1: > All tags SHOULD begin with a
prefix indicating who owns their definition.If I read correctly, the YANG
definition in s4.2 REQUIRES that all tags have aprefix. For clarity, it would
better if this read: All tags MUST begin with a prefix; it is intended that
this prefix SHOULD [or maybe 'should'] indicate the ownership or origination
of the definition.S2, para 1: s/yang type/YANG type/ (I think)S2.2:
s/follwing/following/S3.1, para 2:OLD:If the module definition is IETF
standards track, the tags MUST also be Section2.1. Thus, new modules can drive
the addition of new standard tags to the IANAregistry, and the IANA registry
can serve as a check against duplication.NEW:If the module is defined in an
IETF standards track document, the tags MUST usethe prefix defined in Section
2.1. Thus, definitions of new modules can drivethe addition of new standard
tags to the IANA registry defined in Section 7.2,and the IANA registry can
serve as a check against duplication.ENDSS3.2: s/standard/IETF Standard/S3.3:
It would be useful to introduce the term 'masking' used later in the YANGmodule
definition.S4.1: I think this usage of RFC 8340 makes it normative.S4.2,
extension module-tag definition: This should contain a pointer to RFC8342 which
discusses the system origin concept.Major issues:Minor issues:Nits/editorial
comments:_______________________________________________Gen-art mailing
[email protected]https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
