Re: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)

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

Hello Eric:

Many thanks for your review and time : )

You and Ben has similar concerns and I published 13 to try to address both. 
I compiled the proposed changes in an early publication https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-13  


Let's see below for the details:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 



> As I reviewed draft-ietf-6lo-fragment-recovery before this document, I put
> some COMMENTs in my review of draft-ietf-6lo-fragment-recovery that also
> apply to this document.
> 

Yes, the first comment applies here too:

> -- Section 4.2 and Section 7.1 --
> Should default values for the inter-frame gap be given ?

This is related to a point in Ben's review. It's really dependent on the MAC technology, PHY speed, number of retries (channel occupancy) , and application. 

Quoting myself (he he)

We never know when the next hop will send, it may be busy with a queue of other packets. So there's always a risk unless you schedule like you could with 6TiSCH. Also a TSCH technology will protect against the hidden terminal but a single channel mesh must let the fragment go farther away. So it's like the proverbial time it takes for the canon to cool down.:"Enough time".

So I cannot be more precise that: for TSCH, allow the next hop to forward; for single channel mesh, several times that because the frame must progress out of interference range.

"Enough time" can be expressed as what's needed for a packet to  " progress beyond the next hop and beyond the interference domain before the next shows up.  "
 Is that OK?



> == COMMENTS ==
> 
> Is there a reason why this document uses "Link-Layer address" while the
> companion, draft-ietf-6lo-fragment-recovery, uses "MAC address" ? This is
> cosmetic of course but if the concept is the same, using the same wording
> could only improve the readability of the documents. Same applies for
> "datagram_tag"
> vs "Datagram_Tag" ;-)

Let's go for Datagram_Tag and Link-Layer address in both docs?


> 
> -- Section 5 --
> "Multiple fragments may progress in parallel" is not really correct as the rather
> travel "simultaneously" as they follow the same path but at different steps (i.e.
> not like using parallel links).

True, made the change


> 
> -- Section 6 --
> The "no per-fragment routing" can also be seen as an advantage as it forces all
> fragments to be in order.

See my reply to you and Ben, the order is not really important in general though it plays a role in the recovery because the retries are in order.

> 
> == NITS ==
> 
> Is the case in "Link-Layer" correct? I am a non native speaker but I would have
> used "link-layer".

I have no idea : ) I'm used to uppercasing because of the SLLAO so I do it all the time.
I do not mind at all changing all. Maybe the RFC editor knows better?*Gain, many thanks Eric!

Pascal