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 <[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?
The IP addresses are not expected to be strings (although a concrete API certainly
may offer that option). The type is “defined" here:
https://www.ietf.org/archive/id/draft-ietf-taps-interface-25.html#section-1.1-17.5.1
<https://www.ietf.org/archive/id/draft-ietf-taps-interface-25.html#section-1.1-17.5.1>
And used here:
https://www.ietf.org/archive/id/draft-ietf-taps-interface-25.html#section-6.1-11.1.1
<https://www.ietf.org/archive/id/draft-ietf-taps-interface-25.html#section-6.1-11.1.1>
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:
https://developer.apple.com/documentation/network/ipaddress
<https://developer.apple.com/documentation/network/ipaddress>
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(192.0.2.21)" 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
https://www.ietf.org/archive/id/draft-ietf-taps-interface-25.html#section-6.2.12-4.
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(192.0.2.21)'. "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:
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>
Yes, that is perfect.
Rgds
Brian
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
[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
