[netmod] Re: Erik Kline's No Objection on draft-ietf-netmod-rfc6991-bis-17: (with COMMENT)

[[e-mail]]

Hi Jürgen, Erik, all,

Please see one comment inline.

Cheers,
Med

> -----Message d'origine-----
> De : Jürgen Schönwälder <[e-mail]>
> Envoyé : mercredi 18 décembre 2024 20:01
> À : Erik Kline <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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.