Juergen Schoenwaelder <[email protected]> writes:
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.
I've now added an "module-tag" extension statement.
> - 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?
I *really* want to stay away from over-specifying (over-complicating) this by imposing a
lot of structure and rules. The text uses ":"s suggestively, but I'd rather
remove that than start down the path of standardizing additional structure.
It probably would be useful to restrict the actual characters used in the
string to avoid odd whitespace (e.g., tabs, newlines/carriage returns). Is
there a standard type that just leaves these specific whitespace characters
out? I was hesitant to just use something like yang identifier b/c I figured it
might be useful for people to include non-ascii-like characters (umlats etc..)
Thanks,
Chris.
> - 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
