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

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
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>