Re: Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd)

At Tue, 15 Oct 2013 16:21:34 -0400 (EDT),
Paul Wouters <[email protected]> wrote:

> As discussed, I separated the EDNS TCP keep-alive option from the EDNS
> chain-query document, and Joe Abley kindly offered his assistance in
> (re)writing this document.

I have some comments on the draft.  I've noticed some of them were
covered in the followup discussion in this thread, but I thought it's
more handy to summarize mine in a single message.

Overall, the motivation and approach of the proposal seem to make
sense to me.  I have some comments and questions on details.

- The definition of "timeout" isn't clear to me.  In Section 3.1 it
  only states "a timeout value for the TCP connection".  Section 3.3.2
  explains it as: "the TIMEOUT value that is currently associated with
  the TCP session", which is not really clear to me.  Is that the
  (maximum) duration while the server is waiting for more DNS messages
  from the client (and it would close the connection if there's no
  message during the period)?  Maybe this is obvious for some, but I
  think it's helpful to define it more clearly and specifically.

- In Abstract, it says: "However, clients are currently limited in
  their use of the TCP transport as most implementations limit the TCP
  session to a single DNS query and answer".  Does this
  "implementations" mean clients or servers?  According to the general
  sense of the draft, I guess it means servers, but it's not super
  clear.

  If it means servers, is this true?  And, whether or not it is, I
  think what should matter more is what the deployed servers instances
  do, rather than how many implementations do this out of all existing
  implementations that would include many non-compliant ones.  In that
  sense, IIRC ISC BIND 9, which I believe is still the majority in
  terms of deployment base, supports multiple queries/responses on a
  single TCP connection.

- In my understanding of the draft, clients and servers send this
  option independently, and, in particular, the server may or may not
  send it whether or not the client includes it in the request.  (That
  is, unlike (e.g.) NSID, including this option in a request doesn't
  mean the client requests the server to include it in the response).
  Is this correct?  Maybe obvious, but I think it's helpful to clarify
  that more explicitly.

- I don't understand this part of Section 4:

   The edns-tcp-keep-alive option can potentially be abused to request
   large numbers of sessions in a quick burst.

  Could you (or the next version of the draft) be more specific about
  it?

--
JINMEI, Tatuya
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext