Subject: [6lo] Roman Danyliw's No Objection on draft-ietf-6lo-fragment-recovery-12: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 18 Feb 2020 05:08:19 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this easy to read document.

** Section 5.1.  Per “There is no requirement on the receiver to check for
contiguity of the received fragments, and the sender MUST ensure that when all
fragments are acknowledged, then the datagram is fully received.”, the second
clause doesn’t parse for me.  What must the sender ensure when all of the
fragments are acknowledged?

** Section 5.1.  Fragment_Size.  If this is a 10-bit unsigned integer and the
unit is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)?

** Editorial

-- Section 5.2.  Editorial.
s/A NULL bitmap that indicates that the …/
A NULL bitmap indicates that the …/
s/A FULL bitmap that indicates that the …/
A FULL bitmap indicates that the …/

-- Section 6.1.  Recommend replacing colloquial language – “It inherits … using
a timer to clean the VRB when the traffic _dries up_”

-- Section 10.  Typo. s/ot this/to this/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Feb 2020 15:41:28 +0000

Many thanks for your review, Roman!

Let's see below 
> contiguity of the received fragments, and the sender MUST ensure that when
> all fragments are acknowledged, then the datagram is fully received.”, the
> second clause doesn’t parse for me.  What must the sender ensure when all of
> the fragments are acknowledged?

Yes, awkward.  What about simply:
"
    There is no requirement on the receiver to check for contiguity of the
    received fragments. The sender knows that the datagram is fully received 
    when the acknowledged fragments cover the whole datagram.
"

> 
> ** Section 5.1.  Fragment_Size.  If this is a 10-bit unsigned integer and the unit
> is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)?

Oups fixed

> s/A NULL bitmap that indicates that the …/ A NULL bitmap indicates that the
> …/ s/A FULL bitmap that indicates that the …/ A FULL bitmap indicates that the
> …/
Done

> a timer to clean the VRB when the traffic _dries up_”
Does "clean the VRB once the traffic ceases" work?

> -- Section 10.  Typo. s/ot this/to this/
Done : )

Many thanks again Roman!

I posted v13 with the proposed diffs from your review and that of Peter: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-13 

Pascal