Last Call Review of draft-ietf-dnsop-svcb-https-07
review-ietf-dnsop-svcb-https-07-opsdir-lc-clarke-2021-08-16-00

Request Review of draft-ietf-dnsop-svcb-https
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2021-08-19
Requested 2021-08-05
Authors Benjamin Schwartz, Mike Bishop, Erik Nygren
Draft last updated 2021-08-16
Completed reviews Genart Last Call review of -07 by Dale Worley (diff)
Artart Last Call review of -07 by Cullen Jennings (diff)
Opsdir Last Call review of -07 by Joe Clarke (diff)
Tsvart Last Call review of -07 by Kyle Rose (diff)
Assignment Reviewer Joe Clarke 
State Completed
Review review-ietf-dnsop-svcb-https-07-opsdir-lc-clarke-2021-08-16
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/pJ3vouyVcPG1fMMjbIuW0I8Ouuk
Reviewed rev. 07 (document currently at 08)
Review result Ready
Review completed: 2021-08-16

Review
review-ietf-dnsop-svcb-https-07-opsdir-lc-clarke-2021-08-16

I have been assigned draft-ietf-dnsop-svcb-https to review on behalf of the Ops Directorate.  This document describes two new RR types (Service Binding [SVCB] and HTTPS).  From an operational standpoint, I think this document is ready, and I appreciate the attention paid to interoperability with approaches such as ECS, Alt-Svc, etc.

I did find two issues with the document, however.  On a more editorial front, I found a few references to "ServiceForm" and "AliasForm" (the former being in the appending, but the latter showing up in Security Considerations).  These seem to be left over from a former revision and probably should be ServiceMode and AliasMode now, correct?

Second, you use the term "SVCB-compatible" early on in Section 1, and you mention what its definition might be in Section 1.4, but I don't really get a clear picture of what makes an RR SVCB-compatible.  I feel the document should expound on the minimum requirements to be considered as such.