[Last-Call] Re: Iotdir last call review of draft-ietf-madinas-use-cases-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



@Behcet: Thanks for reviewing the draft. Comments inline:

Thanks,
Yiu


From: Behcet Sarikaya via Datatracker <noreply@xxxxxxxx>
Sent: Wednesday, November 27, 2024 7:25 PM
To: iot-directorate@xxxxxxxx <iot-directorate@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>; sarikaya@xxxxxxxx <sarikaya@xxxxxxxx>
Subject: Iotdir last call review of draft-ietf-madinas-use-cases-13
 
Reviewer: Behcet Sarikaya
Review result: Ready with Nits

I think this is a good document covering not only the use cases but also
context and network impacts of so-called RCM. I would ballot yes but there are
a lot of nits which need to be cleaned.

Sec. 1
Internet-of-thing -> Internet of Things
"monitor" the WLAN packers -> "monitor" the WLAN packets

[YL} Fixed

Sec. 2
shared service device which functions -> shared network device whose functions
BTW there are more of this type of nits, they were listed in the artart  review
by Marco Tiloca

[YL] Indeed. Changes are applied in v15.

Sec. 3
3.1 p.7
... connect to other mediums ...
like what?

[YL] I added DOCSIS as an example

3.2 p.8
physical device and it associated -> physical device and its associated

[YL] Fixed

Sec. 4 p.10 last sentence
That temporal identity may or not be the same for -> That temporal identity may
or may not be the same for

[YL] Fixed

Sec. 5

Sec. 6.1 p.13
ARP, inverse ARP [RFC826], Neighbor Solicitation and, -> ARP, Reverse ARP
[RFC826], Neighbor Solicitation and,

[YL] Fixed

It is mentioned that IoT-related functionalities (door unlock, preferred light
   and temperature configuration, etc.) the use of RCM blocks such services.
I leave it up to the authors to decide to get into this issue more deeply. IoT
devices use IEEE 802.15 (802.15.1 for BLE, 802.15.4 for Zigbee, etc.) It seems
like BLE 4.0+ devices do have RCM type of capability and it is used because
random MAC addresses do not require registration with IEEE. (BTW I suggest
mentioning this fact in the document.)

In BLE 4.0+ devices, some random addresses are resolvable by key sharing, they
are called resolvable random private addresses.

[YL] Use cases of Bluetooth and Zigbee are different from WiFi at least in two aspects. (1) It is used for machine-to-machine communication. User identity isn't present; (2) Once the device is paired, it usually maintains the pairing association with a specific hub. The device wouldn't roam from one hub to another hub. Given that this draft's main focus is about RCM impacting user privacy, imho this is not directly relevant to mention BLE and Zigbee in this draft.

Sec. 6.2 p.15 Table 1
I think Home Network is almost Full trust especially with the almost universal
use of 802.11i WPA2/WPA3

[YL] Agreed. I did mention that observers could still scan the encrypted packets. But Home Network is still considered "Full trust".

Appendix A

The text here (esp. A.1 and A.2) belong to the main text in some sections. They
could easily be incorporated there.

[YL] In WG discussion, we decided to separate out the working schemas and move them to appendix. The reason being this draft is a use case draft. It should not mention schemas or solutions in the main text.





-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux