|
Dear Ines, Thank you very much for your review and sorry for our delayed response. Please see my reponse inline. -----Original Message----- 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." ? => We will change the sentence to "
To avoid confusion with link-local addresses, link-layer addresses are referred to as MAC addresses in this document." 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..." => Thank you very much for your clarification. We will adopt your suggested text. Section 3.3: * Which are the privacy considerations? what about RFC 8981 to mitigate privacy risks? * What it is the meaning of "upstream multicast"? => Privacy considerations are discussed in “4.2.1. Applicability of L3 & L2 Isolation”. We also change “upstream multicast” to “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..."? => We adopt your suggested text.
Thank you very much. XiPeng & co-authors Thanks for this document, Ines. |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
