Reviewer: Tim Chown
Review result: Ready with Nits

This is a INT-DIR review of draft-ietf-intarea-frag-fragile-10, which was updated from the -09 version on 14th May.

Overall: 
This is a well-written draft, explaining both the weaknesses of relying on IP fragmentation for robust operations, and giving recommendations for various audiences on steps to take to minimise both the use and impact of IP fragmentation.

The draft is a more pragmatic approach to living with the realities of IP fragmentation than the somewhat more "aggressive" previous draft from one of its authors - draft-bonica-6man-frag-deprecate-02.  I note that some elements from that draft have been carried forward into this, such as the text on OSPF.  

I fully support publication of this draft, which is pretty much ready to go.  I have a small number of comments below, none of which are critical, but which the authors may wish to address, and a few nits that should be addressed to minimise the work for the RFC Editor.

Comments:

Section 1
The last sentence in paragraph 2 of the Introduction might better be reworded to say something like the 2nd para of section 7.1, about environments where IP fragmentation is supported; as it stands the sentence isn't wholly clear, nor is it clear how "security and interoperability issues are addressed".

Section 2.1
I understand what NOTE1 is saying, but some reference supporting why "for practical purposes many network operators consider the IPv4 minimum link MTU to be 576 bytes" would be welcome.

Section 2.3
Perhaps emphasise that what is described here is existing practice, rather than what is recommended in Section 7 (which may vary), e.g., the text around estimating the MPTU to be 1280 for IPv4 with the DNS(SEC) baggage that comes with that.

Section 4.3 
This subject is also talked about in more detail in Section 4.6, so either move the text or add a pointer there.

Section 4.7:
RFC 4890 targets ICMPv6; the text implies it's generic.
Para 4 should also mention 4.7.4 as we as .2 and .3.
What are the "any other sources" mentioned in the last line?

Section 4.8:
I recall Fernando and I cause some controversy in 6man by discussing such reasons in our draft that was eventually published as RFC 7872, and had to remove them leaving just the measurement results and methodology, so you may run into similar comments here.
If you keep it, there is also draft-taylor-v6ops-fragdrop-02 to consider, which ran into similar choppy waters.

Section 5.1
In the para beginning "Upper-layer protocols", how do you determine that that risk is acceptable?  Is the language of 7.1 better here, about IP fragmentation being known to be supported?

Section 5.1
In para beginning "While TCP will"... there is an example in draft-bonica-6man-frag-deprecate-02 where this may not be true, if there's multiple paths being used?

Section 5.1
At the end, is there maybe something to add about QUIC; it would be interesting to comment on how it handles fragmentation.

Section 6:
In draft-bonica-6man-frag-deprecate-02 there are other examples given, i.e., SIIT, DCCP and NFS.  I think it's fine to just list DNS, OSPF and tunnelling, but maybe emphasise that the key issue with DNS is likely around DNSSEC (as discussed later).

Section 7.5:
Last para, does that open a door to spoofing attacks using those server IPs?  Presumably the suggestion is to only dd this for the ISP's own known servers?

Nits:

Section 1
The first two sentences in the Introduction duplicate the same wording and read rather clumsily.

Page 4 para 2:
IP single -> single IP

Page 4, bottom:
given time, -> given time

Page 5, NOTE3:
is Destination -> is a Destination

Section 2.3, page 7:
relies of -> relies on

Section 4.6:
Add a reference for the Rose attack.
These four issues could also be written as subsections 4.6.1, 4.6.2, etc.

Section 4.7, First para 
the networks to -> the network to

Section 5.1
In the para beginning "Upper-layer protocols" should that reference to 2.1 be 2.3 (and maybe 4.7)?

Section 7.1
At the end, state in -> stated in