jiebi/CodeConvo huggingface dataset:
Change:
Should taps-interface provide a way to close a connection group? I don't see an obvious way to close an HTTP/2 or QUIC connection just using connection-level commands. You could make TAPS automatically close a connection if all user streams are closed, but that's... not great?
What's the problem with closing a connection (I presume you mean the underlying transport's one, not the one exposed by TAPS) once all user streams (i.e., grouped TAPS Connections) are closed? I think this would obviously happen. If I, as a user, want to avoid delay for connection establishment and tear-down, I'm not closing my Connection... Else, closing a group containing multiple open Connections in one go would be a matter of issuing "Close" for all of them... e.g., by checking the Connection's group number, in a loop. We could spec that as part of the API, but it doesn't seem to be extremely useful to me, as this function could very easily be written on top of the TAPS API.
This works for me, Gorry
Alternative discussed: make ConnectionGroup an explicit object (as opposed to just a []Connection), and add (at least) an AbortGroup call on it. Another option: add AbortGroup to a Connection, which aborts all connections in the group. Discussion at December interim leans toward the second: don't create a new object for only one operation.
Also, make sure to be clear that Abort() does NOT close all entangled Connections. (same thing for Close())

Discussion:
example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  If the Remote Endpoint still has data to <del> send, it cannot be received after this call. </del> <ins> send, it cannot be received after this call.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. <del> Abort terminates a Connection without delivering any remaining data: </del> <ins> Abort terminates a Connection without delivering any remaining data. This action does not affect any other Connection that is entangled with this one in a Connection Group. AbortGroup terminates a Connection and also terminates any other Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; aborting the entire group would close the underlying session.  See also groups. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been
Change:
Section 4.2.2 says "If a child node fails to connect before..." without really defining if this means completing the handshake, or making some progress. 4.3.1 does a better job, but for readability there ought to be a reference or rewording in 4.2.2.
/to connect/ is problematic for me also, but /establish connectivity/ is less problematic, although always good to explain!

Discussion:
should not terminate an earlier child connection attempt upon starting a secondary child. <del> If a child node fails to connect before the delay time has expired for the next child, the next child should be started immediately. </del> <ins> If a child node fails to establish connectivity (as in determining- successful-establishment) before the delay time has expired for the next child, the next child should be started immediately. </ins> Staggered racing between IP addresses for a generic Connection should follow the Happy Eyeballs algorithm described in RFC8305.  RFC8421
Change:
Oh yes, and it IS editorial ! :-D
Is "racing" really the right term? It might be a term of art that applies even in cases like this, but many of the relationships between different branches in the tree are based on preference rather than lowest latency. I don't feel strongly about this, but I don't know if this has been brought up yet, so I figured I'd mention it.
I agree that it may seem a bit misleading, but I think it's ok - it's just the word we use for it, and the term and how we use it is quite clearly defined in the Architecture draft, section 4.2.2. Just my 2c
I like "racing" - it's just a term....
Racing is defined in the architecture document; add a reference back there.
Thanks for fixing this!

