Reviewer: Martin Dürst Review result: On the Right Track I'm the assigned reviewer for the App Area for the draft "Service Binding Mapping for DNS Servers" (draft-ietf-add-svcb-dns). I have mainly reviewed -05, but also checked the diff to -06. This is an app area review, and so my concerns are mostly from an application perspective. Summary: As far as I was able to tell (not an expert on DNS, and didn't check [SVCB], which is required reading for implementers), the document is technically okay. But I'm not sure readers will understand where to use this information. Major: The main issue with the document is that there is no explanation on who/where/when this information is to be queried and used. Is this the job of an application (e.g. a web browser or an email user agent)? Is this the job of a resolver in an OS? Is it the job of DNS libraries, e.g. in programming languages such as Ruby and Python? Who/what decides which of the alternatives is used if there are multiple? How should (or shouldn't) DNS queries for SVCB records be combined with queries for other records? While I understand that there may be many different contexts, a pointer to a document describing various potential scenarios or so could help a lot. The addition of a bullet list to section 6, Limitations, is an improvement, but it would be way better if there were more such information, and if that information were worded in a positive way, and if that information were given upfront, or if there were at least a pointer up front to such information. Another idea would be a separate document explaining the possibilities and giving recommendations or proposals. Also, while the above considerations are mainly on the using side, some additional considerations for the publishing side are also desirable. Minor: Section 4.2: "This key is automatically mandatory for this binding. This means that a client that does not respect the "port" key MUST ignore any SVCB record that contains this key. (See Section 7 of [SVCB] for the definition of "automatically mandatory".)" Summary: "Mandatory means MUST ignore" -> This just doesn't make sense. Please improve the wording so that it becomes clear what you want to say on first reading. Section 4.3: "Future SvcParamKeys might also be applicable.": It's totally unclear HOW they might (or might not) be applicable. Section 5.1 ""dohpath" is a single-valued SvcParamKey whose value (both in presentation and wire format) MUST be a URI Template in relative form ([RFC6570], Section 1.1) encoded in UTF-8 [RFC3629].": It would be good to add that this essentially makes the URI Template an IRI [RFC3987] Template. Nits: Section 3.1: "places the port number in an additional *a* prefix" -> "places the port number in an additional prefix" Section 4.1: "All keys specified for use with the HTTPS record": Please add a reference here. Section 4.2: "The client is being used with a DNS server that it trusts not attempt this attack." -> "The client is being used with a DNS server that it trusts not _to_ attempt this attack." Reference [Attrleaf] is an RFC, but is the only RFC that uses a name rather than an RFC number as the reference label. Please streamline. Regards, Martin. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
