Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-v6ops-nd-considerations-06 Reviewer: Ines Robles Review Date: 2024-10-18 IETF LC End Date: 2024-10-18 IESG Telechat date: Not scheduled for a telechat Summary: Summary: The Draft provides a comprehensive review of the challenges associated with IPv6 Neighbor Discovery (ND) and summarizes existing mitigation solutions documented across more than 20 RFCs. Please find below my comments/suggestions below: Major Issues: None Minor Issues/Nits: Section 1.1 "..link-layer addresses are referred to as MAC addresses in this document" --> "In this document, link-layer addresses specifically refer to Media Access Control (MAC) addresses." ? Section 2.1 "..by listening to only one out of multiple Delivery Traffic Indication Message (DTIM) beacons..." — The statement implies that devices may be missing DTIM beacons themselves, which is unclear. I understand that devices rely on DTIM beacons to know when multicast or broadcast traffic is available. Devices wake up for every DTIM beacon, but DTIM beacons occur less frequently than regular beacon frames due to the DTIM period setting. Devices do not selectively ignore DTIM beacons; rather, they may ignore regular beacon frames and only wake up for DTIM beacons. For instance, if the DTIM period is set to a high value (e.g., 10), devices will only wake up every 10 beacon intervals. This can introduce delays in receiving multicast traffic, but devices are not missing DTIM beacons unless they are asleep for extended periods. Therefore, because devices wake up less frequently for DTIM beacons, latency can occur in receiving multicast traffic. Additionally, multicast frames are transmitted at lower data rates and are not retransmitted upon loss, which can lead to packet loss. Thus, for improved clarification, a suggestion as follows: "..In Wi-Fi networks, mobile devices often employ power-saving modes, where they may sleep through multiple beacon intervals and wake up only for Delivery Traffic Indication Message (DTIM) beacons [RFC9119]. Since DTIM beacons occur less frequently, this can introduce delays in receiving multicast traffic. Moreover, multicast frames are transmitted at lower data rates without retransmissions, leading to potential packet loss. As a result, multicast traffic over Wi-Fi can suffer from reduced performance and reliability..." Section 3.3: * Which are the privacy considerations? what about RFC 8981 to mitigate privacy risks? * What it is the meaning of "upstream multicast"? Section 3.11: "...Rate-limiting the NDP queue to avoid CPU/memory overflow..." --> "...Implement rate-limiting mechanisms for NDP (Neighbor Discovery Protocol) message processing to prevent CPU and memory resources from being overwhelmed..."? Thanks for this document, Ines. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
