| Thank you, Ben!
— Carlos Pignataro, https://carlos.pignataro.net“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."
On Tue, Apr 19, 2022 at 11:30 AM Carlos Pignataro via Datatracker < noreply@xxxxxxxx> wrote: Reviewer: Carlos Pignataro
Review result: Ready with Nits
I am an assigned INT directorate reviewer for draft-ietf-dnsop-svcb-https.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.
This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types
to facilitate the lookup of information needed to make connections to network
services, such as for HTTP origins.
This document is clear and comprehensive. Specifically, rev -08 improved
structure, terminology, and readability. It seems ready modulo some nits.
Editorial suggestions:
* s/followup/follow-up/g
* " * Fallback to the the client's non-Alt-Svc connection behavior" -->
duplicate "the" * "IANA from the "Resource Record (RR) TYPEs" subregistry" -->
looks like that's a registry, not sub-registry (same with other parts of the
IANA sections) * s/e.g./e.g.,/g * "2 octet field" -> "2-octet field"
Thanks for flagging these style issues. I've proposed these changes in a Github Pull Request [1], except for the comma changes (which appear to be a contested point of English style).
Editorially, I find this construct a bit interesting -- indirections, and
wonder if a bit more context can be added to S7.5. 7.5. "mandatory"
See Section 8.
8. ServiceMode RR compatibility and mandatory keys
Yes, this is a bit odd, as is the forward reference for "ech". However, it avoids disrupting the flow of Section 7 with extensive subsections, and helps to highlight important material.
I have no strong opinions about how this ought to be laid out in the document.
Thank you for your consideration,
Carlos.
|
Attachment:
signature.asc
Description: Message signed with OpenPGP
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
