DNS Transport over TCP - Implementation Requirements
draft-ietf-dnsext-dns-tcp-requirements-03

Note: This ballot was opened for revision 03 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) Yes

(Ralph Droms) Yes

(Lars Eggert) Yes

(Robert Sparks) Yes

Comment (2010-06-16)
No email
send info
These comments are all minor:

1) The first bullet of section 4 could be read incorrectly to mean that an authoritative server implementation can not limit the size of responses for any reason.

2) It is odd to put normative requirements (MAY) on proprietary (hence non-standard) implementations. Can the section about stub resolvers be rewritten as simple commentary?

3) +1 to Dan's comment re: RECOMMENDS

(Stewart Bryant) No Objection

Comment (2010-06-16)
No email
send info
I agree with Peter's concern WRT the document name. The Abstract could also do with clarifying to indicate this is a deployment imperative and not input to a new protocol specification.

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2010-06-16)
No email
send info
  The Gen-ART Review by Avshalom Houri on 2010-06-11 raised a question
  about about this portion of the document:
  >
  > That requirement is hereby relaxed.  A resolver SHOULD send a UDP
  > query first, but MAY elect to send a TCP query instead if it has good
  > reason to expect the response would be truncated if it were sent over
  > UDP (with or without EDNS0) or for other operational reasons, in
  > particular if it already has an open TCP connection to the server.
  >
  The question was:
  >
  > What should be the behavior here?  Try TCP and then revert to UDP?
  > What should be the timeout for the TCP trial?  Seems that this needs
  > a bit of clarification.
  >
  The response to this question makes sense:
  >
  > In the latter case no text should be necessary (IMHO).  This
  > document doesn't change the protocol processing.  This particular
  > section merely permits TCP first in some cases, relaxing
  > Section 6.1.3.2 of RFC 1123.
  >
  A statement that this is relaxing Section 6.1.3.2 of RFC 1123
  seems like an excellent idea.

Alexey Melnikov No Objection

(Tim Polk) No Objection

Comment (2010-06-15)
No email
send info
Section 4, second bullet:
s/so that the do not/so that they do not/

Is the text regarding proprietary stub resolvers in section 4 necessary?  The section opens with
"All general purpose DNS implementations MUST ...", and a proprietary stub resolver seems to
be explicitly outside the scope of the section.  If it is needed, I would suggest replacing that
paragraph with something a little more restrictive, along the following lines:

   Stub resolver implementations specifically designed for deployment in
   restricted environments where truncation can never occur, or DNS lookup
   failure is acceptable, MAY omit support for TCP.

(Dan Romascanu) No Objection

Comment (2010-06-08)
No email
send info
1. It would be useful to indicate the reference for the terms used in the normative text in section 4 (authoritative server, recursive resolver, stub resolver) - RFC 1035 or other

2. insection 5: 'This document therefore RECOMMENDS ...' - this phrase needs to be reformulated as 'RECOMMENDS' is not the 2119 keyword to be used in a capitalization

(Peter Saint-Andre) No Objection

Comment (2010-06-15)
No email
send info
1. The title "DNS Transport over TCP - Implementation Requirements" makes it sound as if this document is defining requirements for subsequent work regarding implementation of DNS-over-TCP, not requiring implementations to support DNS-over-TCP. Perhaps something like "TCP Required for DNS Implementations" would be clearer.

2. The document exempts "proprietary stub resolver implementations" but does not define "proprietary" in this context. Does this mean that as long as my implementation is not open-source, I don't need to support TCP? Or by "proprietary" does the author mean that the implementation is deployed in a particular environment (as seems to be implied)? If the latter, then the exemption applies to deployments, not implementations.

(Sean Turner) No Objection