Re: [Iot-directorate] Iotdir last call review of draft-ietf-6man-grand-04

[Carles Gomez Montenegro <[e-mail]>]

Hi Jen,

Many thanks for addressing my comments.

Cheers,

Carles


> 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).
>
> On Fri, Jun 18, 2021 at 8:19 PM Carles Gomez via Datatracker
> <[e-mail]> wrote:
>> 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.
>
> 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.
>
>> 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.
>
> Done.
>
>> - 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
>
> Fixed.
>
>> - 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.
>
> 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.1, title: s/Other That/Other Than
>>
>> - Section 5.3.2, bullet 6: s/and wait up/and waits up
>
> Fixed, thanks.
>
>> - 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).
>
> 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
>> Section 7?
>
> Oh that was a copy-n-paste artefact, removed.
>
>> - Section 10: s/layer2/layer-2
>
> Fixed.
>
> --
> SY, Jen Linkova aka Furry
>
> --
> Iot-directorate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-directorate
>