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 <brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>> 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@xxxxxxxx <mailto:last-call@xxxxxxxx> mailing lists by 2024-03-01. Exceptionally, comments may
be sent to iesg@xxxxxxxx <mailto:iesg@xxxxxxxx> 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
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Taps mailing list
Taps@xxxxxxxx <mailto:Taps@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/taps
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
