Hi Pascal,
wow, this is a super-fast fix. Looks all good to me.
Best,
Jörg
On 30.01.20 12:01, Pascal Thubert (pthubert) wrote:
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
