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

[Lars Eggert <[e-mail]>]

Hi,

thanks for the replies. I'll trim my response to only those items where I still have questions.

On Nov 14, 2023, at 19:17, Tommy Pauly <tpauly=[e-mail]> wrote:
>> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <[e-mail]> wrote:
>> ### 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.”

why is this not a MUST, i.e., when would it be appropriate to not specify this in an IETF-stream RFC?

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

How would a developer know what the default endpoint was?

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

I'd argue that "safer" is in the eye of the beholder. I'll certainly agree that TAPS is trying to provide a more principled and more abstract interface to transport functions (also also that the socket API's platform-dependendness is terrible), but at least a developer with sufficient motivation can concretely implement their desired behavior. I remain unconvinced that an abstraction like TAPS will lead to a stable developer experience esp. over time and across platforms.

Thanks,
Lars