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 Internet Area Directorate (intdir)
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-09-01
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 review of the document and its applicability on the current Internet (of things). I do not expect any problem but another pair of eyes will be welcome. Thank you.
Assignment Reviewer Tatuya Jinmei
State Completed
Request Telechat review on draft-ietf-taps-interface by Internet Area Directorate Assigned
Posted at
Reviewed revision 22 (document currently at 26)
Result Ready w/nits
Completed 2023-09-01
I am an assigned INT directorate reviewer for
<draft-ietf-taps-interface-22.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. This draft is generally well-written. Its motivation (providing a
modern network API framework taking into account advanced transport
technologies such as MPTCP, QUICK, or TLS) is reasonable. The design looks
sensible to me.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

1. In section 6.1, I suggest changing the following text:
   Note that an IPv6 address specified with a scope (e.g.
   2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to
   WithIPAddress with an unscoped address and WithInterface together.
   Note that a scoped IPv6 address specified with a scope zone ID (e.g.
   fe80::a420:461%en0) is equivalent to
   WithIPAddress with the address omitting the zone ID and WithInterface

The rationale of the suggestion is as follows:

  - While this may be a pedantic comment, the term (address) "scope" is not
  accurate according to RFC4007. In this context, "(scope) zone" or "(scope)
  zone ID" is a more accurate term. FYI, RFC4007 explains the difference
  between scopes and zones:

   Note that a zone is a particular instance of a topological region
   (e.g., Alice's site or Bob's site), whereas a scope is the size of a
   topological region (e.g., a site or a link).

  - The form "2001:db8:4920:e29d:a420:7461:7073:0a%en0" looks awkward in that
  it uses the <address>%<zone ID> format for a global address.  RFC 4007
  actually even states "The format is meaningless and should not be used for
  global addresses."  And, in fact, some implementations of getaddrinfo don't
  treat it as the "<address>%<zone ID>" form but as some awkward domain name
  (which usually results in an error).

2. In Section 6.1.2, I suggest changing:
   *  Specifying an interface on a RemoteEndpoint qualifies the scope of
      the Remote Endpoint, e.g., for link-local addresses.
   *  Specifying an interface on a RemoteEndpoint qualifies the scope zone of
      the Remote Endpoint, e.g., for link-local addresses.
For the same reason as the previous suggestion.

3. Likewise, in Section 6.2.11, I suggest changing this:
   Note that this property is not used to specify an interface scope for
   a particular endpoint.  Section 6.1.2 provides details about how to
   qualify endpoint candidates on a per-interface basis.
   Note that this property is not used to specify a scope zone for...

4. Mostly a pure editorial matter, I suggest removing the leading 0 from '0a'
in 2001:db8:4920:e29d:a420:7461:7073:0a (that appears in Sections 6.1 and
6.1.4) as it's redundant.

5. Very minor editorial nits follow (those are likely to be caught by the RFC
editor, but just in case)

- Section 3: s/a server/a server;/
   *  through listening on the Preconnection (i.e., passively opening,
      as in a server Section 7.2),
- Section 6: s/of they/or they/
   a multi-homed host, of they might correspond to local interfaces and
- Section 7.1: s/action Section 9.2.5/action (Section 9.2.5)/
   Connection establishment and transmission of the first Message can be
   combined in a single action Section 9.2.5.
- Section 8.1.4: s/packets Section 6.2/packets (Section 6.2)/
   A Transport Services API can request a protocol that supports sending
   keep alive packets Section 6.2.10.  If this property is Numeric, it
- Section s/It/It is/
   can receive.  It specified as the number of bytes.
- Section is this sentence perhaps incomplete?
   In order to set
   these properties, the add and get actions on the MessageContext.  To
- Section s/prefered/preferred/
   avoid network layer fragmentation when transport segmentation is
- Section s/endpount/endpoint/
   source fragmentation of Messages.  When running over IPv4, setting
   this property to true will result in a sending endpount setting the
- Section 13: s/whith/with/
   objects allows an application to determine whith protocol(s) and
- Section 13: s/Tranport/Transport/
   path(s) are in use.  A Tranport Services system SHOULD provide a