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 <noreply@xxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
