Hi Jerome, Thank you for your notes! We have updated the document accordingly.
We will await final approvals from both you and Yiu prior to moving forward in the publication process. The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9797.txt https://www.rfc-editor.org/authors/rfc9797.pdf https://www.rfc-editor.org/authors/rfc9797.html https://www.rfc-editor.org/authors/rfc9797.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9797-auth48diff.html (AUTH48 changes only) Note that it may be necessary for you to refresh your browser to view the most recent version. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9797 Thank you, RFC Editor/st > On Jun 17, 2025, at 9:01 PM, Jerome Henry (jerhenry) <jerhe...@cisco.com> > wrote: > > Thank you Sarah, > > Looks great! A few small nits: > > Section 1: wrong IEEE reference, 802.3 -> 802 > 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 networks [IEEE_802.3]. > > Recommended: change reference at the end from 802.3 to 802: > 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: typo: or -> of > > Current: > Clause 8.4 of [IEEE_802] reminds network designers and operators that all > potential members of a network need to have a unique identifier in that > network (if they are going to coexist in the network without confusion on > which machine is the source or destination or any message). > > Recommended: > Clause 8.4 of [IEEE_802] reminds network designers and operators that all > potential members of a network need to have a unique identifier in that > network (if they are going to coexist in the network without confusion on > which machine is the source or destination of any message). > > Section 5: typo: C -> D > Current: > Managed enterprises: This type of network is similar to (C). > > Recommended: > Managed enterprises: This type of network is similar to (D). > > > Section 6: broken link > The link to RFC903 seems to be broken/does not appear in the text. > > Current: > Routers keep track of which MAC address is on which interface so that they > can form the proper Data Link header when forwarding a packet to a segment > where MAC addresses are used. 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. > > > Thanks again! > > Jerome > > > > On 6/17/25, 6:08 PM, "Sarah Tarrant" <starr...@staff.rfc-editor.org > <mailto:starr...@staff.rfc-editor.org>> wrote: > > > Hi Jerome and Yiu, > > > Thank you for your replies. We have updated the document accordingly and have > no further questions. > > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. Contact us with any further > updates or with your approval of the document in its current form. We will > await approvals from both of you prior to moving forward in the publication > process. > > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9797.txt > <https://www.rfc-editor.org/authors/rfc9797.txt> > https://www.rfc-editor.org/authors/rfc9797.pdf > <https://www.rfc-editor.org/authors/rfc9797.pdf> > https://www.rfc-editor.org/authors/rfc9797.html > <https://www.rfc-editor.org/authors/rfc9797.html> > https://www.rfc-editor.org/authors/rfc9797.xml > <https://www.rfc-editor.org/authors/rfc9797.xml> > > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfcXXXX-auth48diff.html > <https://www.rfc-editor.org/authors/rfcXXXX-auth48diff.html> (AUTH48 changes > only) > > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9797 > <https://www.rfc-editor.org/auth48/rfc9797> > > > Thank you, > RFC Editor/st > > >> On Jun 17, 2025, at 9:50 AM, Lee, Yiu <Yiu_Lee=40comcast....@dmarc.ietf.org >> <mailto:40comcast....@dmarc.ietf.org>> wrote: >> >> Dear editors, >> >> Sport for the delay. I accepted the suggestions posted by Jerome. Thanks for >> editing the draft. >> >> Best, >> Yiu >> > > Cisco Confidential >> From: Jerome Henry (jerhenry) <jerhe...@cisco.com >> <mailto:jerhe...@cisco.com>> >> Sent: Tuesday, June 17, 2025 09:24 >> To: rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> >> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>>; Lee, Yiu >> <yiu_...@comcast.com <mailto:yiu_...@comcast.com>> >> Cc: madinas-...@ietf.org <mailto:madinas-...@ietf.org> <madinas-...@ietf.org >> <mailto:madinas-...@ietf.org>>; madinas-cha...@ietf.org >> <mailto:madinas-cha...@ietf.org> <madinas-cha...@ietf.org >> <mailto:madinas-cha...@ietf.org>>; c...@it.uc3m.es <mailto:c...@it.uc3m.es> >> <c...@it.uc3m.es <mailto:c...@it.uc3m.es>>; Eric Vyncke (evyncke) >> <evyn...@cisco.com <mailto:evyn...@cisco.com>>; auth48archive@rfc-editor.org >> <mailto:auth48archive@rfc-editor.org> <auth48archive@rfc-editor.org >> <mailto:auth48archive@rfc-editor.org>> >> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9797 >> <draft-ietf-madinas-use-cases-19> for your review 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> <mailto:rfc-edi...@rfc-editor.org >> <mailto:rfc-edi...@rfc-editor.org>>" <rfc-edi...@rfc-editor.org >> <mailto:rfc-edi...@rfc-editor.org> <mailto: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://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVLczMnc$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVLczMnc$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVLczMnc$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVLczMnc$> >> >. >> --> 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://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc903__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXJAeDqE$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc903__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXJAeDqE$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc903__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXJAeDqE$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc903__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXJAeDqE$> >> >). 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://urldefense.com/v3/__https://standards.ieee.org/ieee/802.3/7071/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiWqNTAgG$ >> >> <https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.3/7071/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiWqNTAgG$> >> > >> <https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.3/7071/>__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiel1V5Rk$ >> >> <https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.3/7071/&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiel1V5Rk$> >> >. >> >> >> Updated: >> [IEEE_802.3] >> IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, >> DOI 10.1109/IEEESTD.2022.9844436, 29 July 2022, >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9844436__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiezaElFz$ >> >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9844436__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiezaElFz$> >> > >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9844436>__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiUBsHN41$ >> >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9844436&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiUBsHN41$> >> >. >> --> [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://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$ >> >> <https://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$> >> >> <https://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$ >> >> <https://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$> >> > >> 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://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$ >> >> <https://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$> >> >> <https://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$ >> >> <https://urldefense.com/v3/__https://www.cablelabs.com/specifications/CM-SP-CM-__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXPDOD8Y$> >> > >> 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://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWidHtTGY6$ >> >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWidHtTGY6$> >> > >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483>__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRs_aMy6$ >> >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRs_aMy6$> >> >. >> >> >> 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://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWidHtTGY6$ >> >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWidHtTGY6$> >> > >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483>__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRs_aMy6$ >> >> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRs_aMy6$> >> >. >> --> [Authors] By coincidence, the 802.11bh draft just made it through edit >> is the final standard is now available, at: >> https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.11bh/10525/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWia1Bl3Di$ >> >> <https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.11bh/10525/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWia1Bl3Di$> >> >> >> >> >> 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ >> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language__;Iw!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWia0TP-QZ$ >> > <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/ >> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/>*inclusive_language>__;Iw!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiUI41-sO$ >> > >> 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://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/ >> >> <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/>*www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1__;LyM!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXHyPQmM$ >> > >> <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/ >> >> <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/>*www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1>__;LyM!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiaCNs_M9$ >> >. >> >> >> 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> <mailto: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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWif4AWzhD$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWif4AWzhD$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWif4AWzhD$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWif4AWzhD$> >> >). >> >> >> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiTdPGbUQ$ >> >> <https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiTdPGbUQ$> >> >> <https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiTdPGbUQ$ >> >> <https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiTdPGbUQ$> >> >). >> >> >> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiQ_EoPvH$ >> >> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiQ_EoPvH$> >> > >> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary>__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXTNThWY$ >> >> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXTNThWY$> >> >. >> >> >> * 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> >> <mailto: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> >> <mailto: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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWid5IBJyw$ >> >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWid5IBJyw$> >> >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWid5IBJyw$ >> >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWid5IBJyw$> >> > >> >> >> * The archive itself: >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiT8AeOgJ$ >> >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiT8AeOgJ$> >> >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiT8AeOgJ$ >> >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiT8AeOgJ$> >> > >> >> >> * 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> >> <mailto: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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVSga3aJ$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVSga3aJ$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVSga3aJ$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVSga3aJ$> >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVITW8_H$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVITW8_H$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVITW8_H$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiVITW8_H$> >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRXpl_HS$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRXpl_HS$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRXpl_HS$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRXpl_HS$> >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiWRcJZcz$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiWRcJZcz$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiWRcJZcz$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiWRcJZcz$> >> > >> >> >> Diff file of the text: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-diff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWietwanzB$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-diff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWietwanzB$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-diff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWietwanzB$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-diff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWietwanzB$> >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-rfcdiff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiYazEK7_$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-rfcdiff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiYazEK7_$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-rfcdiff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiYazEK7_$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-rfcdiff.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiYazEK7_$> >> > (side by side) >> >> >> Diff of the XML: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-xmldiff1.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiZVImCJD$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-xmldiff1.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiZVImCJD$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-xmldiff1.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiZVImCJD$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-xmldiff1.html__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiZVImCJD$> >> > >> >> >> >> >> Tracking progress >> ----------------- >> >> >> The details of the AUTH48 status of your document are here: >> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiW0YAfkf$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiW0YAfkf$> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiW0YAfkf$ >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiW0YAfkf$> >> > >> >> >> 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