Discussion:
Connection establishment is divided into two top-level steps: Candidate Gathering, to identify the paths, protocols, and endpoints <del> to use, and Candidate Racing, in which the necessary protocol handshakes are conducted so that the transport system can select which set to use.  This document structures candidates for racing as a tree. </del> <ins> to use, and Candidate Racing (see Section 4.2.2 of I-D.ietf-taps- arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use.  This document structures candidates for racing as a tree. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,
Change:
I stared at this sentence for a while before I thought I'd made sense of it. PR forthcoming but I think this might need a little discussion.
lgtm

Discussion:
The application should be notified whenever a Message or partial Message has been consumed by the Protocol Stack, or has failed to <del> send.  The meaning of the Message being consumed by the stack may vary depending on the protocol.  For a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver.  For a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer. </del> <ins> send.  The time at which a Message is considered to have been consumed by the Protocol Stack may vary depending on the protocol. For example, for a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver.  For a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer.  The time at which a message has failed to send is after the Protocol Stack or the Transport Services implementation itself has not successfully sent the entire Message content or partial Message content on any open candidate connection; this may depend on protocol-specific timeouts. </ins> 5.1.3.
Change:
Clarify that the Connection returned by Clone will send a Ready Event or an InitiateError Event.
Clone() is analogous to Initiate(), so why doesn't it return ready events like initiate()?
This should be OK because Initiate doesn't generate the Ready event, etc, but the Connection does. Both Initiate and Clone return a Connection. We can try to clarify this.

Discussion:
Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned <del> Connection.  The connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. </del> <ins> Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  The Connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. </ins> The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words,
Change:
Suggested sentence to unambiguously explain datagram v. connection opening.
For me at least, it would be nice for the implementation draft to also initially remind readers that the Connection objects are relevant to all transports, including those that are not themselves connection-oriented.
Thought to be fixed in
Fixed in
Looks good! Thank you!

Discussion:
enabling applications written to a single API to make use of transport protocols in terms of the features they provide; <del> Unified interface to datagram and connection-oriented transports, allowing use of a common API for connection-establishment and closing; </del> <ins> A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection- establishment and closing; </ins> Message-orientation, as opposed to stream-orientation, using application-assisted framing and deframing where the underlying
Change:
To address NiTs
I-D.ietf-tsvwg-datagram-plpmtud is now a RFC.
See PR
Resolved in PR
The current text says: Constant-Rate Streaming: The application expects to send/receive data at a constant rate after Connection establishment. Delay and delay variation should be minimized at the expense of efficient use of the available capacity. This implies that the Connection might fail if the desired rate cannot be maintained across the Path. this last sentence sounds a little like the app needs to maintain the rate, rather than the path is expected to offer the rate. Could we change the last sentence to: /This implies that the Connection might fail if the Path is unable to maintain the desired rate. /
See PR
This was fixed in PR
Editorial: This text at the end of the intro reads odd to me: ‘This specific transport stack choice is discouraged for general use, because it can reduce the portability.’ I think it should read more like: ‘This choice, which only permits using a specific transport stack is discouraged for general use, because it can reduce the portability.’ —— Editorial; Is a Connection an instance of the stack? The current text says: ‘A Connection represents a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint’ This may be better as?: ‘A Connection represents an instance if a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint’ —— ‘Editorial ‘through a Message Framer which finds message’ Should this be: ‘through a Message Framer that finds message’
See PR
Resolved in PR
This LGTM, thanks!

Discussion:
The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should be minimized at the expense of efficient use of the available <del> capacity.  This implies that the Connection might fail if the desired rate cannot be maintained across the Path.  A transport can interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate-adaptive congestion controller. Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB. </del> <ins> capacity.  This implies that the Connection might fail if the Path is unable to maintain the desired rate.  A transport can interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate-adaptive congestion controller.  Transport system implementations that map the requested capacity profile onto per- connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB. </ins> The application expects to send/receive data at the maximum rate allowed by its congestion controller over a relatively long period
Change:
Addition to clarify what happens when a transport system replays messages -
The current text says: If true, Safely Replayable specifies that a Message is safe to send to the Remote Endpoint more than once for a single Send Action. It marks the data as safe for certain 0-RTT establishment techniques, where retransmission of the 0-RTT data may cause the remote application to receive the Message multiple times. For protocols that do not protect against duplicated messages, e.g., UDP, all messages need to be marked as "Safely Replayable". To enable protocol selection to choose such a protocol, "Safely Replayable" needs to be added to the TransportProperties passed to the Preconnection. If such a protocol was chosen, disabling "Safely Replayable" on individual messages MUST result in a SendError. — I think this could perhaps be misleading, and suggest: 1. I would like to change /UDP/directly over UDP/ .... because clearly it is possible that a transport such as QUIC also uses UDP, but provides this sort of protection above the UDP layer. 2. This is still written from the perspective of the protocol. I think it is important here to also therefore add a sentence then clarifies that the application might be able to designed to detect and ignore such duplication. ‘Protection from replay of messages could be provided by an application when a transport system replays messages’.

Discussion:
this property may be ignored. Safely Replayable: when this is true, this means that the Message <del> can be used by mechanisms that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP Fast Open.  Also, protocols that do not protect against duplicated messages, such as UDP, can only be used with Messages that are Safely Replayable. </del> <ins> can be used by a transport mechanism that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP Fast Open.  Also, protocols that do not protect against duplicated messages, such as UDP (when used directly, without a protocol layered atop), can only be used with Messages that are Safely Replayable.  When a transport system is permitted to replay messages, replay protection could be provided by the application. </ins> Final: when this is true, this means that the sender will not send any further messages.  The Connection need not be closed (in case
Change:
The text reads quire off when it says a priority property represents a hierarchy of priorities: This property represents a hierarchy of priorities. Could this better be: ‘A priority property is organised within a hierarchy of priorities. ‘?
When reading "hierarchy", it's easy to think that there may be priority sub-groups within priority groups, or something of that nature. Yet, this is not the case, it's just a flat priority assignment. Hence, to me, mentioning "hierarchy" here is misleading altogether. Therefore, I think we'd be much better off removing this sentence, i.e. replacing: with
Seems to resolving the odd wording.

Discussion:
100 <del> This property represents a hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </del> <ins> This property specifies the priority of a Message, relative to other Messages sent over the same Connection. </ins> A Message with Priority 0 will yield to a Message with Priority 1, which will yield to a Message with Priority 2, and so on.  Priorities
Change:
Also spotted some further small nits while reviewing the document, will create a pull request for those.

Discussion:
Preference, which is an Enumeration with five possible values: Prohibit, Avoid, Ignore, Prefer, or Require.  Each of these denotes a level of preference of a given property during protocol <del> selection.  (See selection-props.)  The Preference type is used only on Preconnections, and only for Selection Properties. </del> <ins> selection.  (See also selection-props.)  The Preference type is used only on Preconnections, and only for Selection Properties. </ins> 3.3.

Specify a Local Endpoint using a STUN server: <del> Specify a Local Endpoint using a Any-Source Multicast group to join </del> <ins> Specify a Local Endpoint using an Any-Source Multicast group to join </ins> on a named local interface: Source-Specific Multicast requires setting both a Local and Remote

not be used for sending if the connection was created with the Selection Property "Direction of Communication" set to "unidirectional receive" or if a Message marked as "Final" was <del> sent over this connection.  See msg-final. </del> <ins> sent over this connection.  See also msg-final. </ins> Whether the connection can be used to receive data.  A connection cannot be used for reading if the connection was created with the

Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent <del> Event contains a reference to the Message to which it applies. </del> <ins> Event contains a reference to the Message Context of the Message to which it applies. </ins> Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the

completion; i.e. when the Message was not sent before its Lifetime (see msg-lifetime) expired.  This is separate from SendError, as it is an expected behavior for partially reliable transports.  The <del> Expired Event contains a reference to the Message to which it applies. </del> <ins> Expired Event contains a reference to the Message Context of the Message to which it applies. </ins> 7.2.2.3.

system and Protocol Stack to handle, some failure of the underlying Protocol Stack, or a set of Message Properties not consistent with the Connection's transport properties.  The SendError contains a <del> reference to the Message to which it applies. </del> <ins> reference to the Message Context of the Message to which it applies. </ins> 7.2.3.

Each Message Context may contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack <del> dependent.  These are exposed though additional read-only Message </del> <ins> dependent.  These are exposed through additional read-only Message </ins> Properties that can be queried from the MessageContext object (see msg-ctx) passed by the receive event.  The following metadata values are supported:
Change:
Section 6 says. "Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol are simply ignored, and do not raise an error" Should this be normative? "Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol MUST be ignored, and MUST NOT raise an error" I note that this a random sentence where spotted that normative language could be used. I don't look for these kind of occasion systematically...
I could see a case that the first requirement to ignore, I think this actually a requirement for predictable interop? (in which case we could motivate that?) I am much less sure of the second MUST, and think an error notification is not an interop issue?
The first MUST is definitely important for code portability, and so I think this is a good suggestion. I'm also less sure of the second MUST, but I think it's good to keep: yes, errors can be ignored by an application, but they can also lead to application code like: adjust QUIC properties if error: adjust TCP properties If an application absolutely must do this and must find out what's going on, it can, it's ok for a Transport Services system to make everything readable... but throwing errors in addition is yet another hint for a programmer to start developing code like this. We should discourage such code. That's why I'd keep the MUST NOT (as a counter-example, "SHOULD NOT" would mean that there would have to be a good reason for the designer of a Transport Services system to make an exception - what would such a reason be? "This particular function of this particular protocol is so important, I think here I should really throw an error after all?" - Nah...).

Discussion:
Properties may be Generic, applying regardless of transport protocol, or Specific, applicable to a single implementation of a single transport protocol stack.  Generic Connection Properties are defined <del> in connection-props below.  Specific Protocol Properties are defined in a transport- and implementation-specific way, and MUST NOT be assumed to apply across different protocols.  Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol are simply ignored, and do not raise an error; however, too much reliance by an application on Specific Protocol </del> <ins> in connection-props below. Protocol Specific Properties are defined in a transport- and implementation-specific way, and MUST NOT apply across different protocols.  Too much reliance by an application on Protocol Specific </ins> Properties can significantly reduce the flexibility of a transport services implementation.
Change:
Closes issue
We have a “ Terminology and Notation” section, but we don’t define these terms: Clone: Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned Connection. Entangled connection: if we do we need this term, we should define and explain what is different. Callback: can we have a one line definition that explains the different with respect to an event that an application can also asynchronously receive.
I can take care of the first two; regarding callbacks, I think there should also be at least one sentence somewhere explaining the need (why are Events not good enough for security?). I remember that this was clearly said, and I remember understanding it :) but by now, I have forgotten, and I can't find the rationale written anywhere.
As I looked at this now, I felt that such definitions would seem a bit out of place in the "Terminology and Notation" section; rather, if we need to define it globally, the concepts of Cloning and Entanglement should be defined where we also define what our Connections are, what Transport Properties are, etc. - and this is in -arch. Thoughts?
This isn't need for entangled with the way used in PR
I'm adding the arch label so people notice :-)
The one action remaining is defining "callback" within the scope of section 4.3.
Looks like this will be addressed.

Discussion:
Security decisions, especially pertaining to trust, are not static. Once configured, parameters may also be supplied during connection establishment.  These are best handled as client-provided callbacks. <del> Security handshake callbacks that may be invoked during connection establishment include: </del> <ins> Callbacks block the progress of the connection establishment, which distinguishes them from other Events in the transport system.  How callbacks and events are implemented is specific to each implementation.  Security handshake callbacks that may be invoked during connection establishment include: </ins> Trust verification callback: Invoked when a Remote Endpoint's trust must be validated before the handshake protocol can