jiebi/CodeConvo huggingface dataset:
Change:
applications like videoconferencing, or for other live-action video with interactive components, such as some sporting events. <del> Congestion avoidance strategies for this kind of deployment vary widely in practice, ranging from some streams that are entirely unresponsive to using feedback signaling to change encoder settings (as in RFC5762), or to use fewer enhancement layers (as in RFC6190), to proprietary methods for detecting quality of experience issues and cutting off video. </del> <ins> The Secure Reliable Transport protocol SRT also uses UDP in an effort to achieve lower latency for streaming media, although it adds reliability at the application layer. Congestion avoidance strategies for deployments using unreliable transport protocols vary widely in practice, ranging from being entirely unresponsive to congestion, to using feedback signaling to change encoder settings (as in RFC5762), to using fewer enhancement layers (as in RFC6190), to using proprietary methods to detect "quality of experience" issues and turn off video in order to allow less bandwidth-intensive media such as audio to be delivered. More details about congestion avoidance strategies used with unreliable transport protocols are included in udp-behavior. </ins> 5. <del> **Note to Reviewers^^ - this section includes some material that may be tutorial for some readers.  We can decide how to say that, if the tutorial material is worth keeping.  Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless you participated in the QUIC working group. </del> <ins> *Note to Reviewers* This section includes some material on UDP and TCP that may be tutorial for some readers.  We can decide how to explain that, if the working group feels that this tutorial material is worth keeping. Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless the reader participated in the QUIC working group. </ins> Because networking resources are shared between users, a good place to start our discussion is how contention between users, and

Discussion:
Also clarified relationship with UDP Behaviors section
I think this is ready to merge. Opinions?
I was more concerned about overlap when I opened , but what's in the section on Unreliable Transport and what's in the section on UDP behaviors seems to read pretty well to me. Opinions?
SRT, TS-Multicast over UDP, etc.
I THINK this is requesting a change in the "Unreliable Transport" section.
I think this one is also ready to close. Opinions?
Change:
Note: Alerts and any other record types are not handshake messages and are not included in the hash computations. <ins> Any records following a 1-RTT Finished message MUST be encrypted under the application traffic key.  In particular, this includes any alerts sent by the server in response to client Certificate and CertificateVerify messages. </ins> 4.4. TLS also allows other messages to be sent after the main handshake.

Discussion:
(My impression from the list is that we're not doing post-handshake key separation. If I'm wrong and we are, this will need to be slightly tweaked. Anyway, the current state of the world is we don't do it, so I've worded it accordingly.) As the Finished message is an implicit ChangeCipherSpec, it's worth clarifying that this is the point at which the cipher state changes. Should an implementation not send half-RTT data, it may defer switching traffic keys until both Finished messages have been exchanged. This will not work well, as alerts sent in response to a bad client certificate will be unreadable. The outgoing traffic keys must be switched early.
Change:
Identify the leaf L for the new member: if there are empty leaves in the tree, L is the leftmost empty leaf.  Otherwise, the tree is <del> extended to the right by one leaf node and L is the new leaf. </del> <ins> extended to the right as described in adding-and-removing-leaves and L is assigned the leftmost new blank leaf. </ins> For each non-blank intermediate node along the path from the leaf L to the root, add L's leaf index to the "unmerged_leaves" list

