Re: [netmod] Last Call: <draft-ietf-netmod-module-tags-05.txt> (YANG Module Tags) to Proposed Standard

[tom petch <[e-mail]>]

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" <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> 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" <[e-mail]>
> >> To: "IETF-Announce" <[e-mail]>
> >> Cc: <[e-mail]>; <[e-mail]>; "Joel Jaeggli"
> >> <[e-mail]>; <[e-mail]>;
> >> <[e-mail]>
> >> 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
> >>> [e-mail] mailing lists by 2019-03-03. Exceptionally, comments
may
> >> be
> >>> sent to [e-mail] instead. In either case, please retain the
> >> beginning of
> >>> the Subject line to allow automated sorting.
> >>>
> >>> Abstract
>