All, Thank you for your replies. Congratulations - RFC 9797 has been announced! See <https://mailarchive.ietf.org/arch/msg/ietf-announce/qrO7t6zzifIQQKOKo1O5B8zD2c8/>.
Thank you, RFC Editor/sg > On Jun 27, 2025, at 10:40 AM, Jerome Henry (jerhenry) <[email protected]> > wrote: > > I second too, thank you! > > Jerome > > From: "Lee, Yiu" <[email protected]> > Date: Friday, June 27, 2025 at 6:27 AM > To: "Eric Vyncke (evyncke)" <[email protected]>, CARLOS JESUS BERNARDOS CANO > <[email protected]>, Sandy Ginoza <[email protected]> > Cc: "Jerome Henry (jerhenry)" <[email protected]>, RFC Editor > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "Lee, Yiu" > <[email protected]> > Subject: Re: Question - Re: AUTH48: RFC-to-be 9797 > <draft-ietf-madinas-use-cases-19> for your review > > I second. Please update to reflect the most recent RFC. Thanks! > > From: Eric Vyncke (evyncke) <[email protected]> > Sent: Friday, June 27, 2025 5:40:31 PM > To: CARLOS JESUS BERNARDOS CANO <[email protected]>; Sandy Ginoza > <[email protected]> > Cc: Jerome Henry (jerhenry) <[email protected]>; RFC Editor > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]>; Lee, Yiu > <[email protected]> > Subject: [EXTERNAL] Re: Question - Re: AUTH48: RFC-to-be 9797 > <draft-ietf-madinas-use-cases-19> for your review > > Same here but as the responsible AD, let’s use the more recent RFC > > -éric > > From: CARLOS JESUS BERNARDOS CANO <[email protected]> > Date: Friday, 27 June 2025 at 11:39 > To: Sandy Ginoza <[email protected]> > Cc: Jerome Henry (jerhenry) <[email protected]>, RFC Editor > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, Eric Vyncke (evyncke) > <[email protected]>, [email protected] > <[email protected]>, Lee, Yiu <[email protected]> > Subject: Re: Question - Re: AUTH48: RFC-to-be 9797 > <draft-ietf-madinas-use-cases-19> for your review > > Hi Sandy, > > As non-author, I'd recommend to update the reference as suggested. > > But let the authors respond. > > Thanks, > > Carlos > > On Thu, Jun 26, 2025 at 10:45 PM Sandy Ginoza <[email protected]> > wrote: >> Hi Authors, >> >> While preparing this document for publication, we noted that RFC 4941 has >> been obsoleted by RFC 8981. >> >> RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 >> RFC 8981: Temporary Address Extensions for Stateless Address >> Autoconfiguration in IPv6 >> >> May we update the reference and corresponding in-text citations to refer to >> RFC 8981? >> >> This is the only mention of RFC 4941 in the text: >> >> 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]). >> >> We will wait for a reply from at least one author before continuing with the >> publication process. >> >> Thank you, >> RFC Editor/sg >> >> >> >> >> >> > On Jun 24, 2025, at 8:41 AM, Jerome Henry (jerhenry) >> > <[email protected]> wrote: >> > >> > Fantastic, >> > >> > A big thank you to the editor team for this great work on this draft! >> > >> > >> > Jerome >> > >> > On 6/23/25, 5:27 PM, "Sarah Tarrant" <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > >> > 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 >> > <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) >> >> <[email protected] <mailto:[email protected]>> >> >> wrote: >> >> >> >> Same for me, thanks a lot Sarah! >> >> Best >> >> Jerome From: "Lee, Yiu" <[email protected] <mailto:[email protected]>> >> >> Date: Wednesday, June 18, 2025 at 10:05 AM >> >> To: Sarah Tarrant <[email protected] >> >> <mailto:[email protected]>>, "Jerome Henry (jerhenry)" >> >> <[email protected]<mailto:[email protected]>> >> >> Cc: "[email protected] <mailto:[email protected]>" >> >> <[email protected] <mailto:[email protected]>>, >> >> "[email protected] <mailto:[email protected]>" >> >> <[email protected] <mailto:[email protected]>>, >> >> "[email protected]<mailto:[email protected]>" >> >> <[email protected] <mailto:[email protected]>>, >> >> "[email protected] <mailto:[email protected]>" <[email protected] >> >> <mailto:[email protected]>>, "Eric Vyncke (evyncke)" <[email protected] >> >> <mailto:[email protected]>>, "[email protected] >> >> <mailto:[email protected]>" <[email protected] >> >> <mailto:[email protected]>> >> >> 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 <[email protected] >> >> <mailto:[email protected]>> >> >> Sent: Wednesday, June 18, 2025 8:38 AM >> >> To: Jerome Henry (jerhenry) <[email protected] >> >> <mailto:[email protected]>> >> >> Cc: [email protected] <mailto:[email protected]> >> >> <[email protected] <mailto:[email protected]>>; >> >> [email protected] <mailto:[email protected]> <[email protected] >> >> <mailto:[email protected]>>; [email protected] >> >> <mailto:[email protected]> <[email protected] >> >> <mailto:[email protected]>>; [email protected] >> >> <mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Eric >> >> Vyncke (evyncke) <[email protected] <mailto:[email protected]>>; >> >> [email protected]<mailto:[email protected]> >> >> <[email protected] <mailto:[email protected]>>; >> >> Lee, Yiu <[email protected]<mailto:[email protected]>> >> >> 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.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/rfc9797-auth48diff.html__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPPOT22gDA$ >> >> >> >> <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$ >> >> >> >> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9797__;!!CQl3mcHX2A!EKlJykkJnBEgi0ZzNNCrkb0OboXrIbIDPYo5VGX4C1STC4JZNd81UNpihaPPhzg3UVrZqdqAbDHjYc5dDPObbIhMBQ$> >> >> >> >> Thank you, >> >> RFC Editor/st >> >> >> > >> > Cisco Confidential >> >>> On Jun 17, 2025, at 9:01 PM, Jerome Henry (jerhenry) <[email protected] >> >>> <mailto:[email protected]>> 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" <[email protected] >> >>> <mailto:[email protected]> >> >>> <mailto:[email protected]<mailto:[email protected]>>> >> >>> 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.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.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.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$> >> >>> >> >>> <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$> >> >>> >> >>> <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$> >> >>> >> >>> <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 >> >>>> <[email protected] >> >>>> <mailto:[email protected]> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]>>> 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) <[email protected] >> >>>> <mailto:[email protected]> >> >>>> <mailto:[email protected]<mailto:[email protected]>>> >> >>>> Sent: Tuesday, June 17, 2025 09:24 >> >>>> To: [email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>> >> >>>> <[email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>>; >> >>>> Lee, Yiu <[email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>> >> >>>> Cc: [email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>> >> >>>> <[email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>>; >> >>>> [email protected]<mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>> >> >>>> <[email protected]<mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>>; >> >>>> [email protected]<mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>> <[email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>>; Eric Vyncke >> >>>> (evyncke) <[email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>>; >> >>>> [email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]>> <[email protected] >> >>>> <mailto:[email protected]> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]>>> >> >>>> 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, "[email protected] >> >>>> <mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>> <mailto:[email protected] >> >>>> <mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>>>" <[email protected] >> >>>> <mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>> <mailto:[email protected] >> >>>> <mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>>>> 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$>> >> >>>> >> >>>> <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$>> >> >>>> >> >>>> <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_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$> >> >>>> >> >>>> <https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.3/7071/&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiel1V5Rk$<https://urldefense.com/v3/__https://standards.ieee.org/ieee/802.3/7071/&amp;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_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$> >> >>>> >> >>>> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9844436&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiUBsHN41$<https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/9844436&amp;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$>> >> >>>> >> >>>> <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$>> >> >>>> >> >>>> <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_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$> >> >>>> >> >>>> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRs_aMy6$<https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483&amp;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_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$> >> >>>> >> >>>> <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiRs_aMy6$<https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/10214483&amp;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$><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/> >> >>>> >> >>>> <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/> >> >>>> >> >>>> <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/__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 >> >>>> >> >>>> <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/__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 >> >>>> >> >>>> <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, [email protected] >> >>>> <mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>> <mailto:[email protected] >> >>>> <mailto:[email protected]> <mailto:[email protected] >> >>>> <mailto:[email protected]>>> 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$>> >> >>>> >> >>>> <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$>> >> >>>> >> >>>> <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_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$> >> >>>> >> >>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary&gt;__;!!CQl3mcHX2A!Cy4I_cHD8bo76sPNsXvlVKT5sBC5GHCt3-_IjnfxfACEHCdxii8Qb_ePWsAyN3KPxpuU_ewWiXTNThWY$ >> >>>> >> >>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary&amp;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 >> >>>> >> >>>> >> >>>> * [email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>> >> >>>> <mailto:[email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] <mailto:[email protected]>>> >> >>>> (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). >> >>>> >> >>>> >> >>>> * [email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]>> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]> >> >>>> <mailto:[email protected]<mailto:[email protected]>>>, >> >>>> 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$>> >> >>>> >> >>>> <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$>> >> >>>> >> >>>> <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, >> >>>> [email protected] <mailto:[email protected]> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]>> >> >>>> <mailto:[email protected] >> >>>> <mailto:[email protected]> >> >>>> <mailto:[email protected]<mailto:[email protected]>>> >> >>>> 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.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.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.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$>> >> >>>> >> >>>> <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-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_$>> >> >>>> >> >>>> <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$>> >> >>>> >> >>>> <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$>> >> >>>> >> >>>> <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 -- [email protected] To unsubscribe send an email to [email protected]
