Mirja Kühlewind has entered the following ballot position for draft-ietf-intarea-frag-fragile-15: Yes
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-intarea-frag-fragile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing this document! I think this will be a very useful reference also for us ADs! Also thanks for addressing all the comments of TSVART early review (and thanks for Gorry for this really good and detailed review!). I'm not certain if the following comment from that review was finally resolved. Can you maybe double-check with Gorry: >From Gorry's mail on May 29 ">> Section 4.6 >> You may find it useful to check and refer to the following IPv4 specs that relate to the use of fragments: >> - Please note the recommendation to check details and cite RFC6864 on IPv4 Fragment ID. >> - Please note the recommendation to check and cite RFC 4787 on NAT handling of IP fragments. > I'm hard pressed to say what changes you would suggest, or what section you want to see a reference in. To be very honest, a two minute timeout makes a > lot of sense in an Internet in which a packet requires a significant portion of a second to transmit; in a megabit-to-gigabit Internet, the corresponding > interval is probably measured in seconds or, at most, tens of seconds. In any event, I would want to see data supporting the recommendation. > > Please be more specific. RFC 6864 is in the references - which I think is good. Perhaps a way to resolve my comment would be for section 2.1 to mention IPID and then cite RFC6864. I'd be happy to see more text on this topic, but I suspect it is sufficient to simply ensure the reader is aware that these RFCs impact fragmentation. I was imagining something like this: The set of IPn fragments comprising a complete IPv4 datagram all carry the same non-zero value in the IPID field. RFC 6848 describes issues relating to the handling of the IPv4 ID field in middleboxes. Section 10 and 11 of RFC 4787 describes best current practice for handling fragmentation in network devices performing Network Address Translation (NAT)." And one more minor comment: Se 6.1: "In these cases, the protocol will continue to rely on IP fragmentation but should only be used in environments where IP fragmentation is known to be supported." Should this "should" be a "SHOULD"? _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
