Subject: [Int-area] Mirja Kühlewind's Yes on draft-ietf-intarea-frag-fragile-15: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 11:41:08 -0700

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