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

On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <chopps@chopps.org> wrote:

> Thanks for the review! Comments inline.
>
> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <
> ietf-secretariat-reply@ietf.org> wrote:
> >
> > Reviewer: Elwyn Davies
> > Review result: Almost Ready
> >
> ....
> > 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.";
>
>

I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix
"vendor:"
seems a bit short-sighted)

Andy

> 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>