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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Sun, 06 Sep 2020 23:13:06 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-v6ops-nd-cache-init-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

— 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.”

   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?

— 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.

— Section 2.2 —

   neighboring nodes reachability

Nit: this needs to be possessive, “neighboring nodes’ reachability”.

   o  A node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NA
      packet with the Override flag cleared

Nit: “packets”, plural.

— 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.

— 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.

— 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?

---

From: Jen Linkova <[email-masked]>
Date: Mon, 7 Sep 2020 16:44:57 +1000

Hi Barry,

Thanks for reviewing the document so quickly!

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.

-05 has just been submitted to address your comments.

> configure its network stack.”

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

> as the “it” in the previous sentence.  I think you want “that” instead, no?

Fixed, thanks!

> “SLLA” is only used as the undefined “SLLAO”; I suggest defining “SLLAO”

Done.

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

Fixed.

>       packet with the Override flag cleared

Fixed.

> be excessive” feels like better wording here.

Fixed.

> What is “ex.”?  Is it meant to be “except”?  Please spell it out.

Done.

> 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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 7 Sep 2020 08:09:16 -0400

> Thanks for reviewing the document so quickly!

And thanks for the quick reply, Jen, and for addressing all my comments.

> they are more in scope of v6ops than 6man.

I understand the issue of which working group works on which parts,
but I do think that things can happen separately at earlier draft
levels, but the documents could be merged at a later point, before the
two working groups finish with them.  That v6ops is done with this
part already... makes it easy to transfer this finished piece to 6man
for inclusion in the other.  I'll discuss this with Warren and Erik,
and we'll collectively figure out what we think is best.  If we think
we should do a merge, we'll make a proposal to the two WGs.  (And to
be clear, I'm looking to make it easier for the reader to have the
relevant information in one place, without the reader's having to be
aware of the particular WG structure, charters, and scope.)

Barry

---

From: Jen Linkova <[email-masked]>
Date: Wed, 9 Sep 2020 16:56:43 +1000

Hi Barry,

On Mon, Sep 7, 2020 at 10:09 PM Barry Leiba <[email-masked]> wrote:
> for inclusion in the other.

6man is actually done as well, the draft is under AD review currently.

> I'll discuss this with Warren and Erik,
> we should do a merge, we'll make a proposal to the two WGs.

Sounds good. Merging two drafts should be easy.

> (And to be clear, I'm looking to make it easier for the reader to have the

yeah, that makes sense indeed.