|
@Dave: Thanks for reviewing the draft. Comments inline.
Best,
Yiu
From: Dave Thaler via Datatracker <noreply@xxxxxxxx>
Sent: Tuesday, December 3, 2024 11:33 PM To: int-dir@xxxxxxxx <int-dir@xxxxxxxx> Cc: draft-ietf-madinas-use-cases.all@xxxxxxxx <draft-ietf-madinas-use-cases.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; madinas@xxxxxxxx <madinas@xxxxxxxx> Subject: Intdir last call review of draft-ietf-madinas-use-cases-15 Reviewer: Dave Thaler
Review result: Almost Ready 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. [YL] You are absolutely right. This draft is specifically about RCM in WiFi. I think we should add WiFi to the title and abstract.
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. [YL] We will remove voice and keepalive, and replace with traffic or data packets. I heard your argument. MAC isn't relevant to distinguish application type. This draft should only mention what MAC can be
used, We will go back and rework Section 6.
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. [YL] Agreed. Will fix it in next version.
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. [YL] How about replacing it to "Privacy is a major concern for many users"?
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 [YL] We will address those terms in next version.
A PDF copy with my comments and a bunch of editorial nits inline can be found at [YL] Thanks. We will make the changes accordingly in next versoin.
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
