Re: [6lo] Shepherd review of draft-ietf-6lo-minimal-fragment-02

["Pascal Thubert (pthubert)" <[e-mail]>]

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