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

[Juergen Schoenwaelder <[e-mail]>]

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
the idea is to further scope IETF defined tags (there may be multiple
'element' tags), why does this additional scoping need not apply to
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?

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>