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

Tommy Pauly <tpauly@apple.com> Tue, 12 December 2023 17:48 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB05C14F75F for <taps@ietfa.amsl.com>; Tue, 12 Dec 2023 09:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVKcpWF4Dy4L for <taps@ietfa.amsl.com>; Tue, 12 Dec 2023 09:48:18 -0800 (PST)
Received: from ma-mailsvcp-mx-lapp01.apple.com (ma-mailsvcp-mx-lapp01.apple.com [17.32.222.22]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC08C14F74E for <taps@ietf.org>; Tue, 12 Dec 2023 09:48:18 -0800 (PST)
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma-mailsvcp-mx-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5K010Q0ES5YR10@ma-mailsvcp-mx-lapp01.apple.com> for taps@ietf.org; Tue, 12 Dec 2023 09:48:17 -0800 (PST)
X-Proofpoint-ORIG-GUID: E_580FexmOCFp_N2CoOTEahrVttNT7eZ
X-Proofpoint-GUID: E_580FexmOCFp_N2CoOTEahrVttNT7eZ
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-12_11:2023-12-11, 2023-12-12 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 suspectscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 malwarescore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312120135
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wJ0yopz0tEiMo8GBa49FrMInreuHgrP5vOIsFSJO3CQ=; b=wN8PgrFFhWGjhwmsoATPktCdWtMAXvFvXsEMCZqc/kB1bHIF0Tbj4ZvsOsLGz9MVHRtN SvSBH47FruBVQnu9PLKxQjZzqTaTEZEips+l1hFAcmr5uV1FhZaafPQiKbSujfDYrEGX yTYeoBFN6ZHWG2hmqI9h/PpTmdof5OQmgNxDXoUuqzWK8I8ylPDff6OSopl0C0LsWrZs ldyNg8vs4zPooEg2jOzs1Qy3Y0dTyIJKuHwTPVPOZOsHb7PpOrDVL8H0Rg792UqMh6Ny XdBwkhUaUQzHTWZKvVaUfqGUiu89FYYDfO4HE5En6XR7zmWbMZ5pZlE9G/E9aEI7aUop Tg==
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5K00QY0ESD6A60@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 12 Dec 2023 09:48:14 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S5K00J00EPKB000@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 12 Dec 2023 09:48:13 -0800 (PST)
X-Va-A:
X-Va-T-CD: ce2ee51e2cf44ff62f32daef8e80c9a6
X-Va-E-CD: af5bdc872ffde92b8e291b969cf523ac
X-Va-R-CD: ec08cce7c0fef839f4c668287a712400
X-Va-ID: f9c0c0f6-f642-49f3-a1f8-d4de4f746d7f
X-Va-CD: 0
X-V-A:
X-V-T-CD: ce2ee51e2cf44ff62f32daef8e80c9a6
X-V-E-CD: af5bdc872ffde92b8e291b969cf523ac
X-V-R-CD: ec08cce7c0fef839f4c668287a712400
X-V-ID: 55829ea7-0dec-428d-b5a6-76b91efbd032
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-12_11:2023-12-11, 2023-12-12 signatures=0
Received: from smtpclient.apple ([17.11.189.131]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S5K00EHQESD3000@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 12 Dec 2023 09:48:13 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <2FF2518E-C6E6-4BFF-9521-05AB8FE036F0@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_03017073-ECAF-40FB-9533-051CB968BD26"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Tue, 12 Dec 2023 09:48:03 -0800
In-reply-to: <181529E6-CFDC-4969-AABE-502E1C8A1325@eggert.org>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Anna Brunström <anna.brunstrom@kau.se>
To: Lars Eggert <lars@eggert.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>, Michael Welzl <michawe@ifi.uio.no>
References: <169408439315.13814.3746604129872399062@ietfa.amsl.com> <A1CF408B-C691-4003-A989-D0F3284B4E2F@apple.com> <181529E6-CFDC-4969-AABE-502E1C8A1325@eggert.org>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/nJTqmwQPJY9B50V4v2rTL9x__p0>
Subject: Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Dec 2023 17:48:19 -0000

Hi Lars,

Responses inline.


> On Dec 12, 2023, at 3:38 AM, Lars Eggert <lars@eggert.org> 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=40apple.com@dmarc.ietf.org> wrote:
>>> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <noreply@ietf.org> 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?

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