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 <ietf-secretariat-reply@xxxxxxxx>
Date: 06/03/2019 00:26 (GMT+00:00)
To: gen-art@xxxxxxxx
Cc: draft-ietf-netmod-module-tags.all@xxxxxxxx, ietf@xxxxxxxx, netmod@xxxxxxxx
Subject: [Gen-art] Genart last call review of
draft-ietf-netmod-module-tags-06
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like 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-06
Reviewer: Elwyn Davies
Review Date: 2019-03-05
IETF LC End Date: 2019-03-03
IESG Telechat date: Not scheduled for a telechat
Summary:
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:
None
Minor issues:
Abstract/s1: I would judge that RFC 8407 ought to be normative since it is
updated.
S4.2: using the Netmod working group as contact point for the module is not
future 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 normative
Nits/editorial comments:
Abstract: s/modules/module's/
Abstract:
OLD:
This document also provides guidance to future model writers, as such, this
document updates RFC8407.
NEW:
This document also provides guidance to future model writers; as such, this
document updates RFC8407.
ENDS
S1.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 a
prefix. 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 Section
2.1. Thus, new modules can drive the addition of new standard tags to the IANA
registry, 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 use
the prefix defined in Section 2.1. Thus, definitions of new modules can drive
the 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.
ENDS
S3.2: s/standard/IETF Standard/
S3.3: It would be useful to introduce the term 'masking' used later in the YANG
module 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 RFC
8342 which discusses the system origin concept.
Major issues:
Minor issues:
Nits/editorial comments:
_______________________________________________
Gen-art mailing list
Gen-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art
