jiebi/CodeConvo huggingface dataset:
Change:
8.2. <ins> ACME challenges typically require the client to set up some network- accessible resource that the server can query in order to validate that the client controls an identifier.  In practice it is not uncommon for the server's queries to fail while a resource is being set up, e.g., due to information propagating across a cluster or firewall rules not being in place. Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation query fails, the server SHOULD retry the query after some time. While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After HTTP header field in response to requests to the challenge resource. The server MUST add an entry to the "errors" field in the challenge after each failed validation query.  The server SHOULD set the Retry- After header field to a time after the server's next validation query, since the status of the challenge will not change until that time. Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.).  This allows clients to request a retry when state has changed (e.g., after firewall rules have been updated).  Servers SHOULD retry a request immediately on receiving such a POST request.  In order to avoid denial-of-service attacks via client-initiated retries, servers SHOULD rate-limit such requests. 8.3. </ins> With HTTP validation, the client in an ACME transaction proves its control over a domain name by proving that for that domain name it can provision resources to be returned by an HTTP server.  The ACME

Discussion:
A refinement on Servers reflect their state in and Clients can request a retry by re-ing
Change:
The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". <del> When a path resulting in an empty nodelist appears on either side of a comparison: </del> <ins> When either side of a comparison results in an empty nodelist or "Nothing": </ins> <del> a comparison using the operator "==" yields true if and only if the comparison is between two paths each of which result in an empty nodelist. </del> <ins> a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing". </ins> a comparison using the operator "<" yields false. <del> When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value of its node and then: </del> <ins> When any path or function expression on either side of a comparison results in a nodelist consisting of a single node, that side is replaced by the value of its node and then: </ins> a comparison using the operator "==" yields true if and only if the comparison is between:

Discussion:
These editorial changes from PR are needed in the base.
I confess I tend to write tedious text when precision is at stake. Hopefully, the second commit avoids the tedium.
Why was this merged so quickly?!
We merged this editorial change quickly so we could rebase the other substantive PRs on it and put us in a better position to compare their pro's and con's.
Looks good now! Should merge this quickly so we can rebase the others.
Change:
A "suffix-value" is limited to "3*8alphanum". <ins> 3.3. </ins> Multi-character namespaces can be registered specifically for use in <del> this format.  They are assigned by IANA using the "IETF Review" policy defined by RFC8126.  This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags.  The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC.  The RFC MUST specify or include each of the following: </del> <ins> this format, see iana-cons.  The registration policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the tags using the namespace registered. (This subsection uses BCP 14 language to describe the requirements on the information interchanged indirectly by providing requirements on the RFC registering a namespace and the principles of its evolution.) The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC.  The RFC MUST specify each of the following (directly or included by reference): </ins> The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
encrypt an input share, the client first generates an HPKE I-D.irtf- cfrg-hpke context for the aggregator by running <del> where "pk" is the aggregator's public key. "enc" is the encapsulate HPKE context and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </del> <ins> where "pk" is the aggregator's public key and "server_role" is a byte whose value is "0x01" if the aggregator is the leader and "0x00" if the aggregator is the helper. "enc" is the encapsulate HPKE context and "context" is the HPKE context used by the client for encryption. The payload is encrypted as </ins> <del> where "input_share" is the aggregator's input share. [TODO: Fully specify encryption of the shares.  We need to make sure we authenticate things like the PDA parameters and the report timestamp.  We need to decide what the info string for SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and aggregator.] </del> <ins> where "input_share" is the aggregator's input share and "task_id", "time", and "jitter" are the fields of "PDAReport". </ins> The leader responds to well-formed requests to "[leader]/upload" with status 200 and an empty body.  Malformed requests are handled as

Discussion:
For privacy reasons, leaders should not be allowed to replay a given report more than once within the context of a single batch. The current verify+collect model runs in a "streaming mode," wherein the leader sends slices of batch shares to helpers for verification and aggregation. If we changed this to require the leader to send all batch shares in a single verify+collect flow, then replay prevention would be simpler: just scan the list and check for dupes. If we stick with the current model, then the helper must necessarily store some state (on the leader, most likely) representing the shares processed. This state could then be consulted when asked to verify+collect any new share. (We can probably spell out a number of ways to do store this state, but ideally it should not be linear in the number of shares collected so far.) We'd likely also need a way for the leader to request that the helper produce the final aggregate output once the batch is "done" being verified and collected.
One downside to this approach is that it requires the leader to queue up the entire batch of reports before sending the first aggregate request to the helper. This may be OK for some deployments, but it might not be workable for all. I think this is worth pursuing. This is already in the protocol. (See "output share request".)
We could require that the leader feed the helper reports with monotonically increasing timestamps, such that the helper can simply maintain a single timestamp and reject any report older than that. However I'm not sure if that's practical given that clients may submit reports out of order.
One intermediate option would be to maintain a jitter buffer on the leader, so that they keep reports for a few minutes and then feed them out in order. You would still lose some reports, but not too many.
I have a few questions but nothing blocking.
Change:
with which the batch interval of each collect request must be aligned.  (See batch-parameter-validation.) <del> A unique identifier for the VDAF being used for the task. </del> <ins> A unique identifier for the VDAF instance used for the task, including the type of measurement associated with the task. </ins> In addition, in order to facilitate the aggregation and collect protocols, each of the aggregators is configured with following

Discussion:
Extracted and slightly modified from .
(Build failure appears to be some GitHub API issue.)
Ah, this looks like we're hitting the patch for URL I'll check if the upstream template repository has a fix.
Thanks NAME
!
Change:
encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are considered; any other values, such as picture aspect ratio, MUST <del> be ignored.  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks.  This is required regardless of whether the receiver </del> <ins> be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks.  This is required regardless of whether the receiver </ins> supports performing receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic.

Discussion:
The first full bullet on page 18 has a sentence that starts "Note that when considering". Please change that to simply "When considering". As written, there is an implication that this is a consequence of something specified somewhere else.
Yes, this seems rihgt.
To help find it, the whole sentence is is Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO [TS26.114]), as it significantly simplifies the matching logic.
Change:
The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of <del> record 2 (containing the NewSessionTicket message) and if it is not </del> <ins> record 4 (containing the NewSessionTicket message) and if it is not </ins> sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached.

Discussion:
Ben wrote: The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of record 2 (containing the NewSessionTicket message) and if it is not The records in Figure 12 are not labeled (anymore?).
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed
Change:
The server-chosen "response_nonce" field ensures that responses have unique AEAD keys and nonces even when requests are replayed. <ins> 8.5. This design does not provide post-compromise security for responses. A client only needs to retain keying material that might be used compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a client compromise. A server retains a secret key that might be used to remove protection from messages over much longer periods.  A server compromise that provided access to the oblivious request resource secret key could allow an attacker to recover the plaintext of all requests sent toward affected keys and all of the responses that were generated. Accessing requests and responses also requires access to requests and responses, which implies either compromise of TLS connections or collusion with the oblivious proxy resource. The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. </ins> 9. Please update the "Media Types" registry at

Discussion:
And recommend key rotation as a mitigation strategy.
Compromise of the client after it sends the request can be used to recover the keys used to decrypt (or falsify) the response.
NAME suggests that we need to consider how to time-bound server keys to limit the risk of secret key exposure.
Change:
Compute SAN A and SAN B in the same way as the client. Open a TLS connection to the domain name being validated on the <del> requested port, presenting SAN B in the SNI field. </del> <ins> requested port, presenting SAN A in the SNI field. </ins> The server MUST request the certificate using an SNI value of SAN <del> B. </del> <ins> A. </ins> <del> The server SHOULD ensure that it does not reveal SAN A in any way </del> <ins> The server SHOULD ensure that it does not reveal SAN B in any way </ins> when making the TLS connection, such that the presentation of SAN <del> A in the returned certificate proves association with the client. </del> <ins> B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other

Discussion:
This replaces tls-sni-01 with tls-sni-02, which requires that domains being validated return a certificate which contains a hostname that is not revealed by the server in its handshake. This ensures that challenges cannot be passed by domains which auto-generate self-signed certificates in response to requests with SANs for domains not previously seen.
Change:
acknowledgement if two packets that are ack-eliciting are declared lost, and: <del> all packets, across all packet number spaces, sent between the send times of these two packets are declared lost; </del> <ins> across all packet number spaces, none of the packets sent between the send times of these two packets are acknowledged; </ins> the duration between the send times of these two packets exceeds the persistent congestion duration (pc-duration); and

Discussion:
Persistent congestion means that no packets between two ack-eliciting packets was received by the peer. This was codified as all packets between those boundary packets being lost. However, non-ack-eliciting packets can be often never declared as lost, since loss declaration requires a packet to be in-flight (URL). What we really want to say is that none of the packets between these boundary packets were acknowledged. This PR makes this change. Note that the example below the definition already follows this; packets in between the boundary packets are noted as "not acknowledged" rather than marked as lost. (Problem also noted here: URL)
Change:
The "get context" API takes as input: <del> authenticator </del> <ins> authenticator or authenticator request </ins> It returns the certificate_request_context.

Discussion:
In the HTTPbis meeting in Montreal, it was suggested that recipients of a frame should validate that the claimed Request-ID matched the in the supplied authenticator request. However, the document defines no API which would permit us to do that.
Shouldn't this be implemented at the HTTP layer using the "get context" API? This document is not prescriptive about the content of the crc except that it is unpredictable and unique.
allows us to extract it from an authenticator, but doesn't allow performing the same operation on a request.
Good point. This should be a simple addition.
URL
Change:
corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. <ins> A server MUST ensure that the HPKE keys it uses are not valid for any other protocol that uses HPKE with the "ohttp request" label. Designers of other protocols, especially new versions of this protocol, can ensure key diversity by choosing a different label in their use of HPKE.  The "ohttp response" label was chosen for symmetry only as it provides key diversity only within the HPKE context created using the "ohttp request" label. </ins> 8.4. Encapsulated requests can be copied and replayed by the oblivious

