Ballot for draft-ietf-taps-arch
Yes
No Objection
No Record
Note: This ballot was opened for revision 18 and is now closed.
Thanks for this document. It seems like a good successor to "named sockets" which we sadly don't even have for Linux/POSIX :) I look forward to being able to open a secure connection based on just a DNS name, and letting the TAPS system figure out wether to use TLS, QUIC, IPsec, DANE, WebPKI, etc. I support Éric Vyncke's DISCUSS on that this document seems to be rather Informational than Standards Track. I also agree it is a bit strange to see normative BCP14 terms. Security Parameters are primarily associated with a Preconnection object, Wouldn't these apply equally to the Listener objects? It is after all what both need to agree on. RFC-EDITOR: Please remove this section before publication. I would leave in the empty IANA Section - it is preferred over omitting it. As described above in Section 3.3, if a Transport Services implementation races between two different Protocol Stacks, both need to use the same security protocols and options. However, a Transport Services implementation can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. I am not sure this is a very clear distinction. Is IPsec with PolyChacha different from WireGuard with PolyChacha? How about TLS 1.2 with AES-GCM and TLS 1.3 with PolyChacha? How about TLS 1.2 with AES-CBC and TLS 1.2 with AES-GCM ? Or TLS 1.3 vs QUIC? And TLS 1.2 vs QUIC? Or TLS vs DTLS? Some of these might not have fully known properties beforehand? Eg what about TLS 1.2 where the server insists on PSK and rejects PFS? Or IKEv2/IPsec with ECDSA versus IKEv2/IPsec with RSA? It's a very gradient flow between Protocol Stacks. I am not sure the defined distinction between Transport Services and Protocol Stacks is that clear in practise. How does DNS fit into this? Eg is it assumed that the application that can request a minimum encryption can also request DNS resolving properties? Eg insist on DoH/DoT, or insist on not using ADD, or insist on not using the famous Quad DNS servers? Or insisting on DNSSEC validated answers only? How does Remote Access VPN fit into this? Not at all? Or could an application request "only through VPN connection X" ? Or is this completely out of scope? Either way, it could be clarified. Was MPTCP left out on purpose in all the examples?
Firstly, thank you very much for writing this document -- I found it a fascinating read. Like Rob, I'd like to thank Druv for the excellent initial Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-taps-arch-17-opsdir-lc-dhody-2023-04-14/ ), and then the followup (https://datatracker.ietf.org/doc/review-ietf-taps-arch-18-opsdir-telechat-dhody-2023-08-26/) I only have a few nits / suggestions to make: 1: S 1.4. Glossary of Key Terms *Endpoint: An identifier for one side of a Connection (local or remote), such as a hostnames or URL. I'm not really sure that the definition of "Endpoint" works. E.g: the definition of "Connection" is "Shared state of two or more endpoints that persists across Messages". Ok, fine. But can you really have shared state between two **identifiers**? I don't really see how I'd have shared state between e.g hostnames, but I can see how I'd have state between entities *identified* by an identifier like a hostname. I understand what you are aiming for (and also "endpoint" seems to be used in more than one context), but I don't think that the definition as written actually works... 2: S 2.1. Event-Driven API This paragraph compares and contrasts the Socket API and the Transport Services API, but in the paragraph starting with "For example, an application first issues a call to receive new data from the connection.", it is unclear under which paradigm you are meaning. I'd suggest: "For example, when using the Transport Services API, an application first ..."
Thanks to the authors for this *neat* document and addressing by previous DISCUSS about the lack of "requirements" in the title for a proposed standard. My previous ballot is at: https://mailarchive.ietf.org/arch/msg/taps/P1riKVuZVMNgsFFZIBC6vnS1xz4/
# Internet AD comments for draft-ietf-taps-arch-18 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S1.4 * "Racing: ... along with any security parameters" Should this be "Security Parameters" (caps) to refer to the subsequent definition? ### S2.1 * "generally uses a try-and-fail model" I'm not so sure about "generally"; mostly I've seen apps use a kernel-assisted callback style (select/poll/epoll/kqueue/...). It's probably not worth spending too much time trying to recraft text, but if it seems relevant to mention perhaps give it some thought. ### S4.1 * s/connection object/Connection Object/g or s/connection object/Connection object/g? ### S4.1.5 * "Messages are sent in the payload of IP packet." What does this mean in the context of a TCP-TLS transport or a transport using a Framer? A Message will indeed be _somewhere_ in the payload section of an IP packet, but the statement as written might be construed as a Message occupying the entirety of the payload, I think. ### S4.1.7 * What happens if an app wants to half-close without sending a message (e.g. accept() or connect() followed by some flavor of shutdown())? Without having read the other documents yet I'm just wondering how this might be implemented. ### S4.2.3 * Should the definitions in Section 1.4 contain an entry for Connection Context? * Should Figure 3 contain some indication of where a Connection Context fits? ## Nits ### S1.4 * "such as a hostnames or URL": s/hostnames/hostname/ or s/a hostnames/hostnames/ ### S4 * Consider putting a box around "Network Layer Interface" in Figure 3, for consistency with Figures 1 & 2.
Thank you for the work on this document. Many thanks to Robert Sparks for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Y1JAK0kebgGfpCSf8Cr32GMQ2AQ/ and to the authors for addressing it. I didn't go through all the github issues (finding it a bit hard to find the relevant ones now), but I believe Robert's comments have been all addressed since v-11, especially the structural problems (architecture-interface).
# John Scudder, RTG AD, comments for draft-ietf-taps-arch-18 CC @jgscudder Thanks for this well-written, useful, and readable document. I have just a few comments, below. Also, I share Éric and Roman's uncertainty as to whether the status of this document should be Informational instead of Standards Track. ## COMMENTS ### Introduction, "transport networking" In your first sentence, you mention "transport networking". Is this a well-known term of art? It's not familiar to me. If this specific phrasing isn't required, I suggest re-wording, to avoid overlap with the significant existing use of "transport network" in our document set (e.g., https://datatracker.ietf.org/doc/search?csrfmiddlewaretoken=dckTkmSFjJ0QJaYJbABIW3isgeAcoV3KBMgOtF3L9ZoxIz92cOGOD1N23YCpUnb9&name=Transport+network&sort=&rfcs=on&activedrafts=on&by=group&group=) ### Section 4.1.4, simultaneous open The final bullet has "For example, if the Local and Remote Endpoints are TCP host candidates, then a TCP simultaneous open [RFC9293] will be performed". Surely not *will* be, but *might* be? I presume that in many or maybe even most cases of rendezvous, one party or the other would happen to go first, and then what RFC 9293 describes as simultaneous open (both parties launching a SYN at the same time) wouldn't occur. ### Section 4.1.5, payload of IP packet... or packets? The first bullet has "Messages are sent in the payload of IP packet. One packet can carry one or more Messages or parts of a Message." The first sentence either needs an indefinite article on "IP packet" or for "payload" and "packet" to be plural. I think probably you mean "payloads of IP packets" since in general (as the second sentence shows) a message might be split across two or more IP packets. Also, is it even necessary to say that messages are IP payloads? What else would they be? ### Section 4.1.8, multiplexing transport protocols The first and third paragraphs have "For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together." First, it doesn't seem like this sentence needs to occur twice. Second, I assume that what you mean is "transport protocols that support multiplexing", and if that's right I suggest you say it that way since as written it's ambiguous. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
Thanks to Robert Sparks for his ARTART review. I think Paul summed it up nicely, so I'm going to plagiarize: "I support Éric Vyncke's DISCUSS on that this document seems to be rather Informational than Standards Track. I also agree it is a bit strange to see normative BCP14 terms." In Section 1.4, the term "Clone" is defined but not used anywhere.
** Section 3.1. It is RECOMMENDED that the default values for Properties are selected to ensure correctness for the widest set of applications, Is there an opening here to stress “security by default” such that the recommended default values not only ensure correctness but also security and privacy for the end-user for the widest set of applications? ** Section 6. However, a Transport Services implementation can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. I didn’t see any treatment in the earlier text on the “API” properties where an application signals equivalence of security properties. Could a cross reference please be provided. ** Just as Éric Vyncke called out in his ballot, it was also not obvious to me why this document has a PS status rather than informational.
Hi, Thanks to Dhruv from the OPSDIR review. I found this document to be easy to read and understand and I think that is great to be defining a new clean transport API for use by applications. I hope that it is successful and gets traction. A couple of non-blocking minor comments follow. Minor level comments: (1) p 16, sec 4. Transport Services Architecture and Concepts The System Policy provides input from an operating system or other global preferences that can constrain or influence how an implementation will gather Candidate Paths and Protocol Stacks and race the candidates when establishing a Connection. As the details of System Policy configuration and enforcement are largely platform- and implementation- dependent, and do not affect application-level interoperability, the Transport Services API [I-D.ietf-taps-interface] does not specify an interface for reading or writing System Policy. Potentially specifying the System Policy as a YANG Model might be helpful. Even if different platforms are likely to expose this in different ways, having common standard definitions for the configurable fields would likely help interopability - even if only by defining common names and types for particular properties. (2) p 23, sec 4.1.6. Event Handling * Message Received: Delivers received Message content to the application, based on a Receive action. This can include an error if the Receive action cannot be satisfied due to the Connection being closed. Perhaps this is already answered by the other documents, but is it always the case that every message requires a separate event/notification to the application? E.g., I can imagine that under some high performance/throughput scenarios where there are large number of messages being received that the application may only want a single notification that there are one or more messages waiting to be processed, upon which it pulls some/all of them off a receive queue, and only receives another "message received/waiting" event if a message is received when the queue is empty, or the queue is not empty after a subset of the messages have been dequeued. Regards, Rob
I'm likely to abstain on this document, because I agree with Éric that Proposed Standard is not appropriate. This document (and its companion) outline as extremely intricate design, and I am not aware of any attempts to implement even a sizable subset of it. Given the various interactions between the API components and the attributes and behaviors of existing transport protocols (and their implementation), I strongly believe that in-depth experimentation with actual implementations is needed before we can have the confidence in the design we'd like to see for publication on the Standards Track.