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

[Robert Wilton <[e-mail]>]

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

On 13/02/2019 11:22, Juergen Schoenwaelder wrote:
> 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
>