(1) This is requested to be a Proposed Standard. This is correctly indicated in the document.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
Enrollment over Secure Transport [RFC 7030] provides a REST style
interface for doing X.509 certificate enrollment as well as other
operations to support the enrollments. This document provides a
set of procedures to run this REST API using DTLS and CoAP rather
than TLS and HTTP.
Working Group Summary
Following adoption of the document progress in the WG was
smooth. The major issues in terms of formating and structure
were worked out prior to WG adoption.
Document Quality
The document has been reviewed and is directly build on
RFC 7030. Prior to the document going into last call three
different groups of implementers got together and had a
series of virtual inter-op events. These lead to several changes
and clarifications in the document as problems were identified.
Personnel
Jim Schaad acted as the Document Shepherd and Benjamin Kaduk was
the Responsible Area Director.
(3) I verified the following: All of the last call comments were addressed
in some manner, all of the necessary IANA considerations are present, none
of the examples appears to be incorrect from a cursory examination.
(4) I am happy with the review that the document has gotten.
(5) In my opinion the document does not need any broader review.
(6) The following item is a potential concern:
* The document is using tls-unique for the purpose of channel binding.
I know that there were discussions in the TLS WG about using this or
switching to something else. I cannot see that they ended up concluding
anything.
The authors have suggested that the correct way to deal with this issue
would be to create an update to RFC 7030, the base EST draft, to start using
the tls-exporter mechanism.
(7) All authors have confirmed that all appropritae IPR disclosures have been filed.
** van der Stok ** YES - 4/29/19
** Kampanakis ** YES - 5/7/19
** Richardson ** YES - 4/29/19
** Raza ** YES - 4/29/19
(8) There have been no IPR disclosures on this document.
(9) A reasonable percentage of the active members of the working group
have reviewed the document. The majority of the reviews were from about
six people.
(10) There have been no issues with the document. No future problems
are anticipated.
(11) There are a couple of nits with this document that I believe are correct.
1. There is a reference to an obolete document. RFC 5246 is referenced because
there is a difference between how "Finished" message is computed between
TLS 1.2 and TLS 1.3. It is appropriate for this to be called out.
2. The idnits tool calls out I-D.ietf-lamps-rfc5751-bis as being unused,
this is a bug in the tool and the draft is referenced.
3. There is a note to a non-RFC3849-compliant IPv6 address. This is a false
positive.
(12) There are no formal reviews needed for the document.
(13) All references are marked as normative or informative. I have no
issues with where they were placed.
(14) Three normative references are made to document currently in process.
All three of these documents have passed Working Group Last call.
(15) There is one downward reference to RFC 5967. This document is
already listed in the down ref registry.
(16) This is the first version of the document. There are no modifications
of any existing RFCs from this document.
(17) I walked the document looking for things that I thought needed to be
registered and then matched this against the registration requests.
(18) There are no new IANA registries created by this document.
(19) There are no formal language sections in the document.