jiebi/CodeConvo huggingface dataset:
Change:
Each task has a unique _task ID_ derived from the PDA parameters: <del> The task ID of a "PDAParam" `is derived using the following procedure: </del> <ins> The task ID of a "PDAParam" is derived using the following procedure: </ins> Where "SHA-256" is as specified in FIPS180-4.

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:
that only support versions of SSL and not TLS), rendering this method ineffective (see omitsni).  In addition, this technique requires deep packet inspection techniques that can be computationally and <del> infrastructurally expensive and improper configuration of an SNI- based block can result in significant overblocking, e.g., when a </del> <ins> infrastructurally expensive, especially when applied to QUIC where deep packet inspection requires key extraction and decryption of the Client Hello in order to read the SNI.  Improper configuration of an SNI-based block can result in significant overblocking, e.g., when a </ins> second-level domain like populardomain.example is inadvertently blocked.  In the case of encrypted SNI, pressure to censor may transfer to other points of intervention, such as content and

Discussion:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.
Change:
The overall system architecture is shown in pa-topology. [[OPEN ISSUE: This shows two helpers, but the document only allows <del> one for now.  https://github.com/abetterinternet/prio-documents/ </del> <ins> one for now.  https://github.com/abetterinternet/ppm-specification/ </ins> issues/117]] The main participants in the protocol are as follows:

Discussion:
The repo was renamed to "ppm-specification". This commit replaces various occurences of the old repo's name, and also updated URL to reflect the current name of the protocol.
Change:
encrypted input share whose report ID is in this set rejects the report as described in early-input-share-validation. <del> [OPEN ISSUE: This has the potential to require aggreagtors to store </del> <ins> [OPEN ISSUE: This has the potential to require aggregators to store </ins> report ID sets indefinitely.  See issue#180.] A malicious aggregator may attempt to force a replay by replacing the

Discussion:
Historically, the Nonce included a time component. Now that the time component is split out & Nonce is effectively an opaque identifier, ReportID is clearer & more closely matches similar identifiers (TaskID, AggregationJobID, BatchID).
Note this PR includes a single wire-format change: had its fields reordered so that the comes first, since the ID is the primary identifier. I am happy to revert this part of the PR if folks would prefer a purely-editorial PR.
LGTM. Any thoughts on replacing and with a Nonce so then it has both?
I'm pretty happy leaving & as separate fields -- for practical purposes, IMO binds them together closely enough (along with the report extensions). Conceptually, DAP is changing such that the primary identifier for a report is its opaque ID (with this PR, called ). Previously, the primary identifier for a report was . The technical aspects of this change were made by cjpatton in his changes to introduce tasks. If we do decide to introduce a struct that is effectively , I'd prefer if it was called something other than -- while we do expect that this value is a "value to be used only once", it's no longer used as a nonce in any cryptographic operations. And I'd argue there's no better justification to call the report ID (or ) a nonce than, say, the aggregation job ID/batch ID/task ID. That is, IMO "report ID" more accurately names what this type is than "nonce" -- "nonce" is not technically incorrect, just less clear.
Currently, the DAP specification has a number of opaque values used to identify some DAP entity: (identifying a client report) (identifying a task) (identifying an aggregation job) (identifying a batch) 's name differs from the rest. I think this is because, historically, the nonce also included a time component. Now that the time component has been split out, I think we could rename to for clarity of purpose. Thoughts? (and I probably don't need to say this, but there is no reason to push this into DAP-02 -- it could easily land in DAP-03 instead.)
Yup, I think this is a good idea!

I'm tempted to say let's stick this in 02, since it's editorial, but it's actually somewhat invasive because we use the term "nonce set" in so many places. If you want to send a PR, I'd review it. But we should make sure there's broad consensus before merging.
Nice change Yeah I think this is a big win :) good idea NAME
Change:
The "Form-Encoded Body Parameter" and "URI Query Parameter" methods of RFC6750 MUST NOT be used. <del> [[ See issue #104 [32] ]] </del> <ins> [[ See issue #104 [30] ]] </ins> The client software MUST reject as an error a situation where the "flags" field contains the "bearer" flag and the "key" field is

Discussion:
update token rotation response and requirements add considerations for the difficulties of rotating and revoking stateless tokens add considerations on rotation in unreliable networks
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 2284ffefdc540b8743400e9463fb65fc99070d4a Inspect the deploy log: Browse the preview:
Rotation the Access Token: Editor's note: The net result is that the client's always going to use the management URL that comes back. But should we let the server omit it from the response if it doesn't change? That seems like an odd optimization that doesn't help the client.
Close by making inclusion of URI REQUIRED.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
a few minor comments
Change:
We assume that the reader is familiar with the terminology used in QUIC-TRANSPORT.  In addition, we define the following terms: <ins> Path: refers to the 4-tuple {source IP address, source port number, destination IP address, destination port number}. A path refers to "network path" used in QUIC-TRANSPORT. </ins> Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is used in multipath control frames (etc.  PATH_ABANDON frame) to

Discussion:
fixes issue
Good point but I guess this definition is inline with what's already specified for QUIC given NATs...
Consider adding this entry to the terminology section: This also clarifies the link with "network path" in RFC9000.
PR merged
Note that this definition is different from RFC6182 that required the utilization of at least one different addresses for different subflows. In practice, there were deployments where this requirement was not respected and it was overly conservative.
Change:
IANA [SHALL update/has added] the following notes: <del> Experts are to verify that there is in fact a publicly available specification.  An Internet Draft that is posted and never published or a specification in another standards body, industry consortium, university site, etc. suffices. </del> <ins> The role of the designature expert is described in [this-RFC]. The designated expert RFC8126 ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices.  The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the extension. </ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the

Discussion:
This change aligns the DE text and adds more info about what the DE does and doesn't do. It also capitalizes "Recommended" so that it's more clear that we're referring to the column. NAME PTAL
LGTM, thanks for unifying the DE language.
Change:
same). A server which is willing to use CIDs will respond with its own <del> "connection_id" extension, containing the CID which it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use a CID (or again, alternately, to use a zero-length CID). </del> <ins> "connection_id" extension, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use a CID (or again, alternately, to use a zero-length CID). </ins> When a session is resumed, the "connection_id" extension is negotiated afresh, not retained from previous connections in the

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.
Change:
excluding the ASN.1 encoding of "OCTET STRING" of the LDevID(RegAgt) certificate. <del> The body of the agent-signed-data contains an "ietf-voucher-request- prm:agent-signed-data" element (defined in voucher-request-prm-yang): </del> <ins> The body of the agent-signed-data contains an "ietf-voucher- request:agent-signed-data" element (defined in RFC8366bis): </ins> created-on: MUST contain the creation date and time in yang:date- and-time format.

Discussion:
move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.
Change:
extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Delegated credentials limit the exposure of the private key used in a TLS connection by limiting its validity period.  An attacker who

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
environment).  ... even if those features stretch the capabilities of such devices. <del> A security solution MUST be implemented to protect CoAP over TCP and MUST be enabled by default.  This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over TCP when appropriate.  Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see I-D.ietf-core-object- security). </del> <ins> A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default.  This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate.  Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see I-D.ietf-core-object-security). </ins> 7.1.

Discussion:
NAME - can you review (don't see you in the Reviewers list)?
Referencing , I have these comments: I feel the text in Section 7 discussing security solutions pertains to both TCP as well as WebSockets, and therefore propose the following amendment: "A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate." In addition I have the following suggestion for a new subsection as follows: A CoAP client requesting a resource identified by a “coaps+ws” URI negotiates a secure WebSocket connection to a WebSocket server endpoint, with a “wss" URI. This is described and depicted in section 6.4. As provided by the guidance in Section 4.1 of [RFC6455], the client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-implement TLS functionality for certificates, when a CoAP server exposes resources identified by a “coaps+ws” URI. For the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies.
Minor. Regarding for the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies .... RFC6455 actually refers to an HTTPS (HTTP-over-TLS) port in this section:
Thanks Brian, this is ok with me
Change:
data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of <del> the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </del> <ins> the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </ins> 2.5.

Discussion:
However there are cases where the congestion window can increase when 0-RTT continues to be sent. Some involve packet loss and so probably won't result in a net increase in the window, though the total number of packets might still exceed the initial window size. Others, like TLS HelloRetryRequest or large certificates, involve additional round trips in the handshake. The total amount of 0-RTT is also limited by remembered flow control values, though this is indirect as this counts stream data only and packets might be further padded.
The original text sounds correct - cwnd doesn't limit the total number of packets sent when some of those packets are declared lost - although we might want to clarify how the sender can still "retransmit" new packets in later RTTs.
I read this as saying that if your initial congestion window is 10 packets, then you can't send more than 10 packets of 0-RTT. That is not the case, even if it might commonly be that way. A client can send 0-RTT over multiple RTTs if you consider HelloRetryRequest and large handshake flights. In the extreme, there is no real limit to the amount of 0-RTT packets that can be exchanged.
qualification worksYou can't ACK 0-RTT packets in 0-RTT, so realistically it's probably 10 packets worth of 0-RTT data at most, but one could construct some edge cases so this is likely better.
Change:
will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. <del> 8.2.7. </del> <ins> 8.2.6. </ins> The Transport Services interface provides two properties to allow a sender to signal the relative priority of data transmission: the

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
The following list provides an abstract description of the flow depicted in enrollfigure. <del> CA Certs Request: The pledge optionally requests the latest </del> <ins> CA Certs Request [1]: The pledge optionally requests the latest </ins> relevant CA certificates.  This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain- cert (which is contained in the voucher and may be just the domain registrar certificate). <del> CA Certs Response: It MUST contain the current root CA </del> <ins> CA Certs Response [2]: It MUST contain the current root CA </ins> certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates. <del> Attribute Request: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </del> <ins> Attribute Request [3]: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </ins> Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request.  To get these attributes in advance, the attribute request can be used. <del> Attribute Response: It MUST contain the attributes to be included in the subsequent certification request. </del> <ins> Attribute Response [4]: It MUST contain the attributes to be included in the subsequent certification request. </ins> <del> Certificate Request: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </del> <ins> Certificate Request [5]: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </ins> possession of the corresponding private key and proof-of-identity of the requester. <del> Certificate Response: The certification response message MUST </del> <ins> Certificate Response [6]: The certification response message MUST </ins> contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs. <del> Certificate Confirm: An optional confirmation sent after the </del> <ins> Certificate Confirm [7]: An optional confirmation sent after the </ins> requested certificate has been received and validated.  It contains a positive or negative confirmation by the pledge whether the certificate was successfully enrolled and fits its needs. <del> PKI/Registrar Confirm: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </del> <ins> PKI/Registrar Confirm [8]: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </ins> The generic messages described above may be implemented using various enrollment protocols supporting authenticated self-contained objects,

Discussion:
This is mostly typos and rewording, plus converting some diagrams so that aasvg can do a better job.
Thank you for improvements. I will merge them now and then place some fixups.
Change:
A user agent sends a POST request to its configured push service resource to create a new subscription. <del> A 201 (Created) response indicates that the a push subscription was </del> <ins> A 201 (Created) response indicates that the push subscription was </ins> created.  A URI for the push message subscription resource that was created in response to the request MUST be returned in the Location header field.

Discussion:
This is the initial update for the Spencer Dawkins review. I'll wait to see if there are additional comments to address before merging. Editorial update to Section 7.4 Also fixed a the a nit.
Merging per Spencer's response.