Martin Bjorklund <[email protected]> writes:
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.
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.
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 protected]> wrote:Juergen Schoenwaelder <[email protected]> writes: > On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote: >> >> Juergen Schoenwaelder <[email protected]> writes: >> >> 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. > > Seems arbitrary what we call too generic and what not. To me, > 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. >> 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: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? >> > > 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. >> > > 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. > > 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. > > /js
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
