Re: [v6ops] Genart last call review of draft-ietf-v6ops-nd-cache-init-04

[Jen Linkova <[e-mail]>]

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
<[e-mail]> 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