Last Call Review of draft-ietf-madinas-use-cases-13
review-ietf-madinas-use-cases-13-iotdir-lc-sarikaya-2024-11-27-00
Request | Review of | draft-ietf-madinas-use-cases |
---|---|---|
Requested revision | No specific revision (document currently at 19) | |
Type | IETF Last Call Review | |
Team | Internet of Things Directorate (iotdir) | |
Deadline | 2024-11-28 | |
Requested | 2024-11-15 | |
Requested by | Éric Vyncke | |
Authors | Jerome Henry , Yiu Lee | |
I-D last updated | 2025-04-30 (Latest revision 2024-12-20) | |
Completed reviews |
Intdir IETF Last Call review of -15
by Dave Thaler
(diff)
Iotdir IETF Last Call review of -13 by Behcet Sarikaya (diff) Secdir IETF Last Call review of -12 by Brian Weis (diff) Artart IETF Last Call review of -13 by Marco Tiloca (diff) Tsvart IETF Last Call review of -12 by Tommy Pauly (diff) Genart IETF Last Call review of -13 by Thomas Fossati (diff) |
|
Comments |
This I-D is simple to read but it is quite broad as it touches many areas... Meeting the deadline is important but, as the responsible AD for this I-D, I will gladly consider directorate reviews done before the IESG evaluation telechat date (probably in December). Thank you |
|
Assignment | Reviewer | Behcet Sarikaya |
State | Completed | |
Request | IETF Last Call review on draft-ietf-madinas-use-cases by Internet of Things Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/iot-directorate/bQE6iUw59MVHRaq7jZ85jKOofHQ | |
Reviewed revision | 13 (document currently at 19) | |
Result | Ready w/nits | |
Completed | 2024-11-27 |
review-ietf-madinas-use-cases-13-iotdir-lc-sarikaya-2024-11-27-00
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 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 Sec. 3 3.1 p.7 ... connect to other mediums ... like what? 3.2 p.8 physical device and it associated -> physical device and its associated 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 Sec. 5 Sec. 6.1 p.13 ARP, inverse ARP [RFC826], Neighbor Solicitation and, -> ARP, Reverse ARP [RFC826], Neighbor Solicitation and, 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. 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 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.