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

[tom petch <[e-mail]>]

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
>
>
>    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.
>
>
>
>