jiebi/CodeConvo huggingface dataset:
Change:
If necessary, extend the tree to the right until it has at least index + 1 leaves <del> For each intermediate node along the path from the leaf at position "index" to the root, add "index" to the "unmerged_leaves" list for the node. Blank the path from the leaf at position "index" to the root </del> <ins> For each non-blank intermediate node along the path from the leaf at position "index" to the root, add "index" to the "unmerged_leaves" list for the node. </ins> Set the leaf node in the tree at position "index" to a new node containing the public key from the ClientInitKey in the Add, as

Discussion:
Blanking on add (I think) was obsoleted by unmerged leaves Add leaf to unmerged list for non-blank nodes on add There are now four elements in each node
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :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 .
Nice catch, Thank you !
Change:
The next two bits (those with a mask of 0x30) of byte 0 contain a packet type.  Packet types are listed in long-packet-types. <del> The lower four bits (those with a mask of 0x0f) of byte 0 are type-specific. </del> <ins> The semantics of the lower four bits (those with a mask of 0x0f) of byte 0 are determined by the packet type. </ins> The QUIC Version is a 32-bit field that follows the first byte. This field indicates the version of QUIC that is in use and

Discussion:
So I rewrote the sentence instead.
packet-type-specific?
Rob Wilton said:
In this case, you can simply do "type specific", since type-specific is not an adjective before a noun (like "type-specific bits"). But this is good too.
Change:
When (EC)DHE is in use, the server will also provide a "key_share" extension. <del> When authenticating via a certificate (i.e., when a PSK is not in use), the server will send the Certificate (certificate) and CertificateVerify (certificate-verify) messages. </del> <ins> When authenticating via a certificate, the server will send the Certificate (certificate) and CertificateVerify (certificate- verify) messages.  In TLS 1.3 as defined by this document, either a PSK or a certificate is always used, but not both.  Future documents may define how to use them together. </ins> If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters),

Discussion:
I think this addresses the issue raised by Russ Housley without changing the semantics of the protocol.
I will give a post-merge "seems fine", since I was so vocal in trying to nail down what Russ wanted.
Mentions of non-existent yet RFCs look weird to me but heh
Change:
7.2. The responder MUST NOT delay sending an elicited "path_response" <del> or "path_delete" messages. </del> <ins> or "path_drop" messages. </ins> <del> The responder MUST send exactly one "path_response" or "path_delete" message for each received "path_challenge". </del> <ins> The responder MUST send exactly one "path_response" or "path_drop" message for each received "path_challenge". </ins> <del> The responder MUST send the "path_response" or the "path_delete" on the path where the corresponding "path_challenge" has been </del> <ins> The responder MUST send the "path_response" or the "path_drop" on the path where the corresponding "path_challenge" has been </ins> received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour.

Discussion:
Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop
Change:
not be supported. This document proposes an overall solution to this problem by <del> registering ephemeral mDNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates.  WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </del> <ins> registering ephemeral mDNS RFC6762 names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </ins> 2.

