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

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:  https://www.ietf.org/archive/id/draft-ietf-taps-impl-18.html#name-existing-implementations <https://www.ietf.org/archive/id/draft-ietf-taps-impl-18.html#name-existing-implementations>

Cheers,
Michael

> On Feb 16, 2024, at 8:53 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> 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
>> last-call@ietf.org mailing lists by 2024-03-01. Exceptionally, comments may
>> be sent to iesg@ietf.org 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
>> https://datatracker.ietf.org/doc/draft-ietf-taps-interface/
>> 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
>> IETF-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps