jiebi/CodeConvo huggingface dataset:
Change:
Protocol header field value, but future documents MAY define parameters.  Receivers MUST ignore unknown parameters. <del> 4.3. </del> <ins> 4.4. </ins> This document defines the DATAGRAM capsule type (see iana-types for the value of the capsule type).  This capsule allows an endpoint to

Discussion:
Borrowing text from H3. Also I don't think there is a 'FRAMEENCODINGERROR' defined anywhere.
Thanks! Approved pending some minor tweaks
Change:
SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. <ins> While this version of the specification only supports a single audio and video track, in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a 406 Not Acceptable error code. Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error processing the "m=" section, but reject the HTTP POST request with a 406 Not Acceptable error code to prevent having partially successful WHIP sessions. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in RFC8842.  However, if the WHIP client only implements the DTLS client

Discussion:
Until now, I've been working under the assumption that WHIP is limited to two tracks (audio+video) belonging to a single stream. However, I'm now realising that there's nothing in the draft that says this is the case. Please clarify which of the following is correct: the client MUST offer at most one audio and one video track (possibly simulcast/SVC) belonging to a single stream; the server MUST return an error if there are more than two tracks; the client MAY offer more than two tracks; how to handle this case is out of scope for WHIP, but the server MAY return an error if there are more than two tracks and the client MUST retry with just two tracks; the client MAY offer multiple tracks in multiple streams, and the server MUST accept the multiple streams. My preference is for (1) or (2), but I can live with (3).
I had doubts regarding this, as I foresee that we will want to support multi tracks/streams in the near future (for multilanguage support for example) I would propose something like. I don't want to add the retry client logic to the client, as I think most of the times it would be better to inform the end user about the error and explicitly asking form confirmation before doing any change in the stream/track. Note that this could happen today if the server supports audio only and the whip client is sending audio and video. I think that it is better to fail than just force retrying automatically with audio only.
Change:
Each "a=mid" line MUST stay the same. If the m= section is not bundled into another m= section (i.e., it <del> is either not bundled or it is associated with the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= </del> <ins> is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= </ins> section is bundled into another m= section, it MUST NOT have any ICE credentials.

Discussion:
First cut. Need to update the examples.
Overall LG, a handful of comments
LGTM
lgtm and merged. Will do a new PR to handle minor tweaks
BUNDLE draft 27 (URL) indicates that ICE attributes and candidates in re-offers (and with max-bundle, I'm guessing) should only be in the "m=" line associated with the offerer BUNDLE-tag. In other words, the candidates and ICE parameters are not duplicated unnecessarily across m= sections. We should update JSEP to reflect this.
Change:
"(prep_state, prep_msg)". To carry out this step, for each PrepareStep in <del> AggregateContinueReq.prepare_shares received from the leader, the </del> <ins> AggregateContinueReq.prepare_steps received from the leader, the </ins> helper performs the following check to determine if the report share should continue being prepared:

Discussion:
The prepare_shares fields were always of type PrepareStep. To match the convention used for most other field names, I change the name of the field to match its type. (There is no "PrepareShare" type.)
Change:
Generate a provisional GroupContext object by applying the proposals referenced in the commit object in the order provided, <del> as described in proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </del> <ins> as described in proposals.  First the list of update proposals, then the list of remove proposals, and last the list of add proposals.  Add proposals are applied left to right: Each Add proposal is applied at the leftmost unoccupied leaf, or appended to the right edge of the tree if all leaves are occupied. </ins> Process the "path" value using the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the

Discussion:
by updating the description for creating a commit to explicitly mention that first all update proposals are applied, then remove proposals, and last add proposals.
The writes: However, from this it is not immediately clear to me in which order the collections of proposals , , and are to be applied. I assume it should be in that order because it makes practical sense and because they're written in that order in the Commit struct. If my guess is correct, perhaps it would be useful to make this explicit? E.g.:
NAME - I agree with your interpretation here. Could you make a PR with some proposed wording?
Apologies for closing/opening the issue. I will open a PR to update the wording.
Change:
abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort <del> message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </del> <ins> message.  Messages may be in flight or responses outstanding when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </ins> Abort messages are indicated by the 7.05 code (Abort).

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
consider this authorization valid for all applications until the authorization expires. [[ Open issue: More flexible scoping? ]] <del> The challenges that the client needs to fulfill in order to prove </del> <ins> The challenges that the client can fulfill in order to prove </ins> possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array entry is a dictionary with parameters required to validate the <del> challenge, as specified in identifier-validation-challenges. A collection of sets of challenges, each of which would be sufficient to prove possession of the identifier.  Clients complete a set of challenges that covers at least one set in this array.  Challenges are identified by their indices in the challenges array.  If no "combinations" element is included in an authorization object, the client completes all challenges. </del> <ins> challenge, as specified in identifier-validation-challenges.  A client should attempt to fulfill at most one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. </ins> The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  The value of the identifier

Discussion:
This is a fairly complicated part of the protocol, and not used in practice. For instance, in Let's Encrypt's implementation, there are always three challenges, any one of which may be fulfilled by the client. After this change, all challenges are considered to be combined with an "OR." That is, any challenge within an authorization may be completed to make the authorization valid. Authorizations within the new-application object are considered to be combined with an "AND." That is, all of them must become valid before the certificate will be issued. The combination of the two means that we have similar expressiveness as before, even without the combinations array.
Change:
9. One goal of this design is that independent client requests are only <del> linkable by the chosen KeyConfig.  The oblivious proxy and request resources can link requests using the same KeyConfig by matching KeyConfig.key_id.  The oblivious proxy can also link requests using the public key corresponding to KeyConfig.key_id.  The proxy cannot determine precisely which public key was used to encapsulate a request, given that multiple public keys may have matching key identifiers. </del> <ins> linkable by the chosen key configuration.  The oblivious proxy and request resources can link requests using the same key configuration by matching KeyConfig.key_id, or, if the oblivious target resource is willing to use trial decryption, a limited set of key configurations that share an identifier.  An oblivious proxy can link requests using the public key corresponding to KeyConfig.key_id. </ins> Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. <del> Specifically, servers can maliciously construct KeyConfigs to track individual clients.  While KeyConfig discovery is outside the scope of this specification, clients should consider this tracking vector in deployments.  Applications using this design should provide accommodations to mitigation this tracking vector. </del> <ins> Specifically, servers can maliciously construct key configurations to track individual clients.  A specific method for a client to acquire key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations to mitigate tracking. </ins> 10.

Discussion:
The whole mess that is key configuration discovery needs real work. There are cases where trust suffices, but we can't rely on that here. What this does is tweak the language to more clearly note the lines of responsibility for this draft. I also noted that we didn't talk about trial decryption and tracking, so I added that. It seemed like we didn't need to mention multiple keys with the same identifier twice after that.
Change:
element or member value as the filter selector iterates over the array or object. <ins> A singular path by itself in a Boolean context is an existence test which yields true if the path selects a node and yields false if the path does not select a node.  To be more specific about the actual value of a node selected by a path, explicit comparisons are necessary.  This existence test -- as an exception to the general rule -- also works with nodes with structured values. </ins> When a path resulting in an empty nodelist appears on either side of <del> a comparison, the result of the comparison is true if and only if the </del> <ins> a comparison, the comparison yields true if and only if the </ins> comparison operator is "==", ">=" or "<=" and the other side of the comparison is also a path resulting in an empty nodelist.

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:
it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible <del> Certificate (message) covered by the same ESNI key. </del> <ins> Certificate (message) covered by the same ESNI key.  Moreover, the server MUST include the "encrypted_server_name" extension in EncryptedExtensions, and the value of this extension MUST match PaddedServerNameList.nonce. </ins> 5.4. <del> The backend Server ignores both the "encrypted_server_name" and the "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true SNI and so will generally be configured to use a single certificate. communicating-sni describes a mechanism for communicating the true SNI to the backend server. Similar to the Shared Mode behavior, the backend server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. </del> <ins> In Split Mode, the backend server must know PaddedServerNameList.nonce to echo it back in EncryptedExtensions and complete the handshake.  communicating-sni describes one mechanism for sending both PaddedServerNameList.sni and PaddedServerNameList.nonce to the backend server.  Thus, backend servers function the same as servers operating in Shared mode. </ins> 6.

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
(RFC6347), TLS (RFC8446), or OSCORE (RFC8613), provide the additional security features. <ins> This document updates RFC7252 with a recommendation that servers use the Echo option to mitigate amplification attacks. </ins> The document also updates the Token processing requirements for clients specified in RFC7252.  The updated processing forbids non- secure reuse of Tokens to ensure binding of responses to requests

Discussion:
I take URL as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT. (It wasn't intended as an update, as the SHOULD mentioned there is just a copy of the original 7252 SHOULD and we "provide one way", but no objections from me either). Along that I'd offer concrete size numbers, and a note that this really needs piggy-backed responses. Unless objected to, I'd take this into the next version of ERT (as soon as I have processed any other pending comments if there still are any). In draft-ietf-core-echo-request-tag-URL, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure. draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing. The SHOULD in Section 2.4 item 3 is a bit hidden for my taste. My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior. There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated. Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation? If you have a position on this, please reply to the list (or to the chairs) by March 2nd. Grüße, Carsten
Change:
Depending on whether the client is configured to accept the proxy's certificate as authoritative for the public name, this may trigger <del> the retry logic described in handle-server-response or result in a connection failure.  A proxy which is not authoritative for the public name cannot forge a signal to disable ECH. </del> <ins> the retry logic described in rejected-ech or result in a connection failure.  A proxy which is not authoritative for the public name cannot forge a signal to disable ECH. </ins> 9.

Discussion:
Handling server response discusses how to dispatch between accept/reject, but the retry flow is specifically the reject bit.
Change:
When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: <del> If the packet was in the TLS receiving encryption level, sequence the data into the input flow as usual.  As with STREAM frames, the offset is used to find the proper location in the data sequence. If the result of this process is that new data is available, then it is delivered to TLS in order. </del> <ins> If the packet uses the current TLS receiving encryption level, sequence the data into the input flow as usual.  As with STREAM frames, the offset is used to find the proper location in the data sequence.  If the result of this process is that new data is available, then it is delivered to TLS in order. </ins> If the packet is from a previously installed encryption level, it MUST NOT contain data which extends past the end of previously

Discussion:
This also adds a paragraph about buffering of CRYPTO frames that references the buffering text in the transport doc. Closes no issue, but there have been complaints.
Change:
by either party of a TLS connection using data exported from that connection.  It can be transmitted to the other party of the TLS connection at the application layer.  The application layer protocol <del> used to send the authenticator SHOULD use TLS as its underlying transport to keep the request confidential. </del> <ins> used to send the authenticator request SHOULD use TLS as its underlying transport to keep the request confidential.  The application MAY use the existing TLS connection to transport the authenticator. </ins> An authenticator request message can be constructed by either the client or the server.  This authenticator request uses the

Discussion:
NAME are you happy with the adjusted text? I don't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface.
I think that this is sneaking in a big change with the DTLS thing. I'll try to find the email...
Change:
7.7. <del> As described in commit, each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path.  The path contains a public key and encrypted secret value for all intermediate nodes in the path above the leaf.  The path is ordered from the closest node to the leaf to the root; each node MUST be the parent of its predecessor. </del> <ins> As described in commit, each MLS Commit message may optionally transmit a KeyPackage leaf and node values along its direct path. The path contains a public key and encrypted secret value for all intermediate nodes in the path above the leaf.  The path is ordered from the closest node to the leaf to the root; each node MUST be the parent of its predecessor. </ins> The number of ciphertexts in the "encrypted_path_secret" vector MUST be equal to the length of the resolution of the corresponding copath

Discussion:
This PR updates two sections to reference generating and sending an message, as not all Commits transmit fresh key material (as discussed in ). This PR also includes light editorial edits for clarity and adds detail around the steps to perform an update. Section 7.7 currently says that "each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path", but section 10.2 says that an UpdatePath is optional. I can update 7.7 as well, if 10.2 is correct.
I went ahead and changed Section 7.7 to specify that MLS commits may optionally transmit updates for consistency with Section 10.2
Change:
Sending different payloads each time reduces the chances of spurious retransmission. <del> When a PTO timer expires, new or previously-sent data may not be available to send and packets may still be in flight.  A sender can be blocked from sending new data in the future if packets are left in flight.  Under these conditions, a sender SHOULD mark any packets still in flight as lost.  If a sender wishes to establish delivery of packets still in flight, it MAY send an ack-eliciting packet and re- arm the PTO timer instead. </del> 6.3.3. Delivery or loss of packets in flight is established when an ACK

Discussion:
This PR adds text and pseudo-code to clarify what an endpoint should do when PTO fires and there is no data or other ack-eliciting frames to send.
NAME I've done s/endpoint/sender. Let's deal with this separately. On the SHOULD, thinking about this, yes, I think I agree with you. I'll modify the PR, let's see how that looks.
Ok, modified, take a look
As written now, this swaps a SHOULD and a MAY, so I'm changing it to design.
As discussed with NAME 6.2.2.2 is awkward, because in the first paragraph it says And then the very last paragraph changes that by saying What is super unclear is that the final paragraph apparently means to imply that when there is no new or unACKed data to send, nothing should be send, i.e., it invalidates the SHOULD in the first paragraph. Related to that, the pseudo code still uses , which is also inaccurate, since it's really "at least one (unless you don't have new or unACKed data) but can also send two". Good luck finding a good name for that function :-)
The pseudocode now uses SendOneOrTwoPackets(), but the last paragraph pretty clearly violates the previous MUST, which is very bad. The simplest fix would be to change the MUST to a "SHOULD unless otherwise specified", but I'm increasingly thinking we should stick with the MUST and if you get into a situation you have nothing to send, require sending something ack-eliciting to ensure in-flight packets are removed from flight. Thoughts?
Change:
resolver being informed. A full-service resolver that accepts and processes queries from <del> any (or nearly any) stub resolver.  This is sometimes also called a "public resolver", although the term "public resolver" is used </del> <ins> any (or nearly any) client.  This is sometimes also called a "public resolver", although the term "public resolver" is used </ins> more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open.  Open resolvers are discussed in

Discussion:
There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".