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

[Christian Hopps <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> writes:

> On Tue, Feb 12, 2019 at 03:50:08PM -0800, Joel Jaeggli wrote:
>> Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as Proposed Standard on behalf of the NETMOD working group.
>>
>> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
>>
>
> I just looked at the latest diff and I stumbled over the example using
> tags like ietf:rfc8199-element and ietf:routing and while I had an
> intuitive idea what ietf:routing may mean, I was pretty clueless what
> ietf:rfc8199-element is. Back in the old SNMP days, we actually
> learned that using RFC numbers in labels is not always a good idea
> because definitions sometimes get replaced or moved to other RFCs. If

You were clueless after you read RFC8199? :) We could change the tag names to:

  ietf-class-service
  ietf-class-element

And point at RFC8199 in the document for their definition. However, this only seems to further obfuscate the meaning from the user requiring 2 hops to reach the meaning vs. 1 hop. Repeating RFC8199 inside the modules tag draft to remove the reference seems ill-advised if that was your intention.

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.

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.

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

Thanks,
Chris.

> ietf:routing? So bottom line, should the tags _all_ be of the form
>
> - ietf:rfcxxxx:label or
> - ietf:rfcxxxx-label or
> - ietf:scope-label or
> - ietf:scope:label or
> - ietf:label
>
> where scope indicates the topic of the RFC defining the label
> (avoiding the embedding of the RFC number). I think it will be good if
> the ietf: namespace is somewhat organized from the start and it is not
> so good if the initial document is already using different forms.
>
> /js
>
> PS: I also wonder why this document defines ietf:lmp or more precisely
>     what exactly this is. When do I use ietf:protocol? When does it
>     apply and when not? Does it apply to ietf-system.yang since it
>     among other things sets parameters for ntp? I also wonder what the
>     life cycle management of these tag definitions is. If it turns out
>     that tags are underspecified, can I deprecate or obsolete them?