jiebi/CodeConvo huggingface dataset:
Change:
Add a reference to MPS in DPLPMTUD for the Message Size Before Fragmentation property.
LGMT, just replace "models" with something more suitable.

Discussion:
This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or <del> transport layer segmentation at the sender. </del> <ins> transport layer segmentation at the sender.  This property exposes the Maximum Packet Size (MPS) as described in Datagram PLPMTUD I- D.ietf-tsvwg-datagram-plpmtud. </ins> 11.1.8.
Change:
When reading the API draft, I noticed that in some places it was still using the outdated term "Protocol Properties" where it actually means Connection Properties or Message Properties. I replaced the terms in this PR. We do still define "Specific Protocol Properties", so I kept these.

Discussion:
Connection.  These connections are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these two Connections adds a third Connection to the Connection Group, and so <del> on.  Connections in a Connection Group share all Protocol Properties that are not applicable to a Message. </del> <ins> on.  Connections in a Connection Group generally share Connection Properties.  However, there may be exceptions, such as "Priority (Connection)", see conn-priority. </ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection: <del> Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del> <ins> Changing one of the Connection Properties on one Connection in the group changes it for all others.  Message Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Connection Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.

create a new stream on the given Connection, then attempts to clone a Connection will result in a CloneError: <del> The Protocol Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </del> <ins> The Connection Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </ins> Connections in a Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation

11.1. <del> The Connection Properties defined as independent, and available on all Connections are defined in the subsections below. </del> <ins> The Connection Properties defined as independent of the chosen protocol stack, and available on all Connections are defined in the subsections below. </ins> <del> Note that many protocol properties have a corresponding selection property, which prefers protocols providing a supporting transport feature. </del> <ins> Note that many Connection Properties have a corresponding Selection Property, which enables applications to express their preference for protocols providing a supporting transport feature. </ins> 11.1.1.
Change:
The term Protocol Specific Properties is not well introduced. In the Arch doc we have a section about "Specialized Features" and I not added a reference and rephrased the sentence respectively. Do we need to say more than that?
LGTM modulo two nitsLooks good to me, except one nit.

Discussion:
The effect of Selection Properties can be queried on Connections and Messages <del> Note that Configuring Connection Properties and Message Properties on </del> <ins> Note that configuring Connection Properties and Message Properties on </ins> Preconnections is preferred over setting them later.  Early specification of Connection Properties allows their use as additional <del> input to the selection process.  Protocol Specific Properties, see property-names, should not be used as an input to the selection process. </del> <ins> input to the selection process.  Protocol Specific Properties, which enable configuration of specialized features of a specific protocol, see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to the selection process but only support configuration if the respective prototocol has been selected. </ins> 4.2.1.
Change:
It looks like we should use normative language here. We could also use the keywords of the IANA protocol number registry to indicate reserved namespaces for IETF protocols (that can not be used in the vendor or implementation specific namespaces anyway). See URL
Like this?
This is great, thanks!

Discussion:
Transport Property Names are hierarchically organized in the form [<Namespace>.]<PropertyName>. <del> The Namespace part is empty for well known, generic properties, i.e., for properties that are not specific to a protocol and are defined in an RFC. </del> <ins> The Namespace part MUST be empty for well-known, generic properties, i.e., for properties that are not specific to a protocol and are defined in an RFC. </ins> <del> Protocol Specific Properties must use the protocol acronym as </del> <ins> Protocol Specific Properties MUST use the protocol acronym as </ins> Namespace, e.g., "tcp" for TCP specific Transport Properties.  For <del> IETF protocols, property names under these namespaces should be </del> <ins> IETF protocols, property names under these namespaces SHOULD be </ins> defined in an RFC. <del> Vendor or implementation specific properties must use a string </del> <ins> Vendor or implementation specific properties MUST use a string </ins> identifying the vendor or implementation as Namespace. <ins> Namespaces for the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-numbers/ protocol-numbers.xhtml) are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation specific properties. </ins> 4.2.2. Transport Properties can have one of a set of data types:
Change:
Agree, they're definitely objects. While an implementation might choose to implement different types of endpoint identifiers as subtypes of such objects, we don't want to be that specific here.LGTM

Discussion:
5.1. The transport services API uses the Local Endpoint and Remote <del> Endpoint types to refer to the endpoints of a transport connection. Subtypes of these represent various different types of endpoint identifiers, such as IP addresses, DNS names, and interface names, as well as port numbers and service names. </del> <ins> Endpoint Objects to refer to the endpoints of a transport connection. Actions on these Objects can be used to represent various different types of endpoint identifiers, such as IP addresses, DNS names, and interface names, as well as port numbers and service names. </ins> Specify a Remote Endpoint using a hostname and service name:
Change:
I guess we could actually remove all commas in this sentence but previously there were definitely too many...

