Subject: [apps-discuss] (no subject)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 26 Nov 2011 01:03:10 -0800

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-v6ops-happy-eyeballs
Title: Happy Eyeballs: Success with Dual-Stack Hosts
Reviewer: Murray S. Kucherawy
Review Date: November 25-26, 2011
IETF Last Call Date: completed November 10, 2011
IESG Telechat Date: December 1, 2011

Overview: This document provides a basic framework for algorithms to improve user experience when, in a dual-stack environment, the IPv6 version of a service becomes unavailable.

Summary: This draft is almost ready for publication as an RFC but has a few issues that should be fixed before publication.

Major Issues:
1) As Wesley Eddy has already noted in a DISCUSS, this document's scope is limited to applications that use TCP for communication.  It should either disclaim this up-front, or should spend some time talking about stateless transport, even if the algorithms are the same (and if they're not, spend some time talking about how they're different).

2) Certainly the IESG is the arbiter of such choices, but I'm not seeing why this document is appropriate for the Standards Track.  It doesn't introduce anything new that creates new interoperability concerns; everything it describes is local to the machine seeking to make a connection to a service.  It could certainly be the case that my understanding of what's appropriate on the various tracks simply needs adjustment.  :-)

Minor Issues:
1) Section 4.2 talks about "Such an implementation MUST occasionally make connection attempts using the host's preferred address family..."  Is that during an existing session, or when establishing new ones?  I can't tell here if the goal is to change to the preferred address family within a session (if it is detected that such is now possible) or on the next connection attempt.

2) It is unclear from a general reading of this where the Happy Eyeballs algorithm is meant to be implemented.  It seems that this could be a layer of application-level logic, and that is probably the intent, but a piece of networking equipment that implements some of these algorithms could declare a connection failed right away if it has observed a history of that family, prefix, or address failing in the recent past.  Thus, the state of Happy Eyeballs is maintained in the hardware rather than in a new application layer.  Or there might be a co-operation between the two.  (You later allude to this in Section 5.9, specifically talking about OS implementations, which is one of a couple of possible placements.  Maybe Section 5.9 could talk about putting this stuff in hardware too.)

3) Section 5.1 claims there is minimal impact ("small detriment") of Happy Eyeballs implementation.  Has this actually been measured, especially at scale?  If so, a reference to or a description of that work (perhaps in an appendix) would be nice.  If not, this strikes me as speculative, and it should probably say so.

4) Section 5.3 might also suggest (via MAY/OPTIONAL) that, for troubleshooting and debugging purposes, a Happy Eyeballs implementation make available its cache of what connections are working and which are being "de-preferred" because of detected connection difficulties.

5) The recommendations of Section 5.7 seem (admittedly having read none of the history of this document) somewhat arbitrary.  The last sentence rescues it somewhat, but I wonder in what context 150-250ms makes sense.

6) Section 5.8 makes a direct reference to work in the WEBSEC working group, correctly acknowledging the concerns of their Same Origin work.  Has anyone from that working group (perhaps the authors of the referenced draft) reviewed this one?

7) In Section 6, some discussion or even an sample implementation of the caching of results described in Section 4.2 would help to complete the illustration.

8) I anticipate SecDir will request a better treatment of Section 7 (Security Considerations) than this draft currently includes.  At a minimum, I suggest moving the security-specific details to Section 7 and making forward references to them.

Nits:
1) In the last sentence of Section 5.1, "server" should be "servers".

2) In Section 5.5, "an DNS" should be "a DNS".

3) Is Section 5.6 necessary?  If A6 records were already busted to Experimental, it seems like this gives them needless attention.  To that end, perhaps this document (or a different one from v6ops) should declare A6 Historic.