[to this thread in general, not anyone in particular] We have done this work over 2 years in the working group. It has been presented multiple times with multiple revisions etc. We have arrived at a solution that works, and has cleared WG LC, and IETF LC.
We have a process we need to follow it. Yes if something is truly broken and has somehow escaped all the previous checks it needs to be addressed. But general musings about how one might do things a little different or a little better are not appropriate at this very late stage, otherwise we never get anything done. Not getting things done in a timely manner has been a problem highlighted at least with the work in netmod if not the IETF in general, and has been the subject during many meetings at this point, on how to fix it. Endless revisionism is one of the major factors identified as a problem. Can we please restrict discussions on this document to editorial/minor corrections or changes that have to be made b/c otherwise the solution will not work? Thanks, Chris. > On Mar 7, 2019, at 18:40, Alex Campbell <[email protected]> wrote: > > In that case, why not make it so the tags are actually valid URIs, similar to > XML namespaces? > > From: netmod <[email protected]> on behalf of William Lupton > <[email protected]> > Sent: Friday, 8 March 2019 7:37 a.m. > To: Andy Bierman > Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod WG; > General Area Review Team; [email protected] > Subject: Re: [netmod] Genart last call review of > draft-ietf-netmod-module-tags-06 > > 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 > <https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml> > On Thu, 7 Mar 2019 at 18:28, Andy Bierman <[email protected] > <mailto:[email protected]>> wrote: > > > On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <[email protected] > <mailto:[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] <mailto:[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] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/netmod > > <https://www.ietf.org/mailman/listinfo/netmod> > > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