Discussion:
path, the transport system will try the path first, ignoring the preference. <del> Selection, and Connection Properties, as well as defaults for Message </del> <ins> Selection and Connection Properties, as well as defaults for Message </ins> Properties, can be added to a Preconnection to configure the <del> selection process, and to further configure the eventually selected </del> <ins> selection process and to further configure the eventually selected </ins> protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object:
Change:
Just a proposal...
Well, you could do it with streams in SCTP as well so as an example it seems approriate. And good with an example I think.
Yes, we do have actually these kind of examples in many cases in the doc and I just thought when reading one could help here as well.
I don't understand why one would need streams for this in SCTP, but it doesn't matter. As I said I have no strong opinion, I'm fine with adding this example (and I just fixed the nit).
NAME you do not need to, as there are multiple ways to do it in SCTP, but you could.

Discussion:
may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for <del> certain messages. </del> <ins> certain messages, e.g., by multiplexing independent messages onto different streams. </ins> 7.4.4.
Change:
Comma in the first section was wrong but better to rephrase anyway...
nit

Discussion:
10.1. <del> The Connection Properties defined as independent of the chosen protocol stack, and available on all Connections are defined in the subsections below. </del> <ins> Generic Connection Properties are defined independent of the chosen protocol stack and therefore available on all Connections. </ins> Note that many Connection Properties have a corresponding Selection <del> Property, which enables applications to express their preference for </del> <ins> Property which enables applications to express their preference for </ins> protocols providing a supporting transport feature. 10.1.1.
Change:
Btw. does this cover all events? There is an issue where I also ask if we e.g. need an event that sending failed due to lifetime expiry. is there a way to double-check if we considered all needed events? Should we also mention ConnectionErrors here? Maybe we anyway need to say more about error?
These are not all events (just search for the word "event" in the document), and generally they are not all lumped together - e.g. sending related events such as "Sent" appear in the "Sending Data" section - which, in fact, has its own subsection called "Send Events". So, this would be a subsection just related to connection management... but then, you state: "During the lifetime of a connection there are events that can occur when configured." which gives the (wrong) impression that this would be the list of all events that can happen during a connection's lifetime. So, I wouldn't add this subsection heading and not include that statement. Or maybe add the subsection heading (which is ok but doesn't help much - as you see, there are only very few events in there), but remove that statement.
+1 to calling this "connection lifecycle events" or similar (do we refer to a connection lifecycle?)
Changed the heading and fixed the nit. I'm open to have another sentence there if people have proposals. We could even have no text but we usually say something after each heading.
Given the new heading, I'm fine with the sentence as it is - because the context is clear now, it's no longer misleading (i.e., giving the wrong impression that these would be ALL events).

Discussion:
10.3. <ins> During the lifetime of a connection there are events that can occur when configured. 10.3.1. </ins> Asynchronous introspection is also possible, via the SoftError Event. This event informs the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the

even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. <del> 10.4. </del> <ins> 10.3.2. </ins> This event notifies the application of excessive retransmissions, based on a configured threshold (see conn-excss-retransmit).  This
Change:
Following , Section 4.2.3 of the Architecture document now says that fallback between different security protocol versions might be allowed. The Security Considerations section was out of sync. This PR fixes that.

Discussion:
D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both MUST use the same security protocols and options. </del> <ins> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

Moreover, Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if an application requests TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. </del> <ins> secure protocols.  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </ins>
Change:
Proposed some text for - I think this summarizes the "flexibility" advantage of TAPS that we elaborate on in Section 2.3.
In Section 1.2, Overview, the architecture draft says that TAPS offers "the ability to easily adopt different transport protocols". What does "adopt" mean here? I guess this relates to Section 2.3 (maybe say that explicitly here), but even after reading this Section, I don't quite understand why "adopt". Is the point here that a flexible interface makes it easier to add support for new protocols? Then perhaps we should say this here.
It means that applications don't need to rewrite a ton of code or adopt a new library to access a new transport protocol. In how I read it, "adopt" captures that, but if there's some other text you would like to suggest, that's fine.
For me "adopt" is fine as it should be clear from the rest of the doc. However, if we want to be more clear we could say "make use of different protocols without the need to change the interface" or something...?
Looks good, merged!

Discussion:
model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for <del> data transfer, and the ability to easily adopt different transport protocols. </del> <ins> data transfer, and the flexibility to use different transport protocols and paths without requiring major changes to the application. </ins> design explains the design principles behind the Transport Services API.  These principles are intended to make sure that
Change:
Fixed text in the API draft to allow reusing Preconnections as discussed in . However, changes to the Preconnection MUST NOT have any effect on the Connections or Listeners created beforehand - I think normative language is useful here to really highlight this possible pitfall. I omitted any note on deep copy as that's just a way to implement this.
Great catch, it makes me wonder why we had closed issue ? Thanks for doing this!Thank you - fix achieved with minimal changes ;-)

Discussion:
to determine a suitable Local Endpoint), as well as all properties necessary for candidate selection. <del> The Initiate() Action consumes the Preconnection.  Once Initiate() has been called, no further properties may be added to the Preconnection, and no subsequent establishment call may be made on the Preconnection. </del> <ins> The Initiate() Action returns a Connection object.  Once Initiate() has been called, any changes to the Preconnection MUST NOT have any effect on the Connection.  However, the Preconnection can be reused, e.g., to Initiate another Connection. </ins> Once Initiate is called, the candidate Protocol Stack(s) may cause one or more candidate transport-layer connections to be created to