Discussion:
From the 'nits' link on top of the IETF submitted version. ** The abstract seems to contain references ([RFC6762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question.
Probably can just move the ref to the intro section.
URL
LGTM
Change:
a description of how common network management practices will be impacted by QUIC. <del> QUIC is an end-to-end transport protocol.  No information in the protocol header, even that which can be inspected, is mutable by the network.  This is enforced through integrity protection of the wire </del> <ins> QUIC is an end-to-end transport protocol; therefore, no information in the protocol header is intended to be mutable by the network. This property is enforced through integrity protection of the wire </ins> image WIRE-IMAGE.  Encryption of most transport-layer control signaling means that less information is visible to the network than is the case with TCP.

Discussion:
Wire image mutability is more subtle than "is completely immutable", and we get into the details later. New text is sufficient as contrast for TCP.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...
Change:
The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any <del> true expression, such as "1 == 1", and "F" is any false expression, such as "1 == 0"): </del> <ins> expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"): </ins> 3.5.8.3.

Discussion:
Fixes URL
Let's continue in URL
Currently the syntax section of the "Filter Selector" section describes some semantics. These descriptions should be folded into the semantics section.
I'm not sure we are done with this yet. See comments.The reordering looks good to me.
Change:
as described in header-parameters. <del> contains the encrypted key encoded as a bstr.  If there is not an encrypted key, then this field is encoded as a nil value. </del> <ins> contains the encrypted key encoded as a bstr.  All encoded keys are symetric keys, the binary value of the key is the content.  If there is not an encrypted key, then this field is encoded as a nil value. </ins> contains an array of recipient information structures.  The type for the recipient information structure is a COSE_recipient.  (An

Discussion:
Some more edits in response to the review. Does not include one item that was proposed for clarification
Change:
As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with <del> ephemeral Diffie-Hellman and provides a KeyUpdate function for lightweight application protocol rekeying with forward secrecy, in the sense that compromise of the private authentication keys does not </del> <ins> ephemeral Diffie-Hellman.  This provides forward secrecy, in the sense that compromise of the private authentication keys does not </ins> compromise past session keys, and compromise of a session key does <del> not compromise past session keys. While the KeyUpdate method can be used to meet cryptographic limits and provide partial protection against key leakage, it provides significantly weaker security properties than re-running EDHOC with ephemeral Diffie-Hellman.  Even with frequent use of KeyUpdate, compromise of one session key compromises all future session keys, and an attacker therefore only needs to perform static key exfiltration RFC7624.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration instead of static key exfiltration RFC7624.  In the dynamic case, the attacker must have continuous interactions with the collaborator, which is more complicated and has a higher risk profile than the static case. </del> <ins> not compromise past session keys.  Frequently re-running EDHOC forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, which is a significant complication. </ins> To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to

Discussion:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.
Change:
The SDP for |offer-C1| looks like: <del> The SDP for |offer-C1-candidate-1| looks like: </del> <ins> |offer-C1-candidate-1| looks like: </ins> The SDP for |answer-C1| looks like: <del> The SDP for |answer-C1-candidate-1| looks like: </del> <ins> |answer-C1-candidate-1| looks like: </ins> The SDP for |offer-C2| looks like:

Discussion:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward
Change:
consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- manageability (for HTTP/3 and QUIC). <del> 5.3. </del> <ins> 4.3. </ins> "End-to-end" media encryption offers the potential of providing privacy for streaming media consumers, with the idea being that if an

Discussion:
Reverts ietf-wg-mops/draft-ietf-mops-streaming-opcons (still learning github)
Change:
activity correlated by any entity other than their peer, so different connection IDs are used when sending from different local addresses, as discussed in connection-id.  For this to be effective endpoints <del> need to ensure that connections IDs they provide cannot be linked by </del> <ins> need to ensure that connection IDs they provide cannot be linked by </ins> any other entity. At any time, endpoints MAY change the Destination Connection ID they

Discussion:
The editors assumed this was true, but I think it's worth stating this as a MUST to ensure clarity.
I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?
Also, when ACKs packets don't fit in packets, this would also hold for ACK'ing ack-eliciting packets. So you could end up having to not ACK'ing some packets and induce loss. Requiring an ACK for all packets would be problematic. I'm not sure we want that. The result could be very hard to implement while the practical benefit would be small: sending multiple ACK packets with different content due to overflow.
I just synced to master and now this seems to be an editorial change, at least to me. That being said, PTAL at the text and tell me if there are any other changes I should make.
It appears that the spec doesn't actually require sending ACKs for every ACK-eliciting packet. This could lead to a perverse implementation just not ACKing things with obvious problems.
Discussed in Cupertino. Add normative language to prescribe what should be ACKed. Reclassifying as Editorial (adds normative language, but we have consensus on that).
Generally looks good, but I don't think we can have an absolute requirement that every ack-eliciting packet is acknowledged.
Change:
T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded. <ins> Basically the "struct" notation is used in the top level to define a new type.  However, there is one exception that an anonymous structure "struct {}", which means empty, can be used inside of another structure. </ins> 3.6.1. Defined structures may have variants based on some knowledge that is

Discussion:
To let's add some explanations to Section 3.
I have written a syntax validator to check the validity of definitions. In this issue, I would like to point out what I noticed.
(1) Some enum definitions use "floor..ceiling" notation which is not defined. Section 3.5 should clearly define this.
(2) I think that the keyword is allowed only in the top level definitions. But is used inside of EarlyDataIndication. I would suggest to defined the following in the top level:
(3) The following assignment is really strange: I would suggest to change this to:
On Wednesday, September 07, 2016 04:24:15 am Kazu Yamamoto wrote: I don't understand why you consider this current notation here strange. It's the same notation used for enum values elsewhere.
What I can tell from Section 3 is as follows: The "symbol(num)" notation is allowed in the declaration of enum. "symbol" can be used as label of the case clause. "{num, ...}" can be used for assignment. I don't see that "symbol(num)" can be used for assignment. I wrote a parse based on Section 3 and what I reported here is the errors reported by the parser.
Change:
If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be <del> used for sending media. </del> <ins> used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in accordance with RFC7022 and sec.cname. </ins> If a local MediaStreamTrack has been associated, and RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
The implementation stores these properties as a part of the Preconnection object for use during connection establishment.  For Selection Properties that are not provided by the application, the <del> implementation must use the default values specified in the Transport </del> <ins> implementation uses the default values specified in the Transport </ins> Services API (I-D.ietf-taps-interface). 3.1.

Discussion:
Two items here: Normative MUST? I guess this is just a guidance document so doesn't need anything normative. There's some later "should" as well which I would generally ask the same question for. but... here we have some NORMATIVE language. That SHOULD should probably be non-capitalised to align with earlier usage. (and so on later in the document, e.g. in the SCTP description)
The first one can just be "uses the default values", without normative text. Second one can be lowercase as well. SCTP has normative SHOULDs and MUSTs that can be removed.
Change:
cookies (RFC6265) should not be set.  There is no indication in a domain name whether it is a public suffix; that can only be determined by outside means.  In fact, both a domain and a <del> subdomain of that domain can be public suffixes.  At the time this document is published, the IETF DBOUND Working Group DBOUND is dealing with issues concerning public suffixes. </del> <ins> subdomain of that domain can be public suffixes. </ins> There is nothing inherent in a domain name to indicate whether it is a public suffix.  One resource for identifying public suffixes

Discussion:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.
Change:
The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication post-handshake- <del> authentication.  Servers MUST not send a post-handshake </del> <ins> authentication.  Servers MUST NOT send a post-handshake </ins> CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension.

Discussion:
The TLSPlaintext size is at most 2^14, so the TLSInnerPlaintext must be at least one more to fit the content type. This matches with the end of the record payload protection section.
Nice catch! We also misread that and applied the check to the wrong end to begin with, but the +1 seems a good idea anyway. Just seems generally simpler if TLS 1.3 doesn't have a pesky version-specific -1 in figuring out how much data can fit in an outgoing record.
Would be nice to have a new test in bogo that checks for rejection of TLSPlaintext having a size of 2^14+2 (or 2^14+1 in case of TLS 1.2).
Yup, will certainly add a test when we fix it. (Though I'll wait for this PR to either go in or be rejected just to have a ruling on whether we should have a +1 in there.)
So, if we go with 2^14+1 for sizeof(TLSInnerPlaintext), that is fine. That means that you can (absent padding) expect to be able to send 2^14 octets in every record, across every TLS version. The issue that this causes is one for the record size limit draft. The valid maximum for that will be 2^14 in TLS 1.2 and earlier, but 2^14+1 in TLS 1.3. That's OK, but I'll need to change that draft to make that observation. We already need to allow for larger values in case an extension expands the record size, so this will be a good test for that code. It's also going to be lots more annoying to write the cross-checking in code, but that is just how things go.
I had been using the text in : But the text in the very last sentence of says: Which doesn't really make sense. TLSPlaintext includes the record header as well as the encrypted data. I suppose that this is accurate if it means , but I misread this as the entire length of the structure. That's a minor point.

TLSInnerPlaintext can be at most 2^14 (as defined in Section 5.4), which leads to a different limit of 2^14-1 for URL Should we instead say that 2^14+256 is the limit and the AEAD expansion is 256 octets instead of 255? Leading me to think that something along these lines is what should go in Section 5.2: Or something like that.
See
Fixed
See URL And URL Section A.4.2 says: It should say: The definition in Section 7.4.4 (which includes the "supportedsignaturealgorithms" field) is the correct one (confirmed by Eric Rescorla on 2009-02-27) The supportedsignaturealgorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).
This change conflates two things: an editorial fix for "MUST not" instances, and the +1 tweak. These are both OK though, and I think that this is the right answer to the problem.
Change:
Actual keys are registered by supplying the information in record: <del> 'Identifier' contains the key name. </del> <ins> 'Identifier' contains the key name.  A key name ending with a hyphen/ minus sign ""-"" is a namespace that covers all timestamp tag keys beginning with that prefix. </ins> 'Description' contains the name and description of the namespace.

Discussion:
Replace "DST" and "daylight savings time" with "daylight saving time" Replace "timezone" with "time zone" Properly capitalize "Unicode Consortium" Improve phrasing
If you don't have time to work further on this very useful PR, I could merge it and fix these three nits.
Please don't add material to this one. We went the opposite direction in the last interim, so I'm about to remove some of this text.
OK, I pushed a commit just before your last comment but will withhold any further changes.
Sorry for the unsmooth handling of this PR. I now cherry-picked from this PR. Can I ask you to rebase to main and see what remaining parts you want to pursue?
My last message was too close to the holidays. Do you want to rebase this PR? Or do you think it is essentially covered by my cherry-picking?
Thanks for the ping, NAME Almost everything was covered by the cherry-picking, but a few things remain. I have rebased the PR to include only those.