On Tue, Dec 10, 2024 at 10:37:34PM +0100, Jürgen Schönwälder wrote:
> On Sat, Nov 30, 2024 at 03:18:45PM -0800, Erik Kline via Datatracker wrote:
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > # Internet AD comments for draft-ietf-netmod-rfc6991-bis-17
> > CC @ekline
> > 
> > ## Comments
> > 
> > * "typedef protocol-number {
> >                If IPv6 extension headers are present, then the
> >        protocol number type represents the upper layer protocol
> >        number, i.e., the number of the last 'next header' field
> >        of the IPv6 extension headers."
> > 
> >   Surely since this can represent all values of the Next Header field this
> >   _could_ indicate the value of an IPv6 Extension Header?
> > 
> >   It seems to me that we should just say this is the value of the
> >   protocol/next header field wherever this numberspace is indicated, and
> >   that in some contexts extension headers might be skipped over and the
> >   ultimate next header value is what is meant in this field.
> > 
> >   This should be called out on a case-by-case basis, though, I would expect
> >   (i.e. wherever this type is used).
> 
> These are possible alternate semantics making the type more flexible
> to use but also requiring that every usage spells out what is actually
> meant.
>

I actually think this is a valuable idea. To me, it makes sense to
have (i) a type that essentially models what we have in the IANA
protocol number registry and where the usage needs to clarify how this
works with a chain of extension headers and (ii) a derived type that
has the semantics that we currently have for those cases where people
just want the protocol number of the next protocol following any
extension headers.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to