Subject: [Last-Call] Iotdir last call review of draft-ietf-6man-grand-04

From: Carles Gomez via Datatracker <[email-masked]>
Date: Fri, 18 Jun 2021 03:18:43 -0700

Reviewer: Carles Gomez
Review result: Ready with Nits

In my opinion, the document is well written. I found no major issues.

I have reviewed the document from the perspective of constrained nodes or
constrained-node networks.

I understand that the document is intended for devices that do not use RFC
6775/8505. Section 8.2 explicitly discusses why the registration-based approach
in 6775/8505 is not followed in draft-ietf-6man-grand. However, 6775/8505
shares the proactive spirit of the mechanisms defined in draft-ietf-6man-grand.
Regarding  registration-based ND, the document states that "This option
requires some investigation and discussion.". While it makes sense to defer
such discussion beyond the timeline for this document, it would appear that
6775/8505 would allow to achieve goals similar to those allowed by
draft-ietf-6man-grand, while offering additional benefits for constrained-node
networks. Indeed, this area offers opportunities for promising future
discussion/work.

I am not sure about the "implementation complexity" attributed to RFC 6775/8505
in section 8.2, in the sense that such documents have been precisely created
for devices that are typically characterized by significant resource
constraints. Perhaps some clarification or rephrasing might help.

Please find below a number of nits/comments:

- Section 2, bullet 3: "... by creating an INCOMPLETE cache entry...". Perhaps
adding a reference for 'INCOMPLETE cache entry' at the end of the sentence
would be helpful.

- Section 2, bullet 4: s/it would consider/in the worst case, it would consider

- Section 4.1, first sentence: s/Neighbor Advertisement/Neighbor Advertisements

- There are several instances of e.g. "NA" and "Neighbor Advertisement"
throughout the document. It might be good to define the acronym on its first
use and use the acronym thereafter.

- Section 5.1, title: s/Other That/Other Than

- Section 5.3.2, bullet 6: s/and wait up/and waits up

- Section 5.3.2: "within tens of milliseconds". Perhaps this time could be
slightly greater in some cases (e.g. with RTTs in the order of ~100 ms).

- Section 6: shouldn't the last dotted line need to be placed right before
Section 7?

- Section 10: s/layer2/layer-2

---

From: Jen Linkova <[email-masked]>
Date: Mon, 21 Jun 2021 19:39:36 +1000

Hi Carles,

Thanks a lot for the detailed review!
Comments below (when I say 'fixed' it means 'added to -05 which will
be submitted today).

> constraints. Perhaps some clarification or rephrasing might help.

What I meant by 'implementation complexity' was the scope of changes required.
I rephrased it slightly:
OLD TEXT:
However the implementation complexity and unclear adoption timeline
makes this approach less preferable than one proposed in this
document.
NEW TEXT:

However significant changes to the existing IPv6 implementations would
be needed, so unclear adoption timeline makes this approach less
preferable than one proposed in this document.

> adding a reference for 'INCOMPLETE cache entry' at the end of the sentence

Done.

> - Section 4.1, first sentence: s/Neighbor Advertisement/Neighbor Advertisements

Fixed.

> use and use the acronym thereafter.

The Introduction does not use any acronym and the next section is the
Terminology, where all acronyms are explained.
I'm just not sure it's worth defining the acronyms twice (in that
section and on first use).

> - Section 5.3.2, bullet 6: s/and wait up/and waits up

Fixed, thanks.

> slightly greater in some cases (e.g. with RTTs in the order of ~100 ms).

I've changed the text so it says 'within tens of milliseconds in most cases'.

> - Section 6: shouldn't the last dotted line need to be placed right before

Oh that was a copy-n-paste artefact, removed.

> - Section 10: s/layer2/layer-2

Fixed.

-- 
SY, Jen Linkova aka Furry

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 28 Jun 2021 10:36:33 +0200

Hi Jen,

Many thanks for addressing my comments.

Cheers,

Carles

> Iot-directorate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-directorate
>