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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you Pascal for addressing my COMMENTs

__

-éric

-----Original Message-----
From: Pascal Thubert <[e-mail]>
Date: Thursday, 5 March 2020 at 17:02
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)

    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