Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Andy Bierman <[e-mail]>]

On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
> >
> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
> [e-mail]> wrote:
>
> > > - Standard tags defined in description statements
> > >
> > >  I do not like this. YANG has extension statements and having to
> > >  parse stuff out of free text description statements seems to be a
> > >  movement backwards.
> >
> > This is used by the human implementer of the module (i.e., they need to
> write code to implement the module). As such it was not intended for
> machine parsing.
> >
>
> I am personally not convinced. The whole reason why we have YANG is
> automation and I believe people will go and write tools to extract
> tags and having to extract them out of free form text looks like a
> step backwards.
>


It is more than a step backwards.
There is an unexplained procedure for declaring the  module-tag conformance,
in addition to the module-tag mappings.

All YANG designers are supposed to learn the exact text to write (not
free-form at all)
and this draft updates 6087bis with procedures for declaring the module-tags
in the description-stmt.

Also, tool developers are supposed to parse the description-stmt looking
for the
module-tag definitions. But instead, tool developers are going to say "Use
our
proprietary YANG extension because we are never going to parse description
statements"


> > > - System management
> > >
> > >  What is 'system management' and a 'system management protocol'?
> >
> > These were derived from the work the RtgYangDT originally did where we
> were organizing everything under a single device tree. This tree concept
> was (rightly) abandoned to be replaced with use of tags. Examples of
> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
> the description.
> >
>
> I am generally not a fan of definition by example. Is SSH a 'system
> management protocol'?
>


An example is not a definition.
The IETF is supposed to know the difference.



>
> > > - Tag format
> > >
> > >  Apparently, the colon has a special meaning in a tag string and
> > >  otherwise there do not seem to be any restrictions. (Which is good,
> > >  I can finally put various smileys on my gear.)
> > >
> > >  Should we state explicitly somewhere that a colon has a special
> > >  meaning and that tag strings are structured into a sequence of
> > >  'taggies' separated by colons? Or is definition by example good
> > >  enough?
> >
> > I think it's good enough. :)
>
> I am not convinced this will work well. My understanding is that other
> 'hashtags' also have restrictions - whitespace and punctuation
> characters are often excluded, it seems. Apparently ':' already means
> something special here. Should you later need more special meanings,
> you will love to have characters available that you can use. What
> about tags that include whitespace or control characters? Do we really
> want such tags?
>


Section 3 defines prefixes for different types of module tags
There is no actual definition of a module tag.
Is it UTF-8 encoding? US-ASCII? Is it structured such that a pattern could
be defined?
Is every protocol draft that uses module-tags somehow going to define their
own version?

I don't see how this draft provides enough interoperability to be useful.


> > > - Meaning of tag masks
> > >
> > >  Do masks mean a complete string match or can I mask along the prefix
> > >  hierarchy, i.e., 'vendor:acme:' masks everything starting with
> > >  'vendor:acme:'?
> >
> > Exact match, I've added text to clarify this.
>
> OK. One obvious extension is then to have at some point in time tag
> match expressions, such as 'vendor:acme:*' (assuming that * is not
> a valid character for a tag, see above).
>
> /js
>
>

Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>