Authors, This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process.
Thank you, RFC Editor/st > On Jun 9, 2025, at 6:18 PM, rfc-edi...@rfc-editor.org wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > > 1) <!-- [rfced] Document title > > a) Please note that the title of the document has been updated as follows. We > expanded MAC and updated "Address" to "Addresses". Let us know any concerns. > > Original: > Randomized and Changing MAC Address: Context, Network Impacts, and Use Cases > > Current: > Randomized and Changing Media Access Control (MAC) Addresses: Context, > Network Impacts, and Use Cases > > b) Please review the abbreviated title and let us know if the current is okay > or > if any updates would be helpful. Note that the abbreviated title only appears > in > the pdf output (center of running header at the top of each page). > > Original: > RCM Use Cases > > Perhaps 1: > RCM > > Perhaps 2: > RCM: Context, Network Impacts, and Use Cases > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. > --> > > > 3) <!-- [rfced] We have a couple of questions about the following text in the > abstract. > > a) Please review "client and client Operating System vendors". Is this > correct? Or should this be updated to either "clients and OS vendors" or > "client OS vendors"? > > b) FYI - We removed the citation tags in the abstract per Section 4.3 > of RFC 7322 ("RFC Style Guide"). > > Original: > To limit the privacy issues created by the association between a > device, its traffic, its location, and its user in [IEEE_802] > networks, client and client Operating System vendors have started > implementing MAC address randomization. This technology is > particularly important in Wi-Fi [IEEE_802.11] networks due to the > over-the-air medium and device mobility. > > Perhaps 1: > To limit the privacy issues created by the association between a > device, its traffic, its location, and its user in IEEE 802 networks, > clients and OS vendors have started implementing > Media Access Control (MAC) address randomization. This technology is > particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the > over-the-air medium and device mobility. > > Perhaps 2: > To limit the privacy issues created by the association between a > device, its traffic, its location, and its user in IEEE 802 networks, > client OS vendors have started implementing > Media Access Control (MAC) address randomization. This technology is > particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the > over-the-air medium and device mobility. > --> > > > 4) <!-- [rfced] We updated "two existing frameworks" to "some existing > frameworks" because Appendix A includes three frameworks. Please review > and let us know any concerns. > > Original: > Last, this document > examines two existing frameworks to maintain user privacy while > preserving user quality of experience and network operation > efficiency. > > Updated: > Last, this document > examines some existing frameworks that maintain user privacy while > preserving user quality of experience and network operation > efficiency. > --> > > > 5) <!-- [rfced] We're having trouble following the text within the > parentheses, > specifically "also called in this document device, or machine". Would the > following retain the original meaning? > > Original: > At the same time, some network services rely on the end station (as > defined by the [IEEE_802] Standard, also called in this document > device, or machine) providing an identifier, which can be the MAC > address or another value. > > Perhaps: > At the same time, some network services rely on the end station (as defined > by [IEEE_802]) to provide an identifier, which can be the MAC address or > another value. This document also refers to the end station > as a "device" or "machine". > --> > > > 6) <!-- [rfced] Throughout the document, we made updates to avoid using IEEE > citation > tags as adjectives. Please review the diff file for these. We have > questions about specific instances below. > > a) We have updated "[IEEE_802.3] networks" as shown below. However, does this > refer to "Ethernet networks"? If so, would further updating be helpful? > > Original: > Although this document mainly discusses MAC-Address randomization in > Wi-Fi [IEEE_802.11] networks, same principles can be easily extended > to any [IEEE_802.3] networks. > ... > Multiple > services are defined for [IEEE_802.3] networks, and multiple > services defined by the IEEE 802.1 working group are also > applicable to [IEEE_802.3] networks. > > Current: > Although this document mainly discusses MAC address randomization in > Wi-Fi networks [IEEE_802.11], the same principles can be easily > extended to any IEEE 802.3 networks [IEEE_802.3]. > ... > Multiple > services are defined for IEEE 802.3 networks [IEEE_802.3], and multiple > services defined by the IEEE 802.1 working group are also > applicable to IEEE 802.3 networks [IEEE_802.3]. > > Perhaps: > Although this document mainly discusses MAC address randomization in > Wi-Fi networks [IEEE_802.11], the same principles can be easily > extended to Ethernet networks [IEEE_802.3]. > ... > Multiple > services are defined for Ethernet networks [IEEE_802.3], and multiple > services defined by the IEEE 802.1 working group are also > applicable to Ethernet networks [IEEE_802.3]. > > > b) We updated "[IEEE_802.11] or Wi-Fi" and "[IEEE_802.3] or Ethernet" as > follows. Let us know any concerns. > > Original: > 2. Other network devices operating at the MAC layer: many wireless > network access devices (e.g., [IEEE_802.11] access points) are > conceived as layer-2 devices, and as such, they bridge a frame > from one medium (e.g., [IEEE_802.11] or Wi-Fi) to another (e.g., > [IEEE_802.3] or Ethernet). > > Updated: > 2. Other network devices operating at the MAC layer: many wireless > network access devices (e.g., access points [IEEE_802.11]) are > conceived as Layer 2 devices, and as such, they bridge a frame > from one medium (e.g., Wi-Fi [IEEE_802.11]) to another (e.g., > Ethernet [IEEE_802.3]). > --> > > > 7) <!-- [rfced] Will it be clear to readers what was initially intended as a > 48-bit value? The MAC layer, the MAC address, or something else? > > Original: > Initially intended as a 48-bit (6 octets) value in the first versions > of the [IEEE_802.3] Standard, other Standards under the [IEEE_802.3] > umbrella allow this address to take an extended format of 64 bits (8 > octets) which enable a larger number of MAC addresses to coexist as > the 802.3 technologies became widely adopted. > > Perhaps: > In the first versions of [IEEE_802.3], the MAC layer was intended to be a > 48-bit (6-octet) value, but other standards under the IEEE 802.3 > umbrella [IEEE_802.3] allow this address to take an extended format of 64 > bits (8 > octets), which enabled a larger number of MAC addresses to coexist as > the 802.3 technologies became widely adopted. > > Or: > In the first versions of [IEEE_802.3], the MAC address was intended to be a > 48-bit (6-octet) value, but other standards under the IEEE 802.3 > umbrella [IEEE_802.3] allow this address to take an extended format of 64 > bits (8 > octets), which enabled a larger number of MAC addresses to coexist as > the 802.3 technologies became widely adopted. > --> > > > 8) <!-- [rfced] How may we clarify "to register to IEEE" here? Does the IEEE > require the registration, or is the IEEE where these addresses are > registered? > > Original: > Note that universally administered MAC addresses are > required to register to IEEE while locally administered MAC addresses > are not. > > Perhaps 1: > Note that universally administered MAC addresses are > required to be registered with the IEEE, while locally administered MAC > addresses > are not. > > Perhaps 2: > Note that the IEEE requires that universally administered MAC addresses > be registered, but registration of locally administered MAC addresses > is not required. > --> > > > 9) <!-- [rfced] It seems that the definitions for "shared service device" and > "personal device" appear in Section 6.2 of [IEEE_802E] (not Section 6.2 > of [IEEE_802]). We updated the introductory sentence below > accordingly. Please review. > > Original: > However, the same > evolution brought the distinction between two types of devices that > the [IEEE_802] Standard generally referred to as 'nodes in a > network'. Their definition is found in the [IEEE_802E] Recommended > Practice stated in Section 6.2 of [IEEE_802]. > > Current: > However, the same > evolution brought the distinction between two types of devices that > [IEEE_802] generally refers to as "nodes in a > network" (see Section 6.2 of [IEEE_802E] for definitions of these devices): > --> > > > 10) <!-- [rfced] We are having trouble understanding the text in parentheses > in the > sentence below. Please clarify. > > Original: > For most of them, and in > particular for [IEEE_802.11], the source and destination MAC > addresses are not encrypted even in networks that implement > encryption (so that each machine can easily detect if it is the > intended target of the message before attempting to decrypt its > content, and also identify the transmitter, to use the right > decryption key when multiple unicast keys are in effect). > > Perhaps: > For most of them ([IEEE_802.11] in > particular), the source and destination MAC > addresses are not encrypted even in networks that implement > encryption. Thus, each machine can easily detect if it is the > intended target of the message before attempting to decrypt its > content and can also identify the transmitter in order to use the right > decryption key when multiple unicast keys are in effect. > --> > > > 11) <!-- [rfced] Is "device MAC" correct here, or should it be updated to > "device > MAC address"? > > Original: > As a device changes its network attachment (roams) from one > access point to another, the access points can exchange > contextual information, (e.g., device MAC, keying material), > allowing the device session to continue seamlessly. > > Perhaps: > As a device changes its network attachment (roams) from one > access point to another, the access points can exchange > contextual information (e.g., device MAC address and keying material), > allowing the device session to continue seamlessly. > --> > > > 12) <!-- [rfced] We are having trouble parsing this sentence, especially "to > other > mediums than [IEEE_802.3] (e.g., DOCSIS [DOCSIS]), which also > implements". How may we update to improve clarity? > > Original: > Wireless access points may > also connect to other mediums than [IEEE_802.3] (e.g., DOCSIS > [DOCSIS]), which also implements mechanisms under the umbrella of > the general 802 Standard, and therefore expect the unique and > persistent association of a MAC address to a device. > > Perhaps: > Wireless access points may > also connect using other mediums (e.g., the Data-Over-Cable Service > Interface Specification (DOCSIS) > [DOCSIS]) that implement mechanisms under the umbrella of > the general 802 Standard and therefore expect the unique and > persistent association of a MAC address to a device. > --> > > > 13) <!-- [rfced] We updated "wireless 802-technologies exchanges" as follows. > Let > us know if this is incorrect. > > Original: > as the transmitting or receiving > MAC address is usually not encrypted in wireless 802-technologies > exchanges, and as any protocol-compatible device in range of the > signal can read the frame header. > > Updated: > The transmitting or receiving MAC > address is usually not encrypted in wireless exchanges in IEEE 802 > technologies, > and any protocol-compatible device in range of the > signal can read the frame header. > --> > > > 14) <!-- [rfced] We updated the text in parentheses as follows for clarity. > Please > review to ensure that the updated text accurately conveys the intended > meaning. > > Original: > The device MAC address is not visible anymore > unless a mechanism copies the MAC address into a field that can > be read while the packet travels onto the next segment (e.g., > pre- [RFC4941] and pre-[RFC7217] IPv6 addresses built from the > MAC address). > > Updated: > The device MAC address is not visible anymore > unless a mechanism copies the MAC address into a field that can > be read while the packet travels to the next segment (e.g., > IPv6 addresses built from the MAC address prior to the use of the methods > defined in > [RFC4941] and [RFC7217]). > --> > > > 15) <!-- [rfced] We have two questions about the text below. > > a) In the sentence introducing the list, how may we clarify "what trust"? Is > the intent "the degree of trust"? > > b) Is text about "environment" needed in these descriptions of Full trust, > Selective trust, and Zero trust? > > Original: > It is useful to distinguish what trust a > personal device may establish with the different entities at play in > a network domain where a MAC address may be visible: > > 1. Full trust: there is environment where a device establishes a > trust relationship, and the device can share its persistent MAC > address with the access network devices (e.g., access point and > WLAN Controller). In this environment, the network provides > necessary security measures to prevent observers or network > actors from accessing PII. The device (or its user) also has > confidence that its MAC address is not shared beyond the layer-2 > broadcast domain boundary. > > 2. Selective trust: in another environment, depending on the pre- > defined privacy policies, a device may decide to use one pseudo- > persistent MAC address for a set of network elements and another > pseudo-persistent MAC address for another set of network > elements. Examples of privacy policies can be SSID and BSSID > combination, a particular time-of-day, or a pre-set time > duration. > > 3. Zero trust: in another environment, a device may randomize its > MAC address with any local entity reachable through the AP. It > may generate a temporary MAC address to each of them. That > temporary MAC address may or may not be the same for different > services. > > Perhaps: > It is useful to distinguish the degree of trust that a personal > device may establish with the different entities at play in a network > domain where a MAC address may be visible: > > 1. Full trust: The device establishes a > trust relationship and shares its persistent MAC > address with the access network devices (e.g., access point and > WLAN controller). The network provides > necessary security measures to prevent observers or network > actors from accessing PII. The device (or its user) also has > confidence that its MAC address is not shared beyond the Layer 2 > broadcast domain boundary. > > 2. Selective trust: Depending on the > predefined privacy policies, a device may decide to use one > pseudo-persistent MAC address for a set of network elements and > another pseudo-persistent MAC address for another set of network > elements. Examples of privacy policies can be a combination of > Service Set Identifier (SSID) and Basic Service Set Identifier > (BSSID), a particular time of day, or a preset time duration. > > 3. Zero trust: A device may randomize its > MAC address with any local entity reachable through the AP. It > may generate a temporary MAC address to each of them. That > temporary MAC address may or may not be the same for different > services. > --> > > > 16) <!-- [rfced] The title of Section 5 is "Environment" (we updated to the > plural > "Environments"). However, the title of Table 1 within this section is > "Use Cases". Please review the use of "environment" and "use case" > throughout the document, and let us know if any updates would be helpful. > --> > > > 17) <!-- [rfced] Will readers know what "it" refers to in the second and third > sentences below? > > Original: > Most devices in the > network only require simple connectivity so that the network > services are simple. For network support, it is also simple. It > is usually related to Internet connectivity. > --> > > > 18) <!-- [rfced] "Reverse Address Resolution Protocol (RARP)" does not appear > to > be mentioned in [RFC826]. It was defined in RFC 903 > (https://www.rfc-editor.org/info/rfc903). Are any updates are needed > here? Perhaps [RFC826] should be used for ARP and [RFC903] for RARP? > > Original: > MAC address randomization > can cause MAC address cache exhaustion, but also the need for > frequent Address Resolution Protocol (ARP), Reverse Address > Resolution Protocol (RARP) [RFC826], Neighbor Solicitation and, > Neighbor Advertisement [RFC4861] exchanges. > > Perhaps: > MAC address randomization > can cause MAC address cache exhaustion but also the need for frequent > Address Resolution Protocol (ARP) [RFC826], Reverse Address Resolution > Protocol (RARP) [RFC903], and Neighbor Solicitation and Neighbor > Advertisement [RFC4861] exchanges. > --> > > > 19) <!-- [rfced] We do not see "industrial environment" in Section 5. Is the > intent here "managed enterprises (environment type E in Section 5)"? > Please review and let us know if any updates would be helpful. > > Original: > In industrial environments, policies are associated with each group > of objects, including IoT devices. > --> > > > 20) <!-- [rfced] We made updates to many of the IEEE references (e.g., title > and > DOI). Please review for correctness. > --> > > > 21) <!-- [rfced] FYI - The following reference has been superseded; we > updated to > the most current version. Please review and confirm that this is > correct. > > Original: > [IEEE_802.3] > "IEEE 802.3-2018 - IEEE Standard for Ethernet", IEEE > 802.3 , 31 August 2018, > <https://standards.ieee.org/ieee/802.3/7071/>. > > Updated: > [IEEE_802.3] > IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, > DOI 10.1109/IEEESTD.2022.9844436, 29 July 2022, > <https://ieeexplore.ieee.org/document/9844436>. > --> > > > 22) <!-- [rfced] FYI - For the following reference entry, we updated the > title to > match the document itself. Please let us know if there is objection. > > Original: > [DOCSIS] "DOCSIS 4.0 Physical Layer Specification Version I06, DOI > CM-SP-CM-OSSIv4.0", CableLabs DOCSIS , March 2022, > <https://www.cablelabs.com/specifications/CM-SP-CM- > OSSIv4.0?v=I06>. > > Updated: > [DOCSIS] CableLabs, "Cable Modem Operations Support System > Interface Specification", Data-Over-Cable Service > Interface Specifications, DOCSIS 4.0, Version I06, March > 2022, <https://www.cablelabs.com/specifications/CM-SP-CM- > OSSIv4.0?v=I06>. > --> > > > 23) <!-- [rfced] For [IEEE_802.11bh], the link provided goes to an "Inactive - > Draft" standard. We were unable to find an active version of this > reference. Is there an active draft you would prefer to reference? > > For now, we have updated this reference with the information available at the > URL. > > Original: > [IEEE_802.11bh] > "IEEE 802.11bh-2023 - Wireless LAN Medium Access Control > (MAC) and Physical Layer (PHY) Specifications Amendment 8 > : Operation with Randomized and Changing MAC Addresses", > IEEE 802.11bh , 19 July 2023, > <https://ieeexplore.ieee.org/document/10214483>. > > Current: > [IEEE_802.11bh] > IEEE, "IEEE Draft Standard for Information Technology- > Telecommunications and Information Exchange Between > Systems Local and Metropolitan Area Networks - Specific > Requirements - Part 11: Wireless LAN Medium Access Control > (MAC) and Physical Layer (PHY) Specifications Amendment 8: > Operation with Randomized and Changing MAC Addresses", > IEEE P802.11bh/D1.0, 19 July 2023, > <https://ieeexplore.ieee.org/document/10214483>. > --> > > > 24) <!-- [rfced] Is "client device operating system vendor" correct here? We > see > "client OS vendor" elsewhere in the document. > > Original: > Most client device operating system vendors offer RCM schemes, > enabled by default (or easy to enable) on client devices. > > Perhaps: > Most client OS vendors offer RCM schemes that are > enabled by default (or easy to enable) on client devices. > --> > > > 25) <!-- [rfced] Terminology > > a) We see the following forms in the document. We updated to "MAC > address" for consistency. > > MAC Address > MAC-Address > MAC address > > > b) We see the forms below used in the document. Should these be > uniform? If so, please let us know which form is preferred. Another option > (not used in the document) is "MAC address of the device" and "MAC address of > the wireless device". > > device MAC address > device's MAC address > > device wireless MAC address > device's wireless MAC address > --> > > > 26) <!-- [rfced] Abbreviations > > a) FYI - We 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. > > BSSID - Basic Service Set Identifier > DOCSIS - Data-Over-Cable Service Interface Specification > DSCP - Differentiated Services Code Point > ECN - Explicit Congestion Notification > MAC - Media Access Control > SLAAC - Stateless Address Autoconfiguration > SSID - Service Set Identifier > > b) How may we expand AR and VR in the following sentence? > > Original: > Larger and more complex > networks can also incorporate more advanced services, from AAA to > AR/VR applications. > > Perhaps: > Larger and more complex > networks can also incorporate more advanced services, from AAA to > Augmented Reality (AR) or Virtual Reality (VR) applications. > --> > > > 27) <!-- [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. Updates of this nature typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > > In addition, please consider whether "tradition" should be updated for > clarity. While the NIST website indicates that this term is potentially > biased, it is also ambiguous. "Tradition" is a subjective term, as it is not > the same for everyone. See > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>. > > Original: > The federation structure extends the type > of authorities that can be used as identity sources (compared to > traditional enterprise-based 802.1X [IEEE_802.1X] scheme for Wi-Fi), > and facilitates the establishment of trust between local networks and > an identity provider. > --> > > > Thank you. > > RFC Editor/st/rv > > > > > On Jun 9, 2025, at 4:12 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/06/09 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9797.xml > https://www.rfc-editor.org/authors/rfc9797.html > https://www.rfc-editor.org/authors/rfc9797.pdf > https://www.rfc-editor.org/authors/rfc9797.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9797-diff.html > https://www.rfc-editor.org/authors/rfc9797-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9797-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9797 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9797 (draft-ietf-madinas-use-cases-19) > > Title : Randomized and Changing MAC Address: Context, Network > Impacts, and Use Cases > Author(s) : J. Henry, Y. Lee > WG Chair(s) : Carlos J. Bernardos, Juan-Carlos Zúñiga > > Area Director(s) : Erik Kline, Éric Vyncke > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