Discussion:
This is a breaking change, but I think that it's worthwhile. "request" is an extraordinary generic string and the risk of it being used in another context is too high.
We can address test vectors in a followup PR.
Change:
The cloud registrar returned a voucher to the pledge.  The pledge should perform voucher verification as per standard BRSKI operation. The pledge should verify the voucher signature using the <del> manufacturer-installed trust anchor(s). should verify the serial </del> <ins> manufacturer-installed trust anchor(s), should verify the serial </ins> number in teh voucher, and must verify any nonce information in the voucher.

Discussion:
This should be a do-nothing change to the content, which just starts every sentence on fresh line. This aids greatly in reading diffs. One paragraph break added, and one period changed to a dot. And I seem to have included the IEEE reference fix by mistake.
Change:
The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target <del> URI is the .  The content of this request is copied from the .  The MUST NOT add information to the request without the being aware of the type of information that might be added; see relay- responsibilities for more information on relay responsibilities. </del> <ins> URI is the .  The content of this request is copied from the .  An MAY reject requests that are obviously invalid, such as a request with no content.  The MUST NOT add information to the request without the being aware of the type of information that might be added; see relay-responsibilities for more information on relay responsibilities. </ins> When a response is received from the , the forwards the response according to the rules of an HTTP proxy; see HTTP.  In case of

Discussion:
Forwarding an empty request will always yield a failure on the gateway, so just don't do it.
A request without a body is basically malformed, and the gateway will treat it that way. I think relays should be encouraged to reject malformed requests (invalid method, content type, or content body) so this burden doesn't fall on the gateway.
This seems a little bit strange to single out. Do we really need to mandate this? If the relay forwards the request anyway, the gateway will be unable to decrypt it. This creates a shorter and more immediate feedback loop, but it sort of leads to the next question: how much validation do we rely on the relay to do? What if the content-type is not acceptable? Enforcing that choice might be sensible, but it can also lead to ossification, where the relay's view of what is acceptable prevents new options from being deployed. I would have said that it would be better to say something like "A [relay] MAY reject requests that are obviously invalid, such as a request with no content." Obviously, the relay is going to do some amount of denial of service protection on behalf of the gateway, and blocking empty content is a fairly trivial thing to do there, but so is 1 byte of content or a content-type of . We probably don't need to enumerate all the ways and nor do we need to be so strict about what to do.
Your proposed text works for me.
OK, I'll work out how to make that change. I want to submit an update today.
NAME already applied the suggestion!
Yeah, this is much better.
Perfect, thanks!Seems fine. What was the motivation here?
Change:
media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. <del> The media formats in the answer MAY include codecs present in the offer that were discarded in a previous offer/answer exchange. This is necessary for compatibility with third- party call control and SIP use cases. </del> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5.

Discussion:
any guess on what happened to these that caused them to not go in ?
They were somehow targeted to a branch other than master, and that branch was never merged
LGTM but you have a conflict
Change:
An encoder adds an entry to the dynamic table where the header field name matches the header field name of an entry stored in the static or the dynamic table using an instruction that starts with the '1' <del> one-bit pattern.  The second ("S") bit indicates whether the </del> <ins> one-bit pattern.  The second ('T') bit indicates whether the </ins> reference is to the static or dynamic table.  The 6-bit prefix integer (see prefixed-integers) that follows is used to locate the <del> table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the </del> <ins> table entry for the header name.  When T=1, the number represents the static table index; when T=0, the number is the relative index of the </ins> entry in the dynamic table. The header name reference is followed by the header field value

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
one for each potential PSK; if no PSK is selected, it will then need to compute the early secret corresponding to the zero PSK. <ins> Once all the values which are to be derived from a given secret have been computed, that secret SHOULD be erased. </ins> 7.2. Once the handshake is complete, it is possible for either side to

Discussion:
by Hugo Krawczyk.
Other than davegarrett's editorial notes, this looks good.
Change:
The considerations for processing ICMP messages described in pmtud also apply if these messages are used by DPLPMTUD. <del> 14.3. </del> <ins> 14.4. </ins> PMTU probes are ack-eliciting packets.

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
sender: An endpoint that is transmitting records. <del> session: An association between a client and a server resulting from a handshake. </del> server: The endpoint which did not initiate the DTLS connection. CID: Connection ID

Discussion:
This should make things correct. We might consider getting rid of the term connection or association entirely, but each is problematic: association is a historical term but we also use connection a lot anyway.
It's a shame that "association" is so firmly entrenched. I don't see "association" being used much anyway. Good that you have removed "session" though.