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

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Feb 2019 15:50:08 -0800

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/

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Feb 2019 07:53:09 +0100

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

---

From: Christian Hopps <[email-masked]>
Date: Wed, 13 Feb 2019 04:00:01 -0500

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Feb 2019 10:49:38 +0100

> 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 mea…

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.

> 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 cr…

Section 8.2 defines values, this section is not a signaling mechanism
alone anymore.
 
>    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.

/js

---

From: Christian Hopps <[email-masked]>
Date: Wed, 13 Feb 2019 05:19:17 -0500

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

> Section 8.2 defines values, this section is not a signaling mechanism

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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Feb 2019 12:22:21 +0100

First of all, let me clarify that I submitted comments, I did not
raise objections. There is a difference I think.

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

I generally prefer meaningful hopefully unambiguous definition. (That
is multiple readers should have a high chance to come to the same
conclusion when to use a tag or when to not use a tag.) I am fine with
tags that do not have such a definition being removed, I am also find
if someone provides a proper definition. I am not the one to provide
definitions for things where I do not know what they actually mean.
 
> 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-…

I simply asked why we are inconsistent with the initial tags that we
allocate. Others will want to allocate tags in the future, what do we
tell them how to do it? If the idea is to go with a true flat
namespace, then simply remove 'rfc8199-' from the tags and we have
ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user,
which lines up with ietf:routing and the like.

> 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.
 
I am not raising objections. I asked a question. And it is fine to be
told that I should shut up because we are past WG last call and the WG
likes what we have (and the WG or the IETF we will later figure out
what lets say ietf:protocol is really good for or whether scopes like
'rfc8199-' are a good or bad idea).

/js

---

From: Christian Hopps <[email-masked]>
Date: Wed, 13 Feb 2019 08:37:59 -0500

> which lines up with ietf:routing and the like.

But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is what "rfc8199-element" is supposed to be. It'll need to be something like "ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess.

