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

Brian E Carpenter <> Fri, 16 February 2024 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3C55C14F749; Fri, 16 Feb 2024 11:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.196
X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HXAlJDUsIiz0; Fri, 16 Feb 2024 11:54:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (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 (Postfix) with ESMTPS id C4F85C14F5FD; Fri, 16 Feb 2024 11:53:55 -0800 (PST)
Received: by with SMTP id d9443c01a7336-1db51e55023so16612375ad.1; Fri, 16 Feb 2024 11:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1708113235; x=1708718035;; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=UQsJWF5SVfO0k9YA5RAEBaO1r3DtBECXRA5P3KMUVpY=; b=Qz//qpabipG1cKPeQpGXOXElFAod1aXI7KinAKbMkMlinElZ4zYjrOLe6A12nR1f2n 20nfewuyIL3sLVC4zl3HIzEEgQAuVhlimh7Zs5CkJAidr9GU9x5MtCCZ+AFjtup/G3yn yfgGA4/dvs9tkO1xzOC1Z5vrr0jP1Bg0lVwEjLiX5Eug6KegxCKHUKaFYacvTeNa3nMW +oMVsw3HdrENkzFk0wVQKEumTiWZY3jkpluWAzeLEM4xOb3AWT32048plbNcflPgNKly 7uUxgcIL/vf9+DpyFx0vQ+I0xHWhLDC99RSQh9JucgnJXclOTKtYfN/4QJSRZUkZwHOq O5aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1708113235; x=1708718035; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UQsJWF5SVfO0k9YA5RAEBaO1r3DtBECXRA5P3KMUVpY=; b=RJGNndi2vqZ7mW80wNVEeuryI665X3F0uuPQu3DfiU+lyDvOtpR8mtcy9GcZ8hK8/x YPwEG/zVL4brvYCpzyFvyGbE/YKRlpqq/jbke39Jvo+DEsYuAxxN3LylZZoYWaqmBIJe tLP0qqJu55tV1V9gpm45EG6kjJe1MUxVAsYXnetAp4gz6uKm/V8wTKWhLGHCCvE01ca1 wfKi/2fwB7EbMOZfVViA1+2Jcv0ueM8GqTWjUdZ5f/Th8WAW/DMaWn40yEatXqTWxz7/ ymKdJR+AiyFvTEL0HWNdJeLugGWp79y8CYHcoWJXmvI5lFPfAaYMWu0SODhFbDQDybAE 1FvA==
X-Forwarded-Encrypted: i=1; AJvYcCWNn70fre2Y2zAG7ubUJPosS2FspUPdG4gHejUPudispnckbD3Ov/AT5sNH+LGwD8I43OiYyUtIUzVwvO2xFZ26m5FLxeHWBulTs/QRMx+wZU2zfw==
X-Gm-Message-State: AOJu0Yy6A/Fism6wSuBlEFqYbAGpGzd5CdAbwsJ21VD4SoRPnrppbgEf xkQ2gOcMXl6ayfYJABsFxIomLa6AqHqquUMM9a6ADkij2fj4G7gn1jwP/703
X-Google-Smtp-Source: AGHT+IEHWz8ntCIimqiztpMuUYit33tvcyM3AoJABVmRuhOyvOL+RQ7PI6rPEaTUxTNXTWKSRn7tGQ==
X-Received: by 2002:a17:902:6acb:b0:1d9:b751:4752 with SMTP id i11-20020a1709026acb00b001d9b7514752mr6163157plt.62.1708113234859; Fri, 16 Feb 2024 11:53:54 -0800 (PST)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by with ESMTPSA id p5-20020a170902e34500b001dba739d18esm241199plc.95.2024. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Feb 2024 11:53:54 -0800 (PST)
Message-ID: <>
Date: Sat, 17 Feb 2024 08:53:49 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
References: <>
From: Brian E Carpenter <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 16 Feb 2024 19:54:02 -0000

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?

    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