jiebi/CodeConvo huggingface dataset:
Change:
URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol. <ins> DNS API servers MUST implement both POST and GET methods. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are

Discussion:
By my unofficial informal tally, there was a strong agreement on application/dns-udpwireformat being mandatory, and both GET and POST mandatory for servers.
I made some very minor edits NAME merge if you're ok with them
The fact that an HTTP server can provide a response in the format of its choice was not well understood by DNS people. This motivates the MTI format for servers.
On 2018-03-25, NAME sent the following to the list: At the meeting in London last week, we asked the room for opinions on two topics: Should we have a content-type that is Mandatory to Implement? Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. If you would like to voice a dissenting opinion on either point, please reply on this list. Otherwise, the chairs will regard these decisions as the group's consensus.
See PR
I think most of this can be handled by the MTI PR. But I will just make a tiny clarification indicating that the server is really able to return whatever it needs to.
as discussed on list.. 1) Make one mandatory-to-implement 2) Make both mandatory-to-implement 3) Talk about why there is no mandatory-to-implemen
At the face-to-face meeting, I thought the sense of the room was servers MUST implement both GET and POST, clients can implement either or both. This needs to be confirmed on the list.
See PR
My personal take of consensus is that, having heard no opposition to the position of NAME summary above, to go with that.
Change:
The string "proof-of-possession-01" <del> An array of certificates, in Base64url-encoded DER format, that </del> <ins> An array of certificates, in base64url-encoded DER format, that </ins> contain acceptable public keys. In response to this challenge, the client uses the private key

Discussion:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)
Change:
The receiver has to keep track of all the frames received but yet not verified, by storing the authentication tags of each received frame. <del> When a signature is received, the reciever will verify it with the signature key associated to the key id of the frame the singature was sent in.  If the verification is sucessful, the received will mark </del> <ins> When a signature is received, the receiver will verify it with the signature key associated to the key id of the frame the signature was sent in.  If the verification is successful, the received will mark </ins> the frames as authenticated and remove them from the list of the not verified frames.  It is up to the application to decide what to do when signature verification fails.

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
risk that differing semantics are attributed to the same codepoint by different implementations. <del> Use of the first available codepoint in a range is reserved for allocation using the Standards Action policy; see Section 4.9 of RFC8126.  The early codepoint assignment process EARLY-ASSIGN can be used for these values. </del> <ins> Use of the first unassigned codepoint is reserved for allocation using the Standards Action policy; see Section 4.9 of RFC8126.  The early codepoint assignment process EARLY-ASSIGN can be used for these values. </ins> For codepoints that are encoded in variable-length integers (integer- encoding), such as frame types, codepoints that encode to four or

Discussion:
Not sure if this is design. It probably is.
Because that is where contention occurs.
Amanda from IANA says: I believe that the original idea was that we privilege the first unassigned value in each range of values that has a different length encoding for varints. But as we are also using these rules for non-varint encodings, that sort of rulemaking is likely confusing. I'm proposing that this be made simply "first unassigned codepoint". PR to follow. (This will affect more than just -transport, but the text change only occurs there, so I think we're OK.)
This is good.
Change:
according to rules defined by the extension, they might also be randomized as specified in this document. <del> Receiving a transport parameter for an extension that uses the QUIC Bit could be used to confirm that a peer supports the semantic </del> <ins> The receipt of a transport parameter for an extension that uses the QUIC Bit could be used to confirm that a peer supports the semantic </ins> defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according <del> to the rules of the extension, but defer acting on the information </del> <ins> to the rules of the extension but defer acting on the information </ins> conveyed until the transport parameter for the extension is received. Extensions that define semantics for the QUIC Bit can be negotiated

Discussion:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.
Change:
Group ID: A value set by the creator <del> Epoch: 0x00000000 </del> <ins> Epoch: 0 </ins> Tree hash: The root hash of the above ratchet tree

Discussion:
might invalidate this, but in the meantime we should go ahead with this!
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - 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 .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 1 pull request was created, updated or merged. Last week, 1 pull request was updated. :yellow_heart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were no stargazers. - - 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 .

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 .
Change:
the Remote Endpoint if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one <del> direction of a TCP connection ?RFC9293.  The end of a stream can </del> <ins> direction of a TCP connection RFC9293.  The end of a stream can </ins> also be indicated using Message Properties when sending.) Abort: The action the application takes on a Connection to

