On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <[email protected]> wrote:
> Thanks for the review! Comments inline. > > > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies < > [email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
