Hi Stewart, Thanks a lot for your comments, I've just submitted -05. On Fri, Sep 4, 2020 at 3:47 AM Stewart Bryant via Datatracker <noreply@xxxxxxxx> wrote: > Summary: The purpose of the GENART review is to provide a fresh pair of eyes > not familiar with the work. I am sure that those that deal with the detail of > IPv6 day to day will completely understand this on the first pass, but for > those not familiar some attention to the abbreviations is needed. Also the > Abstract and Intro do not seem to this first time reader to align with the > purpose of the text. I've updated the Abstract: OLD TEXT: --- This document discusses how the neighbor discovery state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used. ---- NEW TEXT: --- This document discusses how the neighbor discovery state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used. The various approaches to mitigate the problem are described, with the proposed solution fully documented in I-D.ietf-6man-grand. --- and the Introduction: OLD TEXT ---- This document discusses the operational implications of not proactively creating Neighbor Cache entries on first-hop routers and summarizes various approaches to mitigate the problem. --- NEW TEXT- --- This document discusses the operational implications of not proactively creating Neighbor Cache entries on first-hop routers and summarizes various approaches to mitigate the problem. The document provides an overview of the proposed solution which is fully described in <xref target="I-D.ietf-6man-grand" />. ---- > Major issues: > As far as I can see there is a preferred solution documented in > I-D.ietf-6man-grand, and this text documents the problem and the rejected > alternatives, but that does not come through in reading the abstract or > introduction. See above - please let me know if the updated text does not make it clearer. Actually this document also talks about the preferred solution, giving the justification why it's preferred but not going into details of the solution. > SB> There is a problem I that the introduction uses a number of terms which are > not well known to the wider IETF community, and which are not defined until > later in the text : SLAAC, GUA, DAD. There is a Terminology section which contains all terms/acronyms used in the document. I'm not sure it would make sense to move it before the introduction section. I've updated the Introduction text so acronyms are either removed or explained. SB> The term LLA is not defined here or by > the RFC editor. SB> SLLAO? Needs expanding Fixed, thanks for pointing this out. > ===== > o Some wireless devices are known to fiddle with > SB> an unusual technical term Oh that's weird, I was sure that was fixed in the previous revision of the document, but looks like it was not ;( > ===== > o Data packets to the router LLA > SB> LLA? Not in the editors list and not defined as far as I can see, Fixed. -- SY, Jen Linkova aka Furry -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
