Happy Eyeballs Version 2: Better Connectivity Using Concurrency
draft-ietf-v6ops-rfc6555bis-07

Summary:

I think it's great that we continue to refine the means for making rapid connections in dual-stack environments, and want to thank the authors and working group for putting together a well-written and easy-to-follow document. I have some concerns about distinguishing normative requirements from an "example algorithm" that can be used to meet them, and would like to see better clarity around the relationship between this document and existing, deployed implementations of RFC6555.

Details:

The abstract claims that the document provides an "example" algorithm, while the main text of the document describes the algorithm as "RECOMMENDED" (using normative language), as well as having a variety of other normative statements made regarding its implementation. Given that the document is serving the dual purpose of laying out requirements and giving an exemplary (which I would take to mean "non-normative") algorithm that satisfies those requirements, I would *strongly* recommend removing normative language from the description of the exemplary algorithm.

In order to make that task easier -- and to clarify the intention of the lower-cased word "recommended" in phrases like "The recommended minimum value is 100 milliseconds" -- I would further suggest that this document adopt the new RFC8174 template instead of using the old RFC2119 template. 

That said, there appears to be a random mix of uppercase and non-uppercase "recommended" even when describing the same general concept (e.g., the timer cited above is "recommended," while the timeout for processing DNS responses after a connection is "RECOMMENDED") -- I suggest an editing pass that generally looks at how these terms are used and ensures that normative versus non-normative uses are properly distinguished.

The reason I'm focusing so carefully on normative versus non-normative language use in general, and on carefully making the algorithm itself non-normative in particular ties to the rationale for obsoleting RFC6555. In an earlier response to Mirja's DISCUSS, Tommy Pauly said:

> A "simple" implementation of the 6555bis algorithm is still
> aligned with the algorithm in 6555, and we would like to see
> new implementations taking the nuances of the new algorithm
> description into account.

Which makes perfect sense. I've seen evidence that this point -- that an implementation of the RFC6555 algorithm is fully compliant with the v2 document -- has been broadly missed by the implementation community. See, for example: https://groups.google.com/a/chromium.org/forum/m/#!topic/net-dev/GQaqi5WVlPY  (and, FWIW, I've had similar private feedback from the relevant decision makers inside Mozilla regarding web browser implementations).

To clarify this situation, I think it is really necessary to include text in Appendix A that indicates roughly the same thing as Tommy's text above does.

I completely agree with Adam's Ballot.  [I was in the process of writing something similar, so I'm happy he beat me to it.]

Substantive Comments:

- I agree with Adam's comments about normative language. 

-4, 2nd paragraph, last sentence:
"across networks" and "network changes" are ambiguous. I think you are talking about moving a device from one access network to another, but "across networks" could be interpreted to mean "sending the data across networks". "Network changes" could refer to changes in network configuration.

-10: I don't understand what you mean by "direct" vs "indirect" security considerations.

Editorial Comments:

- Abstract: Please mention that this obsoletes 6555 in the abstract. (The intro already does so.)

- 7.2, last paragraph: The pattern "... recommended at 2 seconds" does not make grammatical sense. I would assume there are missing words, but I see the same pattern occur several times in the document. I suggest "recommended to be..."

Someome id-nits:

     (See RFCs 3967 and 4897 for information about using normative references

     to lower-maturity documents in RFCs)


  == Missing Reference: 'Section 3' is mentioned on line 120, but not defined

  == Missing Reference: 'Section 4' is mentioned on line 164, but not defined

  == Missing Reference: 'Section 5' is mentioned on line 202, but not defined

  == Missing Reference: 'Section 6' is mentioned on line 169, but not defined

     Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).

This document should provide a rationale for why you are favoring v6 over v4 addresses when v4 addresses resolve first. Is there some technical reason (e.g., it works better) or is there just a political reason (we want to push people to v6). I could live with either, but the document should be clear IMO.

I'm removing my discuss as the authors have confirmed that there is strong consensus in the working group to obsolete RFC6555, and edited the text in the intro accordingly. As mentioned to the authors directly already, the abstract should mention this as well!

Thanks also for addressing my other comments!