Hi Éric*, Carlos, and other authors, *Éric - As AD, please review and approve the changes in the second paragraph of Section 6.5. The changes are best viewed in this diff file: https://www.rfc-editor.org/authors/rfc9724-auth48diff.html.
Carlos and other authors - > 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. No worries at all; we understand that this is a busy time. Safe travels to Bangkok! Thank you for responding to our questions; all questions have now been addressed. 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 each author prior to moving forward in the publication process. > 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. Thank you for creating this. We recommend updating the text to match the edited document; other than that, it looks great. Note that we included the following URL in Section 7 (the one above seems to be for edit mode and is not accessible if you aren’t logged in): https://wiki.ietf.org/en/group/madinas/RFC9724. — 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 Mar 8, 2025, at 11:27 PM, CARLOS JESUS BERNARDOS CANO <c...@it.uc3m.es> > wrote: > > 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
