Re: [v6ops] Barry Leiba's Discuss on draft-ietf-v6ops-nd-cache-init-04: (with DISCUSS and COMMENT)

[Jen Linkova <[e-mail]>]

Hi Barry,

Thanks for reviewing the document so quickly!

On Mon, Sep 7, 2020 at 4:13 PM Barry Leiba via Datatracker
<[e-mail]> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is a very clear document, and this DISCUSS is literally that: a discussion
> I’d like to have before the IESG approves it.  My first thought was that this
> document reads more like a Standards Track Applicability Statement than an
> Informational document... but then there’s the 6man-grand “companion” that’s
> Standards Track.  And what I don’t understand is what the relationship is
> between this document and that one.  Why does this document exist?  Why isn’t
> it all in 6man-grand, and what’s the reason to be publishing two separate RFCs
> for this issue?  Neither the document nor the shepherd writeup explain that.

Oh..That's been discussed a number of times at v6ops@ and 6man@ meetings.
V6Ops WG consensus is that the problem statement shall belong to v6ops
document, hence we have two separate drafts.
(Actually I've just asked Warren to delay the telechat on this one, so
both drafts can be reviewed by IESG together).

Merging both of them into one 6man doc would simplify things, I agree.
On the other hand the value of the -nd-cache-init as a separate one is
that it discusses various approaches to solve the issue,
and some of those approaches do not require any protocol changes, so
they are more in scope of v6ops than 6man.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

-05 has just been submitted to address your comments.

> — Section 1 —
> Several abbreviations are used here, two sections before they are defined in
> Section 1.2.  Not knowing that they’d soon be defined, I wondered why they
> weren’t expanded and given citations.  I suggest expanding each abbreviation
> the first time it’s used in the Introduction, so the reader doesn’t have to
> know ahead of time to look down in 1.2 for the expansion.  This applies to ND,
> NS, GUA, DAD, and LLA (you can just add “LLA” to the expansion that’s already
> at the end of list item 1).
>
> “SLAAC” is only used once in the document.  I suggest removing the definition
> in 1.2, and just changing the text here to say, “The RA contains information
> the host needs to perform Stateless Address Autoconfiguration [RFC4862] and to
> configure its network stack.”

I've just done exactly that to address GENART review comments ;)

>    4.  If the host sends multiple probes in parallel, it would consider
>        all but one of them failed.  It leads to user-visible delay in
>        connecting to the network
> Nit: The “it” in the second sentence sounds odd; one wants to make it the same
> as the “it” in the previous sentence.  I think you want “that” instead, no?

Fixed, thanks!

> — Section 1.2 —
> “TLLA” is defined here but never otherwise used; I suggest removing it.
> “SLLA” is only used as the undefined “SLLAO”; I suggest defining “SLLAO”
> instead.

Done.

> — Section 2.2 —
>
>    neighboring nodes reachability
>
> Nit: this needs to be possessive, “neighboring nodes’ reachability”.

Fixed.

>    o  A node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NA
>       packet with the Override flag cleared
>
> Nit: “packets”, plural.

Fixed.

> — Section 3.2 —
>
>    requires some investigation and discussions and seems to be an
>    overkill for the problem described in this document.
>
> Nit: we don’t usually use an article with “overkill”.  In any case, “seems to
> be excessive” feels like better wording here.

Fixed.

> — Section 3.3 —
>
>       so all backup routers (or all active
>       routers ex. one) would not get their neighbor cache updated.
>
> What is “ex.”?  Is it meant to be “except”?  Please spell it out.

Done.


> — Section 3.6 —
>
>    o  Additional overhead for routers control plane (in addition to
>       processing ND packets, the data packet needs to be processed as
>       well).
>
> This doesn’t appear to be a properly formed sentence; can you reword it to make
> it a complete sentence and to fix the “routers control plane” phrase?

Ah, it was because of 'The downside of this approach includes:' a few
lines above.
Changed to:
"
This approach has the following drawbacks:
   - It introduces an additional overhead for routers control plane
(in addition to processing ND packets, the data packet needs to be
processed as well).
"


--
SY, Jen Linkova aka Furry