DNS over Datagram Transport Layer Security (DTLS)
draft-ietf-dprive-dnsodtls-15
Yes
(Terry Manderson)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Suresh Krishnan)
Note: This ballot was opened for revision 13 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(2016-12-15 for -13)
Unknown
I support both of Stephen's DISCUSS points.
Stephen Farrell Former IESG member
(was Discuss)
Yes
Yes
(2016-12-16 for -14)
Unknown
Thanks for addressing my comments (and also for doing that speedily before I'd forgotten whatever it was I meant by them:-) S.
Terry Manderson Former IESG member
Yes
Yes
(for -13)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -13)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -13)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -13)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -13)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-12-14 for -13)
Unknown
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 Former IESG member
No Objection
No Objection
(2016-12-12 for -13)
Unknown
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
Deborah Brungard Former IESG member
No Objection
No Objection
(for -13)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -13)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-12-14 for -13)
Unknown
Eric Vyncke (evyncke) <evyncke@cisco.com> performed the opsdir review.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-12-12 for -13)
Unknown
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?
Spencer Dawkins Former IESG member
No Objection
No Objection
(2016-12-13 for -13)
Unknown
Thanks for the careful treatment of transport topics in this specification.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -13)
Unknown