Skip to main content

Last Call Review of draft-ietf-taps-impl-15

Request Review of draft-ietf-taps-impl
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team DNS Directorate (dnsdir)
Deadline 2023-04-14
Requested 2023-03-30
Authors Anna Brunstrom , Tommy Pauly , Reese Enghardt , Philipp S. Tiesel , Michael Welzl
I-D last updated 2023-04-11
Completed reviews Dnsdir Telechat review of -16 by Peter van Dijk (diff)
Intdir Telechat review of -16 by Benson Muite (diff)
Artart Early review of -12 by Bron Gondwana (diff)
Dnsdir Last Call review of -15 by Peter van Dijk (diff)
Genart Last Call review of -15 by Dale R. Worley (diff)
Opsdir Last Call review of -15 by Linda Dunbar (diff)
Assignment Reviewer Peter van Dijk
State Completed
Request Last Call review on draft-ietf-taps-impl by DNS Directorate Assigned
Posted at
Reviewed revision 15 (document currently at 18)
Result Ready w/nits
Completed 2023-04-11
This document is written very clearly. I much appreciate the phrase "This is
not meant to restrict implementations from structuring racing candidates

In, "... send DNS queries for both A (IPv4) and AAAA (IPv6) records
...", this assumes no other address types will exist in the future. RFC8499
uses "address records" to refer to A/AAAA and any future variants implicitly,
pointing out that RFC2181 informally says "(A, AAAA, etc)". I'm not aware of a
more useful formal reference than 8499, so perhaps something like ".. send DNS
queries for address records, which currently means sending A (IPv4) and AAAA
(IPv6) queries ..."?

While ietf-taps-interface mentions SRV records briefly, this document does not.
An SRV record set could cause a single RemoteSpecifier to map to multiple
names. HTTPS and SVCB records can also cause indirection to multiple names (and
even transport indications). I do not think the document should go into detail
on all of these, but, as with address records, perhaps it can mention that DNS
lookups can involve an extra layer of indirection, and provide SRV, HTTPS and
SVCB as current examples.

Typo in "intefaces"

In 4.3.2, "should follow the Happy Eyeballs algorithm described in [RFC8305]."
- should this be a "SHOULD"? (I noticed a few other lowercase "should"s as

I did not review sections 5, 6, 7 and 8 (other than a cursory check that they
do not mention DNS or name resolving).

In 9.1, ".. resolution answers (A and AAAA queries, for example)" - the queries
are not cached, (part of) their responses is cached. Perhaps ".. resolution
answers (from A and AAAA queries, for example"

No comments on section 10, 11.

Should 12.2 mention DNSSEC? I can very much understand it if you say no :-)