On Wed, Dec 18, 2024 at 11:55:54AM -0800, Erik Kline wrote: > On Wed, Dec 18, 2024 at 11:02 AM Jürgen Schönwälder > <[email protected]> wrote: > > > 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. > > > > > How do you think we should proceed, then?
I guess you discuss all issues related to this document with the other ADS and then the IESG tells the AD how to proceed with this document. I am just a document editor. /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]