I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up this introducing scope stuff. What if there was no "-" symbol used (i.e., "ietf:rfc8199element"?

The normative text says that we are defining no structure outside the prefix (i.e., it's flat). I believe what your saying is that if you ignore this normative text and just look at the "ietf:rfc8199-element" tags by themselves, one might imagine some meaning of scope. Do we need to repeat or reword the fact we are defining no structure beyond the prefix to make this more clear so people don't start imagining structures where we've normatively said they don't exist?

> 'rfc8199-' are a good or bad idea).

Your opinion rightly carries a lot of weight in this group, and so your questions need to be addressed even though they are coming late in the process.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Feb 2019 14:43:34 +0100

> But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is what "rfc8199-element" is supposed to be. It'll need to be something like "ietf:module-cla…

Seems arbitrary what we call too generic and what not. To me,
ietf:protocol is also quite generic.
 
> I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up this introducing scope stuff. What if there was no "-" symbol used (i.e., "ietf:rfc8199element"?

You may miss the point I am making.
 
> The normative text says that we are defining no structure outside the prefix (i.e., it's flat). I believe what your saying is that if you ignore this normative text and just look at the "ietf:rfc81…

You apparently use rfc8199- to scope 'element'...

> Your opinion rightly carries a lot of weight in this group, and so your questions need to be addressed even though they are coming late in the process.

Not true. I am happy to be shut down.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 13 Feb 2019 14:15:42 +0000

My opinion is that we should just push the doc as it stands now.

I don't know whether we have the perfect set of base tags defined in 
section 8.2, but I don't think that this really matters.  One of the 
things that I prefer about tags, compared to the alternative approach of 
having a rigid structure that all YANG modules have to fit into, is that 
the set of tags can evolve over time, and if a user doesn't like the set 
of tags, then they can just fix them via config.  If the "ietf:lmp" tag 
turns out not to be quite right, or not useful, then we just stop using 
it, and perhaps mark it as deprecated in IANA.

I think that it is more important to get the draft finished, 
particularly standardizing the YANG model and semantics.  Once folks 
start to tag YANG modules, we will gain experience figuring out what the 
right/useful tags are, and they can be documented in whatever way is 
most appropriate.

Thanks,
Rob

---

From: Christian Hopps <[email-masked]>
Date: Wed, 13 Feb 2019 09:40:52 -0500

> ietf:protocol is also quite generic.

But, "ietf:protocol" is in fact intended and defined to be generic, "ietf:rfc8199-element" is not defined as generic at all. It's defined very clearly in RFC8199. Using a broad tag "ietf:element" for such a narrow definition is not appropriate.

Again the normative text should take precedence here, so I'm inclined to leave things as they are, unless you'd like a more restricted alternative.

> You apparently use rfc8199- to scope 'element'...

This is getting a bit too abstract for me. Its a tag with a defined meaning. I actually think its very clear and informative as written. I think someone seeing it will immediately open RFC8199 and find the definition for what it means. And, if that's what happens then it's a good choice, not a bad one.

> Not true. I am happy to be shut down.

In that case, seeing as we have normative text that directly addresses the flatness of the space,
unless you have some suggestions on simple changes I'd like to move on. :)

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Feb 2019 16:16:03 +0100

> But, "ietf:protocol" is in fact intended and defined to be generic, "ietf:rfc8199-element" is not defined as generic at all. It's defined very clearly in RFC8199. Using a broad tag "ietf:element" f…

For me, ietf:element has a much more concrete definition than
ietf:protocol. I can probably decide when to tag a module with
ietf:element, I have much less an idea when to tag a module with
ietf:protocol. But I will shut up, my concerns have been recorded in
the archives, the future will tell whether we get into tagging debates
or not and whether the base tags defined in the document provide a
decent example for people defining more tags in the future.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Feb 2019 18:11:50 +0100 (CET)

Hi,

I think one concern with "rfc8199-xxx" is that if this RFC gets reved,
the name will be misleading.  I also agree that "element" is too
vague.

Since 8199 doesn't use the terms "element" and "service", but "network
element" and "network service", how about these changes:

  ietf:rfc8199-element  -->  ietf:network-element
  ietf:rfc8199-service  -->  ietf:network-service
  ietf:rfc8199-vendor   -->  ietf:vendor-defined
  ietf:rfc8199-user     -->  ietf:user-defined
  ietf:rfc8199-standard -->  ietf:standard-defined (or sdo-defined?)

If we make these changes, we have to revise the current
"ietf:network-service".  Maybe "ietf:network-service-protocol".

/martin

Christian Hopps <[email-masked]> wrote:
> >> But, ietf:element is too generic to assign the meaning "RFC8199 module
> >> classification of element" which is what "rfc8199-element" is supposed
> >> to be. It'll need to be something like "ietf:module-class-element" or
> >> "ietf:an-rfc8199-elemenet" or nothing I guess.
> >
> But, "ietf:protocol" is in fact intended and defined to be generic,
> "ietf:rfc8199-element" is not defined as generic at all. It's defined
> very clearly in RFC8199. Using a broad tag "ietf:element" for such a
> narrow definition is not appropriate.
> 
> Again the normative text should take precedence here, so I'm inclined
> to leave things as they are, unless you'd like a more restricted
> alternative.
> 
> >> I have this suspicion that if it had been "ietf:an-rfc8199-element"
> >> you might not have brought up this introducing scope stuff. What if
> >> there was no "-" symbol used (i.e., "ietf:rfc8199element"?
> >
> >> The normative text says that we are defining no structure outside the
> >> prefix (i.e., it's flat). I believe what your saying is that if you
> >> ignore this normative text and just look at the "ietf:rfc8199-element"
> >> tags by themselves, one might imagine some meaning of scope. Do we
> >> need to repeat or reword the fact we are defining no structure beyond
> >> the prefix to make this more clear so people don't start imagining
> >> structures where we've normatively said they don't exist?
> >>
> >
> This is getting a bit too abstract for me. Its a tag with a defined
> meaning. I actually think its very clear and informative as written. I
> think someone seeing it will immediately open RFC8199 and find the
> definition for what it means. And, if that's what happens then it's a
> good choice, not a bad one.
> 
> >> > > 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.
> >> >
> >> Your opinion rightly carries a lot of weight in this group, and so
> >> your questions need to be addressed even though they are coming late
> >> in the process.
> >

---

From: Christian Hopps <[email-masked]>
Date: Wed, 13 Feb 2019 15:28:54 -0500

> the name will be misleading.  I also agree that "element" is too

Isn't this why we have "Updates" and "Obsoletes" for? If this all didn't work we could never refer to our standards by RFC number anywhere, right? Also, the value in the registry is going to point at us and us to RFC8199 no matter what string we end up with. I'm not stuck on this though, so if you still think we need to change I'll take your suggestion, but add the suffix "-class" to be more specific and avoid conflicting with "ietf:network-service" at the same time. Also can change to "sdo-defined-class".

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Feb 2019 21:40:22 +0100 (CET)

Hi,

Christian Hopps <[email-masked]> wrote:
> Isn't this why we have "Updates" and "Obsoletes" for? If this all
> didn't work we could never refer to our standards by RFC number
> anywhere, right? Also, the value in the registry is going to point at
> us and us to RFC8199 no matter what string we end up with. I'm not
> stuck on this though, so if you still think we need to change I'll
> take your suggestion, but add the suffix "-class" to be more specific
> and avoid conflicting with "ietf:network-service" at the same
> time. Also can change to "sdo-defined-class".

I really don't have a strong opinion; this was just a suggestion to
solve the issue.

/martin