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

Alanna Paloma <apaloma@amsl.com> Thu, 04 August 2022 00:48 UTC

Return-Path: <apaloma@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 6CB44C14CF11; Wed, 3 Aug 2022 17:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FAsdUv-5DvoZ; Wed, 3 Aug 2022 17:48:51 -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 65207C14CF04; Wed, 3 Aug 2022 17:48:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3E38B424B44D; Wed, 3 Aug 2022 17:48:51 -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 4TJ21BLhBGst; Wed, 3 Aug 2022 17:48:51 -0700 (PDT)
Received: from amss-mbp.attlocal.net (unknown [IPv6:2600:1700:bac0:1070:dcfe:4f1f:f724:77aa]) by c8a.amsl.com (Postfix) with ESMTPSA id D4933424B44B; Wed, 3 Aug 2022 17:48:50 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Alanna Paloma <apaloma@amsl.com>
In-Reply-To: <rt-4.4.3-8991-1659552209-1127.1237567-37-0@icann.org>
Date: Wed, 03 Aug 2022 17:48:49 -0700
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, otroan@employees.org, Erik Kline <ek.ietf@gmail.com>, auth48archive@rfc-editor.org, 6man-chairs@ietf.org, 6man-ads@ietf.org, Amanda Baber via RT <iana-issues@iana.org>, Sandy Ginoza <sginoza@amsl.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ED01300-D217-4F9C-9A94-52624AF72360@amsl.com>
References: <RT-Ticket-1237567@icann.org> <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> <323E6ED2-7FC1-4EFF-915F-9BC79CFA69FA@amsl.com> <28189A1B-5042-41D1-B22E-290F99402F7F@gmail.com> <rt-4.4.3-8991-1659552209-1127.1237567-37-0@icann.org>
To: Bob Hinden <bob.hinden@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/1OHycgUNpUN0jOOGS_TfYOEhdrc>
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: Thu, 04 Aug 2022 00:48:55 -0000

Hi Bob and Gorry,

Thank you for your replies.  We have updated the files as follows:

1) 
>> The original xml contained this text formatted within <artwork>; however, this is semantically incorrect,
> 
> Sorry, I don’t follow.  Why is it “semantically incorrect”.   It correctly describes the content of the header.

Apologies for not clarifying. The formatting of the text was semantically incorrect because it was originally formatted within <artwork>; however, the text is not <artwork>, so we have updated the files with our suggested formatting. Please review and let us know if further updates are needed.

2) We have updated the IANA Considerations section to include mention of the "Internet Protocol Version 6 (IPv6) Parameters” registry per Amanda’s guidance.

Current:
  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 group [IANA-HBH].) 

…

The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9268.xml
https://www.rfc-editor.org/authors/rfc9268.txt
https://www.rfc-editor.org/authors/rfc9268.html
https://www.rfc-editor.org/authors/rfc9268.pdf

The relevant diff files have been posted here:
https://www.rfc-editor.org/authors/rfc9268-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9268-rfcdiff.html (comprehensive diff with changes side by side)
https://www.rfc-editor.org/authors/rfc9268-auth48diff.html (AUTH48 changes)

The AUTH48 status of the document can be seen here:
  https://www.rfc-editor.org/auth48/rfc9268

Thank you.
RFC Editor/ap

> On Aug 3, 2022, at 11:43 AM, Amanda Baber via RT <iana-issues@iana.org> wrote:
> 
> Hi Bob, all,
> 
> On Wed Aug 03 15:31:10 2022, bob.hinden@gmail.com wrote:
>> Sandy,
>> 
>> Thanks very much, a few comments below.
>> 
>> Bob
>> 
>> 
>>> On Aug 2, 2022, at 4:15 PM, Sandy Ginoza <sginoza@amsl.com> wrote:
>>> 
>>> 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].)
>> 
>> Yes, that would help.
> 
> I'd recommend changing "registry" to "registry group" in that last line:
> 
> 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 group [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.
>> 
>> That would be helpful.
> 
> IANA is in the process of moving from an XML-based to a database-based registry system. Once this change has been implemented, https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 will still work, but will take you only to the list of IPv6 Parameters registries that includes Destination Options and Hop-by-Hop Options, rather than Destination Options and Hop-by-Hop Options itself. We will provide permanent links to specific registries like Destination Options and Hop-by-Hop Options, but that system isn't yet available. 
> 
> Best regards,
> 
> Amanda Baber
> IANA Operations Manager