[Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-taps-interface-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# GEN AD review of draft-ietf-taps-interface-22

CC @larseggert

Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Uohwi2MvOOwswMfkE5w4mt9IZKE).

## Discuss

### Section 4.1, paragraph 8
```
     *  For IETF protocols, the name of a Protocol-specific Property
        SHOULD be specified in an IETF document published in the RFC
        Series.
```
For IETF protocols, i.e., protocols published on the IETF RFC stream,
those names must IMO be also specified in IETF-stream RFCs. I see no
reason to let other RFC streams make definitions for IETF protocols.

### Section 6.1, paragraph 13
```
     *  Interface name (string), e.g., to qualify link-local or multicast
        addresses (see Section 6.1.2 for details):

     LocalSpecifier.WithInterface("en0")
```
How does an application learn which interface name strings are
allowed/available on the system? The API doesn't seem to provide this
information. Also, based on the examples, there seem to be special
names such as "any" - where are those defined and how are conflicts
with names used on the system avoided?

### Section 6.1.3, paragraph 6
```
     In order to scope an alias to a specific transport protocol, an
     Endpoint can specify a protocol identifier.

     AlternateRemoteSpecifier.WithProtocol(QUIC)
```
This is the first and only time protocol identifiers are used. What
are they defined to be?

### Section 6.1.3, paragraph 9
```
     The following example shows a case where example.com has a server
     running on port 443, with an alternate port of 8443 for QUIC.

     RemoteSpecifier := NewRemoteEndpoint()
     RemoteSpecifier.WithHostname("example.com")
     RemoteSpecifier.WithPort(443)

     QUICRemoteSpecifier := NewRemoteEndpoint()
     QUICRemoteSpecifier.WithHostname("example.com")
     QUICRemoteSpecifier.WithPort(8443)
     QUICRemoteSpecifier.WithProtocol(QUIC)

     RemoteSpecifier.AddAlias(QUICRemoteSpecifier)
```
Why does the `RemoteSpecifier` definition not contain a `WithProtocol`
clause for TCP/TLS? And what would that look like, given that TCP/TLS
is a protocol combination?

### Section 6.2, paragraph 0
```
  6.2.  Specifying Transport Properties
```
This section defines a boatload of different properties, many of which
are interacting with each other due to how our current transport
protocols are implemented. Future interactions, due to future
transport protocols potentially becoming available, are undefined. I
question how a potential programmer is supposed to make informed
choices here without needing to be aware of all of this
background/baggage?

### Section 8.1.5, paragraph 4
```
     Default:  Weighted Fair Queueing (see Section 3.6 in [RFC8260])

     This property specifies which scheduler should be used among
     Connections within a Connection Group, see Section 7.4.  A set of
     schedulers is described in [RFC8260].
```
What is this scheduler scheduling? 7.4 is silent on this. I'm guessing
this is related to `connPriority`?

