Éric Vyncke has entered the following ballot position for draft-ietf-6lo-fragment-recovery-13: 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: ---------------------------------------------------------------------- Pascal, thank you for the work put into this document. The idea is simple and smart, I like the fact that all fragments follow the same path, so they should be delivered in the right order. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. I hope that this helps to improve the document, Regards, -éric == COMMENTS == A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header Chains" is applicable ? -- Section 4.2 and Section 7.1 -- Should default values for the inter-frame gap be given ? -- Section 5.1 -- With 8 bits in the Datagram_Tag, this means that a node can only transmit/forward 256 packets over a link. While this seems suffisant, did the author make some investigation on this limit? The text should also state what to do when the 8 bits are not enough. -- Section 5.2 -- I suggest to mention that the use of the Datagram_Tag field will be described in section 6. -- Section 6 -- I find it weird to read in the same paragraph "The RFRAG Acknowledgment can optionally carry an ECN" and later "MUST echo that information by setting the 'E'". I am not a native English speaker but may I suggest to replace the first part with "The RFRAG Acknowledgment has a ECN" -- Section 6.1.2 -- "An implementation may receive overlapping fragments as the result of retries after an MTU change." Is this a security risk (RFC 8200 forbids overlapping fragments but this is a different layers) ? I also suggest to make it a normative "MAY" or "MUST accept". -- Section 7.2 -- Should the network observation installs global states or per destination states ? E.g., typical IP implementations maintain a per destination Path MTU cache. == NITS == -- Section 7 -- Is it "Kbps" or "kbps" ? _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
