Skip to main content

Telechat Review of draft-ietf-taps-impl-16

Request Review of draft-ietf-taps-impl
Requested revision No specific revision (document currently at 18)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2023-09-05
Requested 2023-08-16
Authors Anna Brunstrom , Tommy Pauly , Reese Enghardt , Philipp S. Tiesel , Michael Welzl
I-D last updated 2023-09-05
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 Benson Muite
State Partially completed
Request Telechat review on draft-ietf-taps-impl by Internet Area Directorate Assigned
Posted at
Reviewed revision 16 (document currently at 18)
Result Ready w/issues
Completed 2023-09-05
I am an assigned INT directorate reviewer for
<draft-ietf-taps-impl-16.txt>. 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

Based on my review, if I was on the IESG I would ballot this document as NO OBJECTION.

The draft is a product of the transport services working
group and accompanies draft-ietf-taps-interface and
draft-ietf-taps-arch which describe interfaces to a
general communication layer and architecture for a 
general communication layer. Together with the 
implementation described in the current draft, these
would allow application developers to use middleware
that abstracts details of protocols such as TCP, UDP, DTLS,
SCTP, HTTP/2 and QUIC allowing portability and enabling flexibility
in adding new protocols.  This draft is informational
and contains advice for those implementing the API.


1) draft-ietf-taps-interface has a section on security
considerations for encrypted communication.  Will there
be a separate informational document on how to implement these?
Comparing levels of security to determine if a scheme is
acceptable would seem to be an important part of choosing
a communication protocol when encryption is needed.  It may 
be good to have rfc8922 as an informative reference.
However, it is fine to indicate that the document considers
only transport, not both transport and encryption.

2) Should suggestions for HTTP/3 be made in the introduction?
HTTP/3 is mentioned on page 11 but rfc9114 is not referenced.

3) On pg 29 consider formatting as

NewSentMessage<connection, messageData, messageContext, endOfMessage>

to avoid overly long line.

4) On pg 30 consider formatting as

MessageFramer.Parse(connection, minimumIncompleteLength, maximumLength)
             (messageData, messageContext, endOfMessage)

to avoid overly long line.

5) In section 10, an example using QUIC would be helpful, even
if encryption is ignored.

6) GitHub repositories may be moved or removed.  They also get
updated.  It may be worth referencing a specific commit
and additionally puting a copy of the referenced code on
services such as Zenodo or Software Heritage for archival
purposes as the IETF does not provide a code archiving service.