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

[Christian Hopps <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> writes:

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

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