Specification for DNS over Transport Layer Security (TLS)
draft-ietf-dprive-dns-over-tls-09

-- Section 3.1 --

   A DNS server that supports DNS-over-TLS MUST listen for and accept
   TCP connections on port 853.  By mutual agreement with its clients,
   the server MAY, instead, use a port other than 853 for DNS-over-TLS.

Is it really "instead" (in which case the previous sentence isn't unqualified "MUST"), or is it "in addition?  That is, which of these is correct?:

NEW-1
   A DNS server that supports DNS-over-TLS MUST listen for and accept
   TCP connections on port 853.  By mutual agreement with its clients,
   the server MAY, in addition, use a port other than 853 for
   DNS-over-TLS.
END

NEW-2
   A DNS server that supports DNS-over-TLS MUST listen for and accept
   TCP connections on port 853, unless it has mutual agreement with
   its clients to use a port other than 853 for DNS-over-TLS.
END

(And similarly for the client side in the following paragraph.)

I'm balloting yes, but I do have a few comments/questions:

- 3.1, third paragraph:
This seems to put normative requirements on clients and servers that do not implement this draft. If that is really needed, then perhaps this needs to update the appropriate base spec(s)?

- 3.2, last paragraph:
That's a bit of an odd use of SHOULD. I suggest s/SHOULD/can

- 3.3:
This section seems more about DNS over TCP in general. Is it specific to TLS? Are the 2119 keywords in this section new requirements, or do they describe existing requirements from 5966/7766? (If the latter, please consider stating them with descriptive language rather than normative language.)

- 4 and subsections:
There seems to be a notable absence of a profile that requires server authentication but does not require pinning. I assume there's a good reason for that which is obvious to people with stronger TLS and/or DNS backgrounds than mine. But it might be helpful to say why.

Do (or should) the profiles have anything to say about clear-text fallback if a client cannot connect to the server's DNS-over-TLS port, or the TLS handshake fails? I infer that such fallback should not occur with the pinned profile, but what about the opportunistic profile?

I am a definite Yes on this work, but just have a couple of comments...

* Section 3.1 says "By mutual agreement with its server, the client MAY, instead, use a port other than port 853 for DNS-over-TLS.  Such an other port MUST NOT be port 53..." It would be useful to *briefly* explain the MUST NOT. If it is by mutual agreement, what's the harm?

* Section 3.2 uses the SPKI acronym before it is expanded in section 4.2.

* I do not understand the last sentence of section 3.2, especially the "SHOULD".

Many thanks for doing this work. I look forward to using DNS in this
way. 

I had a discuss but the changes indicated at [1] are plenty good.

[1] https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dprive-dns-over-tls-07.txt&url2=https://raw.githubusercontent.com/paulehoffman/draft-hzhwm-dprive-start-tls-for-dns/master/draft-ietf-dprive-dns-over-tls.txt