Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-intarea-rfc7042bis-11> for your review

["Eric Vyncke (evyncke)" <[e-mail]>]

Indeed, big thank you to all !

Envoyé à partir de Outlook pour Android<https://aka.ms/AAb9ysg>
________________________________
From: Alanna Paloma <[e-mail]>
Sent: Tuesday, April 9, 2024 8:31:41 PM
To: Yizhou Li <[e-mail]>; [e-mail] <[e-mail]>; Donald Eastlake <[e-mail]>
Cc: RFC Errata System <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>; auth48archive@rfc-ed <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9542 <draft-ietf-intarea-rfc7042bis-11> for your review

Authors,

As IANA has updated their registry accordingly and we have received all necessary approvals, we consider AUTH48 complete:
https://www.rfc-editor.org/auth48/rfc9542

Thank you for your attention and guidance during the AUTH48 process.
We will move this document forward in the publication process at this time.

RFC Editor/ap

> On Apr 9, 2024, at 11:13 AM, David Dong via RT <[e-mail]> 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, [e-mail] 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 <[e-mail]> 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 <[e-mail]> wrote:
>>>>
>>>> Hi Alanna,
>>>>
>>>>
>>>> I approve.
>>>>
>>>> Cheers,
>>>> Yizhou
>>>>
>>>> -----Original Message-----
>>>> From: Alanna Paloma [mailto:[e-mail]]
>>>> Sent: Tuesday, April 9, 2024 2:28 AM
>>>> To: Donald Eastlake <[e-mail]>
>>>> Cc: RFC Errata System <[e-mail]>;
>>>> [e-mail]; Yizhou Li <[e-mail]>; intarea-
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]
>>>> 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 <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Fri, Apr 5, 2024 at 2:22 AM <[e-mail]> 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   [phone] (cell)
>>>>> 2386 Panoramic Circle, Apopka, FL 32703 USA [e-mail]
>>>>>
>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> RFC Editor/ap/ar
>>>>>>
>>>>>>
>>>>>> On Apr 4, 2024, [e-mail] 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
>>>>>>
>>>>>> *  [e-mail] (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).
>>>>>>
>>>>>> *  [e-mail], 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,
>>>>>>   [e-mail] 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
>>>>
>>>>
>>>
>