Preconnection during the pre-establishment phase with a Local Endpoint specifier, as well as all properties necessary for Protocol Stack selection.  A Remote Endpoint may optionally be specified, to <del> constrain what Connections are accepted.  The Listen() Action returns a Listener object.  Once Listen() has been called, properties added to the Preconnection have no effect on the Listener and the Preconnection can be disposed of or reused. </del> <ins> constrain what Connections are accepted. The Listen() Action returns a Listener object.  Once Listen() has been called, any changes to the Preconnection MUST NOT have any effect on the Listener.  The Preconnection can be disposed of or reused, e.g., to create another Listener. </ins> Listening continues until the global context shuts down, or until the Stop action is performed on the Listener object:

Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. <del> The Rendezvous() Action consumes the Preconnection.  Once Rendezvous() has been called, no further properties may be added to the Preconnection, and no subsequent establishment call may be made on the Preconnection. </del> <ins> The Rendezvous() Action returns a Connection object.  Once Rendezvous() has been called, any changes to the Preconnection MUST NOT have any effect on the Connection.  However, the Preconnection can be reused, e.g., for Rendezvous of another Connection. </ins> The RendezvousDone<> Event occurs when a Connection is established with the Remote Endpoint.  For Connection-oriented transports, this
Change:
This is fully editorial: I'm not sure if the term "Connection Group" is introduced in the right section. There might be no perfect fit but maybe section 2.2 is a bit better? Also I note that the terms "Connection Group" and "Path" do not not show up in any of the figures...
Make this a new subsection, i.e. 4.1.7.
Works - Thank you!

Discussion:
is intended for immediate termination of a connection, without cleaning up state. <ins> 4.1.7. A Connection Group is a set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </ins> 4.2. This section defines the set of objects used internally to a system

transport service across a network, as required by the abstract interface. <del> Connection Group: A set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </del> Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as routes, addresses, and physical and virtual network interfaces.
Change:
Following the suggestion in , made Local Address Preference a Set(Preference, Enumeration), so an application can now also Require or Prohibit stable addresses. Added a sentence warning that, e.g., preferring stable AND temporary addresses does not make sense - but there are less obvious ways to produce a conflicting set of Selection Properties, too, and we know how to deal with them.
Interim discussion: let's use prohibit/avoid/prefer/require temporary addresses. Default connections to prefer temporary. Default listeners to avoid temporary.
Note that it fails without temporary addresses if you require temporary; which makes IPv4 fail.
Simplified this as discussed in the interim. Please take another look.
Looks good to me – But I am unsure whether we should replace the temporary address with a stable address with Preference. Rational: For IPv6 with outgoing connections, temporary is default anyway, so requiring the special case instead of avoid/prohibit the default looks much more straight forward.
I've read this a few times but I'm still not sure: What alternative solution are you proposing here?
I am proposing to Invert the whole name and meaning of the property – instead of requesting a temporary address, request a stable address.
Thanks for clarifying. I think this Property is straightforward enough as is, no need to invert.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
lgtm

Discussion:
5.2.12. <del> local-address-preference </del> <ins> use-temporary-local-address </ins> <del> Enumeration Default: For Listeners and Rendezvous Connections: Stable.  For other Connections: Temporary This property specifies whether Listeners and Connections should prefer the use of temporary addresses when possible.  This is generally used to prevent linking connections over time when a stable address is not needed.  Possible values are: </del> <ins> Preference </ins> <del> Prefer the use of stable (sometimes called "permanent") local addresses </del> <ins> Avoid for Listeners and Rendezvous Connections.  Prefer for other Connections. </ins> <del> Prefer the use of temporary (sometimes called "privacy") addresses </del> <ins> This property allows the application to express a preference for the use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called "permanent" address, is not needed.  Note that if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, as temporary addresses do not exist in IPv4. </ins> 5.2.13.
Change:
Added defaults for interface and PvD following . Also, I caught one leftover "recommended default".
We require implementations to have default but we don't provide any recommendation for interface and PvD.
For Interface, this would the default be to set "Ignore" on all available interfaces, right? This indicates that the application has no preferences of its own, so the implementation can apply some default system policy. Also, if the application specified some local endpoint, this might constrain the actual interfaces used (related to ). If we try to phrase this as (Preference, Enumeration), it reads a bit weird though: ("Ignore", "Cellular") and ("Ignore", "WiFi"), for example. So perhaps we should just write text saying that the default is to set no application preference.
I think text is fine as well but we need to say something.
Thanks!

Discussion:
with RFC2914.  Also note that reliability is usually combined with congestion control in protocol implementations, rendering "reliable but not congestion controlled" a request that is unlikely to succeed. <del> The recommended default is to Require that the Connection is congestion controlled. </del> <ins> The default is to Require that the Connection is congestion controlled. </ins> 5.2.10.

specified via Provisioning Domain attributes (see prop-pvd) or another specific property. <ins> The default is to not set a preference for any interface. </ins> 5.2.11. pvd

specific PvD instances or interface instances, and should be preferred over these options. <ins> The default is to not set a preference for any PvD. </ins> 5.2.12. local-address-preference