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

Tommy Pauly <tpauly@apple.com> Mon, 11 December 2023 20:58 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 D84E8C14CE51 for <taps@ietfa.amsl.com>; Mon, 11 Dec 2023 12:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 t6dXH3tQWyh2 for <taps@ietfa.amsl.com>; Mon, 11 Dec 2023 12:58:12 -0800 (PST)
Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (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 AB15DC15108C for <taps@ietf.org>; Mon, 11 Dec 2023 12:58:12 -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-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5I00OL1SWR0700@ma-mailsvcp-mx-lapp02.apple.com> for taps@ietf.org; Mon, 11 Dec 2023 12:58:11 -0800 (PST)
X-Proofpoint-ORIG-GUID: dRYqCUn0GOwhvNQeorzwZElGbT26uyR9
X-Proofpoint-GUID: dRYqCUn0GOwhvNQeorzwZElGbT26uyR9
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-11_09:2023-12-07, 2023-12-11 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 bulkscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 suspectscore=0 malwarescore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312110173
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=cEikpv89D1a8gHtHDhAVnIXbqQVr2Hi7wwDBuSIOJQw=; b=HKzbAmzNr8fDtkIsdpjh/vuBUeEBglLC1aaYPr97sqGIIBz7+vH35T6ZkB1npsYAKpj7 LS4d689fBFqmdJZ4MS8gUpjIdu6N1g/MW7Z2V8rLyclby/nwassUfbOi5C4yjF5M1pmg 92N/6jfvaa/qO2I1IpihM0TD3pNbAablRSbh5WZoPbbO/EjpWt9XIfu6X3Dg32NWsMOr ZZrhZxsSxiu5gDHhO7Dp1zlVgqPYDlo2DDUalkOsG+wWDanLCZkqupsQR4US8GHJToXs V7tU/vtUOCuM38IFs46/MguM5t4Zw0ATwfXXrMXhRG+Is3QZcm3EAM0mB0g+kRzrEkmM sw==
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) 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 <0S5I00WJ1SWQF5Z0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 11 Dec 2023 12:58:03 -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 <0S5I00300STSD000@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 11 Dec 2023 12:58:02 -0800 (PST)
X-Va-A:
X-Va-T-CD: e52bc99798a6b8983ba7b5634300aea3
X-Va-E-CD: 131c43a3a6412cc28a5b861b2a311273
X-Va-R-CD: c06fad883c61093726cf88396f321272
X-Va-ID: fa6d95cb-d17d-4269-9fb0-b40c3591be88
X-Va-CD: 0
X-V-A:
X-V-T-CD: e52bc99798a6b8983ba7b5634300aea3
X-V-E-CD: 131c43a3a6412cc28a5b861b2a311273
X-V-R-CD: c06fad883c61093726cf88396f321272
X-V-ID: c841be02-0dff-40f1-be7c-31328aeab596
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-11_09:2023-12-07, 2023-12-11 signatures=0
Received: from smtpclient.apple ([17.11.230.175]) 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 <0S5I00UBRSVMX100@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 11 Dec 2023 12:58:02 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <4A7A0573-E1B6-42D8-955B-AB5DA7098F07@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_275C0D5B-8851-4EC3-809B-257548EE11C1"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Mon, 11 Dec 2023 12:57:52 -0800
In-reply-to: <A1CF408B-C691-4003-A989-D0F3284B4E2F@apple.com>
Cc: 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>
References: <169408439315.13814.3746604129872399062@ietfa.amsl.com> <A1CF408B-C691-4003-A989-D0F3284B4E2F@apple.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/bC0SG9OMUTWIJoqvxAtX5ZvhpZU>
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: Mon, 11 Dec 2023 20:58:14 -0000

Hi Lars,

Thanks again for your review — just a quick reminder to please take a look at the updates, and let us know if there’s anything else that needs to be addressed to clear your DISCUSS.

Best,
Tommy

> On Nov 14, 2023, at 9:17 AM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> 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 <noreply@ietf.org> 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."
>> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org <mailto:Taps@ietf.org>
> https://www.ietf.org/mailman/listinfo/taps