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
> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml> .
>
> On Thu, Dec 19, 2024 at 12:07 AM <[email protected]
> <mailto:[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] <mailto:[email protected]>>; The IESG
> > <[email protected] <mailto:[email protected]>>;
> > [email protected]
> > <mailto:[email protected]>; [email protected]
> > <mailto:[email protected]>;
> > [email protected] <mailto:[email protected]>; [email protected]
> > <mailto:kent%[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
>
> <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]
