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.
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
