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

Brian E Carpenter <> Mon, 11 March 2024 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CE92C14F6BC; Mon, 11 Mar 2024 12:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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 ijh0ZIZ40j6L; Mon, 11 Mar 2024 12:42:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (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 A165DC14F6A6; Mon, 11 Mar 2024 12:42:13 -0700 (PDT)
Received: by with SMTP id d9443c01a7336-1dd8d586126so9178115ad.0; Mon, 11 Mar 2024 12:42:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1710186133; x=1710790933;; 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=FDaSn14xgkj+aq0Mx7gYt1JmRhhvI/2GF5uXPeurnuE=; b=iz4GHtrpKm19hBFKH4UQnYz9TPB7+QtDFYuZS/CQB8FdWqduBa+3W8uDbQW19Wp94V VlFrpfB8dY34wm+R9ob0IjO0VcR0EwcJSHPtnD2lyFzQO+bxU4VIQA8tkwvRQq2o2Y24 vRCqFHmheolFkTbprQ+9IgZGAvTlF5zSUHBjILIc51PMIu1Te65lPkvDUMMtNhW7JMvQ iPw29q49iy08mVeFRsK+sSa7M4WTDPFupX6zktAFUx6dMC/ayAU7bS/E4oPZYLIVeIPk Lsqn9MvfJkbu2NXwKVfife2H5e+TFRroAkV2Dxb6cERpDMUuuWDpDrzhigdCk52gf0F4 ThnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1710186133; x=1710790933; 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=FDaSn14xgkj+aq0Mx7gYt1JmRhhvI/2GF5uXPeurnuE=; b=Cg7Rl5k7h3eHRuFR65laALkiIbsCstq6TgZBIQZJibz36ny3cjrfV7l27YJ872yQgh aThOcP7Jka7iyWtzb5az2T19pf3TuLlS8z76eaU5OtwWZ5WxPh17IU1QZ+1mMvXRK/qc +GWuUeaY9dL30Aw1nBOhZAnY+ZX0pPzbZj+VYQvXwvdqEaKBAQuZdcnfW4tbtoeH7dnP OgXbXXH+DBUdBZuHaeVcnc+dmbKVvATAZziOFjnD7vt4D4QagtEEYHug35pZ2ibXKl11 6SgitAWcvbRB0V8Ng/1XUmtewr222kp7M49I028iSAq90ig7RO5C8fQNsI1sc1Z5u/mq EoXA==
X-Forwarded-Encrypted: i=1; AJvYcCV9BBWiUBm+/2MVNmjOc3feJ0Io6WwyyMli2LMdD97tMU97DgsjJymaXjO6Zt6B3KzaWX8TZsAKYaSjQJ1SsuSHMsnnD4mlGBCmck6jv/Z4rK1AddrxOZiMH0mfJgolJfgcLNxsl23TyuxW+7g0jyEhguZrCSg2hg==
X-Gm-Message-State: AOJu0Yw2GfNjVigQgdpYHEtsJgW7UzpVNEEIoFrUQ1brqCGvcPuVLP68 BTbZGu9GTQ290+NYXOLbq7+p/GvSAqTevV/vQwB6hfU6tMpG/fLvdx9P/vGx
X-Google-Smtp-Source: AGHT+IG+QU81saDAheKcFr/mIeJmEeQmK5eU1c7PCH0VQPwRqIsT4ACfpMdNwjZM11U9ij8BbEJsIQ==
X-Received: by 2002:a17:902:d48b:b0:1dc:854f:9a90 with SMTP id c11-20020a170902d48b00b001dc854f9a90mr1460029plg.23.1710186132881; Mon, 11 Mar 2024 12:42:12 -0700 (PDT)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by with ESMTPSA id q13-20020a170902c74d00b001db616fa11dsm5105958plq.238.2024. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 12:42:12 -0700 (PDT)
Message-ID: <>
Date: Tue, 12 Mar 2024 08:42:08 +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
To: Tommy Pauly <>
References: <> <> <>
From: Brian E Carpenter <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
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: Mon, 11 Mar 2024 19:42:14 -0000

Hi Tommy,

Responses in line:

On 12-Mar-24 04:48, Tommy Pauly wrote:
> Hi Brian,
>> On Feb 16, 2024, at 11:53 AM, 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?
> The IP addresses are not expected to be strings (although a concrete API certainly may offer that option). The type is “defined" here:
> <>
> And used here:
> <>
> Note that this is just as an “address” type, not a string.
> In the concrete API instantiation that we have at Apple, we allow this type to be created either with a data blob or a string:
> <>

That is fair enough, but in that case the citation in  Section 1.1. 'Terminology and Notation': "IP Address: An IPv4 or IPv6 address [RFC5952]" is very confusing, because you aren't referring to the human-readable format in particular. Also, that RFC doesn't define the human-readable format for IPv4 addresses.

For IP addresses as an abstraction, I think you need RFC 791 and RFC 4291. Or no citation at all.

The examples in 6.1. 'Specifying Endpoints' such as "RemoteSpecifier.WithIPAddress(" have the same problem. At the very least, you need to explain that you are using the human-readable format for readability, but that it's shorthand.

This argument doesn't apply to WithHostName and WithPort because they are intrinsically typed. I see that in other places you use undefined abstractions like SourceAddress and GroupAddress and even QUIC. Maybe you need to use IPv6Address and IPv4Address, e.g. RemoteSpecifier.WithIPAddress(IPv4Address).
>> 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.
> I don’t think I agree that an interface identifier needs a top-level type in the API here. While in concrete API instantiations, it is useful to have an interface object or identifier, the nature of the identifier can vary depending on the operating system / platform / language, etc. The “common” type is just a string, as we use it in 6.1, and the exact nature of a more specific type depends on the platform.
> This is similar to the PvD identification situation, described in
> The fact that the interface is technically present in an IPv6 address, but defaults to zero, is a good example of how a higher-level API can make that an optional field.

But, and it's a big but, RFC4007 makes the support of a default optional (a blunder IMHO) and the result is that only some o/s support a default. Crucially, on Linux, you *cannot* default the interface in link-local addresses. So in reality, supporting it isn't an option. If you don't support it, I don't see how TAPS will actually work for link-local IPv6 addresses on a Linux host, even if there is only one interface active.

I can see your argument for not making it a top level type. But 'WithInterface("en0")' presents the same issue as 'RemoteSpecifier.WithIPAddress('. "en0" should be an abstraction such as InterfaceIdentifier.

>> 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?
> As Michael noted, the implementation list is in the implementation draft, which already is past last call, etc:
> <>

Yes, that is perfect.


> Thanks,
> Tommy
>> 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