Hi, 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/direc torate.html. Overall, the document is mature, well written and I find it useful. I do not see any reason to hold up publication. Some minor detailed suggestions follow: - Section 1: The text says: 'Section 5 of [RFC2460] states that, when a host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination.' RFC2460 actually says 'In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280.' While the document states later that 'an IPv6 node cannot easily limit its exposure to the aforementioned attack vector by only generating IPv6 atomic fragments towards IPv4 destinations behind a stateless translator', it would help the reader to add that piece of context from the very beginning of the document. - Section 2: Again, I think it would help adding the context about RFC2460 using atomic fragments only for the purpose of helping an IPv6- to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. - Section 3: when discussing IPv4 Identification collision rates, it would be helpful adding some numbers/equations there to get an idea of what rates we are talking about. - Appendix A: what does 'Linux kernel current' mean? This is very minor, as this section is probably to be removed, but in case it remains after publication as RFC, current should be replaced by the kernel version number. Thanks, Carlos