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

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

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.

  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.

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.

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.