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. > > > 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. > > > 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 > > >>> [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 > > >>> [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 > > >>> [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 > > > 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”. > > > — 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
