Juergen Schoenwaelder <[email protected]> writes:
> 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.
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?
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).
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.
/js
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
