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