FWIW, I'm fine with it as it stands -- it is often what people expect (e.g., "the L4 protocol type, or the encap'd packet type, ..."). This was why I balloted No Objection.
I just feel like there are some situations wherein you want to describe the actual Next Header value and not just the "Next Layer" value, which is what protocol-number here really is. But that's ok, such situations can sort it out when/if they actually arise. On Tue, Jan 28, 2025 at 4:26 PM Mahesh Jethanandani <[email protected]> wrote: > I am trying to figure next steps to resolve this comment. > > The current definition for protocol-number is a 'type uint8’ with a > description that says. > > The protocol-number type represents an 8-bit Internet > protocol number, carried in the 'protocol' field of the > IPv4 header or in the 'next header' field of the IPv6 > header. 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. > > Protocol numbers are assigned by IANA. The current list of > all assignments is available from <https://www.iana.org/>. > > Do we need semantics that describe protocol number of the next protocol > that follows any extension headers? > > Cheers. > > On Dec 19, 2024, at 7:10 AM, Erik Kline <[email protected]> wrote: > > I'm not sure that's the same thing. I was thinking of a field that > represents the uint8_t numberspace that is the values in > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml . > > On Thu, Dec 19, 2024 at 12:07 AM <[email protected]> wrote: > >> Hi Jürgen, Erik, all, >> >> Please see one comment inline. >> >> Cheers, >> Med >> >> > -----Message d'origine----- >> > De : Jürgen Schönwälder <[email protected]> >> > Envoyé : mercredi 18 décembre 2024 20:01 >> > À : Erik Kline <[email protected]>; The IESG <[email protected]>; >> > [email protected]; [email protected]; >> > [email protected]; [email protected] >> > Objet : [netmod] Re: Erik Kline's No Objection on draft-ietf- >> > netmod-rfc6991-bis-17: (with COMMENT) >> > >> > >> > 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. >> > >> >> [Med] Given that we already have ipv6-extension-header-type-name and >> ipv6-extension-header-type in >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-extensions-12#name-initial-version-of-the-ipv6 >> (submitted to IESG for publication), I think that is simpler to recommend >> that specific type is used when manipulating EHs. protocol-number >> description can point to that type for EH and be also updated among the >> lines initially suggested by Erik. >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> > > Mahesh Jethanandani > [email protected] > > > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
