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
