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

[Christian Hopps <[e-mail]>]

> On Oct 17, 2018, at 2:47 AM, Martin Bjorklund <[e-mail]> wrote:
> 
> Hi,
> 
> Christian Hopps <[e-mail]> wrote:
>> 
>> Andy Bierman <[e-mail]> writes:
>>> 
>>> This draft needs to define the module-tag encoding wrt/
>>>   - valid characters (e.g., some subset of UTF-8)
>>>   - min/max length (e.g., implementation MUST support at least 64 chars
>>> and can support larger)
>> 
>> I'm looking for suggestions on how to do this subset. We had intended
>> to allow for as wide as possible content; however, I think disallowing
>> tabs, newlines, carriage returns is more than reasonable. Has a type
>> like this already been standardized or is there an example available
>> somewhere?
>> 
>>> Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
>>> structure to specify the naming authority.
>>> 
>>> According to the YANG module, the data type is a plain string, which
>>> includes lots of
>>> problematic chars and zero-length strings.
>>> 
>>> Does the string "routing" match "ietf:routing" or "vendor:routing"?
>>> How
>>> about "routing:bgp"?
>> 
>> No. Do we need to state that non-matching strings don't match?
> 
> The word "match" is imo problematic.  Use "equal" if that's what you
> mean.  But you're not actually using the word "match" in the draft, so
> that's fine.  However, I think the draft can be clarified.  See below.
> 
> In this case, it _seems_ like there's some hierarchy with tags
> like:
> 
>  ietf:routing
>  ietf:routing:rib
> 
> For example, does ietf:routing:rib imply ietf:routing?
> 
> From your last emails, it seems that the idea is that tags are really
> just strings with the only property that they can be compared for
> equality.  If this is the case, I think it can be made more clear in
> the document.  And if this is the case, I think that type "string" is
> actually fine.  If someone wants to assign the tag
> "vendor:acme::::::::: ", let them.
> 
> OTOH, if the idea is that the tags are hierarchical, and
> ietf:routing-rib implies ietf:routing, then a more specific type is
> needed, and more text.

I'm going to remove the colons (except for the one in the prefix). This has caused a lot of confusion. It is as you say supposed to be free-form after the prefix. Yes, there was an implied structure being suggested, but there was no intention to try and standardize this structure. In the end it comes off as half-baked and confusing so better to remove it.

FWIW I originally envisioned a more flat tag space anyway, so ietf:routing and ietf:igp. I'm not sure how we ended up suggesting hierarchy. 

Thanks,
Chris.

> 
> 
> /martin
> 
> 
> 
>> 
>>> Is the char ":" allowed in a tag?
>> 
>> Yes, why not?
>> 
>>> Is "vendor::::::::" a valid tag?
>> 
>> Again why not?
>> 
>> The only thing the draft talks about are standard prefixes. Why should
>> a standard enumerate a subset of the unbounded set of things it isn't
>> standardizing? This seems more confusing (why was X included as OK but
>> not Y) than just sticking to what it *is* standardizing.
>> 
>> Perhaps a bit of text saying more explicitly that only the prefix is
>> restricted would help though?
>> 
>>> IMO this draft does not need to define any specific module-tag content
>>> but
>>> it does need to define
>>> in precise terms how a protocol encodes a module-tag and how a
>>> module-tag
>>> match is determined.
>> 
>> We considered leaving out all the predefined tags, but conversely we
>> also thought it would be useful to establish a base set. We went with
>> the latter obviously. Perhaps it just needs to be trimmed down more?
>> 
>> Thanks,
>> Chris.
>> 
>>> 
>>> 
>>> Thanks,
>>>> Chris.
>>>> 
>>> 
>>> Andy
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod