Last Call Review of draft-ietf-behave-nat64-discovery-heuristic-13

Request Review of draft-ietf-behave-nat64-discovery-heuristic
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-02-19
Requested 2013-02-07
Draft last updated 2013-02-15
Completed reviews Genart Last Call review of -13 by Brian Carpenter (diff)
Genart Last Call review of -13 by Brian Carpenter (diff)
Assignment Reviewer Brian Carpenter
State Completed
Review review-ietf-behave-nat64-discovery-heuristic-13-genart-lc-carpenter-2013-02-15
Reviewed rev. 13 (document currently at 17)
Review result Ready with Issues
Review completed: 2013-02-15


Please see attached review.


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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)


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

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

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, "". "

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 by FQDN-TBD and have the RFC Editor
fix it up.

The same thing applies to and 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 That responsibility needs
to be defined.