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

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/



----------------------------------------------------------------------
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?


----------------------------------------------------------------------
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...