Last Call Review of draft-ietf-dnsop-edns-tcp-keepalive-04
review-ietf-dnsop-edns-tcp-keepalive-04-opsdir-lc-mitchell-2015-11-29-00

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