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

[Brian E Carpenter <[e-mail]>]

On 18-Feb-24 00:00, Michael Welzl wrote:
> 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

Thanks, that's great. If I have time, I'll look closely at PyTAPS.

By the way, BCP205 states that the implementation status section is temporary and "The authors should include a note to the RFC Editor requesting that the section be removed before publication."

    Brian

> 
> Cheers,
> Michael
> 
> 
>> On Feb 16, 2024, at 8:53 PM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> 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
>>> [e-mail] <mailto:[e-mail]> mailing lists by 2024-03-01. Exceptionally, comments may
>>> be sent to [e-mail] <mailto:[e-mail]> 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/ <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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>> _______________________________________________
>> Taps mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/taps
>