Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Martin Bjorklund <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Juergen Schoenwaelder <[e-mail]> writes:
> 
> > On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote:
> >>
> >> Juergen Schoenwaelder <[e-mail]> 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
>