Hello Peter: Many thanks for your review! I published 09 so the next reviewers will not have to suffer from my nits, and we can progress from there if my proposals are not satisfactory. The delta is available here, please see below for more: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-09 Looking at it I found that the addition of address after MAC had a side effect, I'll fix it next. > Page 9, 1st paragraph after Figure 1, 1st sentence: how does the sender > ensure the full reception of the datagram? It can assume that to be the case, > but there's no further mechanisms available to it to "ensure" anything > beyond that. I added text per Erik's review on this in 6.1.2: " [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint stores "the actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded". How this is computed in implementation specific but relies on receiving all the bytes up to the datagram_size indicated in the first fragment. An implementation may receive overlapping fragments as the result of retries after an MTU change. " Is this OK? > Page 13, 4th full paragraph, 1st sentence: the receiver is instructed send an > RFRAG Acknowledgment without regard to whether the sender wishes to > protect the datagram, in contradiction to the 2nd sentence in the 4th > preceding paragraph (which starts on the bottom of page 12). Try to > rationalize the two paragraphs. Also, what constitutes a "short" timer? How > is an implementer to decide what's reasonable? This really depends on the MAC layer and depth of the mesh. Reasonable is an end-to-end turn around trip delay. What about adding ' e.g., in the order of an average turn around trip delay in the network' ? The result would read as follows: " When all the fragments are received, the receiving endpoint reconstructs the packet, passes it to the upper layer, sends a RFRAG Acknowledgment on the reverse path with a FULL bitmap, and arms a short timer, e.g., in the order of an average round-trip delay in the network, to absorb fragments that are still in flight for that datagram without creating a new state and abort the communication if it keeps going on beyond a reasonable time. " > > Page 14, 2nd full paragraph, 1st sentence: how is a "reasonable" amount of > time calculated? This is indicated in the sentence, time for a packet to progress a few hops. I can change "reasonable" to something clearer. does this look better? " When a single frequency is used by contiguous hops, the sender should insert a delay between fragments of a same datagram that covers multiple transmissions so as to let a fragment progress a few hops and avoid hidden terminal issues. " > > Nits/editorial comments: > Sorry for the French! I went through mostly all, just could not find the following: > Page 8, section 5, 2nd paragraph, last sentence: change "It" to "the" and > insert an "i" before "s". > Page 12, RFRAG Acknowledgment Bitmap, 3rd sentence: delete the first > instance of "that". Change the comma to a semicolon. But I guess we'll find them in the next round. Also, anout: > Page 26, Appendix C, 4th paragraph, last partial sentence: change > "TimeSlotted" > to "Time-Slotted". Well, that's how 6TiSCH spells it, so I'd rather leave it as is. Whao many thanks again, Peter, for your careful review! -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
