Re: [auth48] [IANA #1362724] [IANA] Re: AUTH48: RFC-to-be 9542 <draft-ietf-intarea-rfc7042bis-11> for your review
Alanna Paloma <apaloma@amsl.com> Tue, 09 April 2024 18:28 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 F34D5C14F5E8; Tue, 9 Apr 2024 11:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 EqwSSC4LfNdb; Tue, 9 Apr 2024 11:28:16 -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 A1034C14CF17; Tue, 9 Apr 2024 11:28:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7EF41424B427; Tue, 9 Apr 2024 11:28:16 -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 Wam1YXzwYlJ0; Tue, 9 Apr 2024 11:28:16 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2600:1700:65a2:2250:318d:abf2:c2aa:5cc2]) by c8a.amsl.com (Postfix) with ESMTPSA id E795A424B426; Tue, 9 Apr 2024 11:28:15 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Alanna Paloma <apaloma@amsl.com>
In-Reply-To: <rt-5.0.3-1441350-1712686436-41.1362724-37-0@icann.org>
Date: Tue, 09 Apr 2024 11:28:05 -0700
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Yizhou Li <liyizhou@huawei.com>, jabley@strandkip.nl, intarea-chairs@ietf.org, intarea-ads@ietf.org, iana@iana.org, ggx@gigix.net, evyncke@cisco.com, d3e3e3@gmail.com, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <419A3DE8-3173-4A0B-8D5B-038864A2B5D2@amsl.com>
References: <RT-Ticket-1362724@icann.org> <20240405062213.3F05C139094C@rfcpa.amsl.com> <CAF4+nEF5wX271HhWM8rx4YMV5rAgyP8ruT0j5M-xbZoXDAuy1g@mail.gmail.com> <252ABAC2-5517-45BE-9324-372DBF27F981@amsl.com> <955c4e1bea0945d9a2e9038f3c6cfd89@huawei.com> <62B177DA-96C7-40E8-8F90-A79264582221@amsl.com> <E0D0CFE8-6D49-45A4-9607-8825A0DD46DC@amsl.com> <rt-5.0.3-1441350-1712686436-41.1362724-37-0@icann.org>
To: David Dong via RT <iana-matrix@iana.org>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/1uv_KPtbU4eKU2sTo7rHMpT04u0>
Subject: Re: [auth48] [IANA #1362724] [IANA] Re: AUTH48: RFC-to-be 9542 <draft-ietf-intarea-rfc7042bis-11> 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, 09 Apr 2024 18:28:21 -0000
Hi David, Thank you for the quick turnaround! The changes look good. Best regards, RFC Editor/ap > On Apr 9, 2024, at 11:13 AM, David Dong via RT <iana-matrix@iana.org> wrote: > > Hi Alanna, > > These changes are complete: > > IANA Unicast 48-bit MAC Addresses > Note > These values are prefixed with 00-00-5E. See Section 2.1.3 of > [RFC-ietf-intarea-rfc7042bis-11] > > IANA Multicast 48-bit MAC Addresses > Note > These values are prefixed with 00-00-5E. See Section 2.1.3 of > [RFC-ietf-intarea-rfc7042bis-11] > > 10-00-00-01-00 to EF-FF-FF-FF-FF Unassigned > > Please see: > https://www.iana.org/assignments/ethernet-numbers/ > > We will update the references in the Notes to the RFC after the RFC has been published. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Tue Apr 09 16:16:59 2024, apaloma@amsl.com wrote: >> IANA, >> >> Please update your registries as follows to match the edited document >> at https://www.rfc-editor.org/authors/rfc9542-diff.html. >> >> 1) Please update the section number to be Section 2.1.3 in the notes >> for the “IANA Unicast 48-bit MAC Addresses” and "IANA Multicast 48-bit >> MAC Addresses” registries <https://www.iana.org/assignments/ethernet- >> numbers/>. >> >> Old: >> IANA Unicast 48-bit MAC Addresses: >> These values are prefixed with 00-00-5E. See Section 2.1.5 of [RFC- >> ietf-intarea-rfc7042bis-11] >> >> IANA Multicast 48-bit MAC Addresses: >> These values are prefixed with 01-00-5E. See Section 2.1.4 of [RFC- >> ietf-intarea-rfc7042bis-11] >> >> New (for both registries): >> These values are prefixed with 00-00-5E. See Section 2.1.3 of RFC >> 9542. >> >> >> 2) Please update “FC” to be “EF” in the following entry in the "IANA >> 64-bit MAC Addresses” registry >> <https://www.iana.org/assignments/ethernet-numbers/>. >> >> Old: >> 10-00-00-01-00 to FC-FF-FF-FF-FF >> >> New: >> 10-00-00-01-00 to EF-FF-FF-FF-FF >> >> Best regards, >> RFC Editor/ap >> >>> On Apr 9, 2024, at 8:58 AM, Alanna Paloma <apaloma@amsl.com> wrote: >>> >>> Authors, >>> >>> Yizhou’s approval has been noted on the AUTH48 status page: >>> https://www.rfc-editor.org/auth48/rfc9542 >>> >>> We will now ask IANA to update their registry accordingly. After the >>> IANA updates are complete, we will move forward with the publication >>> process. >>> >>> Thank you, >>> RFC Editor/ap >>> >>>> On Apr 8, 2024, at 6:03 PM, Yizhou Li <liyizhou@huawei.com> wrote: >>>> >>>> Hi Alanna, >>>> >>>> >>>> I approve. >>>> >>>> Cheers, >>>> Yizhou >>>> >>>> -----Original Message----- >>>> From: Alanna Paloma [mailto:apaloma@amsl.com] >>>> Sent: Tuesday, April 9, 2024 2:28 AM >>>> To: Donald Eastlake <d3e3e3@gmail.com> >>>> Cc: RFC Errata System <rfc-editor@rfc-editor.org>; >>>> jabley@strandkip.nl; Yizhou Li <liyizhou@huawei.com>; intarea- >>>> ads@ietf.org; intarea-chairs@ietf.org; ggx@gigix.net; >>>> evyncke@cisco.com; auth48archive@rfc-editor.org >>>> Subject: Re: AUTH48: RFC-to-be 9542 <draft-ietf-intarea-rfc7042bis- >>>> 11> for your review >>>> >>>> Hi Donald, >>>> >>>> Thank you for your reply. We have updated as requested. >>>> >>>>>> b) "EF" has been changed to "FC" to match the IANA registry as >>>>>> follows. >>>>>> Please let us know if this is not correct. >>>>>> >>>>>> Original: >>>>>> 02-00-5E-10-00-00-01-00 to 02-00-5E-EF-FF-FF-FF-FF available for >>>>>> assignment >>>>>> >>>>>> Current: >>>>>> 02-00-5E-10-00-00-01-00 to 02-00-5E-FC-FF-FF-FF-FF available for >>>>>> assignment >>>>> >>>>> I believe the IANA registry (for which I am the primary expert) is >>>>> wrong. This has consistently been "EF" in the RFCs back through RFC >>>>> 7042 and RFC 5342. Looks like an error on my part in reviewing the >>>>> IANA registry 16 years ago back in 2008. This correction to the >>>>> IANA >>>>> registry clearly does not affect any existing assignments or the >>>>> like >>>>> so it should be straight forward. Should I send a separate message >>>>> to >>>>> IANA? >>>> >>>> ) After we have received approvals from each author, we will send >>>> mail to IANA to update their registry accordingly. >>>> ... >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9542.xml >>>> https://www.rfc-editor.org/authors/rfc9542.txt >>>> https://www.rfc-editor.org/authors/rfc9542.html >>>> https://www.rfc-editor.org/authors/rfc9542.pdf >>>> >>>> The relevant diff files have been posted here: >>>> https://www.rfc-editor.org/authors/rfc9542-diff.html (comprehensive >>>> diff) https://www.rfc-editor.org/authors/rfc9542-auth48diff.html >>>> (AUTH48 changes) >>>> >>>> Please review the document carefully and contact us with any further >>>> updates you may have. Note that we do not make changes once a >>>> document is published as an RFC. >>>> >>>> We will await approvals from each party listed on the AUTH48 status >>>> page below prior to moving this document forward in the publication >>>> process. >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9542 >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On Apr 7, 2024, at 4:03 PM, Donald Eastlake <d3e3e3@gmail.com> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Fri, Apr 5, 2024 at 2:22 AM <rfc-editor@rfc-editor.org> wrote: >>>>>> >>>>>> Authors, >>>>>> >>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML >>>>>> file. >>>>>> >>>>>> 1) <!--[rfced] FYI, because this document obsoletes RFC 7042, it >>>>>> has >>>>>> been assigned BCP 141 (the same BCP number as RFC 7042). >>>>>> If you prefer otherwise, please let us know. >>>>>> --> >>>>> >>>>> That's the right thing. >>>>> >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>> appear >>>>>> in the title) for use on https://www.rfc-editor.org/search. --> >>>>> >>>>> All the keywords from RFC 7042 should carry over. I believe those >>>>> are >>>>> Ethernet, EtherType, 802, OUI, EUI, LSAP In addition you should >>>>> add the following keywords >>>>> AFN, CBOR, LLC, SLAP, SNAP, CID >>>>> >>>>>> 3) <!--[rfced] To avoid this hyphenation, may we update "IEEE >>>>>> 802-related" as follows? >>>>>> >>>>>> Original: >>>>>> Some IETF protocols use Ethernet or other IEEE 802-related >>>>>> communication frame formats and parameters [IEEE802]. >>>>>> ... >>>>>> IEEE Std 802 describes assignment procedures and policies for IEEE >>>>>> 802-related identifiers [IEEE802_OandA]. >>>>>> >>>>>> Perhaps: >>>>>> Some IETF protocols use Ethernet or other >>>>>> communication frame formats and parameters related to IEEE 802 >>>>>> [IEEE802]. >>>>>> ... >>>>>> IEEE Std 802 describes assignment procedures and policies for >>>>>> identifiers related to IEEE 802 [IEEE802_OandA]. >>>>>> --> >>>>> >>>>> OK. >>>>> >>>>>> 4) <!--[rfced] Section 1.1: We suggest removing the quotation >>>>>> marks >>>>>> from this section, as they are not typically used in this manner. >>>>>> (Although they are used in RFC 7042, this is an opportunity to >>>>>> improve the document.) Please let us know if this change is >>>>>> acceptable. >>>>>> >>>>>> Current: >>>>>> "AFN" Address Family Number [RFC4760]. >>>>>> >>>>>> "CBOR" Concise Binary Object Representation [RFC8949]. >>>>>> >>>>>> "CFM" Connectivity Fault Management [RFC7319]. >>>>>> >>>>>> [...] >>>>>> >>>>>> Suggested: >>>>>> AFN Address Family Number [RFC4760]. >>>>>> >>>>>> CBOR Concise Binary Object Representation [RFC8949]. >>>>>> >>>>>> CFM Connectivity Fault Management [RFC7319]. >>>>>> >>>>>> [...] >>>>>> --> >>>>> >>>>> I would prefer to leave in the quote marks notwithstanding that >>>>> this >>>>> is not consistent with many other RFCs. My reasons are (1) the last >>>>> entry for "**" would be confusing without the quotes and confusing >>>>> in >>>>> a different way if it was the only entry with quotes, (2) there are >>>>> a >>>>> few multi-word entries for which I think the quotes help a little, >>>>> and >>>>> (3) this is consistent with the previous RFCs in this series: 7042 >>>>> and >>>>> 5342. >>>>> >>>>>> 5) <!-- [rfced] Please review whether any of the notes in this >>>>>> document (for example, the text marked "Historical Note" or >>>>>> "NOTE") >>>>>> should be in the <aside> element. It is defined as "a container >>>>>> for >>>>>> content that is semantically less important or tangential to the >>>>>> content that surrounds it" >>>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> >>>>> >>>>> An interesting question. Examining the "Notes" in this document, I >>>>> believe the one in the first part of Section 2 and the one in >>>>> Section >>>>> 2.3.1, that is to say the two "historical" notes, would reasonably >>>>> be >>>>> viewed as "asides". On the other hand, the two notes in Section >>>>> 2.1.1 >>>>> and the one in Section 5 are important parts of the main text of >>>>> the >>>>> document. >>>>> >>>>> Also, I notice that the two notes in Section 2.1.1 are somewhat >>>>> indented and by different amounts. I think this just follows the >>>>> draft >>>>> but seems wrong to the extent that it may give the false impression >>>>> that they are both subsidiary to the "Standard Assignment - ..." >>>>> item >>>>> just above them while only the first note is. I suggest making the >>>>> second of these two notes have the same indentation as the main >>>>> body >>>>> text (3 spaces for .txt, flush left for .pdf, ...). >>>>> >>>>>> 6) <!--[rfced] Would it be accurate for these instances of "2023" >>>>>> to be updated to "2024"? It seems the year of publication would >>>>>> make >>>>>> more sense here. >>>>>> Original: >>>>>> As of 2023 there >>>>>> are three lengths of prefixes assigned, as shown in the table >>>>>> below; >>>>>> however, some prefix bits can have special meaning as shown in >>>>>> Figure 1. >>>>>> ... >>>>>> As of 2023, 4 out of these 256 values have been >>>>>> assigned. >>>>>> ... >>>>>> As of 2023, 1 out of these 256 values has been >>>>>> assigned. >>>>>> ... >>>>>> As of 2023, 4 out of these 256 >>>>>> values have been assigned. >>>>>> ... >>>>>> As of 2023, 1 out of these 256 values has been >>>>>> assigned. >>>>>> --> >>>>> >>>>> Yes, I've checked and these can all be updated to 2024. >>>>> >>>>>> 7) <!--[rfced] We see that "universal/local" and "Local/Global" >>>>>> are >>>>>> both used to describe the X bit. Should this be made consistent? >>>>>> Original: >>>>>> X bit - This bit is also called the "universal/local" bit >>>>>> ... >>>>>> When so used, the EUI-64 is modified by >>>>>> inverting the X (Local/Global) bit to form an IETF "Modified EUI- >>>>>> 64 >>>>>> identifier". >>>>>> --> >>>>> >>>>> I believe IEEE favors the universal/local nomenclature so I guess >>>>> we >>>>> should go with that. However, at the first instance or the like, >>>>> please add a parenthetical "(formerly called Local/Global)" >>>>> >>>>>> 8) <!--[rfced] As the plus sign could indicate addition, may we >>>>>> replace it with "and"? >>>>>> >>>>>> Original: >>>>>> Y+Z bits - These two bits have no special meaning if the X bit is >>>>>> zero. >>>>>> >>>>>> Perhaps: >>>>>> Y and Z bits - These two bits have no special meaning if the X >>>>>> bit is >>>>>> zero. >>>>>> --> >>>>> >>>>> To avoid verbosity, how about "Y&Z"? >>>>> >>>>>> 9) <!--[rfced] Since two instances of "NOTE" are listed directly >>>>>> after this definition, should "see NOTE below" be more specific? >>>>>> >>>>>> Original: >>>>>> Standard Assigned - MAC addresses in this quadrant are called >>>>>> Standard Assigned Identifiers (SAIs). An SAI is assigned by a >>>>>> protocol specified in an IEEE 802 standard, for example >>>>>> [IEEE802.1CQ] (but see NOTE below). >>>>>> >>>>>> NOTE: While the SLAP has MAC addresses assigned through a local >>>>>> protocol in the SAI quadrant and assigned by a protocol >>>>>> specified in an IEEE 802 standard, the SLAP is optional. Local >>>>>> network administrators may use the IETF protocol provisions in >>>>>> [RFC8947] and [RFC8948] which support assignment of a MAC >>>>>> address in the local MAC address space using DHCPv6 [RFC8415] >>>>>> or other protocol methods. >>>>>> >>>>>> NOTE: There isn't any automated way to determine if or to what >>>>>> extent a local network is configured for and/or operating >>>>>> according to SLAP. >>>>>> --> >>>>> >>>>> Yes, it would probably be good to change the referring text to "see >>>>> first NOTE below" and to decrease the indentation of the 2nd note, >>>>> which is actually related to much of the entire section. See item 5 >>>>> above. >>>>> >>>>>> 10) <!--[rfced] Regarding Section 2.2.2: >>>>>> >>>>>> a) Would it be acceptable to replace this list with a table that >>>>>> exactly matches the IANA registry (as shown in Table 3 of >>>>>> https://www.rfc-editor.org/authors/rfc9542-table.txt)? >>>>>> The rationale is so that the addresses and usage match the >>>>>> registry >>>>>> and because it is referred to as "[t]he following table". >>>>> >>>>> Replacing with the IANA table has the primary advantage of >>>>> including >>>>> the references clearly so I guess it is OK. >>>>> >>>>>> b) "EF" has been changed to "FC" to match the IANA registry as >>>>>> follows. >>>>>> Please let us know if this is not correct. >>>>>> >>>>>> Original: >>>>>> 02-00-5E-10-00-00-01-00 to 02-00-5E-EF-FF-FF-FF-FF available for >>>>>> assignment >>>>>> >>>>>> Current: >>>>>> 02-00-5E-10-00-00-01-00 to 02-00-5E-FC-FF-FF-FF-FF available for >>>>>> assignment >>>>> >>>>> I believe the IANA registry (for which I am the primary expert) is >>>>> wrong. This has consistently been "EF" in the RFCs back through RFC >>>>> 7042 and RFC 5342. Looks like an error on my part in reviewing the >>>>> IANA registry 16 years ago back in 2008. This correction to the >>>>> IANA >>>>> registry clearly does not affect any existing assignments or the >>>>> like >>>>> so it should be straight forward. Should I send a separate message >>>>> to >>>>> IANA? >>>>> >>>>>> c) If you choose the table, we note the "02-00-5E" is not >>>>>> included, >>>>>> so would you like to add text to the preceding paragraph in order >>>>>> to note that? >>>>>> Perhaps: >>>>>> >>>>>> These values are prefixed with 02-00-5E to form unicast modified >>>>>> EUI-64 addresses. >>>>>> --> >>>>> >>>>> Yes, if we convert to a table such a note is essential. >>>>> >>>>>> 11) <!--[rfced] To clarify "8 bits length", may we update this >>>>>> sentence as follows? >>>>>> >>>>>> Original: >>>>>> Should some other multiple of 8 bits length MAC >>>>>> addresses be used in the future, such as a 128-bit (16 octet) MAC >>>>>> address, the TBD1 tag will be used. >>>>>> >>>>>> Perhaps: >>>>>> Should some other multiple of 8 bits be used in the future >>>>>> for the length of MAC addresses, such as a 128-bit (16-octet) MAC >>>>>> address, the 48 tag will be used. >>>>>> --> >>>>> >>>>> That looks fine. >>>>> >>>>>> 12) <!--[rfced] As the protocol identifier uses "AA-AA", should >>>>>> the >>>>>> text be updated to reflect this? >>>>>> >>>>>> Original: >>>>>> xx-xx-AA-AA-03-yy-yy-yy-zz-zz >>>>>> >>>>>> where xx-xx is the frame length and, as above, must be small >>>>>> enough >>>>>> not to be confused with an EtherType; "AA" is the LSAP that >>>>>> indicates >>>>>> this use and is sometimes referred to as the SNAP Service Access >>>>>> Point (SNAP SAP); >>>>>> >>>>>> Perhaps: >>>>>> xx-xx-AA-AA-03-yy-yy-yy-zz-zz >>>>>> >>>>>> where xx-xx is the frame length and, as above, must be small >>>>>> enough >>>>>> not to be confused with an EtherType; "AA-AA" is the LSAP that >>>>>> indicates >>>>>> this use and is sometimes referred to as the SNAP Service Access >>>>>> Point (SNAP SAP); >>>>>> --> >>>>> >>>>> Well, that's actually an interesting question. The "AA-AA" is >>>>> actually >>>>> two protocol points, since it is "AA" appearing in both the DSAP >>>>> and >>>>> SSAP positions. So the current text is not wrong. On the other >>>>> hand, a >>>>> single AA code point is never, as far as I know, paired with a >>>>> different SSAP or DSAP code point. While this could go either way, >>>>> I >>>>> would prefer to leave the current wording. >>>>> >>>>>> 13) <!--[rfced] Should instances of "LLC control" be updated to >>>>>> read >>>>>> simply "LLC" to avoid redundancy (if expanded, "LLC protocol" >>>>>> would >>>>>> read as "Logical Link Control control"). Please review and let us >>>>>> know if any updates are needed. >>>>>> >>>>>> Original: >>>>>> ..."03" is the LLC control octet indicating datagram >>>>>> service; yy-yy-yy is an OUI; and zz-zz is a protocol number, under >>>>>> that OUI, assigned by the OUI owner. The five-octet length for >>>>>> such >>>>>> OUI-based protocol identifiers results, with the LLC control octet >>>>>> ("0x03"), in the preservation of 16-bit alignment. >>>>>> --> >>>>> >>>>> I think the wording needs to stay as is. "LLC" refers to the entire >>>>> header pattern of which the "control byte", value 03, is only part. >>>>> >>>>>> 14) <!--[rfced] May we clarify "it" in the list item to be "the >>>>>> assignment"? >>>>>> >>>>>> Original: >>>>>> New assignments of protocol numbers >>>>>> (qq-qq) under the IANA OUI must meet the following requirements: >>>>>> ... >>>>>> * it must be documented in an Internet-Draft or RFC, and >>>>>> --> >>>>> >>>>> "it" => "the protocol" >>>>> >>>>>> 15) <!--[rfced] We are having some difficulty parsing this >>>>>> sentence. >>>>>> How should it be updated for clarity? >>>>>> >>>>>> Original: >>>>>> (Either that EtherType can be used directly or, >>>>>> in the LSAPs case, using the SNAP SAP and putting an all-zeros >>>>>> "OUI" before the EtherType as described above.) >>>>>> >>>>>> Perhaps (where each hyphen would be two hyphens): >>>>>> >>>>>> (That EtherType can be used directly, or >>>>>> - in the LSAPs case - it can be used with the SNAP SAP by putting >>>>>> an all-zero "OUI" before the EtherType as described above.) >>>>>> --> >>>>> >>>>> Your re-wording is fine. >>>>> >>>>>> 16) <!--[rfced] Does "is felt to be large enough" mean "is >>>>>> considered >>>>>> to be large enough" or "is believed to be large enough"? Would it >>>>>> be >>>>>> more clear as one of those? >>>>>> >>>>>> Original: >>>>>> While finite, the universe of MAC code points from which Expert- >>>>>> judged assignments will be made is felt to be large enough that >>>>>> the >>>>>> requirements given in this document and the Experts' good judgment >>>>>> are sufficient guidance. >>>>>> --> >>>>> >>>>> "considered" is better. >>>>> >>>>>> 17) <!--[rfced] This document and the IANA registry do not match >>>>>> for >>>>>> the following description ("24-bit OUI" vs. "OUI"). Which one is >>>>>> correct? >>>>>> >>>>>> This document: >>>>>> | 24-bit OUI | 16391 | >>>>>> >>>>>> vs. IANA registry (https://www.iana.org/assignments/address- >>>>>> family-numbers):: >>>>>> 16391 OUI >>>>>> >>>>>> --> >>>>> >>>>> An OUI is always 24-bits long, just drop the "24-bit" here from the >>>>> document to make it consistent with the IANA registry. >>>>> >>>>>> 18) <!--[rfced] Section 5.7: Regarding the actual notes on the >>>>>> IANA >>>>>> registries, "IANA Unicast 48-bit MAC Addresses" mentions Section >>>>>> 2.1.5 and "IANA Multicast 48-bit MAC Addresses" mentions Section >>>>>> 2.1.4. >>>>>> >>>>>> For the latter, is 2.1.4 correct? >>>>>> This document indicates "Section 2.1.5" for both: >>>>>> >>>>>> The Notes for the "IANA Unicast 48-bit MAC Addresses" registry and >>>>>> for the "IANA Multicast 48-bit MAC Addresses" registry are changed >>>>>> to >>>>>> the following: >>>>>> >>>>>> | These values are prefixed with 00-00-5E. See Section 2.1.5 of >>>>>> RFC >>>>>> | 9542. >>>>>> --> >>>>> >>>>> Ahhh, looking at the purpose of this reference, I believe that both >>>>> the "IANA Unicast 48-bit MAC Addresses" registry and the "IANA >>>>> Multicast 48-bit MAC Addresses" registry notes should reference >>>>> 2.1.3, >>>>> not 2.1.5. So it is correct that they both reference the same >>>>> section, >>>>> it is just that they reference the wrong section right now. 2.1.3 >>>>> is >>>>> the 48-bit section parallel with what 2.2.2 is for 64-bit. >>>>> >>>>>> 19) <!-- [rfced] Would you like the references to be alphabetized >>>>>> or >>>>>> left in their current order? >>>>>> --> >>>>> >>>>> Please alphabetize. >>>>> >>>>>> 20) <!--[rfced] As this document informatively references RFC >>>>>> 5798, >>>>>> would you like to delay publishing in order to be published at the >>>>>> same time as draft-ietf-rtgwg-vrrp-rfc5798bis-18, which is also >>>>>> currently in the RFC Editor queue? --> >>>>> >>>>> I don't think the reason for this reference will change in any way >>>>> so >>>>> there is no reason to hold up publication of rfc7042bis. >>>>> >>>>>> 21) <!--[rfced] We note that the following term is used >>>>>> inconsistently throughout the document. Please review and let us >>>>>> know >>>>>> how it may be made consistent. >>>>>> >>>>>> 'CF Series' vs. CF Series vs. "CF" series >>>>>> --> >>>>> >>>>> I think the single/double quotes here can just be removed except >>>>> where >>>>> there is the literal quote of text taken from RFC 2153 which should >>>>> be >>>>> faithful to the punctuation in RFC 2153. >>>>> >>>>>> 22) <!-- [rfced] FYI, we have added expansions for the following >>>>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). >>>>>> Please >>>>>> review each expansion in the document carefully to ensure >>>>>> correctness. >>>>>> >>>>>> Network Layer Protocol Identifier (NLPID) >>>>>> --> >>>>> >>>>> OK. >>>>> >>>>>> 23) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>> the online Style Guide >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>> and let us know if any changes are needed. >>>>>> >>>>>> For example, please consider whether "sanity" should be updated. >>>>>> --> >>>>>> </back> >>>>> >>>>> You may replace "sanity" with "reasonableness". >>>>> >>>>> >>>>> CHANGES FROM REVIEW OF DOCUMENT: >>>>> >>>>> >>>>> Section 2.3.2: This is a pretty minor persnickety comment but in >>>>> the >>>>> .txt version I don't like where the line break falls in the >>>>> indented >>>>> text about CF-00-00. In particular, in the .txt version, it can be >>>>> mistaken for two separate lines of independent text, both >>>>> ungrammatical. To avoid this problem for some readers, I suggest >>>>> rewording this with no change in meaning as >>>>> >>>>> "CF-00-00 is reserved. CF-00-00-00-00-00 is a multicast identifier >>>>> listed by IANA as used for Ethernet loopback tests." >>>>> >>>>> This should move the line break to after CF-00-00-00-00-00 instead >>>>> of >>>>> just before CF-00-00-00-00-00 eliminating this minor problem. >>>>> (There >>>>> is no problem in the .html and .pdf versions.) >>>>> >>>>> >>>>> Effective April 2nd, I am no longer sponsored by Futurewei >>>>> Technologies. My affiliation need to be changed on the first page >>>>> and >>>>> in the Author Addresses section. >>>>> OLD >>>>> Futurewei Technologies >>>>> NEW >>>>> Independent >>>>> >>>>> >>>>> Acknowledgements >>>>> "people persons" -> "persons" >>>>> >>>>> >>>>> Thanks, >>>>> Donald >>>>> =============================== >>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>>> 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com >>>>> >>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/ap/ar >>>>>> >>>>>> >>>>>> On Apr 4, 2024, rfc-editor@rfc-editor.org wrote: >>>>>> >>>>>> *****IMPORTANT***** >>>>>> >>>>>> Updated 2024/04/04 >>>>>> >>>>>> RFC Author(s): >>>>>> -------------- >>>>>> >>>>>> Instructions for Completing AUTH48 >>>>>> >>>>>> Your document has now entered AUTH48. Once it has been reviewed >>>>>> and >>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>> If an author is no longer available, there are several remedies >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>> >>>>>> You and you coauthors are responsible for engaging other parties >>>>>> (e.g., Contributors or Working Group) as necessary before >>>>>> providing >>>>>> your approval. >>>>>> >>>>>> Planning your review >>>>>> --------------------- >>>>>> >>>>>> Please review the following aspects of your document: >>>>>> >>>>>> * RFC Editor questions >>>>>> >>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>> that have been included in the XML file as comments marked as >>>>>> follows: >>>>>> >>>>>> <!-- [rfced] ... --> >>>>>> >>>>>> These questions will also be sent in a subsequent email. >>>>>> >>>>>> * Changes submitted by coauthors >>>>>> >>>>>> Please ensure that you review any changes submitted by your >>>>>> coauthors. We assume that if you do not speak up that you agree >>>>>> to >>>>>> changes submitted by your coauthors. >>>>>> >>>>>> * Content >>>>>> >>>>>> Please review the full content of the document, as this cannot >>>>>> change once the RFC is published. Please pay particular attention >>>>>> to: >>>>>> - IANA considerations updates (if applicable) >>>>>> - contact information >>>>>> - references >>>>>> >>>>>> * Copyright notices and legends >>>>>> >>>>>> Please review the copyright notice and legends as defined in RFC >>>>>> 5378 and the Trust Legal Provisions (TLP – >>>>>> https://trustee.ietf.org/license-info/). >>>>>> >>>>>> * Semantic markup >>>>>> >>>>>> Please review the markup in the XML file to ensure that elements >>>>>> of >>>>>> content are correctly tagged. For example, ensure that >>>>>> <sourcecode> >>>>>> and <artwork> are set correctly. See details at >>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>> >>>>>> * Formatted output >>>>>> >>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>> formatted output, as generated from the markup in the XML file, is >>>>>> reasonable. Please note that the TXT will have formatting >>>>>> limitations compared to the PDF and HTML. >>>>>> >>>>>> >>>>>> Submitting changes >>>>>> ------------------ >>>>>> >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as >>>>>> all the parties CCed on this message need to see your changes. The >>>>>> parties >>>>>> include: >>>>>> >>>>>> * your coauthors >>>>>> >>>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>>> >>>>>> * other document participants, depending on the stream (e.g., >>>>>> IETF Stream participants are your working group chairs, the >>>>>> responsible ADs, and the document shepherd). >>>>>> >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing >>>>>> list >>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>> list: >>>>>> >>>>>> * More info: >>>>>> >>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- >>>>>> 4Q9l2USx >>>>>> IAe6P8O4Zc >>>>>> >>>>>> * The archive itself: >>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>> >>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>>> matter). >>>>>> If needed, please add a note at the top of the message that you >>>>>> have dropped the address. When the discussion is concluded, >>>>>> auth48archive@rfc-editor.org will be re-added to the CC list >>>>>> and >>>>>> its addition will be noted at the top of the message. >>>>>> >>>>>> You may submit your changes in one of two ways: >>>>>> >>>>>> An update to the provided XML file >>>>>> — OR — >>>>>> An explicit list of changes in this format >>>>>> >>>>>> Section # (or indicate Global) >>>>>> >>>>>> OLD: >>>>>> old text >>>>>> >>>>>> NEW: >>>>>> new text >>>>>> >>>>>> You do not need to reply with both an updated XML file and an >>>>>> explicit list of changes, as either form is sufficient. >>>>>> >>>>>> We will ask a stream manager to review and approve any changes >>>>>> that >>>>>> seem beyond editorial in nature, e.g., addition of new text, >>>>>> deletion >>>>>> of text, and technical changes. Information about stream managers >>>>>> can be found in the FAQ. Editorial changes do not require >>>>>> approval from a stream manager. >>>>>> >>>>>> >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> >>>>>> To approve your RFC for publication, please reply to this email >>>>>> stating that you approve this RFC for publication. Please use >>>>>> ‘REPLY >>>>>> ALL’, as all the parties CCed on this message need to see your >>>>>> approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> https://www.rfc-editor.org/authors/rfc9542.xml >>>>>> https://www.rfc-editor.org/authors/rfc9542.html >>>>>> https://www.rfc-editor.org/authors/rfc9542.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9542.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9542-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9542-rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9542-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9542 >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9542 (draft-ietf-intarea-rfc7042bis-11) >>>>>> >>>>>> Title : IANA Considerations and IETF Protocol and >>>>>> Documentation Usage for IEEE 802 Parameters >>>>>> Author(s) : D. Eastlake, J. Abley, Y. Li >>>>>> WG Chair(s) : Juan-Carlos Zúñiga, Wassim Haddad >>>>>> >>>>>> Area Director(s) : Erik Kline, Éric Vyncke >>>> >>>> >>> >
- [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-intar… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Donald Eastlake
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… jabley
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Donald Eastlake
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Yizhou Li
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Alanna Paloma
- [auth48] [IANA] Re: AUTH48: RFC-to-be 9542 <draft… Alanna Paloma
- [auth48] [IANA #1362724] [IANA] Re: AUTH48: RFC-t… David Dong via RT
- Re: [auth48] [IANA #1362724] [IANA] Re: AUTH48: R… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-i… Eric Vyncke (evyncke)