Re: [auth48] AUTH48: RFC-to-be 9268 <draft-ietf-6man-mtu-option-15> for your review

Sandy Ginoza <sginoza@amsl.com> Tue, 02 August 2022 23:15 UTC

Return-Path: <sginoza@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BA3C14F744; Tue, 2 Aug 2022 16:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 HpSKqSCxKvL6; Tue, 2 Aug 2022 16:15:40 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330DBC14F740; Tue, 2 Aug 2022 16:15:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id F32CE4243EC1; Tue, 2 Aug 2022 16:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVAlJvaTBC6F; Tue, 2 Aug 2022 16:15:39 -0700 (PDT)
Received: from smtpclient.apple (2603-8000-9603-b513-0966-acf4-04b2-4bcb.res6.spectrum.com [IPv6:2603:8000:9603:b513:966:acf4:4b2:4bcb]) by c8a.amsl.com (Postfix) with ESMTPSA id A086B424B455; Tue, 2 Aug 2022 16:15:39 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Sandy Ginoza <sginoza@amsl.com>
In-Reply-To: <4BA3B35B-3A7D-4EFE-A7A8-581BCF0CFFAC@gmail.com>
Date: Tue, 02 Aug 2022 16:15:26 -0700
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, RFC Editor <rfc-editor@rfc-editor.org>, 6man-ads@ietf.org, 6man Chairs <6man-chairs@ietf.org>, Ole Trøan <otroan@employees.org>, Erik Kline <ek.ietf@gmail.com>, auth48archive@rfc-editor.org, iana@iana.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <323E6ED2-7FC1-4EFF-915F-9BC79CFA69FA@amsl.com>
References: <20220714145855.6FBE76AA26@rfcpa.amsl.com> <5B5B0365-137E-4709-ACC5-2252C499FF71@gmail.com> <bb4df2aa-f475-fda4-88a5-ba6e99879ade@erg.abdn.ac.uk> <D302102C-963C-4591-8ACD-155E7824B4A4@amsl.com> <4BA3B35B-3A7D-4EFE-A7A8-581BCF0CFFAC@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/uuqP0H6KhanarLf7rkNant25a4w>
Subject: Re: [auth48] AUTH48: RFC-to-be 9268 <draft-ietf-6man-mtu-option-15> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 23:15:44 -0000

Hi Bob, IANA,

Just jumping in on this one — I’ve added IANA to this thread so they can chime in if we’ve misunderstood or in case anything has changed. 

> On Aug 2, 2022, at 2:26 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
> 
>>>> 
>>>> I note that the reference to the IANA HBH option registry was changed from:
>>>> 
>>>>  [IANA-HBH] "Destination Options and Hop-by-Hop Options",
>>>> 
>>>> <https://www.iana.org/assignments/ipv6-parameters/
>>>>             ipv6-parameters.xhtml#ipv6-parameters-2>
>>>> .
>>>> 
>>>> to:
>>>> 
>>>>  [IANA-HBH] IANA, "Destination Options and Hop-by-Hop Options",
>>>> 
>>>> <https://www.iana.org/assignments/ipv6-parameters/>
>>>> .
>>>> 
>>>> The original reference goes directly the specific Destination Options and Hop-by-Hop Options registry, where the new one goes to the general IPv6 parameter registry.   Why the change?
>> 
>> We updated the reference per input from IANA. IANA recommended that RFCs point to the top-most registry since they are considered stable; they prefer that the direct URLs to specific registries on a page not be used.
> 
> I wasn’t aware of that.   The result is a little confusing.  The text in the reference says:
> 
> "Destination Options and Hop-by-Hop Options”
> 
> but it goes to a page titled:
> 
> Internet Protocol Version 6 (IPv6) Parameters

I see what you’re saying.  My hope is that a reader will search for the registry title on the main page.  Would it be more clear to add some text where the registry is cited?  For example:

IANA has registered an IPv6 Hop-by-Hop Option type in the "Destination Options and Hop-by-Hop Options" registry within the "Internet Protocol Version 6 (IPv6) Parameters” registry [IANA-HBH].)



> Would something like the following be better?
> 
> IANA, "Destination Options and Hop-by-Hop Options”, Internet Protocol Version 6 (IPv6) Parameters, <https://www.iana.org/ assignments/ipv6-parameters/>.

The current format is based on IANA’s input.  We suggested a similar format in the past, but there was a preference not to include the top-level registry/group title as the page may/will be formatted differently in the future (e.g., the registry/group title may change or no longer appear).  

Previously proposed: 
[NAME]  IANA, "Top-Level Registry Name: Registry Name", <URL to top-level registry>.


> Seems to me that for IANA registries that are stable, like this one, it’s not too burdensome for IANA to have a stable link to each sub-registry.

I believe this is in the works.

Thanks,
Sandy