Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)
Tommy Pauly <tpauly@apple.com> Thu, 14 December 2023 14:13 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 59C4FC14F618 for <taps@ietfa.amsl.com>; Thu, 14 Dec 2023 06:13:28 -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, MIME_QP_LONG_LINE=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=unavailable 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 vnKI5GfH1W7J for <taps@ietfa.amsl.com>; Thu, 14 Dec 2023 06:13:24 -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 301F9C14F61C for <taps@ietf.org>; Thu, 14 Dec 2023 06:13:24 -0800 (PST)
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma-mailsvcp-mx-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5N007LVU63EI20@ma-mailsvcp-mx-lapp01.apple.com> for taps@ietf.org; Thu, 14 Dec 2023 06:13:22 -0800 (PST)
X-Proofpoint-GUID: xvwFJiNldQ6ODCVsEpw7hhewy4q28GPD
X-Proofpoint-ORIG-GUID: xvwFJiNldQ6ODCVsEpw7hhewy4q28GPD
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-14_09:2023-12-14, 2023-12-14 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 mlxlogscore=999 mlxscore=0 spamscore=0 bulkscore=0 adultscore=0 phishscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312140098
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=DoMYAppciaz9jX7Fskar1HAYuOEmgpY/FXVKwexHYNY=; b=K3DjjLkv14Cqez+vvi13nu9zzLmfd5V5ezCW8mmJtGE1u6uShG8gTyYpYgRt+C7rZgEU KWoR1Y5z5/XS6B105NNVWUwJALFnrDTIM+x95I71qrNxNoabA7gaF50RA4uWZNtUju5l uQCvae55ha1jwLOkNP8GfCDuwyCA3uCmOH/p/ysiSBbLs0ktVkV4oufH1B+d/9ZV3K98 0u6PY7eSKXJdrsIojjDHcTPjv9wfY7G2ZKYfmJpuiycs1KQS5/3Rz0miZ2HIh+iY7BFQ wgbgyCAP0sqzqpxjhhpaWMBHkqG3qd2KvTNpnWQM9IDdUcCY03/6wGHE2XRQBqZttiJ7 qQ==
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5N0063KU679V70@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 14 Dec 2023 06:13:19 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S5N00U00U20YA00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 14 Dec 2023 06:13:19 -0800 (PST)
X-Va-A:
X-Va-T-CD: e52bc99798a6b8983ba7b5634300aea3
X-Va-E-CD: af5bdc872ffde92b8e291b969cf523ac
X-Va-R-CD: ec08cce7c0fef839f4c668287a712400
X-Va-ID: 9118b3fe-7e08-4208-ab41-6f4734a4a947
X-Va-CD: 0
X-V-A:
X-V-T-CD: e52bc99798a6b8983ba7b5634300aea3
X-V-E-CD: af5bdc872ffde92b8e291b969cf523ac
X-V-R-CD: ec08cce7c0fef839f4c668287a712400
X-V-ID: 89585bbb-bfe6-4a93-917c-d98acc4d8207
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-14_09:2023-12-14, 2023-12-14 signatures=0
Received: from smtpclient.apple (unknown [17.234.15.127]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S5N00X24U677700@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 14 Dec 2023 06:13:19 -0800 (PST)
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
From: Tommy Pauly <tpauly@apple.com>
MIME-version: 1.0 (1.0)
Date: Thu, 14 Dec 2023 06:13:07 -0800
Message-id: <14B9DBDA-6DF6-419F-89C4-72503503A443@apple.com>
References: <F16F27A0-AC25-498F-AE25-F04B9421712D@eggert.org>
Cc: Brian Trammell <ietf@trammell.ch>, Michael Welzl <michawe@ifi.uio.no>, 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>
In-reply-to: <F16F27A0-AC25-498F-AE25-F04B9421712D@eggert.org>
To: Lars Eggert <lars@eggert.org>
X-Mailer: iPhone Mail (21D31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/4NbxF22KR8Wfg3ML-m2XcOrz6aI>
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: Thu, 14 Dec 2023 14:13:28 -0000
Hi Lars, > On Dec 12, 2023, at 10:42 AM, Lars Eggert <lars@eggert.org> wrote: > > Hi, > > On Dec 12, 2023, at 19:48, Tommy Pauly <tpauly@apple.com> wrote: >>>>> ### 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. > > OK, but where in the example does it set that the default it TCP/TLS? The only thing specified for the "default" is port 443 - is something inferring TCP/TLS based on the port? The default isn’t explicitly set to TCP/TLS there—it’s the endpoint address/host/port details that are set as default. So it’s saying “use this default endpoint for any protocol that’s used, except if quic is chosen because I know it uses a different port”. Theoretically if the stack could choose TLS/TCP, QUIC, and something else like SCTP, that default would apply to everything other than QUIC. > >>> 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? > > I don't, and that was a comment (i.e., not part of the discuss), so I don't expect changes. Understood, thanks. Tommy > > Thanks, > Lars >
- [Taps] Lars Eggert's Discuss on draft-ietf-taps-i… Lars Eggert via Datatracker
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Lars Eggert
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Michael Welzl
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Lars Eggert
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Brian Trammell (IETF)
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Philipp S. Tiesel
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Lars Eggert
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly
- Re: [Taps] Lars Eggert's Discuss on draft-ietf-ta… Tommy Pauly