Re: [6lo] Warren Kumari's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

Awesome. thank you, I have cleared my discuss position,
W

On Fri, Mar 6, 2020 at 1:57 PM Pascal Thubert (pthubert)
<[e-mail]> wrote:
>
> Hello Warren
>
> Many thanks for your review!
>
> Please find the proposed changes discussed below in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14
>
> Let's see below:
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > [ Be ye not afraid - this should be easy to address.]
> > "datagram_size: The size of the datagram in its Compressed Form before it is
> > fragmented. The datagram_size is expressed in a unit that depends on the
> > MAC layer technology, by default a byte." and: "Fragment_Size:  10-bit
> > unsigned integer; the size of this fragment in a unit that depends on the MAC
> > layer technology.  Unless overridden by a more specific specification, that
> > unit is the octet, which allows fragments up to 1024 bytes."
> >
> > I spent quite a while going though the document, looking at the 13 places
> > where you use 'byte' and 3 where you use 'octet', trying to figure out if there
> > is a reason that different terms are used. Normally I'd just say "meh, these
> > are synonyms" and ignore it, but in this particular specification (because of
> > the "by default" / "Unless overridden") I think it is actually important.... Can
> > you standardize on one of the other, or provide more explanatory text if
> > there is a reason?
>
> Standardized to Byte, per Carsten's recommendation. As a Frenchman I preferred octet : )
> Note that the definition is now removed from this document and inherited from I-D.ietf-6lo-minimal-fragment per Benjamin's review.
>
> The end of appendix A becomes:
> "
>
>    Mechanisms such as TCP or application-layer segmentation could be
>    used to support end-to-end reliable transport.  One option to support
>    bulk data transfer over a frame-size-constrained LLN is to set the
>    Maximum Segment Size to fit within the link maximum frame size.
>    Doing so, however, can add significant header overhead to each
>    802.15.4 frame and cause extraneous acknowledgements across the LLN.
> "
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you for a useful and interesting read -- I really enjoyed this document.
> >
> > I do also support Benjamins "I think we should be more clear about whether
> > a "FULL bitmap" always has 32 bits set to one, or if "merely" having as many
> > bits as the sender sent fragments set to one also counts as "FULL". "
> > comment, and had something very similar drafted...
> >
>
> Yes, I addressed this in Benjamin's review. But I did not really find the place that triggered the doubt.
> There is new text now, I hope that fixes it. There is also a definition of FULL and NULL bitmaps:
>
> "
>    NULL bitmap:  Refers to a bitmap with all bits set to zero.
>
>    FULL bitmap:  Refers to a bitmap with all bits set to one.
>
> "
> I hope it is clear enough, but happy to reword if needed.
>
> Many thanks again for your review : )
>
> Pascal



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf