Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06

[Christian Hopps <[e-mail]>]

Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <[e-mail]> wrote:
> 
> Reviewer: Elwyn Davies
> 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.

RFC8407 is a BCP not a Standard though so I don't think it's appropriate to make it normative.

> 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?

Speaking of 8407 guidelines... It gives guidance here. I will follow it. :)

  "The "contact" statement MUST be present.  If the module is contained
   in a document intended for Standards Track status, then the WG web
   and mailing information SHOULD be present, and the main document
   author or editor contact information SHOULD be present."

> S7.2: [This is a thought that occurred to me...] ought there to be an ietf:
> security tag?

Yes, added.

> S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative

8199: Informational
8340: BCP
8407: BCP

8342: Standard, and I think your right, moved to 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.,/

Updated with your suggestions.

> 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.

The intent was to not put the MUST on users. As the final arbiters of tags, users should be free to do whatever they want and not have implementations or standards superfluously block them from doing so. How about we carry the SHOULD into the typedef in the YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
    type string {
      length "1..max";
      pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
    }
    description
      "A tag is a type 'string' value that does not include carriage
       return, newline or tab characters. It SHOULD begin with a
       standard prefix.";

> 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.

How about:

"Tags of any kind can be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =masked-tag= entry for
a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer to RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod