jiebi/CodeConvo huggingface dataset:
Code change:
Servers MUST drop incoming packets under all other circumstances. <ins> 5.2.3. A server deployment could load balance among servers using only source and destination IP addresses and ports.  Changes to the client's IP address or port could result in packets being forwarded to the wrong server.  Such a server deployment could use one of the following methods for connection continuity when a client's address changes. Servers could use an out-of-band mechanism to forward packets to the correct server based on Connection ID. If servers can use other dedicated server IP addresses or ports than the one that the client initially connects to, they could use the preferred_address transport parameter to request that clients move connections to these dedicated addresses.  Note that clients could choose not to use the preferred address. A server in a deployment that does not implement a solution to maintain connection continuity during connection migration SHOULD disallow migration using the disable_active_migration transport parameter. Server deployments that use this simple form of load balancing MUST avoid the creation of a stateless reset oracle; see reset-oracle. </ins> 5.3. A QUIC connection is a stateful interaction between a client and

Related discussion:
text: This is sort of ops-drafty but there real requirements on servers to behave in a secure way. I think someone with full command of the transport draft would figure this out, but it is not clearly stated anywhere.
I agree with Martin Duke and the language he suggests makes sense to me.
This does feel a bit ops-drafty to me, but I'd be happy to review a PR.
I'm sure that this is now basically unrecognizable...Some more suggestions, but overall this LG
Code change:
contains the information about the plain text or encryption process that is to be integrity protected.  The field is encoded <del> in CBOR as a 'bstr' if present and the value 'null' if there is no </del> <ins> in CBOR as a 'bstr' if present and the value 'nil' if there is no </ins> data.  The contents of the protected field is a CBOR map of the protected data names and values.  The map is CBOR encoded before placing it into the bstr.  Only values associated with the current

Related discussion:
text: The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.
Code change:
recommended) as defined by RFC8447.  The following entries are to be updated: <del> Other entries of the resgistry remain the same. </del> <ins> Other entries of the registry remain the same. </ins> 9. Concerns with TLS 1.2 implementations falling back to SHA-1 is an <del> issue.  This draft updates the TLS 1.2 specification to deprecate </del> <ins> issue.  This document updates the TLS 1.2 specification to deprecate </ins> support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.

Related discussion:
text: NAME thanks, updated with the additional changes.
NAME NAME NAME Feel free to merge when you get a chance
Great! Now on to Daniel's comments.
Code change:
to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a <del> client instance at runtime through the response-dynamic-handles or MAY be obtained in another fashion, such as a static registration process at the AS. </del> <ins> client instance at runtime through a grant response (response- dynamic-handles) or MAY be obtained in another fashion, such as a static registration process at the AS. </ins> When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:
Code change:
7. QUIC version 1 without extensions uses an acknowledgment strategy <del> adopted from TCP.  That is, every other packet is acknowledged. However, generating and processing QUIC acknowledgments can consume significant resources, both in terms of processing costs and link utilization, especially on constraint networks.  Some applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </del> <ins> adopted from TCP Section 13.2 of RFC9000).  That is, it recommends every other packet is acknowledged.  However, generating and processing QUIC acknowledgments consumes resources at a sender and receiver.  Acknowledgments also incur forwarding costs and contribute to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </ins> 8.

Related discussion:
text: Suggesting a rewording to clarify various issues and correct some mistakes.
Previously scope of this text was agreed, but what appeared seems to me to have various NiTs: • Saying "every other packet is acknowledged" is a recommendation in RC9000. I suggest citing also. • The text seems to conflate endpoint processing optimisation, and network path performance optimisation: /constraint/ wasn't the correct word, but even /constrained/ was a value judgment on design traedoffs for any mobile/RF link - and many bandwidth-limited cabled link, which could be avoided by simply saying what is intended and saying either /which can impact performance of some types of network/ or /which can impact performance across some types of network/ ... depending on your viewpoint as an operator or application. • I think we can do better than URL, suggesting removing some and leaving might. This might be resolved in a PR .
Code change:
order things are sent and the application data MAY therefore be sent before a NewSessionTicket.  TLS application data 0x00 is therefore to be interpreted as success after the EAP-Request that contains TLS <del> application data 0x00.  After the EAP-TLS server has received an empty EAP-Response to the EAP-Request containing the TLS application data 0x00, the EAP-TLS server sends EAP-Success. </del> <ins> application data 0x00.  After the EAP-TLS server has sent an EAP- Request containing the TLS application data 0x00 and received an EAP- Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server sends EAP-Success. </ins> figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest

Related discussion:
text: URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".
Code change:
The endpoint uses RTT samples and peer-reported host delays (see Section 13.2 of QUIC-TRANSPORT) to generate a statistical description of the network path's RTT.  An endpoint computes the following three <del> values for each path: the minimum value observed over the lifetime of the path (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </del> <ins> values for each path: the minimum value over a period of time (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </ins> 5.1.

Related discussion:
text: This should be fixed. I've sent out .
The natural question that follows will be "which period of time", but I think that is already.Thanks, LG
Code change:
application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are <del> consistent with those it expected.  For example, if the ALPN value has changed, it is likely unsafe to retransmit the original </del> <ins> consistent with those it expected.  For example, if the selected ALPN protocol has changed, it is likely unsafe to retransmit the original </ins> application layer data. 4.2.9.1.

Related discussion:
text: 1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.
Code change:
In this document, we describe a protocol based on tree structures that enable asynchronous group keying with forward secrecy and post- compromise security.  Based on earlier work on "asynchronous <del> ratcheting trees" art, the mechanism presented here use a </del> <ins> ratcheting trees" art, the protocol presented here uses an </ins> asynchronous key-encapsulation mechanism for tree structures.  This mechanism allows the members of the group to derive and update shared keys with costs that scale as the log of the group size.

Related discussion:
text: Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Code change:
For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the <del> string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) </del> <ins> string in Internet Extended Date/Time Format (IXDTF).  (An application might require the presence of specific suffix tags, though.) </ins> Without further indication, they are also <del> : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </del> <ins> : Even if included in the IXDTF string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </ins> A suffix tag may also indicate that it is <del> : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </del> <ins> : The recipient is advised that it MUST not act on the Internet Extended Date/Time Format (IXDTF) string unless it can process the suffix tag as specified.  A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </ins> <del> Internet Date/Time Format strings such as: </del> <ins> IXDTF strings such as: </ins> are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for

Related discussion:
text: We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks
Code change:
Abort terminates a Connection without delivering remaining data: <del> A ConnectionError can inform the application that the other side has aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. </del> <ins> A ConnectionError informs the application that data to could not be delivered after a timeout, or the other side has aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. </ins> 11.

Related discussion:
text: Notable changes: added control over using multipath (which was a late addition to minset) added a timeout for conn. establishment, separate from the other conn. abort timeout (see ) renamed InitiateWithIdempotentSend into InitiateWithSend, and adjusted the text to recommend declaring idempotence. This addresses the minset function that goes back to TCP's send-with-SYN.
Status: NAME said "LGTM modulo tiny nits" and I think these nits are now addressed. NAME requests something more than just a boolean to enable/disable usage of multiple paths. It seems to me that this needs more discussion, but it also doesn't seem like a show-stopper for the boolean to begin with; I think we can discuss this more after landing this PR. NAME hasn't reacted (or am I missing this), but this has an ok from NAME and NAME In conclusion: I think this is good to go. I'll wait until tomorrow; unless someone speaks up by then, I'll merge this PR.
If you make it a boolean it cannot be used as a selection property, so I do not think that is a good choice. Or how should it be interpreted for the selection?
NAME what do you mean, that it should be a (binary - yes/no) Preference instead? I thought this would be more limiting but I'm fine with this as well.
NAME I meant that it should be a Preference as pointed out in the original comment by NAME I do not understand what a boolean means during selection (is it a requirement or a preference?) I also do not understand what it means in the middle of a connection. You mean you should try and use a single or several subflows for scheduling data, assuming you already have a multipath connection? I guess this is possible, but then the description needs to be more clear that this is what it means. In the appendix about minset your have "Disable MPTCP: "Parallel Use of Multiple Paths" Property." I assume this refers to the Protocol Selection phase? It does not make sense to disable or enable MPTCP in the middle of a connection I think. I guess part of how to specify the property depends on how to interpret this part from the intro to the Managing Connections section: "The application can set and query Connection Properties on a per-Connection basis.
Code change:
Abort terminates a Connection without delivering remaining data: <del> A ConnectionError can inform the application that the other side has aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. </del> <ins> A ConnectionError informs the application that data to could not be delivered after a timeout, or the other side has aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. </ins> 11.

Related discussion:
text: Connection Properties that are not read-only can be set during pre-establishment (see {{selection-props}}), as well as on connections directly using the SetProperty action" I interpreted this as properties set during pre-establishment are selection properties, but maybe this is not the intention as they may need to be expressed differently? If they are not intended as selection properties, we are missing a selection property for multipath I guess.
NAME Ok. That's what I meant, yes - but I agree that's not covered by the description, it really is a selection preference only as it's written now. OK (though you CAN do it with the "real" API, by closing subflows, but this goes beyond the spec'd protocol, and I'm also not sure it's a good idea, especially when limited to only enabling / disabling it altogether). I would have understood this as in your first interpretation: "properties set during pre-establishment are selection properties".
NAME Closing a subflow is not the same as disabling MPTCP to me. You will still be using MPTCP, only with a single subflow. And you can certainly not open a subflow unless MPTCP is already enabled. But seems we now have a common understanding.
NAME ack, we've converged. I just pushed a commit that turns the "Parallel Use of Multiple Paths" property into a Selection property.
these are a few minor changes to apply, and properties to add (e.g. "disable MPTCP")
this is done, yes?
No. But I'm planning to do a PR to address this issue this week.
Note that this also requires closing , which I re-opened with a concrete proposal to address something from minset.
LGTM modulo tiny nitsSorry, missed this until just now. Looks fine with me, I just have a small question and my 2 cents to the multipath discussion (which we can have at a later point).
Code change:
result MAY be used by the client instance in the request- capabilities of the request. <del> OPTIONAL.  A list of the AS's interaction methods.  The values of this list correspond to the possible fields in the request- interact of the request. </del> <ins> OPTIONAL.  A list of the AS's interaction start methods.  The values of this list correspond to the possible values for the request-interact-start of the request. OPTIONAL.  A list of the AS's interaction finish methods.  The values of this list correspond to the possible values for the method element of the request-interact-finish of the request. </ins> OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the

Related discussion:
text: The discovery fields for the interaction methods were still in a single list, even though those have now been split into start and finish sections.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 754d971b07753b2b9580c2c6f0b3c8997c34b260 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Yes, makes sense
Code change:
Each leaf is given an _index_ (or _leaf index_), starting at "0" from the left to "n-1" at the right. <ins> Finally, a node in the tree may also be _blank_, indicating that no value is present at that node (i.e. no keying material).  This is often the case when a leaf was recently removed from the tree. </ins> There are multiple ways that an implementation might represent a ratchet tree in memory.  For example, left-balanced binary trees can be represented as an array of nodes, with node relationships computed

Related discussion:
text: The definition of blank node needs to move ahead into ## Ratchet Tree Terminology as it is used in the section immediately following (## Views of a Ratchet Tree).
Code change:
could choose to send Messages of different Priority on streams of different priority. <del> Ordered: when this is false, it disables the requirement of in- </del> <ins> Ordered: when this is false, this disables the requirement of in- </ins> order-delivery for protocols that support configurable ordering. <del> Safely Replayable: when this is true, it means that the Message </del> <ins> Safely Replayable: when this is true, this means that the Message </ins> 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. <del> Final: when this is true, it means that a transport connection can be closed immediately after its transmission. </del> <ins> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. </ins> Corruption Protection Length: when this is set to any value other than -1, it sets the minimum protection in protocols that allow

Related discussion:
text: Changes to address Issue
Message Properties This isn’t really about /removing/ we need to express this differently, not sure what you wish to say: For example, TCP cannot remove bytes from its send buffer, while in case of SCTP, such control over the SCTP send buffer can be exercised using the partial reliability extension [RFC8303]. and: /Final: when this is true, it means that a transport connection can be closed immediately after its transmission./ I think this is: /Final: when this is true, it means that a transport connection can be closed immediately after transmission of the message./
See PR Update draft-ietf-taps-URL
Looks good, just some more nits on top