Dear Rebecca, Thanks a lot. Please see my responses below inline.
On Fri, Jan 24, 2025 at 8:26 PM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > 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. > > [Carlos] https://standards.ieee.org/ieee/802.11/10548/ > > >> 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. > > [Carlos] It's OK, 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). > > 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). > > [Carlos] The new proposed text is good, thanks! > > > 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. > [Carlos] The changes are good, 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. > > --> > > > > [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? > [Carlos] No strong opinion here. I think the note can be removed if you think it's clearer. Thanks! 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 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
