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 <[email protected]> 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: +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
