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
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
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.
-->
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.
-->
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.
-->
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.
-->
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]
-->
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 ...
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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>.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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."?
-->
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
-->
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.
-->
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>.
-->
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.
-->
28) <!-- [rfced] We have some questions about the following text and the
accompanying reference entry:
Original:
It is possible to use PNGM for wired Ethernet connections through
some passive observation of network traffic, such as STP
[IEEE802.1D-2004], LLDP [IEEE802.1AB-2016], DHCP or Router
Advertisements to determine which network has been attached.
...
[IEEE802.1D-2004]
IEEE 802.1, "IEEE Std 802.1D-2004: IEEE Standard for Local
and metropolitan area networks: Media Access Control (MAC)
Bridges", 2004.
a) This reference entry is provided for STP, but we see the following at
https://ieeexplore.ieee.org/document/1309630: "remove the Spanning Tree
protocol defined in Clause 8". The document is behind a paywall so we cannot
check that it contains information about STP. Please confirm this reference
is accurate.
b) We see that IEEE Std 802.1D-2004 has been superseded. See
https://standards.ieee.org/ieee/802.1D/3387/.
It seems that it has been superseded several times:
by 802.1Q-2014 - https://standards.ieee.org/ieee/802.1D/3387/
by 802.1Q-2014 - https://standards.ieee.org/ieee/802.1Q/5801/
by 802.1Q-2018 - https://standards.ieee.org/ieee/802.1Q/6844/
The active standard seems to be IEEE 802.1Q-2022 (see
https://standards.ieee.org/ieee/802.1Q/10323/ and
https://ieeexplore.ieee.org/document/10004498).
Would you like to cite the active standard? If so, please note that it is also
behind a paywall so we cannot check that it discusses STP.
-->
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>.
-->
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/>).
-->
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.
-->
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
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.
-->
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)
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
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.
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
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.
-->
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.
-->
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.
-->
Thank you.
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
