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