Discussion:
This PR fixes small issues that I noticed while implementing proposal validation and fixing some external join bugs: The pseudocode for determining whether a path is required assumes that all proposals are by-reference. The PR updates the pseudocode to be more general, and also account for proposals by value. There were two references to adding a single leaf to the tree, which are updated to make clear that the tree grows by doubling, not by single leaves. There was no current requirement that an Update proposal have a distinct , so one is added.
Change:
preferred_address transport parameter. An endpoint SHOULD ensure that its peer has a sufficient number of <del> available and unused connection IDs.  Endpoints store received connection IDs for future use and advertise the number of connection IDs they are willing to store with the active_connection_id_limit transport parameter.  An endpoint MUST NOT provide more connection IDs than the peer's limit.  An endpoint that receives more connection IDs than its advertised active_connection_id_limit MUST close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. </del> <ins> available and unused connection IDs.  Endpoints advertise the number of active connection IDs they are willing to maintain using the active_connection_id_limit transport parameter.  An endpoint MUST NOT provide more connection IDs than the peer's limit.  An endpoint MAY send connection IDs that temporarily exceed a peer's limit if the NEW_CONNECTION_ID frame also requires the retirement of any excess, by including a sufficiently large value in the Retire Prior To field. A NEW_CONNECTION_ID frame might cause an endpoint to add some active connection IDs and retire others based on the value of the Retire Prior To field.  After processing a NEW_CONNECTION_ID frame and adding and retiring active connection IDs, if the number of active connection IDs exceeds the value advertised in its active_connection_id_limit transport parameter, an endpoint MUST close the connection with an error of type CONNECTION_ID_LIMIT_ERROR. </ins> An endpoint SHOULD supply a new connection ID when the peer retires a connection ID.  If an endpoint provided fewer connection IDs than the

Discussion:
The rules for the active connection ID limit were such that the brief bump that NEWCONNECTIONID + Retire Prior To could add was not permitted. Strictly speaking, if you requested retirement, the connection IDs that you requested be retired are still active until you receive a RETIRECONNECTIONID frame. That means that you were technically violating this MUST in the spec. Adding an exception for this case was the best way I could see to fix this. The other was to change the definition of "active connection ID". I tried that and, while it was a smaller change, it made the definition less crisp. This approach seems best. (This is not new normative requirements as this is already .)
LGTMThanks for making (yet) another attempt to clarify this. Looks good.
Change:
concerned about this form of attack can discard out-of-epoch records. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in DTLS-CID.  There are, however, several improvements: </del> <ins> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </ins> The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with

Discussion:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.
Change:
they need to update their GroupState with information about the new member: <ins> The "index" field indicates where in the tree the new member should be added.  The new member can be added at an existing, blank leaf node, or at the right edge of the tree.  In any case, the "index" value MUST satisfy "0 <= index <= n", where "n" is the size of the group.  The case "index = n" indicates an add at the right edge of the tree).  If "index < n" and the leaf node at position "index" is not blank, then the recipient MUST reject the Add as malformed. </ins> A group member generates this message by requesting a UserInitKey from the directory for the user to be added, and encoding it into an Add message.

Discussion:
Right now, we blank out leaf nodes when we remove their holders, but we never reduce the size of hte tree or repopulate interior blanks with new members. This PR adds those functions: Reduce the size of the tree and the roster when you remove from the right edge Add an field to the message, to enable new members to be added to blank slots in the tree, not just at the right edge. In addition to performing "garbage collection", this change should make it easier to do a state resync -- just remove the desync'ed endpoint and add them back in the same spot.
NAME Do you think this is ready to merge? say it's OK as long as we can convince ourselves that truncation preserves the tree invariant. Proof sketch: The tree invariant is a universal statement over nodes in the tree and members in the group: ! Since subtrees are just subsets of the set of nodes in the tree, if the tree invariant holds for a given tree, then it also holds for any subtree of that tree. So since truncation just moves from a tree to a subtree, the invariant continues to hold.
Currently, the tree only ever grows: When you add someone, you have to add them at the right edge, even if there are blank leaves When you remove someone, the tree never shrinks We should enable reclaiming of blank leaves and automatically reduce the size of the tree to the minimum necessary size.
After discussion at 2019-01 interim: Agreement that this seems OK as long as we can verify that the tree invariant holds when you truncate the tree.
Change:
bytes. An opaque blob that the client can use with a future Initial <del> packet.  The token MUST NOT be empty.  An endpoint MUST treat receipt of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> packet.  The token MUST NOT be empty.  A client MUST treat receipt of a NEW_TOKEN frame with </ins> <del> An endpoint might receive multiple NEW_TOKEN frames that contain the </del> <ins> A client might receive multiple NEW_TOKEN frames that contain the </ins> same token value if packets containing the frame are incorrectly <del> determined to be lost.  Endpoints are responsible for discarding </del> <ins> determined to be lost.  Clients are responsible for discarding </ins> duplicate values, which might be used to link connection attempts; see validate-future. <del> Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt </del> <ins> Clients MUST NOT send NEW_TOKEN frames.  A server MUST treat receipt </ins> of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION.

Discussion:
Since only servers can send NEW_TOKEN, using "client" is clearer. "Servers MUST treat" is used only here, so it is changed into "A server MUST treat".
Please see the for full context. This issue is tracking the following IANA question: >IANA Question --> Section 22.1.2 says, "Applications to register codepoints in QUIC registries MAY include a codepoint as part of the registration. IANA MUST allocate the selected codepoint unless that codepoint is already assigned or the codepoint is the first unallocated codepoint in the registry."
I think it is a good question that has two aspects. If a registrant is requesting additional consecutive values beyond an earlier registration is that okay? But other registrants they need to draw a new random value to not block the next value? Or any future allocation should have to select a new random value? Also, is it IANA or the designated expert that is making the determination if this request is allowed or not?
I think what this is intended to convey is: Permanent registrations for the first unallocated codepoint are intended for use in Standards-track documents The "negotiation" involved in a provisional registration is essentially to confirm that the requestor is doing so for use in a document which is likely to become a Standards-track RFC. It's the "likely to" that becomes squishy. Do we actually need this?
So in I have a comment that indicates a potential solution or direction for how to work with this using either of two process that will be clearer. Either provisional for test and development value and then assign a final value when approving the specification, or early allocation per RFC 7120. I also like to point out that there is very large hole in this algorithm. If a registry has assigned 0-N then asking for N+1 is rejected, but asking for N+2 is the approved without question per these rules unless you are in a registry with the special rules for 0-63 values.
Could we make some progress here?
I think fixes this too. NAME ?
This was fixed by
Thanks, NAME !
Change:
and functional characteristics, and it can communicate with different Remote Endpoints to optimize performance.  Beyond these, if the API for the system remains the same over time, new protocols and features <del> may be added to the system's implementation without requiring significant changes in applications for adoption. </del> <ins> may be added to the system's implementation without requiring changes in applications for adoption. </ins> The following considerations were used in the design of this architecture.

Discussion:
seeing no comment... :)
Sorry, looks good =) Busy week over here!
See thread at URL Suggested resolution: implementation must have a deterministic tiebreaker, current recommendation is that path properties take precedence. API should note expected behavior. There should be additional text on candidate selection and ordering.
Give example for path candidate gathering and sorting (get selection properties, get available paths in system preferred order, walk through them cancelling out the prohibited ones, and ranking preferences; get ultimate list). Do the same for protocols likely.
Added text to API and Implementation drafts on branch "conflicting-policies". API has an example, implementation still needs one. Feel free to add, otherwise I'll come back to it later today or tomorrow.
I guess that works for -00 For -01, we might want to integrate the resolution a little bit more into the decision process.
Resolved by PR
The Sec Con section contains a large number of unexpanded abbreviations. Compared to the remainder of the document this requires much more knowledge of these terms, suggest we expand them here.
The sentence reads: Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring significant changes in applications for adoption. However, this kind of suggests that some small change is needed to apps. That's not necessarilly true, and I think the key point is the converse (i.e, 3.1 below). Can I suggest: Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring changes in applications for adoption. Hi, I made this comment in the past in QUIC when discussing migration. One policy may be prefer wifi over cellular network, Second policy prefers quic cove TCP Now I walk into my house and my cellphone has HTTP over QUIC. At home will switch to wifi but quic is not supported on the wifi so will fall back to TCP. This contradicts the second policy. So two options wifi TCP or cellular QUIC , how to decide? Roni Even
Change:
by refusing to emit output shares. Input validity proof forging.  Any aggregator can collude with a <del> malicious client to craft a proof share that will fool honest </del> <ins> malicious client to craft a proof that will fool honest </ins> aggregators into accepting invalid input. 6.1.2.3.

Discussion:
Remove terms which are infrequently used (and in a few cases, remove the unnecessary references) Clean up a few terms which appear to be defined incorrectly.
Change:
condition: an attempt to send a Message which is too large for the system and Protocol Stack to handle, some failure of the underlying Protocol Stack, or a set of Message Properties not consistent with <del> the Connection's transport properties.  The SendError contains an implementation-specific reference to the Message to which it applies. </del> <ins> the Connection's transport properties.  The SendError contains a reference to the Message to which it applies. </ins> 7.4.

