Telechat Review of draft-ietf-taps-interface-22
review-ietf-taps-interface-22-intdir-telechat-jinmei-2023-09-01-00

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
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. 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.
to:
   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
   together.

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.
to:
   *  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.
to:
   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 8.1.11.3: s/It/It is/
   can receive.  It specified as the number of bytes.
- Section 9.1.2.2: is this sentence perhaps incomplete?
   In order to set
   these properties, the add and get actions on the MessageContext.  To
- Section 9.1.3.9: s/prefered/preferred/
   avoid network layer fragmentation when transport segmentation is
   prefered.
- Section 9.1.3.10 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