1)
Document: draft-ietf-dprive-dtls-and-tls-profiles
RFC Requested: Proposed Standard
RFC Indicated: Yes
Document Shepherd: Tim Wicinski
Area Director: Terry Manderson
This is the proper type of RFC as it is documenting the authentication
profiles for the existing mechanisms for a DNS client can authenticate to
a DNS server. It defines profiles for
the two existing mechanisms - DNS-over-TLS (RFC 7858) and
DNS-over-Datagram TLS (DTLS). RFC 7858 is standards track, and we felt
that this one should be as well - it doesn't update RFC7858, but is to closely
related that PS seemed right.
2)
Technical Summary:
This document discusses Usage Profiles, based on one or more
authentication mechanisms, which can be used for DNS over Transport
Layer Security (TLS) or Datagram TLS (DTLS). This document also
specifies new authentication mechanisms - it describes several ways a
DNS client can use an authentication domain name to authenticate a
DNS server. Additionally, it defines (D)TLS profiles for DNS clients
and servers implementing DNS-over-(D)TLS.
Working Group Summary:
The working group spent much time working through all the different
authentication mechanisms, primarily making sure that the DNS-over-TLS
and DNS-over-DTLS profiles were accurate, which were held up
waiting for the DNS-over-DTLS draft to be moved forward.
Document Quality:
Document is of good quality. It has been through both normative review
as well as editorial review and the shepherd feels it is worthy of
publishing.
(3) The Document Shepherd did a throughly normative review as well as a
deep editorial review. The shepherd feels this document is of good
quality.
(4) The shepherd has no concerns about the depth or breath of the
reviews.
(5) Since the document discussed authentication profiles, there was
outreach to the TLS working group as well as the security area for
completeness. Additionally, one of the authors is heavily involved with
the TLS working groups, so the shepherd felt this was covered.
More review is always welcome
(6)
Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
(7) The authors have confirmed there are no known IPR disclosures.
(8) No, there is No IPR disclosures
(9) The working group is solidly behind this. There was a delay in the
WGLC process, as many did not state their acceptance to the mailing list.
There was a solid acceptance during the meeting at IETF96, but the
chairs always want the mailing list to be the place for all approvals.
(10) No, there has been no appeal
(11) All nits have been found and addressed.
(12) No formal reviews needed.
criteria, such as the MIB Doctor, media type, and URI type reviews.
(13) All references have been identified as normative and/or informative
(14) No, There are no normative references to documents that are not
ready for advancement
(15) No, There are no downward normative references references
(16) No, Publication will not change the status of any RFCs
(17) No, there are No IANA considerations
(18) No, there are No IANA registries needing updated.