> On Mar 11, 2024, at 12:42 PM, Brian E Carpenter <[email protected]>
> wrote:
>
> 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.
Good point! Switching those references to RFC 791 and RFC 4291 makes sense
here, I think.
>
> 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).
Yes, it can be made clear that these are taking the previously defined types,
not necessarily a human-readable format.
>
>>>
>>> 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.
I would lean towards having the text explain (as it does for PvDs) that this
takes whatever system identifier is present for an interface, be it a string or
integer or strongly-typed object.
Thanks,
Tommy
>
>>>
>>> 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
