Last Call Review of draft-ietf-6lo-fragment-recovery-07
review-ietf-6lo-fragment-recovery-07-iotdir-lc-nordmark-2019-11-27-00

Request Review of draft-ietf-6lo-fragment-recovery
Requested rev. no specific revision (document currently at 21)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2019-11-29
Requested 2019-11-04
Requested by Suresh Krishnan
Authors Pascal Thubert
Draft last updated 2019-11-27
Completed reviews Iotdir Last Call review of -07 by Erik Nordmark (diff)
Genart Last Call review of -08 by Peter Yee (diff)
Secdir Last Call review of -08 by Tirumaleswar Reddy.K (diff)
Tsvart Last Call review of -11 by Colin Perkins (diff)
Genart Telechat review of -12 by Peter Yee (diff)
Assignment Reviewer Erik Nordmark 
State Completed
Review review-ietf-6lo-fragment-recovery-07-iotdir-lc-nordmark-2019-11-27
Posted at https://mailarchive.ietf.org/arch/msg/Iot-dir/GO1642x4azuE8K0xXwdAMYah9L4
Reviewed rev. 07 (document currently at 21)
Review result Almost Ready
Review completed: 2019-11-27

Review
review-ietf-6lo-fragment-recovery-07-iotdir-lc-nordmark-2019-11-27

Review of draft-ietf-6lo-fragment-recovery-07

Section 4.3 seems to silently assume that all fragments of a datagram go through the same intermediate hops. This should at a minimum be made explicit. But does the intended deployments satisfy such an assumption?

Drawing in section 5.1 shows an 8 byte datagram_tag but the text says it is 16 bits. That's inconsitent.

I'd like to understand the issues and protection against reuse of the datagram_tag. Since this is rewritten on each hop and the hops can be routers forwarding at high rate, even 16 bits can cycle very quickly.

The document should presumably specify how the receiver knows it has received all the fragments in 6.0; as I understand the sequence number can not be used for this but instead the receiver needs to check that it has received every byte offset from zero to datagram_size at least once. (The refragmenting due to MTU changes makes this complex.)
Question: If the receiver has already received from byte range once and receives a subset of that range again (due to a retransmission after MTU change) is the receiver supposed to do something to compare the content being the same for the repeated byte range?

Note that for IP fragmentation we have determined that overlapping fragments can be used to fool firewalls. I don't know to what extent that is an issue for this fragmentation. Perhaps that should be mentioned in the security considerations section?

Section 6.1.1 seems to make the assumption that a packet with sequence zero is only transmitted once, hence I don't understand how this will work when it is lost and then retransmitted by the sender.

Nits:
Section 2.3 defines 5 terms but all of "LLN" are unused. I suggest the unused terms be removed to avoid any confusion.
Yet other terms like "LSP" are not defined.