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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
