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

[Andy Bierman <[e-mail]>]

On Tue, Oct 16, 2018 at 3:15 PM, 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?
>

I suppose yang-identifier type is too restrictive so I will agree that
restricting whitespace and colon chars
is probably good enough


> 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 official prefixes and colon char lead people to believe the string is
structured.
Intelligent searches on sub-sfields might be purpose of such structure. Or
not I guess.


> Is the char ":" allowed in a tag?
>>
>
> Yes, why not?
>

Because it confuses people who think the colon character has special
meaning in this string



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


I think the registry details have to be there to populate the IANA
registery



>
> Thanks,
> Chris.
>
>
>>
>> Thanks,
>>
>>> Chris.
>>>
>>>
>> Andy
>>
>
>
Andy