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

[Alanna Paloma <[e-mail]>]

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]>; [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
>> 
>> 
>