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 . 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