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

[Michael Welzl <[e-mail]>]

> On Dec 12, 2023, at 6:48 PM, Tommy Pauly <[e-mail]> wrote:
> 
> Hi Lars,
> 
> Responses inline.
> 
> 
>> On Dec 12, 2023, at 3:38 AM, Lars Eggert <[e-mail]> wrote:
>> 
>> 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?
> 
> Yeah, I think this could be a MUST.
> 
> Brian, Michael, what do you think?

I dug into the issues and found this:  https://github.com/ietf-tapswg/api-drafts/issues/1330 <https://github.com/ietf-tapswg/api-drafts/issues/1330>
where we have closed this as “overtaken by events” - so I struggle to find the discussion that led to the specific sentence that was added. I believe we just left the SHOULD as it was, and fixed this to refer to "the RFC series after IETF review".

History and github issues aside, I completely agree, a MUST would make more sense here. Let’s do this.

Cheers,
Michael



> 
>> 
>>>> ### 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?
> 
> The “default” endpoint is the one that the application developer themselves provided that didn’t include a protocol-specific binding. In the example above, that’s the port 443 endpoint, while there’s a protocol-bound endpoint that uses port 8443.
> 
>> 
>>>> ### 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.
> 
> It’s certainly fair to have a different opinion on how the usefulness and stableness of various transport/socket options will play out over time.
> 
> Personally, I think the best philosophy for setting options on a connection / socket should be to set the minimum set required, so as to not unnecessarily constrain the behavior of the stack. If an application sets many options that can eventually only be satisfied by a set of existing protocols, and not some future as-yet-undesigned protocols, then indeed the connections will be constrained to use the existing protocols that work. But apps that only set the options they strictly need will allow for more variation.
> 
> Are there specific changes you are thinking of for the document?
> 
>> 
>> Thanks,
>> Lars
>> 
> 
> 
> Thanks,
> Tommy
>> 
>