Chris I am still left thinking that the existing urn: scheme would do the job just as well. Tom Petch ----- Original Message ----- From: "Christian Hopps" <chopps@xxxxxxxxxx> Sent: Thursday, February 21, 2019 12:05 PM > Perhaps we could add some more text in the "Tag Values" section to make this clearer: > > <t> > Except for the conflict-avoiding prefix, this document is not specifying any structure on (i.e., restricting) the tag values on purpose. The intent here is to avoid arbitrarily restricting the values that designers, implementers and users may can use. As a result of this choice, designers, implementers and users are free to add any structure they may find useful to their own tag values. > </> > > Thanks, > Chris. > > Christian Hopps <chopps@xxxxxxxxxx> writes: > > > The document does *not* create ways for specifying names for objects. Its a way to associate meta-data with an implemented yang module. Even says this right at the start of the abstract. > > > > The body of the document does *not* fail to specify the syntax. As you even quoted: > > > > <t> > > All tags SHOULD begin with a prefix indicating who owns their > > definition. An IANA registry is used to support standardizing > > tag prefixes. Currently 3 prefixes are defined with all others > > reserved. No further structure is imposed by this document on > > the value following the standard prefix, and the value can > > contain any yang type 'string' characters except > > carriage-returns, newlines and tabs. > > </t> > > > > "NO FURTHER STRUCTURE..." > > > > There's no structure. People are free to pick any value they want for the tag. If a vendor or an operator wants to create their own sub-structure they are free to do so; however, the base specification does not and should not say this as we specifically do *not* want to restrict things. > > > > I think the problem is that some people want to start restricting this concept and get into specifying and limiting tags to some arbitrary structure, and so they say it's missing. It's not missing, it's intentionally designed to not have it. Its simple, and it's powerful in it's simplicity. > > > > I don't know why there would be any objection to using IANA to create a registry for specifying standard values for a specific use (module tags). That's what IANA is for. There are countless examples of standardizing values w/o using URNs to do it. > > > > Thanks, > > Chris. > > > > > > tom petch <daedulus@xxxxxxxxxxxxx> writes: > > > >> This I-D creates new way of specifying names for objects; why? > >> > >> We have several existing ways, such as urn: (currently being used by > >> IPPM for its registry, in form of urn:ietf:.. ) and YANG already makes > >> extensive use of urn: so that is part of the vocabulary of YANG modules, > >> so why do we need a new one? > >> > >> And for a new one, the specification seems vague; again, urn or, more > >> generally, uri provides an example of how to specify things. > >> > >> More specifically, > >> > >> - the body of the document fails to specify the syntax. Delve into the > >> YANG module and I find > >> pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; > >> but I expect something in the body, ABNF perhaps. > >> > >> - that pattern allows an infinite depth and is accompnied by > >> length "1..max"; > >> so we could have thousands of characters and the structure seems to be a > >> tree yet the I-D fails to specify how the tree is used, who can create > >> what where. Can I, or someone else, create > >> ietf:hardware:cisco:router:2513:trn > >> Well, the I-D says > >> " No further structure is imposed by this document on the value" > >> so the answer is yes: not a good way to start IMHO - better to start > >> small and expand as needs arise. The I-D cites #hashtags as part of its > >> justification; for me, the opposite is true, where standards work is > >> concerned. > >> > >> In the same vein, > >> "If the module definition is IETF standards track, the tags MUST also be > >> IETF standard tags" > >> but I see nothing to stop proprietary modules using ietf: tags. > >> > >> - CR NL tab are excluded but type string allows > >> any Unicode or ISO/IEC 10646 character > >> so scope there for i18n > >> > >> - there is work for IANA but the I-D references the obsolete RFC5226 and > >> so, e.g., fails to specify a Group name (which I find makes the > >> difference between being able to find something readily on the IANA > >> website and not). > >> > >> - " Other SDOs (standard organizations) wishing to standardize their > >> own > >> set of tags could allocate a top level prefix from this registry." > >> How? Documents like those on URI give guidelines, an e-mail to IANA > >> perhaps. > >> > >> - "The allocation policy for this registry is Specification Required" > >> So what should a Designated Expert look for? It is customary for an I-D > >> to give guidance, if only to the IESG who have to appoint the expert. > >> > >> Then there are a number of glitches. > >> > >> The Abstract contains > >> this document updates [RFC8407]. > >> which looks like a reference, not allowed in Abstract > >> > >> The YANG module contains > >> " described in BCP 14 [RFC2119] [RFC8174] " > >> which again looks like a reference whereas YANG modules must be plain > >> text. > >> > >> Copyright is 2018 > >> > >> YANG module import statement lacks a reference statement > >> > >> The I-D contains an update to RFC8407 which says > >> "The module writer can use existing standard tags" > >> The phrase "module writer" is not used by RFC8407. > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "The IESG" <iesg-secretary@xxxxxxxx> > >> To: "IETF-Announce" <ietf-announce@xxxxxxxx> > >> Cc: <ibagdona@xxxxxxxxx>; <netmod-chairs@xxxxxxxx>; "Joel Jaeggli" > >> <joelja@xxxxxxxxx>; <draft-ietf-netmod-module-tags@xxxxxxxx>; > >> <netmod@xxxxxxxx> > >> Sent: Monday, February 18, 2019 3:49 AM > >> Subject: Last Call: <draft-ietf-netmod-module-tags-05.txt> (YANG Module > >> Tags) to Proposed Standard > >> > >> > >>> > >>> The IESG has received a request from the Network Modeling WG (netmod) > >> to > >>> consider the following document: - 'YANG Module Tags' > >>> <draft-ietf-netmod-module-tags-05.txt> as Proposed Standard > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits > >> final > >>> comments on this action. Please send substantive comments to the > >>> ietf@xxxxxxxx mailing lists by 2019-03-03. Exceptionally, comments may > >> be > >>> sent to iesg@xxxxxxxx instead. In either case, please retain the > >> beginning of > >>> the Subject line to allow automated sorting. > >>> > >>> Abstract >
