Hi, Christian Hopps <[email protected]> wrote: > > 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".
I really don't have a strong opinion; this was just a suggestion to solve the issue. /martin > > 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 > >> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
