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

[Martin Bjorklund <[e-mail]>]

Hi,

Christian Hopps <[e-mail]> wrote:
> 
> Martin Bjorklund <[e-mail]> 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 <[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
> >>