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

[Tommy Pauly <[e-mail]>]

Hi Lars,

Thanks for your detailed review! The authors appreciate the helpful comments.

The authors have just posted a -23 version that addresses the IESG comments, including your DISCUSS. https://www.ietf.org/archive/id/draft-ietf-taps-interface-23.html

Below, I’ve added inline responses to each DISCUSS point.

Best,
Tommy (on behalf of the authors)

> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <[e-mail]> wrote:
> 
> 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.

This now reads: "For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in an IETF document published in the RFC Series after IETF review.”

> 
> ### 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?

This is addressed with https://github.com/ietf-tapswg/api-drafts/pull/1456

This updates the text to allow the “Resolve” functionality for Rendezvous to be used generically to enumerate interfaces/addresses.

> 
> ### 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?

These comments around protocol-specific endpoints are addressed with https://github.com/ietf-tapswg/api-drafts/pull/1408 and https://github.com/ietf-tapswg/api-drafts/pull/1451

The text now clarifies that the values for the protocol scoping here are implementation-provided enumerations.

"To scope an Endpoint to apply conditionally to a specific transport
 protocol (such as defining an alternate port to use when QUIC
 is selected, as opposed to TCP), an Endpoint can be
 associated with a protocol identifier. Protocol identifiers are
 objects or enumeration values provided by the Transport
 Services API, which will vary based on which protocols are
implemented in a particular system."

The reason to show one protocol being specified with an override is to show how there’s a default endpoint that the connection should use, and it should conditionally load an alternate when using a particular protocol. This then doesn’t constrain the protocol stacks being used, but only customizes the endpoint in case a particular protocol is loaded.

> 
> ### 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?

Please see comments on https://github.com/ietf-tapswg/api-drafts/issues/1334

"Complex interactions may exist between socket options in the existing BSD sockets API.
There are also implementations of TAPS systems available, at least one of which is fairly comprehensive.
Future interactions of properties of future protocols are also unclear in the BSD sockets API.

In a sense, we offer a safer set of options than BSD sockets, as we have constrained the generic ones to the set of properties that do not constrain selection amongst existing protocols. Everything that is protocol-specific goes in its own protocol namespace and only applies when this protocol is selected. The intent is for future protocol-specific options to also be categorized that way. We cannot guarantee that no future transport protocol will somehow be constrained by our generic properties, but the analysis in our prior RFCs (specifically the minset RFC) leads us to believe that we have chosen a workable subset."

> 
> ### 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`?

Yes, thank you; we clarified this in the text by adding a reference to the conn priority with https://github.com/ietf-tapswg/api-drafts/pull/1393

> 
> ### 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.)

This is addressed with https://github.com/ietf-tapswg/api-drafts/pull/1397, which clarifies:

"If the contradicting Message Property
 cannot be supported by the Connection (such as requiring reliability
 on a Connection that uses an unreliable protocol), the `Send` action
 will result in a `SendError` event."
>