Hi Jerome and Yiu, Jerome - apologies for the belated response! Thank you for your approval.
We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9797 Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. Sincerely, RFC Editor/st > On Jun 18, 2025, at 10:24 PM, Jerome Henry (jerhenry) > <jerhenry=40cisco....@dmarc.ietf.org> wrote: > > Same for me, thanks a lot Sarah! > Best > Jerome From: "Lee, Yiu" <yiu_...@comcast.com> > Date: Wednesday, June 18, 2025 at 10:05 AM > To: Sarah Tarrant <starr...@staff.rfc-editor.org>, "Jerome Henry (jerhenry)" > <jerhe...@cisco.com> > Cc: "rfc-edi...@rfc-editor.org" <rfc-edi...@rfc-editor.org>, > "madinas-...@ietf.org" <madinas-...@ietf.org>, "madinas-cha...@ietf.org" > <madinas-cha...@ietf.org>, "c...@it.uc3m.es" <c...@it.uc3m.es>, "Eric Vyncke > (evyncke)" <evyn...@cisco.com>, "auth48archive@rfc-editor.org" > <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9797 <draft-ietf-madinas-use-cases-19> for > your review > Dear Sarah, > I reviewed the draft. I do not have any new input. This is good to publish. > Thanks, > YiuFrom: Sarah Tarrant <starr...@staff.rfc-editor.org> > Sent: Wednesday, June 18, 2025 8:38 AM > To: Jerome Henry (jerhenry) <jerhe...@cisco.com> > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; > madinas-...@ietf.org <madinas-...@ietf.org>; madinas-cha...@ietf.org > <madinas-cha...@ietf.org>; c...@it.uc3m.es <c...@it.uc3m.es>; Eric Vyncke > (evyncke) <evyn...@cisco.com>; auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org>; Lee, Yiu <yiu_...@comcast.com> > Subject: Re: AUTH48: RFC-to-be 9797 <draft-ietf-madinas-use-cases-19> for > your review > 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPih-saVA$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPO7udcjmQ$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPOniQG51g$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPrdKYwqw$ > > The relevant diff files have been posted here (please refresh): > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797-auth48diff.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPOT22gDA$ > (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPObbIhMBQ$ > > 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPih-saVA$ > > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.txt__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPih-saVA$ > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPO7udcjmQ$ > > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.pdf__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPO7udcjmQ$ > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPOniQG51g$ > > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPOniQG51g$ > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPrdKYwqw$ > > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9797.xml__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPrdKYwqw$ > > > > > > > > > The relevant diff files have been posted here (please refresh): > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfcXXXX-auth48diff.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPP38uqYmg$ > > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfcXXXX-auth48diff.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPP38uqYmg$ > > > (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPObbIhMBQ$ > > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPObbIhMBQ$ > > > > > > > > > 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:/>*https://urldefense.com/v3/__http://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1__;LyM!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXHyPQmM$__;Kg!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPP8ldP3cA$ > >> > > >> <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/ > >> > >> <https://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/>*https://urldefense.com/v3/__http://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1>__;LyM!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiaCNs_M9$__;Kg!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPMnTK4lpw$ > >> >. > >> > >> > >> 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
