Re: [6lo] WG Last Call: draft-ietf-6lo-minimal-fragment-01

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Dominique:

Many thanks for your review! 
Please see below:

> Section 1, Overview:
> "Each fragment can be uniquely identified by the source and destination link-
> layer addresses of the frame that carries it, and the datagram_tag."
> It seems to me that "datagram_offset" should also be mentioned here as
> contributing to uniquely identifying a fragment.

Yes, this text was doubly wrong. 
In my mind it is enough that the destination is not part of uniqueness, the datagram_tag is unique to the source. But RFC 4944 has it differently, quoting section 5.3:
"
   The recipient of link fragments SHALL use (1) the sender's 802.15.4
   source address (or the Originator Address if a Mesh Addressing field
   is present), (2) the destination's 802.15.4 address (or the Final
   Destination address if a Mesh Addressing field is present), (3)
   datagram_size, and (4) datagram_tag to identify all the link
   fragments that belong to a given datagram.
"

Proposed change:

"
Each datagram can be uniquely identified by the source and final destination link-layer addresses of the frame that carries it, the fragment_size and the datagram_tag.
Each fragment can be identified within its datagram by the datagram-offset.
"

------------------
 
> Section 2.2
> "Assuming the topology from Figure 2, where nodes A, B, C and D all send
> packets through node E." Incorrect grammatical construct.
> 

What about
"
To illustrate this we use the topology from topology from Figure 2, where nodes A, B, C and D all send packets through node E.
"

-----------------

> 
> Section 3
> "Each VRB table entry can be 12 B (assuming 16-bit link-layer addresses)."
> It is not immediately obvious to me why 12. I guess I could try to figure it out.
> But [ARTICLE] says 20. Probably under a different assumption.
> Could you provide a detailed count, to spare the reader the exercise?
> BTW, in [ARTICLE], it seems to me that some means and remembering which
> fragment have already been forwarded are missing. The key sentence is "After
> having forwarded the last fragment, node B clears that VRB entry", but how
> does node B knows is has forwarded all fragments? The same comment applies
> to draft-ietf-lwig-6lowpan-virtual-reassembly-01. But I'm digressing here.

I'd like to remove that text altogether.
In some cases there's a need to keep some bytes form the previous fragment because the expansion and recompression of the 6LoWPAN header lead to lower compression. I'd rather indicate the abstract data that can be found in the VRB.

What about:

"The abstract data in the VRB contains at a minimum the MAC address of the predecessor and that of the successor, and the datagram_tag used by the predecessor and the datagram_tag that this node will swap with it. The VRB may need to store a few octets from the last fragment that may not have fit within MTU and that will be prepended to the next fragment.
"

------------------------
 
> Section 7, references
> Ref [ARTICLE] is dated 2009, I guess you mean 2019. Besides, I could only find
> the HAL archive, I suppose this is accepted for publication, but not published
> yet.
> Oops, just saw that Georgios already uncovered this nit.
> 
> 
> 


fixed : )

Many thanks!

Pascal