### Section 9.1.3, paragraph 9
```
     If a Message Property contradicts a Connection Property, and if this
     per-Message behavior can be supported, it overrides the Connection
     Property for the specific Message.  For example, if reliability is
     set to Require and a protocol with configurable per-Message
     reliability is used, setting msgReliable to false for a particular
     Message will allow this Message to be sent without any reliability
     guarantees.  Changing the msgReliable Message Property is only
     possible for Connections that were established enabling the Selection
     Property perMsgReliability.
```
How is this going to work in the opposite case, i.e., if an unreliable
connection was set up and then some messages are passed in which
require reliable transmission? At connection open, the stack may have
chosen a transport protocol that cannot support reliable
transmission? (Also, I think this general principle of message >
connection has other issues for other properties.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## Comments

I'm likely to abstain on this document, because I disagree that
Proposed Standard is appropriate. This document (and its companion)
outline as extremely intricate design, and I am not aware of any
attempts to implement even a sizable subset of it. Given the various
interactions between the API components and the attributes and
behaviors of existing transport protocols (and their implementation),
I strongly believe that in-depth experimentation with actual
implementations is needed before we can have the confidence in the
design we'd like to see for publication on the Standards Track.

### Section 1.1, paragraph 23
```
     *  String: Instances are represented in a way that is common to the
        programming language, e.g.  UTF-8.
```
If the intend of this API is to be language independent, it can't
really fall back on assuming a defined string representation of a
given language. Instead, it should define how strings are encoded.

### Section 4.1, paragraph 1
```
     Transport Properties are referred to by property names.  For the
     purposes of this document, these names are alphanumeric strings in
     which the following characters are allowed: lowercase letters a-z,
     uppercase letters A-Z, digits 0-9, the hyphen -, and the underscore
     _. These names serve two purposes:
```
This allows property names that are indistinguishable from integers.
Is that a bug or a feature? Also, are they case-sensitive?

### Section 4.1, paragraph 7
```
     Namespaces for each of the keywords provided in the IANA protocol
     numbers registry (see https://www.iana.org/assignments/protocol-
     numbers/protocol-numbers.xhtml) are reserved for Protocol-specific
     Properties and MUST NOT be used for vendor or implementation-specific
     properties.  Terms listed as keywords as in the protocol numbers
     registry SHOULD be avoided as any part of a vendor- or
     implementation-specific property name.
```
This doesn't work if vendors use property names that the IETF later
adds to the IANA registry. Suggest to instead define a
vendor-specific prefix/name here, ideally one that is illegal for the
IANA registry.

### Section 6, paragraph 6
```
     If more than one Local Endpoint is specified on a Preconnection, then
     all the Local Endpoints on the Preconnection MUST represent the same
     host.  For example, they might correspond to different interfaces on
     a multi-homed host, of they might correspond to local interfaces and
     a STUN server that can be resolved to a server reflexive address for
     a Preconnection used to make a peer-to-peer Rendezvous.
```
In order to make this MUST enforceable, a concrete definition of
what "represent the same host" means is IMO needed. Is this a static
or dynamic check?

### Section 6, paragraph 6
```
     If more than one Remote Endpoint is specified on the Preconnection,
     then all the Remote Endpoints on the Preconnection should represent
     the same service, to the extent that the application and the
     Transport Services system can validate that the Remote Endpoints are
     indeed the same service.  For example, the Remote Endpoints might
     represent various network interfaces of a host, or a server reflexive
     address that can be used to reach a host, or a set of hosts that
     provide equivalent local balanced service.
```
It's a lowercase "should", but I still have no idea how a programmer
or the API would verify whether all endpoints are the same service.
Seems unenforceable.

### Section 6.1, paragraph 8
```
     *  Port (a 16-bit integer):
```
Previously, only length-unlimited integer types were defined?

### Section 6.1, paragraph 10
```
     *  Service (an identifier that maps to a port; either the name of a
        well-known service, or a DNS SRV service name to be resolved):

     RemoteSpecifier.WithService("https")
```
I assume when you say "name of a well-known service" you mean "service
name associated with a port number on
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml"?
It would be good to explicitly say that. Also, there seems to be an
assumption that the OS provides `getservbyname` or similar - is this
a reasonable assumption?

### Section 6.1.1, paragraph 4
```
     RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
```
It's a design choice to not overload `WithIPAddress` here and instead
define `WithMulticastGroupIP`. I'd have overloaded, in order to avoid
the need for error handling if the wring type of IP address is passed
in.

### Section 6.1.1, paragraph 3
```
     RemoteSpecifier.WithTTL(TTL)
```
I'd point out that since IPv6, we switched to "hop count" for the
term, to make it clear it's not actually a time value
(anymore). Suggest to use the more modern term?

### Section 6.1.4, paragraph 3
```
     RemoteSpecifier := NewRemoteEndpoint()
     RemoteSpecifier.WithHostname("example.com")
     RemoteSpecifier.WithService("https")
```
Does `WithService("https")` implicitly set `WithProtocol(TCP/TLS)` or
is that missing from the example? If it does, which other such
implications are defined?

### Section 6.2.5, paragraph 0
```
  6.2.5.  Use 0-RTT Session Establishment with a Safely Replayable Message
```
This is an awfully specific preference compared to all the others.
Maybe make it a bit less specific by calling it "Initial Message will
be Safely Replayable" without mentioning a specific use case such as
0-RTT? (Or maybe even define a "replayable" message flag, and only do
0-RTT if that is set on the first message.)

### Section 6.2.7, paragraph 4
```
     This property specifies the application's need for protection against
     corruption for all data transmitted on this Connection.  Disabling
     this property could enable later control of the sender checksum
     coverage (see Section 9.1.3.6).
```
I don't know what "enable later control of the sender checksum
coverage" is supposed to mean. Also, how does this
(and `fullChecksumRecv`) intersect with `reliability`, which also
talks about corruption?

### Section 8.1.1, paragraph 3
```
     Type:  Integer (non-negative) or Full Coverage

     Default:  Full Coverage
```
How is "Full Coverage" expressed?

### Section 8.1.8, paragraph 4
```
     Numeric values of these properties specify an upper-bound rate that a
     transfer is not expected to exceed (even if flow control and
     congestion control allow higher rates), and/or a lower-bound rate
     below which the application does not deem it will be useful.  These
     are specified in bits per second.  The enumerated value Unlimited
     indicates that no bound is specified.
```
Over what timescale, or is this supposed to apply to instantaneous
bandwidth? Because an app can control how much data over time to feed
into a connection, but cannot usually know what send rate that
results in.

### Section 8.1.11.1, paragraph 3
```
     This property, if applicable, represents the maximum Message size
     that can be sent without incurring network-layer fragmentation at the
     sender.  It is specified as the number of bytes.  It exposes a value
     to the application based on the Maximum Packet Size (MPS) as
     described in Datagram PLPMTUD [RFC8899].  This can allow a sending
     stack to avoid unwanted fragmentation at the network-layer or
     segmentation by the transport layer.
```
Is this supposed to vary as PMTUD happens?

### Section 9.2.1, paragraph 2
```
     messageData := "hello"
     Connection.Send(messageData)
     The interpretation of a Message to be sent is dependent on the
     implementation, and on the constraints on the Protocol Stacks implied
     by the Connection’s transport properties.  For example, a Message may
     be a single datagram for UDP Connections; or an HTTP Request for HTTP
     Connections.
```
I don't think you mean "UDP datagram here", since that would include
the UDP header. UDP payload?

### Section 9.2.6, paragraph 2
```
     A Transport Services system gives no guarantees about how its
     expression of relative priorities will be realized.  However, the
     Transport Services system will seek to ensure that performance of
     relatively-prioritized Connections and Messages is not worse with
     respect to those Connections and Messages than an equivalent
     configuration in which all prioritization properties are left at
     their defaults.
```
Without defining what is meant by "performance" in this case, it's not
possible to know what "not worse" means. (Or how a transport system
might seek to ensure that.)

### Section 9.3.2, paragraph 1
```
     Each call to Receive will be paired with a single Receive event,
     which can be a success or an error.  This allows an application to
     provide backpressure to the transport stack when it is temporarily
     not ready to receive Messages.
```
Isn't the act of not reading and the resulting buffer growth already
providing this backpressure?

### Too many authors

The document has eight authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms `natively` and `native`; alternatives might be `built-in`,
   `fundamental`, `ingrained`, `intrinsic`, `original`

### IP addresses

Found IP block or address not inside RFC5737/RFC3849 example ranges:
`232.1.1.1`.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 9.1.3.9, paragraph 4
```
-    prefered.
+    preferred.
+          +
```

#### Section 9.1.3.10, paragraph 3
```
-    this property to true will result in a sending endpount setting the
-                                                        ^
+    this property to true will result in a sending endpoint setting the
+                                                        ^
```

### Outdated references

Reference `[RFC8229]` to `RFC8229`, which was obsoleted by `RFC9329` (this may
be on purpose).

### Grammar/style

#### Section 1.1, paragraph 2
```
ming language, e.g. UTF-8. If the intend of this API is to be language indep
                                  ^^^^^^
```
The word "intend" is a verb. Did you mean the noun "intent"?

#### Section 2, paragraph 2
```
 the kind of transport, can be bi-directional or unidirectional, and that ca
                               ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 6.1.2, paragraph 3
```
tener := Preconnection.Listen() Join an Source-Specific Multicast group in re
                                     ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 8, paragraph 9
```
lgorithm); to prefer immediate acknowledgment from the peer endpoint when su
                               ^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text.

#### Section 8.1.6, paragraph 11
```
onal Message Context, which allows to add Message Properties, identify Send
                                   ^^^^^^
```
Did you mean "adding"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

#### Section 8.1.10, paragraph 4
```
 In these cases, they add an additional transformation to further encode or e
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This phrase might be redundant. Consider either removing or replacing the
adjective "additional".

#### Section 9.3.2.3, paragraph 3
```
paths and are not necessarily privacy sensitive. Still, some information cou
                              ^^^^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 9.3.2.3, paragraph 3
```
l, some information could be privacy sensitive because it might reveal usage
                             ^^^^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 14, paragraph 5
```
cts (see Section 6.2) that are pre-configured with frequently used sets of p
                               ^^^^^^^^^^^^^^
```
Do not mix variants of the same word ("pre-configure" and "preconfigure")
within a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool