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

[Alanna Paloma <[e-mail]>]

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