Last Call Review of draft-ietf-madinas-use-cases-12
review-ietf-madinas-use-cases-12-tsvart-lc-pauly-2024-11-19-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thank you for writing this document to explain the landscape of MAC address
usage and randomization. Overall, I think this is a useful informational document.

From the perspective of the transport area review team, this document generally
doesn't have many direct transport considerations. It is primarily concerned with
MAC addresses as identifiers within a local network, and recognizing such identifiers
over time and across networks. However, there are a few points that can improve how
they relate to the transport layers:

- Section 2.1 says:
"Additionally, multiple layers implemented at
   upper OSI layers have been designed with the assumption that each
   node on the LAN, using these services, would have a MAC address that
   would stay the same over time, and that this document calls a
   'persistent' MAC address."
I would suggest that we describe the upper layers of the protocol stack
in another way than "OSI layers", since OSI is not necessarily the
best way to view the Internet protocol suite. Perhaps say "upper protocol
layers", and explain the layers you mean (applications, etc).

- Section 6 gives an description of the basic service of a network as
"ability to
   connect to the Internet (e.g., DNS service or relay, and routing in
   and out through a local gateway)"
Later in the paragraph it talks about prioritizing certain flows of traffic
over others, so it might be useful to also mention in here any functions that
the network might be performing with regards to allowing transport flows,
and interacting with them (marking ECN for congestion, etc).

Other issuers:

Section 1 says:
"When individual devices are no longer easily
   identifiable, it also becomes difficult to associate a series of
   network packets with a particular individual using one particular
   device."
This seems to imply that the MAC address randomization is happening
at the granularity of "a series of network packets", which sounds almost
like a single flow. All of the examples I'm aware of are changing MAC
addresses only at the boundary of a network attachment session, so
the "series of network packets" is not necessarily the right granularity.

Section 4 defines a set of "Trust Degrees" (Full, Selective, and Zero).
Later, Table 1 in Section 6.2 describes various uses cases with
"Trust Degrees" of (High, Medium, Low). It would be good to reconcile these.
Additionally, it seems important to explain or justify the ratings in the
table more clearly. 

For example, the home network case explains:
"users are not worried about other users (or the home
   network admin) seeing their MAC address"
This seems overly reductionist, and assumes that all users of a home
network trust one another with all PII. Guests on the network may
not have this stance, and users might not be able to guarantee that
other devices on their home networks are not observing and maliciously
reporting information about their MAC addresses to then correlate with
other networks.

Other nits:

Section 1 says:
" Wi-Fi is an over-the-air technology, attackers
   with surveillance equipment can "monitor" WLAN packets and track the
   activity of WLAN devices."
This seems like it missing a word. Do you mean ".. technology, on which attackers..."?

Section 1 says:
"It could be useful to enumerate services that may be affected by RCM,"
Given that this is the point of the document, it would be nice to say something stronger
than "it could be useful". How about saying that it *is* useful, and explaining to whom,
something like: "It is useful for implementations of clients and network devices to..."

Section 3 says:
"However, the plurality of actors involved in the exchanges
   tends to blur the boundaries of what privacy should be protected
   against."
I think we are protecting against "privacy violations", not "privacy" itself?