Discussion:
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM
Change:
violates the best common practice to avoid "port overloading" as described in RFC4787. <del> 4.8.2. </del> <ins> 4.9.2. </ins> Concealing client address changes in order to simplify operational routing issues will mask important signals that drive security

Discussion:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.
Change:
datagram size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion <del> control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent </del> <ins> control reaction; see Bullet 7 in Section 3 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent </ins> transmission by an application. 14.4.1.

Discussion:
to make RFC Editor diffs smaller
These are manual; if only there were a tool... Diffs in the are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of URL).
I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick). The changes should be visible at URL if CI ever passes. Which of course it has not at this point...
Seems to be working occasionally; I fixed a lint problem, and diffs are now at URL
NAME I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for and it should consistently show all instances, whether or not there's a section being referenced). If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.
NAME Fair enough. This LGTM.
Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time). URL I've spotted one problem there already, but it does look good so far.
NAME and NAME I have learned something new about kramdown-rfc2629. Cheers.
NAME
NAME and NAME should approveThanks for doing this, recovery LGTM
Change:
objects in cases where it is necessary for the Delivery Service to examine such messages. <ins> The field "confirmation_tag" MUST be present if "content_type" equals commit.  Otherwise, it MUST NOT be present. </ins> External sender types are sent as MLSPlaintext, see external- proposals for their use.

Discussion:
As discussed in the mailing list, not having the signature contribute to the new epoch's key schedule leads to a one-off effect where parties stay in sync (with respect to keys) for one more epoch, before inevitably go out of sync. This pull request addresses this issue by including the signature in the confirmed transcript hash rather than the interim transcript hash. See the mailing list for a security consideration of this change. Credit: This pull request was primarily authored by Marta Mularczk; I'm just posting it here for administrative reasons.
Change:
HTTP. In the absence of information about the authenticity of responses, <del> such as DNSSEC, a DNS API server can poison a client's cache.  A client MUST NOT authorize arbitrary DNS API servers.  Instead, a client MUST specifically authorize DNS API servers using mechanisms such as explicit configuration. </del> <ins> such as DNSSEC, a DNS API server can give a client invalid data in responses.  A client MUST NOT authorize arbitrary DNS API servers. Instead, a client MUST specifically authorize DNS API servers using mechanisms such as explicit configuration. </ins> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP

Discussion:
This is the only place where a client cache is mentioned, and stub resolvers normally don't have caches. (Some browsers have caches for the stub resolvers, but this is rare and not well known outside a small group of people.) This change replaces that one instance with wording that still explains the main problem.
Change:
field from the decrypted request is outside of the current time window. <del> SHOULD allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks. </del> <ins> might need to allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks.  Insufficient tolerance of time differences could result in valid requests being unnecessarily rejected. </ins> MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to

Discussion:
This really just needs a good explanation of what might happen.
From NAME I understand the goal of the sentence above, but I am not sure the SHOULD is appropriate here - in particular if I think about the above as an interoperability requirement, I don't think it gives enough information to the implementer of what is recommended here. If this was to give for example a default time window, it would be a different story. Can we rephrase? (You can also leave as is, but I think it will come up again in IESG review with no change)
Change:
they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: <del> The number, type and port number of m-lines. </del> <ins> The number, type and port number of m= lines. </ins> The generated ICE credentials (a=ice-ufrag and a=ice-pwd).

Discussion:
Also, update IceCandidate section to use consistent “m= line” terminology, and also make it clearer that use of MID, if present, is a MUST.
WFM
The current example in S 3.2 refers to SDES, but that's not in JSEP any more. We need a new example.
Change:
The TokenRequest.blinded_msg is of the correct size. If any of these conditions is not met, the Issuer MUST return an HTTP <del> 400 error to the client. 5.2. Upon receipt of a TokenRequest, the Issuer tries to deseralize </del> <ins> 400 error to the client.  The Issuer then tries to deseralize </ins> TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of OPRF, yielding "blinded_element".  If this fails, the Issuer MUST return an HTTP 400 error to the client.  Otherwise, if the Issuer is

