I am an assigned INT directorate reviewer for draft-ietf-6man-deprecate-atomfrag-generation-06.txt These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html . This document doesn’t appear to actually recommend a course of action other than in the Abstract.   It seems to me that this document is arguing (perhaps?) that firewalls should drop atomic fragments, or perhaps that hosts should.   But it never gives any actual advice. It seems to me that the document could be substantially improved by explicitly saying what behaviors are being recommended here.   Otherwise, the statement in the Abstract that this is intended to motivate changes to the core IPv6 protocol specifications seems to leave whoever does that with the task of reading this document, thinking through the problem the authors have already thought through, and trying to come up with the right changes to the base spec. While doable, this seems unnecessary given that the authors have put a lot of thought into this.  Even if the document were to recommend a course of action that wasn’t ultimately followed, walking through the reasoning behind those recommendations would likely be helpful.   Given that the document is informational, this advice could be described as a recommendation for future work, and not as advice to implementors. It might also be useful, and would likely render any worries about this document being treated as normative, if the authors were to talk about what to do to clean up existing implementations if the decision is taken to retain the atomic fragment functionality. That said, the document is mature, and useful as written.   I do not see any reason to hold up publication if the working group is unwilling or unable to make the changes I’ve suggested. Some minor detailed suggestions follow: OLD:   Once the attack   packet has been sent, it will be the aforementioned routers   themselves the ones dropping their own traffic. NEW:   Once the attack   packet has been sent, the aforementioned routers   will themselves be the ones dropping their own traffic.   o  As noted in Section 3, SIIT [RFC6145] (including derivative Expand SIIT acronym?   2.  The IPv4 node is located behind an IPv4 link with an MTU smaller       than 1260 bytes It would be helpful to talk about when this might happen.   It’s not clear to me that this is a plausible real-world scenario in these modern times, but if it is it would be good to identify the situations in which the proposed change will create operational problems.  I don't think that any use case you might list here would lead the reader to conclude that therefore we need to keep atomic fragments, but such use cases should be discussed, or the lack of any known such use cases should be discussed, for completeness.