Happy Eyeballs: Success with Dual-Stack Hosts
RFC 6555

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

(Jari Arkko) Yes

(Ron Bonica) Yes

(Wesley Eddy) (was Discuss) Yes

Comment (2011-11-23)
No email
send info
It may be worth mentioning at some point that in the "race" between an IPv4 and IPv6 SYN that the IPv6 SYN can be at a disadvantage due to potential tunneling causing an even less efficient path to be taken than the one that the IPv4 packet takes.

(Peter Saint-Andre) (was Discuss) Yes

(Stewart Bryant) No Objection

Comment (2011-11-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Wes raises an interesting point, the draft needs to discuss connectionless transport protocols.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-12-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I understand why improving IPv6 experience in dual stack deployments is
valuable to the IETF in promoting migration to IPv6. For that reason, 
publication of this document may be beneficial and encourage 
implementations to include more flexible selection algorithms such as 
that described in this document. However, I don't see anything in this
document that impacts interworking, so I don't see why it is Standards

(Stephen Farrell) (was Discuss) No Objection

(David Harrington) (was Discuss) No Objection

(Russ Housley) No Objection

(Pete Resnick) (was Discuss, No Objection) No Objection

Comment (2011-12-11)
No email
send info
I really think this document should have had a co-author in the apps area. It is written exceedingly "thinly" and doesn't really understand some of the application implementation issues. That said, I still think it is valuable and worth publishing (and hopefully updating in the future). Though it is a bit this for the standards track as it is now, I see the potential to fill this in over time with more proscriptive information, and therefore I don't object to go it going on the standards track now in anticipation of that. Some issues to consider for this go-round:

3.1 - This has nothing to do with URIs. It is about hostnames. Hostnames used that don't appear in URIs have exactly the same issues.

4. - Though using SYN and ACK in the diagram is fine, I recommend using words like "connection attempt" in the descriptive text. SYN and ACK are probably not as familiar to application layer folks, and since this is aimed at them, it is likely better to use the application layer terminology. Furthermore, there is a performance/resource impact to making a "connection attempt" that an apps person will understand that they might not if it is understood as only an additional packet.

I agree with Stephen's concerns regarding "MUST cache". There are valid reasons to try v6 later even if v4 succeeds first, but those reasons must be carefully considered and understood. That sounds like a SHOULD.

4.1 - The first few paragraphs strike me as introductory material, not part of the alogirthm requirements.

4.2. - "SHOULD do so every 10 minutes" I think instead you mean "SHOULD do so no more frequently than every 10 minutes". It's perfectly fine to do so every 20 minutes, or once a day.

4.3. - DNA does not describe how applications (which are the ones who are going to implement Happy Eyeballs) are to be notified of these changes. Though I agree that a Happy Eyeballs app should be able to ask its host to do a DNA for it (or more to the point, get notifications from the host), that's an additional requirement on these apps and should be noted.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2011-12-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please consider the editorial comments suggested by Sandy in here secdir review: