Skip to main content

Happy Eyeballs: Success with Dual-Stack Hosts
RFC 6555

Yes

(Jari Arkko)
(Peter Saint-Andre)
(Ron Bonica)

No Objection

(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Stephen Farrell)

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

Jari Arkko Former IESG member
Yes
Yes ()

                            
Peter Saint-Andre Former IESG member
(was Discuss) Yes
Yes (2011-12-21)

                            
Ron Bonica Former IESG member
Yes
Yes ()

                            
Wesley Eddy Former IESG member
(was Discuss) Yes
Yes (2011-11-23)
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.
Adrian Farrel Former IESG member
No Objection
No Objection (2011-12-11)
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
Track.
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
David Harrington Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Pete Resnick Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2011-12-11)
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.
Ralph Droms Former IESG member
No Objection
No Objection ()

                            
Robert Sparks Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection ()

                            
Sean Turner Former IESG member
No Objection
No Objection (2011-12-14)
Please consider the editorial comments suggested by Sandy in here secdir review:

http://www.ietf.org/mail-archive/web/secdir/current/msg03016.html
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2011-12-09)

                            
Stewart Bryant Former IESG member
No Objection
No Objection (2011-11-28)
Wes raises an interesting point, the draft needs to discuss connectionless transport protocols.