Dear editor, Thank you for this detailed edit. We approve the publication, and provided the input requested inline below.
Best Yiu and Jerome. On 6/9/25, 7:20 PM, "rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>" <rfc-edi...@rfc-editor.org <mailto: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 [Authors] Change approved, thank you. 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 --> RCM: Context, Network Impacts, and Use Cases [Authors] 2 is better, as 1 merely names a mechanism. 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>. --> RCM, Universal MAC address, Local MAC address, Locally Administered MAC address, Personal Device, Shared Service Device, Network Functional Entities, Human-Related Entities, Over-the-Air (OTA) observers, Wireless access network operators, Network access providers, Over-the-Wired internal (OTWi) observers, Over-the-Wired external (OTWe) observers, full trust, selective trust, zero trust, privacy, Residential settings, Managed residential settings, public guest network, Enterprises with Bring-Your-Own-Device (BYOD), Managed Enterprises. [Authors] the keywords are sorted by decreasing order of importance, thus please feel free to remove as appropriate (starting from the end of the list) if you find that we proposed too many entries. 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"? [Authors] Correct as written, but maybe clumsy? The intent is client vendors, and client Operating System vendors. b) FYI - We removed the citation tags in the abstract per Section 4.3 of RFC 7322 ("RFC Style Guide"). [Authors] Acknowledged, thank you. 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. --> 1 reads better (the " This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the over-the-air medium and device mobility." Part). Clients and OS vendors, or client OS vendors does not read right, because we are talking about client vendors, and client OS vendors (contracting Operating System to OS is fine). Removing client from 'OS vendors" creates ambiguity. For example Citrix, or Cisco, produce OSes and are OS vendors, but not for clients (and have nothing to do with what the RFC discusses), so the expression needs to include client. Samsung is a client vendors, but not a client OS vendor. Google is a client OS vendor, but not a client vendor (we consider the Google Pixel phone as a proof of concept more than a real product). Apple is both a client vendor (iPhone/iPads) and a client OS vendor (iOS, iPadOS). Therefore, our recommendation is 1, but with the client and client OS vendors part, as in: 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 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. --> [authors] acknowledged, and thank you for the fix, approved. 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". --> [Authors] much better, thank you, approved. 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]. --> [Authors} The suggestion is better than the original, accepted. Indeed, 802.3 are Ethernet networks, and the rewording also makes the sentences easier to read. Thank you. 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]). --> [Authors] Accepted, thank you. 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. --> [Authors] The second proposal is better, but there is a typo. This paragraph does not reference 802.3, but just 802 (the umbrella standard above the 802.1, 802.3, 802.11 standards), thus: In the first versions of [IEEE_802], the MAC address was intended to be a 48-bit (6-octet) value, but other standards under the IEEE 802 umbrella [IEEE_802] 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 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. --> [Authors] 1 is better, thank you. Note that universally administered MAC addresses are required to be registered with the IEEE, while locally administered MAC addresses are not. 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): --> [Authors] Perfect thank you. 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. --> [Authors] The parenthesis explains why encryption is not in place for the addresses even in encrypted network. The ability to identify the intended target (and select the key) are indeed consequences, but they are also the goals for keeping the addresses not encrypted. Maybe: For most of them ([IEEE_802.11] in particular), the source and destination MAC addresses are not encrypted even in networks that implement encryption. This lack of encryption allows each machine to easily detect if it is the intended target of the message before attempting to decrypt its content and also helps 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. --> [Authors] MAC address is much, much better, thank you. Accepted. 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. --> [Authors] The proposed fix reads better, accepted thank you. 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. --> [Authors] Better thank you, maybe even better with 'using': The transmitting or receiving MAC address is usually not encrypted in wireless exchanges using 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]). --> [Authors] much better, accepted thank you. 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. --> [Authors] Both corrections accepted thank you. Indeed, the 'level' of trust is what the first sentence intended. We also initially had some wording about which environments would match each type of trust, before removing the explicit list later in the draft, as environments are addressed in their own section. Thus the 'environment' segment has lost its raison-d'etre and is better entirely removed. Thanks again. 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. --> [Authors] Ah,. No change needed beyond the current version as you posted it. This terminology was ... hem... the opportunity for robust exchanges of view in the group, with the conclusion that A0, b) etc. in the table were use cases, but the description above, with the use cases and their characteristics, would be the 'environments'. Thank you for the plural edit (this was indeed much needed), the rest is intentional. 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. --> [Authors] Perhaps we can align with the guest network wording, thus: Most users connecting to a residential network only expect simple Internet connectivity services, so the network services are simple. If users have issues connecting to the network or accessing the Internet, they expect limited to no technical support. 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 <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. --> [Authors] Great catch thank you, RFC903 is indeed what this sentence needed. Suggestion accepted with thanks. 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. --> [Authors] Indeed: In managed enterprise 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. --> [Authors] Verified thank you. We found the following discrepancies in section 1 and 2, where 802.3 is present were the text 9and reference) should be about the parent protocol, 802. 802 defines the MAC address and its usage. 802.3 defines Ethernet networks (which commonly connect to access points providing 802.11 services): End of section 1: 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] Expected: 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 networks [IEEE_802]. Section 2: Current: In IEEE 802.3 [IEEE_802.3] technologies , the Media Access Control (MAC) layer defines rules to control how a device accesses the shared medium. In a network where a machine can communicate with one or more other machines, one such rule is that each machine needs to be identified as either the target destination of a message or the source of a message (and the target destination of the answer). Initially intended as a 48-bit (6-octet) value in the first versions of , other standards under the IEEE 802.3[IEEE_802.3] umbrella allow this address to take an extended format of 64 bits (8 octets), which enabled a larger number of MAC addresses to coexist as IEEE 802.3 technologies became widely adopted. Expected: In IEEE 802 [IEEE_802] technologies , the Media Access Control (MAC) layer defines rules to control how a device accesses the shared medium. In a network where a machine can communicate with one or more other machines, one such rule is that each machine needs to be identified as either the target destination of a message or the source of a message (and the target destination of the answer). Initially intended as a 48-bit (6-octet) value in the first versions of , other standards under the IEEE 802 [IEEE_802] umbrella allow this address to take an extended format of 64 bits (8 octets), which enabled a larger number of MAC addresses to coexist as IEEE 802 technologies became widely adopted. Please note that other references are correctly made to 802.3 (e.g. in section 3). The issues above seem to have only affected selected paragraphs in section 1 and 2. 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/> <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> <https://ieeexplore.ieee.org/document/9844436>>. --> [Authors] Perfect, thank you, indeed the standard was revised in 2022. 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- <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- <https://www.cablelabs.com/specifications/CM-SP-CM-> OSSIv4.0?v=I06>. --> [Authors], perfect, thank you. 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> <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> <https://ieeexplore.ieee.org/document/10214483>>. --> [Authors] By coincidence, the 802.11bh draft just made it through edit is the final standard is now available, at: https://standards.ieee.org/ieee/802.11bh/10525/ 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. --> [Authors] client OS vendors is much better for parity with the other instances, thank you, suggestion accepted. 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 --. [Authors] Thank you, MAC address is the correct form. 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 --> [Authors] thank you indeed, consistency is better. My English teacher in K-12 taught me that possessive was not required for objects, although usage varies, thus I would suggest 'device MAC address' and 'device wireless MAC address', but we would gladly accept any consistency proposal you would make, even if you suggest the possessive form. Naturally, the instances where 'wireless' is inserted need to keep that word, because in context there is possible ambiguity with a non-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 --> [Authors] perfect, these are the correct expansion, thank you. 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. --> [Authors] suggestion accepted. The expansion makes the sentence a bit heavier, but clearer. 27) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <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. --> [Authors] Reviewed, thank you, we did not see particular words in the draft that would raise a flag. 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> <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. --> [Authors] what about 'typical"? The federation structure extends the type of authorities that can be used as identity sources (compared to typical 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 Cisco Confidential On Jun 9, 2025, at 4:12 PM, rfc-edi...@rfc-editor.org <mailto: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/ <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 <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> <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 <mailto: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 <mailto: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 <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ <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 <mailto: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.xml> https://www.rfc-editor.org/authors/rfc9797.html <https://www.rfc-editor.org/authors/rfc9797.html> https://www.rfc-editor.org/authors/rfc9797.pdf <https://www.rfc-editor.org/authors/rfc9797.pdf> https://www.rfc-editor.org/authors/rfc9797.txt <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-diff.html> https://www.rfc-editor.org/authors/rfc9797-rfcdiff.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 <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 <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
