I have reviewed draft-ietf-dnsop-edns-tcp-keepalive-04 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I found the document is technically clear and Ready w/nits. This is a standards track document by the DNS op working group which defines an EDNS0 option which, when negotiated, can be utilized by DNS servers to signal to DNS clients the time period a TCP session should remain open to conduct future DNS transactions, allowing DNS servers to manage TCP session resource utilization more easily. Nits - Abstract: I feel the abstract is a bit vague and should not refer as much to "balancing UDP and TCP" which is a possible effect of the wide scale implementation of this option (in other words a motivation of the draft) rather than exactly what this option does. The abstract could more easily be worded "encourage more use of TCP transport" than balancing. The last sentence might finish more easily with "managed more effectively by DNS Servers to encourage more use of long lived TCP sessions which minizes the impact of DNS transaction time of using TCP transport". Introduction: 1st paragraph - would recommend striking last sentence as off topic and speculative (although likely true). 5th paragraph - it's unclear if the expensive overhead being referred to here is the resources on the server or the overhead talked about in the next paragraph for the initial setup time impacting response time. If the later, this paragraph should be merged with the later paragraph. Either way this deserves clarification, maybe it means both (as covered in the following paragraphs). 6th paragraph - last sentence, would prefer ending this paragraph with "is minimized as N increases." over unity as unity refers to the equation while the subject of the sentence is about the overall impact of the 3 way handshake. 1 is not an impact, also, these sessions are not likely to be infinitely long lived so any value approaching the unity is not going to be achieved in many cases. 8th paragraph - I believe it should be noted, in the proper place in this section. Perhaps either in the introduction either in paragraph 1 which seems to imply the reader is familiar with this already or in paragraph 6 which covers RTT comparisons. 10th paragraph - as in the abstract comment, saying promoting better balance is a bit vague, how about encourages implementations to use TCP for initial DNS requests rather than just as a fall back mechanism? This doesn't seem to have any motivation to balance out TCP and UDP as transports rather than just move people to TCP if I understand correctly? Section 3: I'm not sure it's accurate to say it can be utilized by clients to signal a willingness to keep an idle TCP session for a certain amount of time given they can't send a value for timeout. It's clear that clients have to signal willigness to support the option for a server to specify this value. Section 3.2.1: 2nd paragraph - if the implementation supports this document, isn't SHOULD appropriate? Section 3.2.2: 2nd paragraph - typically in protocols, a timeout is the time when you do the action, in this case the document says the client must initiate a close before the timeout expires. Is this intential or a wording issue? Isn't it ok to initiate the close "once" the timeout expires? Also, if you implement this draft, shouldn't this be MUST? 3rd paragraph - why not MUST? 4th paragraph - this appears to be a normative reference to the 5966bis, not informational. Also that document refers back to this document - is it the intention these documents to be clustered for publication? Section 4: It's not clear that this case is any different than that of one in which either the client or server doesn't implement edns-tcp-keepalive in regards to impact ? Section 5: 1st paragraph - is this an additional security concern of edns-tcp-keepalive or just DNS over TCP in general? References: As stated earlier, it appears 5966bis is normative due to reference for behavior in section 3.2.2. Also - is there no stable URL that could be used for "Fragmenetation Considered Poisonous" or "DNS Response Rate Limiting"? Cheers, Jon