Dear Rebecca, My apologies for the belated reaction. The IETF122 I-D submission deadline plus other things that were delayed because of that created some additional lag. Again, apologies.
We have finally created the page on the IETF wiki: https://wiki.ietf.org/e/en/group/madinas/RFC9724 Please, let us know if this is fine. Last, but not lease, please see below for our pending responses to A-D. On Fri, Feb 21, 2025 at 11:55 PM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > Hi authors, > > We are checking in regarding this document. > > Followup questions A-D from the email dated 2025-02-7 (see below) are > still open. > > In addition, we believe that you will be using wiki.ietf.org (rather than > GitHub) to host the text from Section 7 of the document (per question 21). > Once that has been implemented, we will update Section 7 accordingly to > point to wiki.ietf.org. > > For the AUTH48 status page of this document, please see > https://www.rfc-editor.org/auth48/rfc9724. > > Please let us know if you have any questions. > > Best regards, > RFC Editor/rv > > > > > On Feb 7, 2025, at 2:19 PM, Rebecca VanRheenen < > rvanrhee...@staff.rfc-editor.org> wrote: > > > > Hi Juan Carlos, > > > > Thank you for your response! We have updated the document accordingly > (see list of files below) and have some followup questions: > > > > A) > > > >>>> 6) <!-- [rfced] How may we expand "STA"? As "station"? If so, would > it be > >>>> helpful > >>>> to describe this in the first sentence below rather than in the > second? > >>>> > >>>> Original: > >>>> In an 802.11 network, a station exposes its MAC address in two > >>>> different situations: > >>>> > >>>> * While actively scanning for available networks, the MAC address > is > >>>> used in the Probe Request frames sent by the device (a.k.a. > >>>> IEEE 802.11 STA). > >>>> > >>>> Perhaps: > >>>> In an 802.11 network, a device (also known as an IEEE 802.11 > station or > >>>> STA) > >>>> exposes its MAC address in two different situations: > >>>> > >>>> * While actively scanning for available networks, the MAC address > is > >>>> used in the Probe Request frames sent by the STA. > >>>> --> > >>>> > >> [Carlos] I prefer the original text, maybe replacing "station" with > >> "station (or STA)". The reason is that stations are not the only type of > >> devices in IEEE 802.11 networks, and the text refers to the behavior of > >> stations. Then we can remove the expansion of STA in the second > sentence. > >> > >> [JCZ] I actually think that the suggestion is good. Unlike the IETF use > of station, for 802.11 “all” devices are an STA when they access the > medium. Only “some” STAs implement higher MAC functionality that makes them > different, like an AP. Hence, I think that the suggested text is generic > enough to encompass all definitions. > > > > There is a difference of opinion here. Please discuss this and let us > know how/if the document should be updated. > > > [Carlos] Let's go for the "Perhaps" option, which is the one Juan Carlos preferes (he is much more familiar with IEEE 802.11 terminology). > > > > B) > > > >>> b) We cannot locate this this document. We do not see it listed at > >>> https://wballiance.com/resource/. Can you provide a URL? > >>> > >>> Original: > >>> [wba_paper] > >>> Alliance, W. B., "Wi-Fi Identification Scope for Liasing - > >>> In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro: > >>> Post MAC Randomization Era v1.0 - IETF liaison , March > >>> 2020. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Regarding the document, > this > >> was shared sd part of the liaison: > >> > https://mailarchive.ietf.org/arch/msg/madinas/ZmMhpHBquVf6TOD4uU_x2Yenvuw/ > >> > >> In any case, I think we can replace it with the following whitepaper: > >> > https://wballiance.com/wi-fi-device-identification-a-way-through-mac-randomization/ > >> What do you think Juan Carlos? > >> [JCZ] I agree, good suggestion Carlos. > > > > We updated [wba_paper] to reference the white paper mentioned above. > However, please review the text where [wba_paper] is mentioned in the > document. This text should be revised as it refers to “a first version of > that document”. What is the best way to update this sentence? > > > > Current: > > As part of this work, the WBA has documented a set of use cases that > > a Wi-Fi Identification Standard should address in order to scale and > > achieve longer-term sustainability of deployed services. A first > > version of that document, a paper titled "Wi-Fi Identification In a > > post MAC Randomization Era v1.0" [wba_paper], was created while > > liaising with the IETF MADINAS Working Group. > > > > Perhaps: > > As part of this work, the WBA has documented a set of use cases that > > a Wi-Fi Identification Standard should address in order to scale and > > achieve longer-term sustainability of deployed services (see > [wba_paper]). > > > > Or: > > As part of this work, the WBA has documented a set of use cases that > > a Wi-Fi Identification Standard should address in order to scale and > > achieve longer-term sustainability of deployed services. See > [wba_paper]; > > the WBA liaised with the IETF MADINAS Working Group on the early > drafts > > of this paper. > > > [Carlos] I prefer the "Perhaps" version. > > > > C) We have updated the following reference entries to include the URLs > that you provided. May we also update the titles and release numbers as > detailed below to match the info in the URLs? > > > >>> 27) <!-- [rfced] We were unable to locate the following reference > entries. Can you > >>> point us to URLs so that we can verify these? > >> > >> [JCZ] These references can be found on the 802.11 repository: > https://mentor.ieee.org/802.11/documents > >> > >>> Original: > >>> [rcm_privacy_csd] > >>> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >>> Changing MAC Addresses Study Group CSD on user experience > >>> mechanisms", doc.:IEEE 802.11-20/1346r1 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-1346-04-0rcm-csd-draft-for-privacy-amendment-of-rcm-project.docx > > > > Original title: > > IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on > user experience mechanisms > > > > Perhaps: > > Proposed CSD for P802.11bi > > > > Original release number: > > 1346r1 > > > > Perhaps: > > 1346r4 > > > [Carlos] Keep the original title and update the release number. > > > >>> [rcm_privacy_par] > >>> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >>> Changing MAC Addresses Study Group PAR on privacy > >>> mechanisms", doc.:IEEE 802.11-19/854r7 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-0854-07-0rcm-par-proposal-for-privacy.docx > > > > Original title: > > IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on > privacy mechanisms > > > > Perhaps: > > RCM: A PAR Proposal > > > [Carlos] Keep the original title. > > > >>> [rcm_tig_final_report] > >>> IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And > >>> Changing MAC Addresses Topic Interest Group Report", > >>> doc.:IEEE 802.11-19/1442r9 , 2019. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/19/11-19-1442-09-0rcm-rcm-tig-draft-report-outline.odt > > > > No updates needed; titles and release numbers match. > > > > > >>> [rcm_user_experience_csd] > >>> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >>> Changing MAC Addresses Study Group CSD on user experience > >>> mechanisms", doc.:IEEE 802.11-20/1117r3 , 2020. > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-1117-05-0rcm-rcm-sg-proposed-rcm-csd-draft.docx > > > > Original title and release number: > > IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on > user experience mechanisms > > > > Perhaps: > > Proposed CSD for P802.11bh > > > > Original release number: > > 1117r3 > > > > Perhaps: > > 1117r5 > [Carlos] Keep the original title and update the release number. > > > > > >>> [rcm_user_experience_par] > >>> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >>> Changing MAC Addresses Study Group PAR on user experience > >>> mechanisms", doc.:IEEE 802.11-20/742r5 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-0742-06-0rcm-proposed-par-draft.docx > > > > Original title: > > IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on > user experience mechanisms > > > > Perhaps: > > RCM: A PAR Proposal for 802.11bh > > > > Original release number: > > 742r5 > > > > Perhaps: > > 742r6 > > > [Carlos] Keep the original title and update the release number. > > > > D) > > > >>> c) May we update the expansion of RCM as follows? If so, we will also > update > >>> "RCM" to "RCM address" in the sentences below. > >>> > >>> Original (expansion): > >>> Randomized and Changing MAC addresses (RCM) > >>> > >>> Perhaps: > >>> Randomized and Changing MAC (RCM) addresses > >>> > >>> > >>> Original (sentences with RCM): > >>> As of 2024, two task groups in IEEE 802.11 are dealing with issues > >>> related to RCM: > >>> > >>> * The IEEE 802.11bh task group, which is looking at mitigating the > >>> repercussions that RCM creates on 802.11 networks and related > >>> services. > >>> > >>> Perhaps: > >>> As of 2024, two task groups in IEEE 802.11 are dealing with issues > >>> related to RCM addresses: > >>> > >>> * The IEEE 802.11bh task group, which is looking at mitigating the > >>> repercussions that RCM addresses create on 802.11 networks and > related > >>> services. > >> > >> [Carlos] The new proposal is fine with me. > >> > >> [JCZ] Even though I agree with the comments, the original text aligns > more with the actual IEEE 802.11bh use, where “address” is implicit in RCM: > https://ieee802.org/11/Reports/tgbh_update.htm > >> > >> > >>> d) We see this note in Section 6: > >>> > >>> Note about the used naming convention: the "M" in MAC is included in > >>> the acronym, but not the "A" from address. This allows one to talk > >>> about a PVOM Address, or PNGM Address. > >>> > >>> Per this note, may we update the expansions in Section 6.1-6.6 as > follows and > >>> then update instances like "PDGM" in the document to "PDGM address"? > >>> > >>> Original: > >>> Per-Vendor OUI MAC address (PVOM) > >>> Per-Device Generated MAC address (PDGM) > >>> Per-Boot Generated MAC address (PBGM) > >>> Per-Network Generated MAC address (PNGM) > >>> Per-Period Generated MAC address (PPGM) > >>> Per-Session Generated MAC address (PSGM) > >>> > >>> Perhaps: > >>> Per-Vendor OUI MAC (PVOM) Address > >>> Per-Device Generated MAC (PDGM) Address > >>> Per-Boot Generated MAC (PBGM) Address > >>> Per-Network Generated MAC (PNGM) Address > >>> Per-Period Generated MAC (PPGM) Address > >>> Per-Session Generated MAC (PSGM) Address > >> > >> [JCZ] Similarly to the previous comment, the tendency in 802.11/Wi-Fi > terminology is to omit the (A)ddress from the acronym as we originally > proposed. > > > > Thank you for letting us know this. Would you like to align these with > the form typically used by 802.11/Wi-Fi? If so, perhaps we can also adapt > the note in the original to be more clear. > > > > Original: > > Note about the used naming convention: the "M" in MAC is included in > > the acronym, but not the "A" from address. This allows one to talk > > about a PVOM Address, or PNGM Address. > > > > Perhaps: > > Note: The naming convention for these terms aligns with 802.11/Wi-Fi > terminology in > > that the “A” for “address” is not included in the acronym. For > example, “PVOM” > > stands for "Per-Vendor OUI MAC address” and “PNGM” stands for > "Per-Network > > Generated MAC address”. > > > [Carlos] I agree with Juan Carlos's suggestion of omitting the (A)ddress from the acronym. I also think it's a good idea to adapt the original note with the "Perhaps" text. Thanks a lot! Carlos > > > — FILES (please refresh) — > > > > Updated XML file: > > https://www.rfc-editor.org/authors/rfc9724.xml > > > > Updated output files: > > https://www.rfc-editor.org/authors/rfc9724.txt > > https://www.rfc-editor.org/authors/rfc9724.pdf > > https://www.rfc-editor.org/authors/rfc9724.html > > > > Diff files showing all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9724-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9724-auth48rfcdiff.html (side by > side diff) > > > > Diff files showing all changes: > > https://www.rfc-editor.org/authors/rfc9724-diff.html > > https://www.rfc-editor.org/authors/rfc9724-rfcdiff.html (side-by-side > diff) > > https://www.rfc-editor.org/authors/rfc9724-alt-diff.html (diff showing > changes where text is moved or deleted) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9724 > > > > Thank you, > > > > RFC Editor/rv > > > > > > > > > > > >> On Feb 5, 2025, at 2:19 PM, Juan Carlos Zuniga (juzuniga) <juzuniga= > 40cisco....@dmarc.ietf.org> wrote: > >> > >> Dear all, > >> Please find below my inputs marked with [JCZ], right after Carlos’ ones: > >> From: CARLOS JESUS BERNARDOS CANO <c...@it.uc3m.es> > >> Date: Thursday, January 23, 2025 at 05:17 > >> To: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >> Cc: Juan Carlos Zuniga (juzuniga) <juzun...@cisco.com>, > amelia.i...@andersdotter.cc<amelia.i...@andersdotter.cc>, > madinas-...@ietf.org <madinas-...@ietf.org>, madinas-cha...@ietf.org < > madinas-cha...@ietf.org>, pe...@akayla.com <pe...@akayla.com>, Eric > Vyncke (evyncke) <evyn...@cisco.com>, auth48archive@rfc-editor.org < > auth48archive@rfc-editor.org> > >> Subject: Re: [AD] Re: AUTH48: RFC-to-be 9724 > <draft-ietf-madinas-mac-address-randomization-15> for your review > >> Dear RFC Editor, > >> > >> Please find my comments and responses inline below. > >> > >> On Tue, Jan 21, 2025 at 8:31 AM <rfc-edi...@rfc-editor.org> wrote: > >> > >>> Authors and AD*, > >>> > >>> Authors, while reviewing this document during AUTH48, please resolve > (as > >>> necessary) the following questions, which are also in the XML file. > >>> > >>> *AD, please see question #21 below. > >>> > >>> > >>> 1) <!-- [rfced] How may we update the document title to improve > clarity? > >>> Also, > >>> note that we expanded the acronym MAC per Section 3.6 of RFC 7322 ("RFC > >>> Style Guide"). Please review. > >>> > >>> Original: > >>> Randomized and Changing MAC Address State of Affairs > >>> > >>> Perhaps: > >>> State of Affairs for Randomized and Changing Media Access Control > (MAC) > >>> Addresses > >>> > >>> Or: > >>> Overview of Privacy Issues with Randomized and Changing Media Access > >>> Control (MAC) Addresses > >>> --> > >>> > >>> [Carlos] My preference would be "State of Affairs for Randomized and > >> Changing Media Access Control (MAC) Addresses". > >> [JCZ] I’m also fine with the first proposal. > >> > >> > >>> > >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>> the title) for use on https://www.rfc-editor.org/search. --> > >>> > >>> > >>> [Carlos] privacy, tracking, slap. > >> [JCZ] rcm, 802.11bh, 802.11bi > >> > >> > >> > >>> 3) <!-- [rfced] We updated this long sentence as follows to improve > >>> readability. Note that we pulled out the text "for instance...web > >>> trackers, etc." into a new sentence. Please review to ensure the > updated > >>> text accurately conveys the intended meaning. > >>> > >>> Original: > >>> This is due to many factors, such as the vast digital footprint that > >>> users > >>> leave on the Internet with or without their consent, for instance > >>> sharing information on social networks, cookies used by browsers and > >>> servers for various reasons, connectivity logs that allow tracking of > >>> a user's Layer-2 (L2/MAC) or Layer-3 (L3) address, web trackers, > >>> etc.; and/or the weak (or even null in some cases) authentication and > >>> encryption mechanisms used to secure communications. > >>> > >>> Updated: > >>> This is due to many factors, such as the vast digital footprint that > >>> users > >>> leave on the Internet with or without their consent and the weak (or > >>> even null) authentication and encryption mechanisms used to secure > >>> communications. A digital footprint may include information shared > >>> on social networks, cookies used by browsers and servers for various > >>> reasons, connectivity logs that allow tracking of a user's Layer 2 > >>> (L2) address (i.e, MAC address) or Layer 3 (L3) address, web > >>> trackers, etc. > >>> --> > >>> > >>> [Carlos] The updated text is fine, thanks! > >> [JCZ] Agree > >> > >> > >>> > >>> 4) <!-- [rfced] In Figure 1, will readers know what the "I/G bit" is? > The > >>> "U/L > >>> bit" is described in the paragraph following the figure. > >>> --> > >>>> > >>> [Carlos] Readers might not know, though that bit is not that relevant > for > >>> the purpose of this document. Text might be added to indicate that the > >>> "I/G" (or Individual/Group) bit indicates that a frame is meant to > reach > >>> only one network interface, when set to 0, or to a group of network > >>> interfaces, when set to 1. > >>> > >> [JCZ] Good suggestion from Carlos. > >> > >> > >>> 5) <!-- [rfced] We updated this long sentence to use a definition list > >>> (i.e., > >>> <dl>). Let us know any concerns. > >>> > >>> Original: > >>> Most physical devices are provided with a > >>> universally administered address, which is composed of two parts: (i) > >>> the Organizationally Unique Identifier (OUI), which are the first > >>> three octets in transmission order and identify the organization that > >>> issued the identifier, and (ii) Network Interface Controller (NIC) > >>> Specific, which are the following three octets, assigned by the > >>> organization that manufactured the NIC, in such a way that the > >>> resulting MAC address is globally unique. > >>> > >>> Updated: > >>> A universally administered address is uniquely assigned to a device > >>> by its manufacturer. Most physical devices are provided with a > >>> universally administered address, which is composed of two parts: > >>> > >>> Organizationally Unique Identifier (OUI): The first three octets in > >>> transmission order, which identify the organization that issued > >>> the identifier. > >>> > >>> Network Interface Controller (NIC) Specific: The following three > >>> octets, which are assigned by the organization that manufactured > >>> the NIC, in such a way that the resulting MAC address is globally > >>> unique. > >>> --> > >>> > >>> [Carlos] The updated text is fine, thanks! > >> [JCZ] Good improvement. I also think that for consistency the first > sentence of 2.1 should read “Most Mobile devices today are Wi-Fi enabled.” > I don’t see any other instance of WLAN in the document. > >> > >> > >>> > >>> 6) <!-- [rfced] How may we expand "STA"? As "station"? If so, would it > be > >>> helpful > >>> to describe this in the first sentence below rather than in the second? > >>> > >>> Original: > >>> In an 802.11 network, a station exposes its MAC address in two > >>> different situations: > >>> > >>> * While actively scanning for available networks, the MAC address is > >>> used in the Probe Request frames sent by the device (a.k.a. > >>> IEEE 802.11 STA). > >>> > >>> Perhaps: > >>> In an 802.11 network, a device (also known as an IEEE 802.11 station > or > >>> STA) > >>> exposes its MAC address in two different situations: > >>> > >>> * While actively scanning for available networks, the MAC address is > >>> used in the Probe Request frames sent by the STA. > >>> --> > >>> > >>> [Carlos] I prefer the original text, maybe replacing "station" with > >> "station (or STA)". The reason is that stations are not the only type of > >> devices in IEEE 802.11 networks, and the text refers to the behavior of > >> stations. Then we can remove the expansion of STA in the second > sentence. > >> > >> [JCZ] I actually think that the suggestion is good. Unlike the IETF use > of station, for 802.11 “all” devices are an STA when they access the > medium. Only “some” STAs implement higher MAC functionality that makes them > different, like an AP. Hence, I think that the suggested text is generic > enough to encompass all definitions. > >> > >> > >>> > >>> 7) <!-- [rfced] We recommend updating this long sentence to use a > bulleted > >>> list > >>> to improve readability. Also, because [IEEE_802E] and [IEEE_802c] seem > to > >>> be > >>> published, is it correct to refer to them as PARs and include the > >>> definition of PARs? > >>> > >>> Original: > >>> The work and discussions from the group have generated multiple > >>> outcomes, such as: 802E PAR (Project Authorization Request, this is > >>> the means by which standards projects are started within the IEEE. > >>> PARs define the scope, purpose, and contact points for a new > >>> project): Recommended Practice for Privacy Considerations for IEEE > >>> 802 Technologies [IEEE_802E], and the 802c PAR: Standard for Local > >>> and Metropolitan Area Networks - Overview and Architecture Amendment > >>> - Local Medium Access Control (MAC) Address Usage [IEEE_802c]. > >>> > >>> Perhaps: > >>> The work and discussions from the group have generated multiple > >>> outcomes, such as the following Project Authorization Requests > (PARs). > >>> PARs are the means by which standards projects are started within the > >>> IEEE; they define the scope, purpose, and contact points for a new > >>> project. > >>> > >>> * "IEEE Recommended Practice for Privacy Considerations for IEEE > >>> 802(R) Technologies" [IEEE_802E] > >>> > >>> * "IEEE Standard for Local and Metropolitan Area Networks: Overview > >>> and Architecture - Amendment 2: Local Medium Access Control (MAC) > >>> Address > >>> Usage" [IEEE_802c] > >>> > >>> Or: > >>> The work and discussions from the group have generated multiple > >>> outcomes, such Project Authorization Requests (PARs) that resulted in > >>> the > >>> following documents: > >>> > >>> * "IEEE Recommended Practice for Privacy Considerations for IEEE > >>> 802(R) Technologies" [IEEE_802E] > >>> > >>> * "IEEE Standard for Local and Metropolitan Area Networks: Overview > >>> and Architecture - Amendment 2: Local Medium Access Control (MAC) > >>> Address > >>> Usage" [IEEE_802c] > >>> --> > >>> > >>> [Carlos] The first proposed text is fine, but I'd like Juan Carlos or > >> Amelia (as IEEE 802 participants) to confirm. > >> > >> [JCZ] Here the proposed text is more accurate. It is true that the > specifications have been published, so mentioning that PARs were created > and that the work resulted in specifications is I think the most > comprehensive definition. > >> > >>> > >>> 8) <!-- [rfced] The title of Section 2.3 uses "Experiments", but the > text > >>> in > >>> paragraphs 3 and 4 uses "trials". Would you like to make these > >>> consistent? > >>> > >>> For example: > >>> 2.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802 > >>> meetings > >>> ... > >>> In order to test the effects of MAC address randomization, trials > >>> were conducted at the IETF and IEEE 802 meetings between November > >>> 2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in Berlin. > >>> The purpose of the trials was to evaluate ... > >>> --> > >>> > >>> [Carlos] I think making them consistent is better. I'd prefer to use > >> "experiments". Thanks! > >> > >> [JCZ] Agree. > >> > >> > >>> > >>> 9) <!-- [rfced] We have several questions about the text below. > >>> > >>> a) Please review the text starting with "user privacy solutions > applicable > >>> to > >>> IEEE Std 802.11", and let us know how we can revise for clarity. > >>> > >>> b) Would it be helpful to add numbers like (1) and (2) to improve > >>> readability > >>> of this long sentence? > >>> > >>> c) Are the "two new standards projects" projects mentioned in this > sentence > >>> the [IEEE_802] and [IEEE_802E], which are discussed in the two > paragraphs > >>> following this text? If so, adding a sentence indicating this might be > >>> helpful > >>> to readers. See suggestion below. > >>> > >>> Original: > >>> In the summer of 2020 this work emanated in two new standards > projects > >>> with the purpose of developing mechanisms that do not decrease user > >>> privacy but enable an optimal user experience when the MAC address of > >>> a device in an Extended Service Set (a group of interconnected IEEE > >>> 802.11 wireless access points and stations that form a single logical > >>> network) is randomized or changes [rcm_user_experience_par] and user > >>> privacy solutions applicable to IEEE Std 802.11 [rcm_privacy_par]. > >>> > >>> Perhaps: > >>> In the summer of 2020, this work emanated in two new standards > projects. > >>> The purpose of these projects was to develop mechanisms that do not > >>> decrease user > >>> privacy but enable an optimal user experience when (1) the MAC > address > >>> of > >>> a device in an Extended Service Set (a group of interconnected IEEE > >>> 802.11 wireless access points and stations that form a single logical > >>> network) is randomized or changes [rcm_user_experience_par] and (2) > user > >>> privacy solutions descibed in IEEE Std 802.11 [rcm_privacy_par] > apply. > >>> These projects > >>> are described below. > >>> --> > >>> > >>> [Carlos] The updated text is fine, but Amelia and/or Juan Carlos, > please > >> check! > >> > >> [JCZ] Agree. > >> > >>> > >>> 10) <!-- [rfced] Please confirm that "Annex T" is correct here. We do > not > >>> see an > >>> Annex T in the referenced document, but we do see that Annex I is > titled > >>> "Privacy considerations in bridged networks". > >>> > >>> Link: > https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10225636 > >>> (You may need to sign in to view.) > >>> > >>> Original: > >>> Annex T of IEEE Std 802.1AEdk-2023: > >>> MAC Privacy Protection [IEEE_802.1AEdk-2023] discusses privacy > >>> considerations in bridged networks. > >>> --> > >>> > >>> [Carlos] Amelia/Juan Carlos: can you please check this and provide a > >> response? > >> > >> [JCZ] Indeed, the reference should be to Annex I. Thanks. > >> > >> > >>> > >>> 11) <!-- [rfced] Would it be helpful to include a citation for "IEEE > Std > >>> 802.11 > >>> medium access control (MAC) specification"? Will readers know which > >>> specification is being discussed here? > >>> > >>> Original: > >>> * The IEEE 802.11bi task group, which is chartered to define > >>> modifications to the IEEE Std 802.11 medium access control (MAC) > >>> specification to specify new mechanisms that address and improve > >>> user privacy. > >>> --> > >>> > >>> [Carlos] I think adding a reference would be useful, thanks! > >> [JCZ] This is the 802.11bi PAR > https://development.standards.ieee.org/myproject-web/public/view.html#pardetail/8772 > . > >> The 802.11bi specification is still being worked out, with the latest > draft being: > >> IEEE P802.11bi™/D1.0 > >> 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 5: Enhanced Service with Data Privacy > >> Protection > >> > >> > >>> > >>> 12) <!-- [rfced] We have questions about the text below and the > [wba_paper] > >>> reference entry. > >>> > >>> a) The second sentence below is difficult to follow (the first is > included > >>> for > >>> context). How may we update for clarity? > >>> > >>> Original: > >>> As part of this work, WBA has documented a set of use cases that a > >>> Wi-Fi Identification Standard should address in order to scale and > >>> achieve longer term sustainability of deployed services. A first > >>> version of this document has been liaised with the IETF as part of > >>> the MAC Address Device Identification for Network and Application > >>> Services (MADINAS) activities through the "Wi-Fi Identification In a > >>> post MAC Randomization Era v1.0" paper [wba_paper]. > >>> > >>> Perhaps: > >>> As part of this work, WBA has documented a set of use cases that a > >>> Wi-Fi Identification Standard should address in order to scale and > >>> achieve longer-term sustainability of deployed services. A first > >>> version of that document, a paper titled "Wi-Fi Identification In a > >>> post MAC Randomization Era v1.0" [wba_paper], was created while > >>> liaising with the IETF MADINAS Working Group. > >>> > >>> > >>> b) We cannot locate this this document. We do not see it listed at > >>> https://wballiance.com/resource/. Can you provide a URL? > >>> > >>> Original: > >>> [wba_paper] > >>> Alliance, W. B., "Wi-Fi Identification Scope for Liasing - > >>> In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro: > >>> Post MAC Randomization Era v1.0 - IETF liaison , March > >>> 2020. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Regarding the document, > this > >> was shared sd part of the liaison: > >> > https://mailarchive.ietf.org/arch/msg/madinas/ZmMhpHBquVf6TOD4uU_x2Yenvuw/ > >> > >> In any case, I think we can replace it with the following whitepaper: > >> > https://wballiance.com/wi-fi-device-identification-a-way-through-mac-randomization/ > >> What do you think Juan Carlos? > >> [JCZ] I agree, good suggestion Carlos. > >> > >>> > >>> 13) <!-- [rfced] Please clarify "In order to do so". Is the intended > >>> meaning "To > >>> generate temporary addresses"? Also, may we add numbers to improve > >>> readability of this long sentence? > >>> > >>> Original: > >>> In order to do so, a node produces a sequence of temporary global > >>> scope addresses from a sequence of interface identifiers that appear > >>> to be random in the sense that it is difficult for an outside > >>> observer to predict a future address (or identifier) based on a > >>> current one, and it is difficult to determine previous addresses (or > >>> identifiers) knowing only the present one. > >>> > >>> Perhaps: > >>> To generate temporary addresses, a node produces a sequence of > >>> temporary global > >>> scope addresses from a sequence of interface identifiers that appear > >>> to be random in the sense that (1) it is difficult for an outside > >>> observer to predict a future address (or identifier) based on a > >>> current one and (2) it is difficult to determine previous addresses > (or > >>> identifiers) knowing only the present one. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Thanks! > >> > >> [JCZ] Agree > >> > >> > >>> > >>> 14) <!-- [rfced] FYI - We combined these sentences. Please review to > >>> confirm that > >>> the updated text conveys the intended meaning. > >>> > >>> Original: > >>> Not only MAC and IP addresses can be used for tracking purposes. > >>> Some DHCP options carry unique identifiers. > >>> > >>> Updated: > >>> In addition to MAC and IP addresses, some DHCP options that carry > unique > >>> identifiers can also be used for tracking purposes. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Thanks! > >> [JCZ] Agree > >> > >> > >>> > >>> 15) <!-- [rfced] Please review the text starting with "to be taken..." > and > >>> let us > >>> know how to update for clarity. > >>> > >>> Original: > >>> It has not been unusual for the 24-bit value > >>> to be taken as an incrementing counter, assigned at the factory, and > >>> burnt into non-volatile storage. > >>> > >>> Perhaps: > >>> It is not unusual for the 24-bit value > >>> to be an incrementing counter that was assigned at the factory and > >>> burnt into non-volatile storage. > >>> > >>> Or: > >>> It is not unusual for the 24-bit value > >>> to be used as an incrementing counter that was assigned at the > factory > >>> and > >>> burnt into non-volatile storage. > >>> --> > >>> > >>> > >>> [Carlos] The second proposal (Or:) text is fine with me. Thanks! > >> > >> [JCZ] Agree > >> > >> > >>> 16) <!-- [rfced] Does "802.15.4" need a reference entry? > >>> > >>> Original: > >>> Note that 802.15.4 use 64-bit MAC addresses, and the IEEE assigns > >>> 32-bit prefixes. > >>> > >>> Perhaps: > >>> Note that IEEE Std 802.15.4 [IEEE_802.15.4] uses 64-bit MAC > addresses, > >>> and the IEEE assigns > >>> 32-bit prefixes. > >>> ... > >>> [IEEE_802.15.4] IEEE, "IEEE Standard for Low‐Rate Wireless Networks", > >>> IEEE Std 802.15.4-2024, > >>> DOI 10.1109/IEEESTD.2024.10794632, 2024 < > >>> https://ieeexplore.ieee.org/document/10794632>. > >>> --> > >>> > >>> [Carlos] I think adding the reference is good. Thanks! > >> > >> [JCZ] Agree > >> > >> > >>> > >>> 17) <!-- [rfced] FYI - We updated "*not*" here to be enclosed in the > >>> <strong> > >>> element. This yields asterisks in the txt output and bold in the html > and > >>> pdf outputs. > >>> > >>> Original: > >>> The resulting MAC address is *not* stored > >>> in non-volatile storage. > >>> --> > >>> > >>> [Carlos] OK! > >> > >> [JCZ] Thanks. > >> > >> > >>> > >>> 18) <!-- [rfced] How may we clarify the parenthetical here? > >>> > >>> Original: > >>> This is typically used with Wi-Fi (802.11) networks where the network > >>> is identified by an SSID Name. > >>> > >>> Perhaps: > >>> This is typically used with Wi-Fi networks (i.e., 802.11 networks) > >>> where the network > >>> is identified by an SSID Name. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Thanks! > >> > >> [JCZ] Agree > >> > >> > >>> > >>> 19) <!-- [rfced] These sentences are difficult to parse. Please > clarify. > >>> Also, how > >>> should "WPA/802.1x" be expanded here? > >>> > >>> Original: > >>> This will > >>> involve a new WPA/802.1x session: new EAP, TLS, etc. negotiations. A > >>> new DHCP, SLAAC will be done. > >>> --> > >>> > >> > >> [Carlos] I propose to use the following updated text: > >> This will involve a new WPA/802.1x session, as well as obtaining (or > >> refreshing) a new IP address (e.g., using DHCP or SLAAC). > >> [JCZ] Some minor corrections: > >> “This will involve a new 802.1X session, as well as > obtaining/refreshing a new IP address (e.g., using DHCP or SLAAC). > >> > >> > >>> > >>> 20) <!-- [rfced] This sentence appears in both Sections 6.5 and 6.6. In > >>> Section > >>> 6.6 about PSGM, would you like to update "Like PNGM" to "Like PNGM and > >>> PPGM"? > >>> > >>> Original: > >>> Like PNGM, it is used primarily with Wi-Fi. > >>> > >>> Perhaps: > >>> Like PNGM and PPGM, it is used primarily with Wi-Fi. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Thanks! > >> > >> [JCZ] Agree > >> > >> > >>> 21) <!-- [rfced] This question is for the *AD and authors. This GitHub > URL > >>> appears > >>> in the first paragraph of Section 7: > >>> > >>> > >>> > https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-practices.md > >>> > >>> Because the link contains text from Section 7 of this document, we > >>> recommend > >>> creating a new repo or a wiki page on https://wiki.ietf.org/ to host > the > >>> information in order to remove "draft" from the URL. We also recommend > >>> updating the text to align with the edited document and replacing > >>> "draft-ietf-madinas-mac-address-randomization" with "RFC 9724". Please > let > >>> us > >>> know your thoughts. > >>> --> > >>> > >> > >> [Carlos] From my side, it would be fine to host this on wiki.ietf.org, > as > >> there IETF keeps the control of the page. And of course we can update > the > >> text to keep it aligned and use RFC 9724. If the AD agrees with this > >> change, we can discuss how to implement this change. > >> > >> [JCZ] I agree that hosting it on wiki.org would be more beneficial in > the long run. > >> > >> > >>> > >>> > >>> 22) <!-- [rfced] FYI - The URL provided in the following sentence > results > >>> in a 404 > >>> error, so we removed it. We also created a reference entry for the > >>> Wayback Machine URL. > >>> > >>> Original: > >>> Table 1 summarizes current practices for Android and iOS, as the time > >>> of writing this document (original source posted at: > >>> https://www.fing.com/news/private-mac-address-on-ios-14, latest > >>> wayback machine's snapshot available here: > >>> > https://web.archive.org/web/20230905111429/https://www.fing.com/news/ > >>> private-mac-address-on-ios-14, updated based on findings from the > >>> authors). > >>> > >>> Updated: > >>> Table 1 summarizes current practices for Android and iOS at the time > >>> of writing this document (the original source is available at > >>> [private_mac]) and includes updates based on findings from the > >>> authors. > >>> --> > >>> > >>> [Carlos] The proposed text is fine with me. Thanks! > >> [JCZ] Agree > >> > >> > >>> > >>> 23) <!-- [rfced] Table 2 includes both "Random" (no period) and > "Random." > >>> (with > >>> period). We believe this stands for "randomization", so may we update > all > >>> instances in the table to be "Random."? > >>> --> > >>> > >>> [Carlos] Yes, this is good. > >> > >> [JCZ] Agree > >> > >> > >>> > >>> 24) <!-- [rfced] We updated this sentences as follows, including > creating > >>> parallel > >>> structure in the list. Would it be helpful to further update to use a > >>> bulleted list? > >>> > >>> Original: > >>> Table 2 summarizes our findings, where show on > >>> different rows whether the OS performs address randomization per > >>> network (PNGM according to the taxonomy introduced in Section 6), per > >>> new connection (PSGM), daily (PPGM with a period of 24h), supports > >>> configuration per SSID, supports address randomization for scanning, > >>> and whether it does that by default. > >>> > >>> Current: > >>> Table 2 summarizes our findings; the rows in the table show whether > >>> the OS performs address randomization per network (PNGM according to > >>> the taxonomy introduced in Section 6), performs address randomization > >>> per new connection (PSGM), performs address randomization daily (PPGM > >>> with a period of 24 hours), supports configuration per SSID, supports > >>> address randomization for scanning, and supports address > randomization > >>> for scanning by default. > >>> > >>> Or: > >>> Table 2 summarizes our findings; the rows in the table show whether > >>> the OS: > >>> > >>> * performs address randomization per network (PNGM according to > >>> the taxonomy introduced in Section 6) > >>> > >>> * performs address randomization per new connection (PSGM) > >>> > >>> * performs address randomization daily (PPGM with a period of 24 > hours) > >>> > >>> * supports configuration per SSID > >>> > >>> * supports address randomization for scanning > >>> > >>> * supports address randomization for scanning by default > >>> --> > >>> > >>> [Carlos] The first proposed text (no bullet list) is fine with me. > Thanks! > >> [JCZ] I have a slight preference for the bullets, but the paragraph > style is also fine. > >> > >> > >>> > >>> 25) <!-- [rfced] Would it be helpful to add a citation [IEEE_802E] > here? > >>> > >>> Original: > >>> A major conclusion of the work in IEEE Std 802E concerned the > >>> difficulty of defending privacy against adversaries of any > >>> sophistication. > >>> > >>> Perhaps: > >>> A major conclusion of the work in IEEE Std 802E [IEEE_802E] concerned > >>> the > >>> difficulty of defending privacy against adversaries of any > >>> sophistication. > >>> --> > >>> > >>> [Carlos] I agree that adding the reference is good. Thanks! > >> > >> [JCZ] Agree > >> > >> > >>> 26) <!-- [rfced] FYI - We updated the title of this reference entry to > >>> match the > >>> title at the included URL. In addition, we updated the URL because > >>> https://support.apple.com/en-us/HT211227 redirects to > >>> https://support.apple.com/en-us/102509. > >>> > >>> Original: > >>> [privacy_ios] > >>> Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14, > >>> and watchOS 7", > >>> <https://support.apple.com/en-us/HT211227>. > >>> > >>> Current: > >>> [privacy_ios] > >>> Apple Inc., "Use private Wi-Fi addresses on Apple > >>> Devices", Apple Support, > >>> <https://support.apple.com/en-us/102509>. > >>> --> > >>> > >>> [Carlos] Fine with me. Thanks! > >> > >> [JCZ] OK > >> > >> > >> 27) <!-- [rfced] We were unable to locate the following reference > entries. Can you > >> point us to URLs so that we can verify these? > >> > >> [JCZ] These references can be found on the 802.11 repository: > https://mentor.ieee.org/802.11/documents > >> > >> Original: > >> [rcm_privacy_csd] > >> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >> Changing MAC Addresses Study Group CSD on user experience > >> mechanisms", doc.:IEEE 802.11-20/1346r1 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-1346-04-0rcm-csd-draft-for-privacy-amendment-of-rcm-project.docx > >> > >> [rcm_privacy_par] > >> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >> Changing MAC Addresses Study Group PAR on privacy > >> mechanisms", doc.:IEEE 802.11-19/854r7 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-0854-07-0rcm-par-proposal-for-privacy.docx > >> > >> [rcm_tig_final_report] > >> IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And > >> Changing MAC Addresses Topic Interest Group Report", > >> doc.:IEEE 802.11-19/1442r9 , 2019. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/19/11-19-1442-09-0rcm-rcm-tig-draft-report-outline.odt > >> > >> [rcm_user_experience_csd] > >> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >> Changing MAC Addresses Study Group CSD on user experience > >> mechanisms", doc.:IEEE 802.11-20/1117r3 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-1117-05-0rcm-rcm-sg-proposed-rcm-csd-draft.docx > >> > >> [rcm_user_experience_par] > >> IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And > >> Changing MAC Addresses Study Group PAR on user experience > >> mechanisms", doc.:IEEE 802.11-20/742r5 , 2020. > >> > >> [JCZ] > https://mentor.ieee.org/802.11/dcn/20/11-20-0742-06-0rcm-proposed-par-draft.docx > >> --> > >> > >> > >> > >> 28) <!-- [rfced] We have some questions about the following text and the > >> accompanying reference entry: > >> > >> Original: > >> It is possible to use PNGM for wired Ethernet connections through > >> some passive observation of network traffic, such as STP > >> [IEEE802.1D-2004], LLDP [IEEE802.1AB-2016], DHCP or Router > >> Advertisements to determine which network has been attached. > >> ... > >> [IEEE802.1D-2004] > >> IEEE 802.1, "IEEE Std 802.1D-2004: IEEE Standard for Local > >> and metropolitan area networks: Media Access Control (MAC) > >> Bridges", 2004. > >> > >> a) This reference entry is provided for STP, but we see the following at > >> https://ieeexplore.ieee.org/document/1309630: "remove the Spanning Tree > >> protocol defined in Clause 8". The document is behind a paywall so we > cannot > >> check that it contains information about STP. Please confirm this > reference > >> is accurate. > >> > >> > >> b) We see that IEEE Std 802.1D-2004 has been superseded. See > >> https://standards.ieee.org/ieee/802.1D/3387/. > >> > >> It seems that it has been superseded several times: > >> by 802.1Q-2014 - https://standards.ieee.org/ieee/802.1D/3387/ > >> by 802.1Q-2014 - https://standards.ieee.org/ieee/802.1Q/5801/ > >> by 802.1Q-2018 - https://standards.ieee.org/ieee/802.1Q/6844/ > >> > >> The active standard seems to be IEEE 802.1Q-2022 (see > >> https://standards.ieee.org/ieee/802.1Q/10323/ and > >> https://ieeexplore.ieee.org/document/10004498). > >> > >> Would you like to cite the active standard? If so, please note that it > is also > >> behind a paywall so we cannot check that it discusses STP. > >> --> > >> [JCZ] I checked with the 802.1 chair and I got the following response: > >> First, there is no paywall for active IEEE 802 standards, but there is > a login wall. That is, you now have to login with a (free) IEEE account to > get access to IEEE 802 standards. However, there is a paywall for > withdrawn/superseded standards. If the RFC Editor needs a login-free > access, we can work with IEEE SA staff to provide this. > >> Second, STP was deprecated over 20 years ago and replaced with RSTP, > which interworks with STP in the same network. STP was last defined in > (the now superseded) IEEE 802.1D-1998 clause 8. Any new IETF RFC should > reference RSTP (or MSTP or SPB). These are defined in 802.1Q-2022 clause > 13 Spanning tree protocols. (…) if this is just an example, I suggest not > using the acronym and using the current reference. That is, change STP > [IEEE802.1D-2004] > >> to spanning tree protocols [IEEE802.1Q-2022] > >> This will provide reference to the current protocols, but also show > history to the superseded STP. > >> [JCZ-cont] Hence, I suggest we follow the recommendation and use > “spanning tree protocols [IEEE802.1Q-2022]” > >> > >> > >> > >> 29) <!-- [rfced] FYI - We updated the date in this reference entry from > July 2020 > >> to May 2021 match the date of the conference (see > >> https://ieeexplore.ieee.org/document/9488728). > >> > >> Original: > >> [contact_tracing_paper] > >> Leith, D. J. and S. Farrell, "Contact Tracing App Privacy: > >> What Data Is Shared By Europe's GAEN Contact Tracing > >> Apps", IEEE INFOCOM 2021 , July 2020. > >> > >> Updated: > >> [contact_tracing_paper] > >> Leith, D. J. and S. Farrell, "Contact Tracing App Privacy: > >> What Data Is Shared By Europe's GAEN Contact Tracing > >> Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer > >> Communications, DOI 10.1109/INFOCOM42981.2021.9488728, May > >> 2021, <https://ieeexplore.ieee.org/document/9488728>. > >> --> > >> [JCZ] OK, thanks. > >> > >> > >> 30) <!-- [rfced] Please review the text starting with "performed as > part..." and > >> let us know how to update for clarity. > >> > >> Original: > >> Finally, authors would > >> also like to thank the IEEE 802.1 Working Group for its review and > >> comments, performed as part of the Liaison statement on Randomized > >> and Changing MAC Address (https://datatracker.ietf.org/ > >> liaison/1884/). > >> > >> Perhaps: > >> Finally, authors would > >> like to thank the IEEE 802.1 Working Group for its review and > >> comments, which resulted in the "Liaison statement on Randomized > >> and Changing MAC Address" (https://datatracker.ietf.org/ > >> liaison/1884/). > >> > >> Or: > >> Finally, authors would > >> like to thank the IEEE 802.1 Working Group for its review and > >> comments (see <https://datatracker.ietf.org/ > >> liaison/1884/>). > >> > >> --> > >> [JCZ] The last version looks fine. Thanks. > >> > >> > >> 31) <!-- [rfced] We see a number of author-inserted comments in the > .xml file for > >> this document. We are unsure if these have been resolved. Please review > >> and let us know if these can be deleted or if they need to be addressed. > >> --> > >> > >> [JCZ] You can ignore the comments. Thanks. > >> > >> > >> 32) <!-- [rfced] Terminology > >> > >> a) We note inconsistencies in the term below throughout the text. > Should these > >> be uniform? If so, please let us know which form is preferred. > >> > >> MAC address randomization vs. MAC randomization > >> > >> [JCZ] MAC address randomization > >> > >> > >> b) Is "overcome" the best word choice here? Would "address" or > >> something else be better? > >> > >> Original: > >> There have been several initiatives within the IETF and the IEEE 802 > >> standards committees to overcome some of these privacy issues. > >> ... > >> There have been several initiatives at the IETF and the IEEE 802 > >> standards committees to overcome some of these privacy issues. > >> ... > >> One way to overcome this privacy concern is by using randomly > >> generated MAC addresses. > >> --> > >> > >> [JCZ] “address” is more appropriate. > >> > >> > >> 33) <!-- [rfced] Abbreviations > >> > >> a) FYI - We have 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. > >> > >> Media Access Control (MAC) > >> Standards Development Organization (SDO) > >> Link Layer Discovery Protocol (LLDP) > >> Extensible Authentication Protocol (EAP) > >> DHCP Unique Identifier (DUID) > >> > >> [JCZ] These are fine, thanks. > >> > >> > >> b) How should the following acronyms be expanded in this document? Our > list > >> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list) includes > several > >> expansions for each. > >> > >> SSID > >> STP > >> > >> [JCZ] > >> Service Set Identifier (SSID) > >> Spanning Tree Protocol (STP) > >> > >> > >> c) May we update the expansion of RCM as follows? If so, we will also > update > >> "RCM" to "RCM address" in the sentences below. > >> > >> Original (expansion): > >> Randomized and Changing MAC addresses (RCM) > >> > >> Perhaps: > >> Randomized and Changing MAC (RCM) addresses > >> > >> > >> Original (sentences with RCM): > >> As of 2024, two task groups in IEEE 802.11 are dealing with issues > >> related to RCM: > >> > >> * The IEEE 802.11bh task group, which is looking at mitigating the > >> repercussions that RCM creates on 802.11 networks and related > >> services. > >> > >> Perhaps: > >> As of 2024, two task groups in IEEE 802.11 are dealing with issues > >> related to RCM addresses: > >> > >> * The IEEE 802.11bh task group, which is looking at mitigating the > >> repercussions that RCM addresses create on 802.11 networks and > related > >> services. > >> > >> [JCZ] Even though I agree with the comments, the original text aligns > more with the actual IEEE 802.11bh use, where “address” is implicit in RCM: > https://ieee802.org/11/Reports/tgbh_update.htm > >> > >> > >> d) We see this note in Section 6: > >> > >> Note about the used naming convention: the "M" in MAC is included in > >> the acronym, but not the "A" from address. This allows one to talk > >> about a PVOM Address, or PNGM Address. > >> > >> Per this note, may we update the expansions in Section 6.1-6.6 as > follows and > >> then update instances like "PDGM" in the document to "PDGM address"? > >> > >> Original: > >> Per-Vendor OUI MAC address (PVOM) > >> Per-Device Generated MAC address (PDGM) > >> Per-Boot Generated MAC address (PBGM) > >> Per-Network Generated MAC address (PNGM) > >> Per-Period Generated MAC address (PPGM) > >> Per-Session Generated MAC address (PSGM) > >> > >> Perhaps: > >> Per-Vendor OUI MAC (PVOM) Address > >> Per-Device Generated MAC (PDGM) Address > >> Per-Boot Generated MAC (PBGM) Address > >> Per-Network Generated MAC (PNGM) Address > >> Per-Period Generated MAC (PPGM) Address > >> Per-Session Generated MAC (PSGM) Address > >> > >> [JCZ] Similarly to the previous comment, the tendency in 802.11/Wi-Fi > terminology is to omit the (A)ddress from the acronym as we originally > proposed. > >> > >> > >> e) FYI - We see "Interface Identifier", "interface identifier", and > "IID" used > >> throughout the document. We updated to use the expansion in the first > instance > >> and the abbreviation for all other instances. > >> [JCZ] Thanks. > >> > >> > >> > >> 34) <!-- [rfced] Please review whether the following note in this > document should > >> be in the <aside> element. It is defined as "a container for content > that > >> is semantically less important or tangential to the content that > >> surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > >> > >> Original: > >> Note about the used naming convention: the "M" in MAC is included in > >> the acronym, but not the "A" from address. This allows one to talk > >> about a PVOM Address, or PNGM Address. > >> --> > >> [JCZ] I agree it could be in the <aside> element. > >> > >> > >> > >> 35) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > >> Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >> and let us know if any changes are needed. Updates of this nature > typically > >> result in more precise language, which is helpful for readers. > >> > >> Note that our script did not flag any words in particular, but this > should > >> still be reviewed as a best practice. > >> --> > >> [JCZ] Nothing pops out. > >> Thanks a lot for the thorough review! > >> > >> > >> > >> Thank you. > >> > >> RFC Editor/rv > > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
