Roman Danyliw has entered the following ballot position for draft-ietf-6lo-fragment-recovery-12: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this easy to read document. ** Section 5.1. Per “There is no requirement on the receiver to check for contiguity of the received fragments, and the sender MUST ensure that when all fragments are acknowledged, then the datagram is fully received.”, the second clause doesn’t parse for me. What must the sender ensure when all of the fragments are acknowledged? ** Section 5.1. Fragment_Size. If this is a 10-bit unsigned integer and the unit is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)? ** Editorial -- Section 5.2. Editorial. s/A NULL bitmap that indicates that the …/ A NULL bitmap indicates that the …/ s/A FULL bitmap that indicates that the …/ A FULL bitmap indicates that the …/ -- Section 6.1. Recommend replacing colloquial language – “It inherits … using a timer to clean the VRB when the traffic _dries up_” -- Section 10. Typo. s/ot this/to this/ _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
