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 StandardThe IESG has received a request from the Network Modeling WG (netmod)toconsider 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 solicitsfinalcomments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2019-03-03. Exceptionally, comments maybesent to iesg@xxxxxxxx instead. In either case, please retain thebeginning ofthe Subject line to allow automated sorting. Abstract This document provides for the association of tags with YANGmodules.The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be standardized and assigned during module definition; assigned by implementations; ordynamicallydefined and set by users. This document provides guidance tofuturemodel writers and, as such, this document updates [RFC8407]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ballot/ No IPR declarations have been submitted directly on this I-D.
Attachment:
signature.asc
Description: PGP signature
