Last Call Review of draft-ietf-behave-nat64-discovery-heuristic-13
review-ietf-behave-nat64-discovery-heuristic-13-genart-lc-carpenter-2013-02-15-00

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.