Martin: many thanks for this review – I have reported it in my No Objection ballot, as I agree with you especially on that some more context would help a reader. Looking forward to the authors’ and
wg’s reply.
Francesca
From: last-call <last-call-bounces@xxxxxxxx> on behalf of Martin Dürst via Datatracker <noreply@xxxxxxxx>
Date: Wednesday, 13 July 2022 at 11:07
To: art@xxxxxxxx <art@xxxxxxxx>
Cc: add@xxxxxxxx <add@xxxxxxxx>, draft-ietf-add-svcb-dns.all@xxxxxxxx <draft-ietf-add-svcb-dns.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: [Last-Call] Artart last call review of draft-ietf-add-svcb-dns-06
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
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
