[Last-Call] Intdir telechat partial review of draft-ietf-taps-impl-16

[Benson Muite via Datatracker <[e-mail]>]

Review is partially done. Another assignment may be needed to complete it.

Reviewer: Benson Muite
Review result: Ready with Issues

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
https://datatracker.ietf.org/group/intdir/about/.

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

Summary:
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.

Comments:

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

                        MessageFramer
                              |
                              V
NewSentMessage<connection, messageData, messageContext, endOfMessage>

to avoid overly long line.

4) On pg 30 consider formatting as

MessageFramer.Parse(connection, minimumIncompleteLength, maximumLength)
                                 |
                                 V
             (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.