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 <[email protected]> > 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 >> [email protected] mailing lists by 2024-03-01. Exceptionally, comments may >> be sent to [email protected] 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
