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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


   This document provides for the association of tags with YANG
modules.
   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; or
dynamically
   defined and set by users.  This document provides guidance to
future
   model 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux