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

[Juergen Schoenwaelder <[e-mail]>]

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

On Wed, Feb 13, 2019 at 05:19:17AM -0500, Christian Hopps wrote:
> 
> 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.

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

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

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