Discussion:
Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message. If it does, the "reason" parameter can point to that message and/or a messageContext. The beginning of Section 7 actually already said that this IS the messageContext. I removed the word "implementation-specific" because to me this word made it sound like this reference can't be the messageContext. Split into two sentences and changed the second sentence to active voice. Also, I slightly reworded the beginning of Section 7, which is now a bit clearer in my opinion.
When reading the current API draft, I found three minor issues related to Message Contexts. The RendezvousError (Section 6.3) includes a messageContext (which is even required), but neither the InitiateError nor the ListenError include one. Why? Should this messageContext at least be optional?In Section 7.3, it says "The Sent Event contains an implementation-specific reference to the Message to which it applies." - Is this in addition to the messageContext? If yes, why do we need both?In Section 9, it says "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." - I think this sentence is a bit hard to parse and it wasn't immediately obvious to me what kind of framing meta-data this refers to. Perhaps this refers to Section 10.2, so I think it's worth adding a reference to that section here. Also, I suggest turning this into two sentences, with the sentence on framing meta-data specifying that this is per-Message metadata to be used by the framer.
Thanks a lot for doing this! It clears things up nicely, I think.
Change:
secrets and the handshake transcript.  Note that because the handshake transcript includes the random values in the Hello messages, any given handshake will have different traffic secrets, <del> even if the same input secrets are used, as is the case when +the same PSK is used for multiple connections </del> <ins> even if the same input secrets are used, as is the case when the same PSK is used for multiple connections </ins> 7.1.

Discussion:
This is how NSS behaves as well. This seems like a reasonable argument.
added the changes previously discussed.
I did not verify that the moved text is only move and no edits, but the other chunks seem okay.
NAME are you OK with this SHOULD?
Sounds reasonable. Mostly I just don't want to encourage servers to enforce anything about this.
Change:
The RTCP feedback extensions MUST only include those that are present in the most recent answer. <del> The "a=rtcp" line MUST only be added if the most recent answer did not include an "a=rtcp-mux" line. </del> <ins> The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. </ins> <del> The "a=rtcp-mux" line MUST only be added if present in the most </del> <ins> The "a=rtcp-mux" line MUST NOT be added unless present in the most </ins> recent answer. The "a=rtcp-mux-only" line MUST NOT be added. <del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. </del> <ins> The "a=rtcp-rsize" line MUST NOT be added unless present in the most recent answer. </ins> An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP

Discussion:
The bullets on page 45 use the construct "MUST only" three times. This is confusing, and likely to lead to implementors doing the wrong thing. Please rewrite in the form "The 'a=rtcp' line MUST NOT be added unless..."
In the section "Subsequent Offers" we have the text o The RTCP feedback extensions MUST only include those that are present in the most recent answer. o The "a=rtcp" line MUST only be added if the most recent answer did not include an "a=rtcp-mux" line. o The "a=rtcp-mux" line MUST only be added if present in the most recent answer. Next step - Rewrite as adam suggested.
This works for me.
Change:
"subjectPublicKeyAlgorithm" element, respectively. If authentication credentials are CBOR Web Tokens (CWTs) or CWT <del> Claims Sets (CCSs) RFC8392, the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters. </del> <ins> Claims Sets RFC8392, the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters. </ins> Authentication credentials are used to derive pairwise keys (see key- derivation-pairwise) and are included in the external additional

Discussion:
So far, it was used 1x in abbreviated form, and 2x as "CWT Claims Sets (CCS)". The abbreviation was problematic the way it was used while being a reference into RFC8392, it was not defined there. I'm not 100% happy with dropping the term "CCS" because it having an abbreviation is a good pointer for users to see that this is an established, good and compact thing to use (right?), but I'd rather spare readers the confusion of clicking through to 8392 and not finding the letters "CCS". I'd be happy with any better handling of the possible confusion, this is just the best I'm coming up with.
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-08 Change ClientInitKeys so that they only refer to one ciphersuite (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)

Discussion:
Merging myself because this is trivial.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :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 .