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

[Jürgen Schönwälder <[e-mail]>]

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
> <[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany