[6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-13: 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:
----------------------------------------------------------------------

Pascal, thank you for the work put into this document.  The idea is simple and
smart, I like the fact that all fragments follow the same path, so they should
be delivered in the right order.

Nevertheless, please find below some non-blocking COMMENTs (and I would
appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header
Chains" is applicable ?

-- Section 4.2 and Section 7.1 --
Should default values for the inter-frame gap be given ?

-- Section 5.1 --
With 8 bits in the Datagram_Tag, this means that a node can only
transmit/forward 256 packets over a link. While this seems suffisant, did the
author make some investigation on this limit? The text should also state what
to do when the 8 bits are not enough.

-- Section 5.2 --
I suggest to mention that the use of the Datagram_Tag field will be described
in section 6.

-- Section 6 --
I find it weird to read in the same paragraph "The RFRAG Acknowledgment can
optionally carry an ECN" and later "MUST echo that information by setting the
'E'". I am not a native English speaker but may I suggest to replace the first
part with "The RFRAG Acknowledgment has a ECN"

-- Section 6.1.2 --
"An implementation may receive overlapping fragments as the result of retries
after an MTU change." Is this a security risk (RFC 8200 forbids overlapping
fragments but this is a different layers) ? I also suggest to make it a
normative "MAY" or "MUST accept".

-- Section 7.2 --
Should the network observation installs global states or per destination states
? E.g., typical IP implementations maintain a per destination Path MTU cache.

== NITS ==

-- Section 7 --
Is it "Kbps" or "kbps" ?