Reviewer: Erik Nordmark Review result: Almost Ready 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
