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.