Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> writes:

> On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote:
>>
>> In any case this is general purpose meta-data after all, while some data may be immediately recognizable (e.g., ietf:routing) other data may require looking at a specification to determine it's meaning.
>
> Frankly, I can't really tell where ietf:protocol applies or not or
> what exactly is ietf:signaling vs some of the other closely related
> tags. The descriptions are rather open ended.

Please make suggestions (descriptive text, remove the tag, etc) on how to fix things to clear your objections.

>> All that said, if these RFC8199 are inappropriate for inclusion in this document or confusing, I'd rather remove them than stall the work. To use a routing analogy, the intent of this work is to create a method for "signaling" values, not to define the "values" themselves.
>
> Section 8.2 defines values, this section is not a signaling mechanism
> alone anymore.

Section 8.2 is there to help get things started. I'd rather remove it than perfect it. Perfect is not possible IMO, and TBH in netmod it often feels like good enough is ridiculously hard to come by.

>> > the idea is to further scope IETF defined tags (there may be multiple
>> > 'element' tags), why does this additional scoping need not apply to
>>
>> There is no intent to add additional scoping.  Indeed this was part of the motivation behind the addition of the final sentence in the "Tag Value" text in v3 of the document:
>>
>>    All tags begin with a prefix indicating who owns their definition.
>>    An IANA registry is used to support standardizing tag prefixes.
>>    Currently 3 prefixes are defined with all others reserved.  No
>>    further structure is imposed by this document on the value following
>>    the standard prefix, and the value can contain any yang type 'string'
>>    characters except carriage-returns, newlines and tabs.
>
> The 'rfc8199-' part in some of the tags does look to me like an
> attempt to scope 'service', 'element' etc. If this is being used, you
> will see that labels will use ad-hoc forms of scoping. The networking
> vocabulary is small and reuse of terms with different meanings in
> different contexts is common. If scopes are not needed, then I would
> argue 'rfc8199-' is not needed. Or it is needed and then it would be
> useful as well for ietf-qos and friends.

RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection?

Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well.

Thanks,
Chris.

>
> /js