Telechat Review of draft-ietf-taps-interface-22
review-ietf-taps-interface-22-dnsdir-telechat-brown-2023-08-27-00

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 https://wiki.ietf.org/en/group/dnsdir

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.