[netmod] Re: Erik Kline's No Objection on draft-ietf-netmod-rfc6991-bis-17: (with COMMENT)
Jürgen Schönwälder <jschoenwaelder@constructor.university> Wed, 18 December 2024 19:01 UTC
Return-Path: <jschoenwaelder@constructor.university>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D801C1516E9; Wed, 18 Dec 2024 11:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.241
X-Spam-Level:
X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4gcq5jHFfYu; Wed, 18 Dec 2024 11:01:44 -0800 (PST)
Received: from beadg.de (beadg.de [178.254.54.206]) by ietfa.amsl.com (Postfix) with ESMTP id 51696C16943F; Wed, 18 Dec 2024 11:01:08 -0800 (PST)
Received: from localhost (firewallix.jacobs-university.de [212.201.44.246]) by beadg.de (Postfix) with ESMTPSA id 35EA116A054; Wed, 18 Dec 2024 20:01:08 +0100 (CET)
Date: Wed, 18 Dec 2024 20:01:07 +0100
From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6991-bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net
Message-ID: <Z2Mb84EDZTlt-39L@alice.eecs.jacobs-university.de>
Mail-Followup-To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6991-bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net
References: <173300872561.1209392.14021524612881553547@dt-datatracker-5679c9c6d-qbvvv> <Z1i0njRttnEEdXS-@alice.eecs.jacobs-university.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z1i0njRttnEEdXS-@alice.eecs.jacobs-university.de>
Message-ID-Hash: C7MU43IUPWNVGYIOP6AU4ZNZZIZF5XJW
X-Message-ID-Hash: C7MU43IUPWNVGYIOP6AU4ZNZZIZF5XJW
X-MailFrom: jschoenwaelder@constructor.university
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
Subject: [netmod] Re: Erik Kline's No Objection on draft-ietf-netmod-rfc6991-bis-17: (with COMMENT)
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X6vN1MKs8bOCGs1hNK_Wmo3iNXY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>
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.
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
- [netmod] Erik Kline's No Objection on draft-ietf-… Erik Kline via Datatracker
- [netmod] Re: Erik Kline's No Objection on draft-i… Jürgen Schönwälder
- [netmod] Re: Erik Kline's No Objection on draft-i… Jürgen Schönwälder
- [netmod] Re: Erik Kline's No Objection on draft-i… Erik Kline
- [netmod] Re: Erik Kline's No Objection on draft-i… Jürgen Schönwälder
- [netmod] Re: Erik Kline's No Objection on draft-i… mohamed.boucadair
- [netmod] Re: Erik Kline's No Objection on draft-i… Erik Kline
- [netmod] Re: Erik Kline's No Objection on draft-i… Mahesh Jethanandani
- [netmod] Re: Erik Kline's No Objection on draft-i… Erik Kline