Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
RFC 7050

Note: This ballot was opened for revision 13 and is now closed.

(Russ Housley) Discuss

Discuss (2013-02-18 for -13)
  This DISCUSS position builds on comments from the Gen-ART Review by
  Brian Carpenter on 15-Feb-2013.

  (1) This document says:
  
    "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."

  I hope that day comes, and comes soon.  That said, the second sentence
  really does not tell an implementer anything.  Why is any strategy
  other than an "off" switch required?  The answer to that question may
  help an implementer decide what to include in their code.  If there
  are no more IPv4-only services, there will be (observably) no traffic
  in the NAT64 box.

  (2) The IANA Considerations in this document says:

    "The well-known domain name could be, for example, "ipv4only.arpa"."

  If this is an example, then you cannot refer to it unconditionally
  earlier in the document.  Please make an explicit request to IANA for
  this exact name. Otherwise, you need to replace all occurrences of
  ipv4only.arpa by FQDN-TBD and have the RFC Editor insert the
  IANA-assigned FQDN.

  (3) The same thing applies to 192.0.0.170 and 192.0.0.171. Either
  they need to be IP-ADDR-TBD1 and IP-ADDR-TBD2 in the text, or you
  need an explicit request to IANA.

  (4) Who populates the DNS with the RRs for ipv4only.arpa? That
  responsibility needs to be defined.
Comment (2013-02-18 for -13)
No email
send info
  The Gen-ART Review by Brian Carpenter on 15-Feb-2013 raises this
  issue.  I have taken the crux of Brian's comment and added by
  thoughts to it.  I do not consider the comment blocking, but I
  would like the authors to consider it.

  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.

(Wesley Eddy) Yes

(Martin Stiemerling) (was No Objection) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2013-03-07 for -14)
No email
send info
Thanks for adding text regarding registration of special use domain names.

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-02-25 for -14)
No email
send info
- 3.1.2, step 2: I thought walking the DNS tree like this was
frowned upon. I'd be interested in knowing why its ok in this
case to chase CNAME/DNAME but not in other cases.  (I'm not
objecting, just trying to understand.)

- 3.2, "hoping the problem is temporary"? That seems odd. Is it
really desirable?

- IANA stuff - given that we're moving the special purpose
address registries from RFCs to be IANA-only, do any of the
allocation requests here need to change? (Or, when do we stop
referring to 5735 & 5736 and start referring to the new IANA
registry?)

(Brian Haberman) No Objection

(Barry Leiba) No Objection

(Pete Resnick) No Objection

(Sean Turner) No Objection