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

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.