DNS over Datagram Transport Layer Security (DTLS)

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

(Stephen Farrell) (was Discuss) Yes

Comment (2016-12-16 for -14)
No email
send info
Thanks for addressing my comments (and
also for doing that speedily before I'd forgotten
whatever it was I meant by them:-)


(Terry Manderson) Yes

(Kathleen Moriarty) Yes

Comment (2016-12-15 for -13)
No email
send info
I support both of Stephen's DISCUSS points.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2016-12-14 for -13)
No email
send info
Update: Looks like the address for Dan Wing needs to be updated.

-1: Is TCP head of line blocking considered a problem between the client and cacheing resolver? Otherwise, between that and the potential to use TCP fast open, the motivation for not just using TLS seems weak (which may not be a problem for an experimental RFC.)

- 3.1: "DNS clients and servers MUST NOT use port 853 to transport cleartext
   DNS messages. "
Am I correct to assume that this requirement is really about clients and servers that do not implement this spec? While I see the point, how would such a client or server even know about the restriction?

(Benoît Claise) No Objection

Comment (2016-12-12 for -13)
No email
send info
Under which conditions do we know that this experiment will be successful?
Anything worth nothing?
As an example of a similar RFC, see https://tools.ietf.org/html/rfc7360#section-1.3

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

Comment (2016-12-13 for -13)
No email
send info
Thanks for the careful treatment of transport topics in this specification.

(Joel Jaeggli) No Objection

Comment (2016-12-14 for -13)
No email
send info
Eric Vyncke (evyncke) <evyncke@cisco.com> performed the opsdir review.

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2016-12-12 for -13)
No email
send info
Regarding the shepherd write-up: There is no requirement for an implementation section. There is a recommendation to have one, to track implementations efforts during the draft's live-time, but such a section is usually removed on publication as RFC as this information easily out-dates. There is another recommendation to have a section explaining the goals and/or next steps after the end of a (successful) experiment. I personally don't think this is required here, given that I understand the experiment is to figure out if this will be adopted (given there is stable reference).

One small question on the text in the draft:
"For the client, state should be destroyed when
   disconnecting from the network (e.g., associated IP interface is
   brought down). "
Does this mean all state including state used for session resumption?

(Alexey Melnikov) No Objection

Alvaro Retana No Objection