Hello Pascal, Carsten, Yes, I am OK with your proposed updates, including that the title becomes "6LoWPAN Fragment Forwarding".
Thanks for addressing my comments! Cheers, Carles > Hello Carles > > Manu thanks for you review! > > Please see below > >> >> - "LLN" is used in the title and in the abstract, but the actual body of >> the >> document uses the term "6LoWPAN" (or "6Lo"), which in fact is more >> specific. >> Should "LLN" be replaced with "6LoWPAN" (or "6Lo")? (I tend to think >> so...) >> > > Yes, in the title that makes sense. > Actually we use the term Low Power Lossy Network beyond 6lo, e.g., in > ROLL. > I'd rather keep the term but certainly expand it on first use. > >> - The document uses the term "minimal" also in the title and in the >> abstract, >> but the document does not explicitly define how the concept of "minimal" >> needs to be understood. Furthermore, "minimal" is not present in the >> body of >> the document. Perhaps some clarification on the concept of "minimal" >> (e.g. in >> the Introduction) might help the reader. > > Right. > It is minimal vs. the flow control and recovery of the other draft. This > is why we split. > But I agree with you that the term minimal is not needed at all. Could we > just remove it? > Based on your 2 suggestions combined, the title becomes "6LoWPAN Fragment > Forwarding" > >> >> - The idnits tool reports a few issues that should be taken care of (at >> least, the >> first and the last ones). Please find them below for your >> convenience: >> >> ** The abstract seems to contain references >> ([I-D.ietf-lwig-6lowpan-virtual-reassembly]), which it shouldn't. >> Please replace those with straight textual mentions of the >> documents in >> question. > > Ack: The resulting abstract would be: > > This document provides a simple method to forwarding 6LoWPAN fragments. > When employing adaptation layer fragmentation in 6LoWPAN, it may be > beneficial > for a forwarder not to have to reassemble each packet in its entirety > before forwarding it. > This has always been possible with the original fragmentation design of > RFC4944. > This method reduces the latency and increases end-to-end reliability in > route-over forwarding. > It is the companion to the virtual Reassembly Buffer which is a pure > implementation technique. > > >> -- The document date (June 24, 2019) is 24 days in the past. Is this >> intentional? > > I'll post a 03 > >> -- Found something which looks like a code comment -- if you have code >> sections in the document, please surround them with '<CODE BEGINS>' >> and >> '<CODE ENDS>' lines. > > NO such thing. > >> == Unused Reference: 'BOOK' is defined on line 266, but no explicit >> reference was found in the text > > Removed the ref > >> Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments >> (--). >> >> I have no further comments. >> > > Great! > > Please confirm that you're OK with the changes above and Ill post > > Many thanks again > > Pascal > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
