Thank you XiPeng for addressing my comments. Best Regards,
Ines. On Tue, Nov 19, 2024 at 7:49 PM Xipengxiao <xipengx...@huawei.com> wrote: > Dear Ines, > > > > Thank you very much for your review and sorry for our delayed response. > Please see my reponse inline. > > > > -----Original Message----- > From: Ines Robles via Datatracker <nore...@ietf.org> > Sent: Saturday, October 19, 2024 12:48 AM > To: gen-art@ietf.org > Cc: draft-ietf-v6ops-nd-considerations....@ietf.org; last-c...@ietf.org; > v6...@ietf.org > Subject: Genart last call review of draft-ietf-v6ops-nd-considerations-06 > > > > 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. > > > > >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
