Hi Éric, > I had in mind that I had already replied to Q21 telling the two authors to > use whatever means they prefer but with a slight preference to wiki.ietf.org, > which also has authors’ preference.
Yes, you did reply to question #21. We are now waiting for notification that the information is on wiki.ietf.org. We’ll then update Section 7 accordingly. In addition to this, followup questions #A, B, C, and D for the authors (from the email dated 2025-02-7) are still open. I've also pasted these below for their convenience: 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 27, 2025, at 5:36 AM, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > > From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > Date: Friday, 21 February 2025 at 23:56 > To: Juan Carlos Zuniga (juzuniga) <juzuniga=40cisco....@dmarc.ietf.org>, > CARLOS JESUS BERNARDOS CANO <c...@it.uc3m.es>, amelia.i...@andersdotter.cc > <amelia.i...@andersdotter.cc> > Cc: RFC Editor <rfc-edi...@rfc-editor.org>, 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: AUTH48: RFC-to-be 9724 > <draft-ietf-madinas-mac-address-randomization-15> for your review > 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. > > Text below elided for clarity. > I had in mind that I had already replied to Q21 telling the two authors to > use whatever means they prefer but with a slight preference to wiki.ietf.org, > which also has authors’ preference. > Regards > -éric > >> > >>> 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. > >> > >> > >>> > >>> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
