On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote: > > > > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder < > [email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
