Last Call Review of draft-ietf-dprive-dtls-and-tls-profiles-09
review-ietf-dprive-dtls-and-tls-profiles-09-opsdir-lc-vyncke-2017-05-22-00

I have reviewed draft-ietf-6man-rfc4291bis-07 as part of the Operational
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed in last
call may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last call
comments.

From the abstract: 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. DPRIVE (DNS Private exchange) aims at enhancing DNS
privacy by encrypting the DNS traffic (DNSsec only provides
authentication/integrity).

There are two profiles: strict and opportunistic. The latter allows normal DNS
operations as a fallback, which is key for successful deployment.

This document in section 6  compares the SIX different authentication
mechanisms and gives some guidelines with a lot of SHOULD and MAY and little
MUST. Unsure whether it makes the implementers' task easy. Section 8 is more
directive and more useful.

Section 7.3 is mainly about the legacy DHCP server for the legacy IPv4. No word
about IPv6 and no word about RFC 8106 (DNS info for SLAAC).

Overall, there are no discussion about the performance (latency, load of
clients/servers) of one authentication mechanism compared to the others, no
discussion about resilience (i.e. if one server fails, for example in the PKIX
cert chains) and I believe that performance and resilience to network error
could be useful for the implementer/architect.

As a reader, I regret that this document combines two aspects: description of
the profiles but also how to extend one TLS authentication method to DTLS... I
would have preferred having two documents. But, this is mainly about
readability.

Hope this helps

-éric