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 <mohamed.boucad...@orange.com> wrote:
> Hi Jürgen, Erik, all,
>
> Please see one comment inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Jürgen Schönwälder <jschoenwaelder@constructor.university>
> > Envoyé : mercredi 18 décembre 2024 20:01
> > À : Erik Kline <ek.i...@gmail.com>; The IESG <i...@ietf.org>;
> > draft-ietf-netmod-rfc6991-...@ietf.org; netmod-cha...@ietf.org;
> > netmod@ietf.org; kent+i...@watsen.net
> > 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.
>
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
