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

[David Dong via RT <[e-mail]>]

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
> >>
> >>
> >