Hi Carlos, Thank you for responding to our questions. We have updated the document accordingly (see list of files below) and have a few followup questions.
We will wait for Juan Carlos and Amelia to respond to questions #7, #9, #10, #12b, #27, and #28. We will also wait for the AD to address question #21. Here are our followup questions: >> 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! What reference should we use for “IEEE Std 802.11 medium access control (MAC) specification”? Is [IEEE_802.11aq] correct? If another document is intended, please provide a URL so we can construct the reference entry. >> 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! We updated to use the reference entry above, but please confirm that the cited reference is correct in context (i.e., it uses 64-bit MAC addresses). We are unable to verify. > 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). We have updated as you suggest. How should WPA be expanded here? As "Wi-Fi Protected Access (WPA)”? If so, would it be correct to update as follows with “or”? Current: 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). Perhaps: This will involve a new Wi-Fi Protected Access (WPA) or 802.1x session, as well as obtaining (or refreshing) a new IP address (e.g., using DHCP or SLAAC). > 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 > > > [Carlos] This is fine. We updated the titles of Sections 6.1-6.6 as shown above. We also added “address” or “addresses" after PDGM and PNGM in several places in Section 6.3, 6.4, 6.5, and 6.6. We did not make any changes like this in Section 7 as it didn’t seem needed in the context. Please review these changes in the diff file to ensure correctness. > 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. > --> > > [Carlos] It is fine to put the note in the <aside> element. We placed the note in Section 6 in the aside element. However, is the note necessary? — 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 Jan 23, 2025, at 2:16 AM, CARLOS JESUS BERNARDOS CANO <c...@it.uc3m.es> > wrote: > > 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". > > 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. > 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! > > 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. > > > 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! > > 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. > > 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. > > 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! > > 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! > > > 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? > > 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! > > 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? > > 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! > > 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! > > 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! > 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! > > 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! > > 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! > > 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). > > > > 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! > > > 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. > > > 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! > > > 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. > > 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! > > > 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! > > > 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! > > > 27) <!-- [rfced] We were unable to locate the following reference entries. > Can you > point us to URLs so that we can verify these? > > 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. > > [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. > > [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. > > [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. > > [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. > --> > > [Carlos] Here I prefer Juan Carlos or Amelia, as active participants in IEEE > 802, provide the references. > > 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. > > [Carlos] I leave this for Juan Carlos or Amelia as IEEE participants. > > 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. > --> > > [Carlos] I leave this for Juan Carlos or Amelia as IEEE participants. > > 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>. > --> > > > [Carlos] OK > > 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/>). > --> > > [Carlos] I prefer the second proposal (Or:). > > 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. > --> > > [Carlos] All author comments can be deleted. 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 > > [Carlos] 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. > --> > > [Carlos] I think "address" is better. Thanks! > > 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) > > [Carlos] This is good, 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 > > [Carlos] SSID: service set identifier > STP: spanning tree protocol > > 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 > > [Carlos] The new proposal is fine with me. > > > 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] This is fine. > > 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 > > > [Carlos] This is fine. > 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. > --> > > [Carlos] This is fine. > > 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. > --> > > [Carlos] It is fine to put the note 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. > --> > > [Carlos] Reviewed and it's fine. Thanks > > Thank you. > > [Carlos] Thanks a lot for all the very helpful comments and changes to > improve the overall quality. > > Thanks, > > Carlos > > RFC Editor/rv > > > > > On Jan 20, 2025, at 11:26 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/01/20 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9724.xml > https://www.rfc-editor.org/authors/rfc9724.html > https://www.rfc-editor.org/authors/rfc9724.pdf > https://www.rfc-editor.org/authors/rfc9724.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9724-diff.html > https://www.rfc-editor.org/authors/rfc9724-rfcdiff.html (side by side) > > Alt-diff of the text (allows you to more easily view changes > where text has been deleted or moved): > https://www.rfc-editor.org/authors/rfc9724-alt-diff.html > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9724-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9724 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9724 (draft-ietf-madinas-mac-address-randomization-15) > > Title : Randomized and Changing MAC Address State of Affairs > Author(s) : J. Zúñiga, C. Bernardos, A. Andersdotter > WG Chair(s) : Carlos J. Bernardos, Juan-Carlos Zúñiga > > Area Director(s) : Erik Kline, Éric Vyncke -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
