Please see attached review. Brian I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-behave-nat64-discovery-heuristic-13.txt Reviewer: Brian Carpenter Review Date: 2013-02-15 IETF LC End Date: 2013-02-05 IESG Telechat date: 2013-02-21 Summary: Almost ready (but definitely NOT ready) -------- Comment: -------- This is identical to my Last Call review as I have seen no response from the authors. I've classified the issues as minor, but I think they need to be fixed. IANA has serious comments too. Firstly let me note that I kept out of the discussion of this draft in BEHAVE, although I'm completely familiar with NAT64 and DNS64. It is indeed a heuristic. As far as I can tell it's the best that can be done and it was very thoroughly bashed around in the WG. I just don't find it convincing as standards track material; it walks, talks and quacks like an Experimental RFC. This is personal opinion and the counter-argument is at http://www.ietf.org/mail-archive/web/behave/current/msg10517.html Minor Issues: ------------- This document definitely cannot be understood by anyone who has not first understood the NAT64 and DNS64 documents. It might be useful to state this explicitly in the first paragraph. " A day will come when this tool is no longer needed. At that point the best suited techniques for implementing an exit strategy will be documented." The second sentence really says nothing. Why is any strategy other than an "off" switch required? If there are no more IPv4-only services, there will be (observably) no traffic in the NAT64 box. 8. IANA Considerations "The well-known domain name could be, for example, "ipv4only.arpa". " If it's an example, you can't refer to it unconditionally earlier in the document. I would make an explicit request to IANA for this exact name. Otherwise, you'd need to replace all occurrences of ipv4only.arpa by FQDN-TBD and have the RFC Editor fix it up. The same thing applies to 192.0.0.170 and 192.0.0.171. Either they need to be TBD1 and TBD2 in the text, or you need an explicit request to IANA. Who populates the DNS with the RRs for ipv4only.arpa? That responsibility needs to be defined.