Discussion:
ends with two paragraphs that really belong in Section 5.2, because they are about the processing of the request.
Change:
Per client-behavior and server-behavior, implementations are required to track, alongside each PSK established by a previous connection, <del> whether the connection negotiated this extension with the "ech_accept" response type.  If so, this is referred to as an "ECH PSK".  Otherwise, it is a "non-ECH PSK".  This may be implemented by adding a new field to client and server session states. </del> <ins> whether ECH was accepted for this connection.  If so, this is referred to as an "ECH PSK".  Otherwise, it is a "non-ECH PSK".  This may be implemented by adding a new field to client and server session states. </ins> 6.1.

Discussion:
Section 6: implementations to track, alongside each PSK established by a previous connection, whether the connection negotiated this extension with the "echaccept" response type. If so, this is referred to as an "ECH PSK". Otherwise, it is a "non-ECH PSK". This may be implemented by adding a new field to client and server session states. "echaccept" is not defined anywhere.
I suspect "the connection negotiated this extension with the 'ech_accept' response type" is an incorrect way of saying that ECH was accepted.
Change:
This document deals with the formatting of data in an external representation.  The following very basic and somewhat casually <del> defined presentation syntax will be used.  The syntax draws from several sources in its structure.  Although it resembles the programming language "C" in its syntax and XDR RFC4506 in both its syntax and intent, it would be risky to draw too many parallels.  The purpose of this presentation language is to document TLS only; it has no general application beyond that particular goal. </del> <ins> defined presentation syntax will be used. </ins> 3.1.

Discussion:
The caveats at the beginning are silly We don't seem to every use Foo = { A, B} but we do use Foo = A;
Fixed, thanks
Change:
An optional set of extensions describing the parameters of the certificate being requested.  The "signature_algorithms" extension <del> MUST be specified. </del> <ins> MUST be specified.  Clients MUST ignore unrecognized extensions. </ins> In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the

Discussion:
Per the recent thread. I could have sworn this was in here, but can't find it... The NewSessionTicket section explicitly says to ignore unknown extensions, so I've added the analogous text to ClientHello and CertificateRequest.
Change:
removing any PSKs which are incompatible with the server's indicated cipher suite. <ins> Optionally adding, removing, or changing the length of the "padding" extension RFC7685. </ins> Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1.3 and receives a ClientHello at any other time, it MUST terminate the connection with an "unexpected_message" alert.

Discussion:
The padding extension is typically computed as part of serializing the ClientHello, in hopes of targetting a particular size. As specified right now, the second ClientHello must not use this same logic and instead must retain the previous extension sizethough this would likely not hit the same target size. The server's going to ignore it anyway, so allow it to be recalcuated. This avoids unnecessary state in clients and extra logic to serialize the first and second ClientHellos differently.
Good catch; +1
Change:
The examples are based on the simple JSON value shown in fig-example- value, representing a bookstore (that also has bicycles). <del> The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in an object, and to perform numeric comparisons of member values with a constant. </del> <ins> tbl-example shows some JSONPath queries that might be applied to this example and their intended results. </ins> 3.

Discussion:
The deleted text referred, erroneously, to an example obtaining the number of elements in an array. It also used the term "expression mechanism" instead of "filter expression". On the whole, it seemed better to slim the text down to the bare minimum.
Change:
4. The Original Header Block (OHB) contains the original values of any <del> modified header fields.  In the encryption process, the OHB is </del> <ins> modified RTP header fields.  In the encryption process, the OHB is </ins> appended to the RTP payload.  In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform.

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If <del> TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. </del> <ins> TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable. </ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not

Discussion:
I couldn't immediately parse, and I'm assuming this is a NiT, but I can always be surprised by nuances in security-related text, so I'm writing this as an issue: /If TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable./ If TLS over TCP cannot be supported, the connection should be aborted, and the application should present a suitable prompt to the user that secure communication is unavailable./
I guess we can remove the "instead" but why did you change the "in order to"? The reason to abort instead of just moving on without security is, so that the application recognises and can tell the user.
NAME ?
OK on removing instead Is this better?: /If TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable./