Kathleen prompted me to review the latest revision of this draft, promising me that I would "be a lot happier with version 21". I am actually looking at version 22, and I certainly appreciate the amount of work that went into improving this draft. We saw 9 revisions over the last two months, so clearly the authors have been very busy. And the result is indeed much improved. The old versions were sometimes irritating, the new version is much easier to follow. I appreciate that in many places, instead of just lamenting the loss of clear text inspection capabilities, the draft lists the ongoing efforts in the IETF to propose alternatives. Mostly, I like the general tone, carefully asserting that documenting controversial practices is not an endorsement. And I like the call for cooperation between application providers and network managers, to develop suitable management and debugging API. By and large, I believe that this document is ready. By that, I mean that we have probably reached an equilibrium, and that further discussions might delay publication, but will not significantly alter the content. Despite that general assertion of readiness, I think that mention two sections that could still be improved. The section on load balancers (2.2.1) fails to mention that end to end solutions may very well solve the issue with CDN anycast, by simply migrating the connections to a CDN unicast address. MTCP would allow this today, and QUIC most probably will allow that tomorrow. Simple improvements in the end-to-end transport might obviate the need for complex deployment of load balancers in the network, resulting in an overall simpler architecture. I am very skeptical of the justification for performance enhancing proxies in section 2.2.4. It develops the idea that having a form of hop-by-hop transport would be more efficient than end-to-end transport, because each hop controller would have a shorter RTT to manage and thus could react more quickly. I understand that argument, and in fact I used to believe it in the early 80's. Hop by hop control, as done by X.25 and HDLC in 1980, was arguably more efficient than end-to-end control via TCP, although of course less flexible. But then by 1988 Van Jacobson demonstrated that with improved congestion control, TCP was in fact as efficient or more than hop by hop alternatives. At that point, the better flexibility of TCP and the simpler network architecture won the day. I am pretty sure that someone in the CCRG will come up with innovative congestion control that will similarly moot the debate. In fact, they may already have. And I would appreciate a pointer to this kind of history in the draft. I could go on with more detailed feedback, but I want to keep this review short, and maybe I am suffering a bit from review fatigue. My final point is that there are quite a few typos in the draft. Please run a spell checker and fix them. -- Christian Huitema
