Last Call Review of draft-ietf-madinas-use-cases-15
review-ietf-madinas-use-cases-15-intdir-lc-thaler-2024-12-03-00

Although the document has good information in it, I found a couple of
important issues that I think should be addressed before publication.

1. Neither the title nor the abstract is WiFi specific (or even wireless specific).
   However some places in this document appear to be very WiFi specific.
   If the intent is to be wifi specific or wireless specific, then I’d recommend
   changing the title and the abstract to add WiFi or wireless in them.
   If the intent is not to be wifi specific (and the MADINAS WG charter implies
   to me that it should not be wireless specific), then some sections of the
   document need work to just use wifi as an example, rather than implying the
   point is only relevant to wifi. I called out several such places in my
   marked up copy.

2. Section 6 talks about using a MAC address to distinguish "voice traffic coming
   from a smartphone" from "keepalive data coming from an IoT endpoint".  I think
   voice vs keepalive here sounds irrelevant.  Wouldn’t it be more correct to
   remove “voice” and “keepalive data” and just say “traffic”?  In such a scenario
   as the one described, it seems that the point it's making about using a mac identity
   is NOT about identifying the _traffic type_ per se (voice from smartphone vs
   keepalive data from a smartphone) but rather about the _device_ (voice or data
   from a smartphone, vs voice or data from a baby monitor). If you could distinguish
   the traffic type then you shouldn’t need the mac identity since you could
   prioritize voice (whether from phone or from baby monitor) over keepalive data
   (whether from phone or from baby monitor).  So the example in section 6 doesn't
   make sense to me as written.

3. Section 6.1 says "Changing the MAC
   address, even at disconnection-reconnection phase, without changing
   the IP address, may disrupt the stability of these mappings for these
   peers, if the change occurs within the caching period."  
   This is true, but that would generally be a bad idea anyway since then you’d
   have persistent linkage by IP address which would defeat the purpose of the MAC
   randomization in the first place.  So saying it may disrupt the stability is a
   relatively minor issue to point out by comparison.  It’d be better to rephrase
   to point out that this issue should not exist if devices actually follow existing
   privacy recommendations. 

4. Section 6.2 says about public Wi-Fi that "Privacy is the
   number one concern for the user."  Really? Can you cite a study that supports
   this claim?  I’d think that reliable connectivity (no connection drops) and
   bandwidth may be higher priority concerns for many users, especially novice
   users (e.g., kids) who are unaware of the privacy dangers.

5. A couple of terms are used without definition and I find hard to follow:
   - Hospitality environment
   - "fast-paced" MAC address randomization (as opposed to fast paced MAC address
     _changing_)
   - over-solicited

A PDF copy with my comments and a bunch of editorial nits inline can be found at
https://1drv.ms/b/s!Aqj-Bj9PNivcoIJPKEdMZa9zQhpnBA?e=hBVO2d