Many thanks Joerg! Please see below: > Generally, the document is in good state and almost ready to publish. A few > nits, one on protocol state management below: > > Nits: > > The text uses both "6lo fragments" and "6LoWPAN fragments". Changed to 6LoWPAN fragments everywhere > > Section 5, end of 1st para: > "Since the datagram_tag is uniquely associated to the source Link-Layer > address of the fragment, the forwarding node MUST assign a new > datagram_tag from its own namespace for the next hop and rewrite the > fragment header of each fragment with that datagram_tag." > > This sentence is correct but it comes after the description of handling > subsequent fragments, rather than the first one, and subsequent ones should, > of course, not receive a new datagram_tag. Maybe move the sentence further > up or make explicit reference to the first fragment. Great point, moved up. > > Sect. 5, bullet list, "* a datagram_size" > Just as a remark, this does not seem to be used. It *could* be used to check if > a fragment beyond the end of the packet arrives, but has otherwise no > (documented) meaning. The draft should spell out its purpose. Since we did not use it the simplest is to remove it 😊 > > Sect. 5, bullet list, "a timer that allows discarding the stale FF state after some > timeout" > Surely needed, but no advice is given. There is generally no explicit statement > when to discard the state. What should an implementation do to interoperate, > given that upstream multiplexing of packet fragments from multiple sources > can yield diverse intervals between consecutive fragments? Would this be the > same timer previously used for reassembly? If so, maybe just state this. Great point again! Does the below work, added to the bullet? " The duration of the timer should be longer than that which covers the reassembly at the receiving end point. " > > Sect. 7, 2nd bullet: "attck" -> "attack" > Fixed! Many thanks again, Joerg. I posted 09 with the above. Please let me know if we are OK? All the best Pascal -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
