IPv6 Guidance for Internet Content Providers and Application Service Providers
RFC 6883

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

(Ron Bonica) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2013-01-11)
No email
send info
Thanks for addressing my DISCUSS

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-01-08 for -04)
No email
send info
Very readable thanks.

- 5.2, please expand TCAM

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2013-01-04 for -04)
No email
send info
  Please consider the editorial comments provided in the Gen-ART Review
  by Meral Shirazipour on 19-Dec-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg08007.html

(Barry Leiba) No Objection

(Robert Sparks) No Objection

Comment (2013-01-07 for -04)
No email
send info
Consider pointing to HELD (RFC5985) as one way to get a more real-time binding between IP address and geolocation.

(Sean Turner) No Objection

Comment (2013-01-08 for -04)
No email
send info
Not sure if it's worth adding here, but an additional reason to use DNS names and not IP addresses are names in certificates.  If you're putting the IPv4 address in now you also gotta do it for your IPv6 addresses - better to just use DNS names.

Fernando's VPN traffic leakages in dual stack networks draft (draft-ietf-opsec-vpn-leakages-00) might be worth a mention or at least a warning that folks should test to make sure the problem described therein is fixed before blindly accepting that it works.

Pretty please suggest people actually turn security on for the protocols they enable: DNSSEC, DHCPv6 Auth, etc.

s12: r/provid./provided.

(Martin Stiemerling) Abstain

Comment (2013-01-09 for -04)
No email
send info
I'm not fully convinced about the usefulness of this draft, as the content is either widely known by folks skilled in the art or you can read it somewhere else or a lot of providers just did it already. Therefore, I am balloting Abstain. 
The draft is probably 5 years late.

Some comments you might consider:

Did this draft receive any input or feedback from any what you call ICP?

Section 1., paragraph 4:

>    Nevertheless, it is important that the introduction of IPv6 service
>    should not make service for IPv4 customers worse.  In some
>    circumstances, technologies intended to assist in the transition from
>    IPv4 to IPv6 are known to have negative effects on the user
>    experience.  A deployment strategy for IPv6 must avoid these effects
>    as much as possible.

  What are those effects?


Section 3., paragraph 2:

>    There is an anecdote of one IPv6 deployment in which prefixes
>    including the letters A to F were avoided by design, to avoid
>    confusing system administrators unfamiliar with hexadecimal notation.
>    This is not a desirable result.  There is another anecdote of a help
>    desk responder telling a customer to "disable one-Pv6" in order to
>    solve a problem.  It should be a goal to avoid having untrained staff
>    who don't understand hexadecimal or who can't even spell "IPv6".

  That are tales but what's the meat?


Section 5.3., paragraph 1:

>    It must be understood that as soon as an AAAA record for a well-known
>    name is published in the DNS, the corresponding server will start to
>    receive IPv6 traffic.  Therefore, it is essential that an ICP tests

  To be precise: An AAAA record does not imply that the IP address
  list in this record is reachable. I.e., the server could receive
  IPv6 traffic if the IPv6 network is setup correctly. Your text
  suggests that setting the AAAA record is just enough.