Suggesting these changes: https://github.com/ietf-tapswg/api-drafts/pull/1467
Tommy > On Mar 12, 2024, at 8:02 AM, Tommy Pauly <[email protected]> > wrote: > > > >> 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 > > -- > last-call mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
