Reviewer: Tommy Pauly Review result: Ready with Issues 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@xxxxxxxx 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? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
