Telechat Review of draft-ietf-dprive-dtls-and-tls-profiles-09
review-ietf-dprive-dtls-and-tls-profiles-09-genart-telechat-dupont-2017-05-10-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dprive-dtls-and-tls-profiles-09.txt
Reviewer: Francis Dupont
Review Date: 20170509
IETF LC End Date: 20170302
IESG Telechat date: 20170511

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 I am afraid there are some abuses of not well known and not introduced
abbreviations. Unfortunately I know well the context so I had no problem
reading the document but perhaps it won't be the case for all readers
including in the intended audience... I tried to find them but likely
I missed a few.

 - ToC page 2 an 12 page 19: Acknowledgements -> Acknowledgments
 
 - 1 page 3: Intented -> intended in "Note that this document has the
      Intended status of Experimental."

 - 1 page 3: generalised -> generalized

 - 1 page 4: please expand SPKI abbrev

 - 6.1 page 10 and 6.3 page 12 ADN only: recognisable -> recognizable

 - 6.3 page 11: please expand SNI abbrev

 - 6.3 page 12 DANE and TLS entries, 11.1 page 18: e.g. -> e.g.,

 - 6.4 page 13: pleae expand HPKP abbrev (BTW it is
  HTTP Public Key Pinning cf RFC7469 (i.e.e, your reference) Figure 4,
  and it is not in RFC Editor abbrev list so expansion is required).

 -  6.5 page 13 (wording/style):
  "DNS clients issuing queries under an opportunistic profile which know
   authentication information for a given privacy-enabling DNS server
   MAY choose to try to authenticate the server using the mechanisms
   described here."

=> I suggest to add for instance an "and" before the "which" so it
becomes clear the subject of "know" is "DNS clients".

 - 6.5 page 13: authenticated, encrypted connection. ->
   authenticated and encrypted connection.

 - 9.2 page 16: another example of my concern: for me it is obvious
  then -TA means trust-anchor and -EE end-entity so the (short) text
  is enough to give a good idea of what it is about. I am not sure to
  not be an exception. Now you can answer you ask for a solid
  understanding of DANE/DANE Operations, etc, so eiher readers do not
  know the referenced documents so they should fix this, or they know
  and they should not have problems...

 - 11 page 18: i.e. -> i.e.,

I tried ispell with the British (vs standard/US) variant for English
and as I expected it gave some spelling errors too: optimize,
organizational, honor, maximizes. So I recommend to adopt for
the document US English (easier and it works better when an RFC
is cited as 99% of them are in US English). Now you do what you'd like
as soon as it is coherent in the whole document.

Thanks

Francis.Dupont@fdupont.fr