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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
