Skip to main content

Telechat Review of draft-ietf-taps-interface-22

Request Review of draft-ietf-taps-interface
Requested revision No specific revision (document currently at 26)
Type Telechat Review
Team DNS Directorate (dnsdir)
Deadline 2023-09-01
Requested 2023-08-21
Requested by Éric Vyncke
Authors Brian Trammell , Michael Welzl , Reese Enghardt , Gorry Fairhurst , Mirja Kühlewind , Colin Perkins , Philipp S. Tiesel , Tommy Pauly
I-D last updated 2023-08-27
Completed reviews Secdir Telechat review of -22 by Sean Turner (diff)
Dnsdir Telechat review of -22 by Matt Brown (diff)
Intdir Telechat review of -22 by Tatuya Jinmei (diff)
Secdir Early review of -13 by Sean Turner (diff)
Artart Early review of -13 by Robert Sparks (diff)
Artart Last Call review of -20 by Robert Sparks (diff)
Genart Last Call review of -20 by Thomas Fossati (diff)
Secdir Last Call review of -20 by Sean Turner (diff)
Please have a quick light review of the document and focus on any part about DNS. Thank you.
Assignment Reviewer Matt Brown
State Completed
Request Telechat review on draft-ietf-taps-interface by DNS Directorate Assigned
Posted at
Reviewed revision 22 (document currently at 26)
Result Ready
Completed 2023-08-27
I have been selected as the DNS Directorate reviewer for this draft. The DNS
Directorate seeks to review all DNS or DNS-related drafts as they pass through
IETF last call and IESG review, and sometimes on special request. The purpose
of the review is to provide assistance to the ADs. For more information about
the DNS Directorate, please see

This draft is the middle (API defining) document in a set of 3 related drafts
(the others being I-D.ietf-taps-arch, I-D.ietf-taps-impl) which together seek
to define a new Transport Services architecture which provides applications
with improved functionality (primarily faster deployment of new transport
protocols and protocol features without application changes).

The only relevant DNS content within the draft is in s6.1 where a hostname
and/or service name can be used in the specification of a remote endpoint. In
constrast to existing transport APIs (e.g. BSD/POSIX) where resolution occurs
prior to the transport API being invoked, the new Transport Services API
encourages and expects that resolution will now commonly be performed within
the new implementation to provide maximum flexibility during connection
establishment (although endpoint specification by IP address remains fully
supported too).

While a notable change in when resolution occurs on the host, from the DNS
system perspective, the resolution process remains straightforward and
unchanged from the perspective of all other elements of the system, noting the
brief discussion in s13 about the privacy implications that can arise from the
timing of resolution. The subsequent draft (I-D.ietf-taps-impl) has further
discussion of resolution implications of the API which is also useful.

All up, the proposed architecture overall seems reasonable from a quick read;
and specifically from the perspective of this individual draft covering the API
itself the proposed usage of DNS hostname and service names looks reasonable
and raises no concerns for me.