Re: [Taps] Last Call: <draft-ietf-taps-interface-25.txt> (An Abstract Application Layer Interface to Transport Services) to Proposed Standard

Michael Welzl <> Sat, 17 February 2024 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2930CC18DB90; Sat, 17 Feb 2024 03:00:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hjZ4YnsemMNy; Sat, 17 Feb 2024 03:00:50 -0800 (PST)
Received: from ( [IPv6:2001:700:100:8210::76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 9F510C18DB85; Sat, 17 Feb 2024 03:00:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=key2309; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KlBLy+oHujoT2N+nUjw7hx6rF2+DjHt3ll3tzKiw+Rc=; b=R3Kj5GfetF6UsKaWU6oWgH1tdj S2f898kWDvuUJEngP9d+VeA5PU2s8+sQlewH5I4ptgutokVtxmy5iwFole6f25eSaV6hvNxv6PnlK wIGbj1BLM3KJECroRsiw97hRUCwaoYGs5SIUPAL8Q3MLgvF8SAtQHUfdkAbAXCIFS6GzjOt1Zz2Dr qqjEGzqCsChAhSHo8r7nFiYVzG9/1eL4Gexw+Ba9zKRcALbG/zRhdpwTyFXwHPzeKVZWGRHep0nJ2 5fcBjZqSQdIltFh95nvSqtz70A1DTeCvFV50ZkyrwS37ODjytFVxQzL3DCwLj7DktTRrgIr1ZFq2D I8Gfn3Ag==;
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <>) id 1rbIR3-00384t-0c; Sat, 17 Feb 2024 12:00:45 +0100
Received: from [] ( by with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96.2) (envelope-from <>) id 1rbIR2-000G6K-0O; Sat, 17 Feb 2024 12:00:45 +0100
From: Michael Welzl <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_04D65ECE-48D9-4E22-9A8F-4BB088D2A9CC"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Date: Sat, 17 Feb 2024 12:00:43 +0100
In-Reply-To: <>
To: Brian E Carpenter <>
References: <> <>
X-Mailer: Apple Mail (2.3696.
X-UiO-SPF-Received: Received-SPF: neutral ( is neither permitted nor denied by domain of client-ip=;;;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.053, HTML_MESSAGE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 19DD42D8675E3F67701FE9DA42AC70CF586D3E73
X-UiOonly: 6C2CA1A74361B3AED2EDEB68267421EACE435B5E
Archived-At: <>
Subject: Re: [Taps] Last Call: <draft-ietf-taps-interface-25.txt> (An Abstract Application Layer Interface to Transport Services) to Proposed Standard
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Feb 2024 11:00:55 -0000

Dear Brian,

I’ll leave it for others to publicly answer your items 1. and 2., but for 3., I wanted to say that we do have an overview of implementations; we thought it would fit best in the companion document that’s focused on implementation, so this is where it is: <>


> On Feb 16, 2024, at 8:53 PM, Brian E Carpenter <> wrote:
> It's good to see this work advancing. I have a few comments:
> 1. Unless I've missed it, the terminology and notation only support IP addresses in their human-readable form. There are situations where an API user needs to manipulate addresses as binary objects. (The Python ipaddress.ip_address class is an example of how to handle this,
> with its .packed property.) How does the TAPS API expose this?
> 2. The same applies to interface names, which (as described in RFC 4007, where they are called Zone Identifiers) correspond to  underlying interface indexes (integers). IPv6 addresses are actually {address, interface_index} 2-tuples - the interface index is not optional, it's just normally defaulted to zero. I think this property needs to be listed in section 1.1, not hidden away in section 6.1, with a citation of RFC 4007.
> 3. I realise that this is an abstract API, but for such an ambitious project, I am quite disappointed that there is no Implementation Status section per BCP205. How many implementations already exist?
> Regards
>   Brian Carpenter
> On 17-Feb-24 03:17, The IESG wrote:
>> The IESG has received a request from the Transport Services WG (taps) to
>> consider the following document: - 'An Abstract Application Layer Interface
>> to Transport Services'
>>   <draft-ietf-taps-interface-25.txt> as Proposed Standard
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> mailing lists by 2024-03-01. Exceptionally, comments may
>> be sent to instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
>> Abstract
>>    This document describes an abstract application programming
>>    interface, API, to the transport layer that enables the selection of
>>    transport protocols and network paths dynamically at runtime.  This
>>    API enables faster deployment of new protocols and protocol features
>>    without requiring changes to the applications.  The specified API
>>    follows the Transport Services architecture by providing
>>    asynchronous, atomic transmission of messages.  It is intended to
>>    replace the BSD sockets API as the common interface to the transport
>>    layer, in an environment where endpoints could select from multiple
>>    network paths and potential transport protocols.
>> The file can be obtained via
>> This draft is going for a 2nd IETF last call due to the changes resulted during the IESG evaluation. A diff towards the -20 version of this document should show the changes since the previous IETF last call.
>> No IPR declarations have been submitted directly on this I-D.
>> _______________________________________________
>> IETF-Announce mailing list
> _______________________________________________
> Taps mailing list