On Thu, Mar 7, 2019 at 10:37 AM William Lupton <wlup...@broadband-forum.org> wrote:
> This remark might be out of context (I haven't been following the details) > but this reference to prefixes makes me wonder whether there's any way that > registered URN namespaces could be regarded as valid prefixes. > https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml > looks like a great solution and would be less duplication of registries Andy > > On Thu, 7 Mar 2019 at 18:28, Andy Bierman <a...@yumaworks.com> wrote: > >> >> >> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <cho...@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-re...@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 >>> >> _______________________________________________ >> 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
