jiebi/CodeConvo huggingface dataset:
Change:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.

Discussion:
acknowledged at the connection level with a DATA_ACK.  Further details are in sec_close. <del> There is an additional method of connecton closure, referred to as </del> <ins> There is an additional method of connection closure, referred to as </ins> "Fast Close", which is analogous to closing a single-path TCP connection with a RST signal.  The MP_FASTCLOSE signal is used to indicate to the peer that the connection will be abruptly closed and

the MPTCP connection would continue to provide a regular TCP service. Since key generation is implementation-specific, there is no <del> requirement that they be simply random numbers.  An implemention is </del> <ins> requirement that they be simply random numbers.  An implementation is </ins> free to exchange cryptographic material out-of-band and generate these keys from this, in order to provide additional mechanisms by which to verify the identity of the communicating entities.  For

numbers is not required, then an implementation MAY include just the lower 32 bits of the data sequence number in the data sequence mapping and/or Data ACK as an optimization, and an implementation can <del> make this choice independently for each packet.  An implementaton </del> <ins> make this choice independently for each packet.  An implementation </ins> MUST be able to receive and process both 64-bit or 32-bit sequence number values, but it is not required that an implementation is able to send both.

can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session.  The MP_FAIL signal affects only one direction of traffic.  It is not mandatory <del> for the reciever of an MP_FAIL to also respond with an MP_FAIL, since </del> <ins> for the receiver of an MP_FAIL to also respond with an MP_FAIL, since </ins> the paths may only be damaged in one direction.  However, implementations MAY choose to send a MP_FAIL in the reverse direction and entirely revert to a regular TCP session.

that can be applied here.  Furthermore, an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms.  Also a change from RFC6824 has removed the subflow <del> identifer from the MP_PRIO option (sec_policy), to remove the </del> <ins> identifier from the MP_PRIO option (sec_policy), to remove the </ins> theoretical attack where a subflow could be placed in "backup" mode by an attacker.
Change:
NAME I'm struggling with Github here and can't figure out what change you want.
Thanks.
Disregard, I found it and pushed myself.

Discussion:
4.2.3. <del> Each PAUploadReq carries a list of extensions that clients may use to </del> <ins> Each UploadReq carries a list of extensions that clients may use to </ins> convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form:
Change:
Remove terms which are infrequently used (and in a few cases, remove the unnecessary references) Clean up a few terms which appear to be defined incorrectly.

Discussion:
by refusing to emit output shares. Input validity proof forging.  Any aggregator can collude with a <del> malicious client to craft a proof share that will fool honest </del> <ins> malicious client to craft a proof that will fool honest </ins> aggregators into accepting invalid input. 6.1.2.3.

aggregating invalid inputs. This capability is no stronger than any aggregator's ability to <del> forge validity proof shares in collusion with a malicious client. </del> <ins> forge validity proof in collusion with a malicious client. </ins> Relaying messages between aggregators.  The leader can compromise availability by dropping messages.

[TODO: Decide how to provide mutual authentication in leader-to- helper and collector-to-leader connections.  One option is to use client certificates for TLS; another is to have the leader sign its <del> messages directly, as in Prio v2.  For collector-to-leader connections, we may just have this be up to deployment.  (For instance, the collector might authenticate themselves by logging into a website that has some trust relationship with the leader.)] </del> <ins> messages directly.  For collector-to-leader connections, we may just have this be up to deployment.  (For instance, the collector might authenticate themselves by logging into a website that has some trust relationship with the leader.)] </ins> 11.

faster implementations?]] The table below lists parameters that meet these criteria at various <del> levels of security.  (Note that #1 is the field used in "Prio v2".) The "size" column indicates the number of bits required to represent elements of the field. </del> <ins> levels of security.  The "size" column indicates the number of bits required to represent elements of the field. </ins> [TODO: Choose new parameters for 2, 3, and 5 so that p is as close to 2^size as possible without going over. (4 is already close enough; 1
Change:
Apply to clean up some other whitespace stuff, too.
Because you'll also want a "jitter buffer" on the receiver side and that means something different. Instead of having a random value, why not just have time be to a nanosecond clock and then lexically sort between collisions?
Which will also help one remove duplicates.
Yeah, this is a bad name :)

Discussion:
Each endpoint in the system must agree on the configuration for each task, which is defined using the Param structure: <del> "nonce": A unique sequence of bytes used to ensure that two </del> <ins> "uuid": A unique sequence of bytes used to ensure that two </ins> otherwise identical "Param" instances will have distinct "TaskID"s.  It is RECOMMENDED that this be set to a random 16-byte string derived from a cryptographically secure pseudorandom number
Change:
It seems silly to have clients revalidating the HPKE key for each request, so we probably want some kind of caching. I'm not sure HTTP Caching is quite what we want, but something... NAME NAME recommendations?
I'm going to need a little more context to provide good advice. If we don't need key consistency (it doesn't appear so) and you only need correctness, then the client should just be able to talk directly to the collector and get keys periodically. HTTP caching works fine for that purpose. This would also need a rejection message so that the collector (or the leader on their behalf - the leader is more likely to learn about bad key identifiers before clients) can reject an out-of-date key in case the cache needs to be invalidated.
We do not need key consistency. The rejection message seems like a good idea.

Discussion:
is derived from the PPM parameters as: <del> Where param is just the serialization of Param. </del> <ins> Where param is the serialization of Param. </ins> 4.2.

Config.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: <del> [TODO: Decide whether to use the same config structure as OHTTP/ECH. This would add support for multiple cipher suites.] </del> <ins> [OPEN ISSUE: Decide whether to expand the width of the id, or support multiple cipher suites (a la OHTTP/ECH).] </ins> The client issues a key configuration request to "Param.leader_url" and "Param.helper_url".  It aborts if any of the following happen for

the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <ins> Aggregators SHOULD use HTTP caching to permit client-side caching of this resource RFC5861.  Aggregators SHOULD favor long cache lifetimes to avoid frequent cache revalidation, e.g., on the order of days. Aggregators can control this cached lifetime with the Cache-Control header, as follows: </ins> Clients SHOULD follow the usual HTTP caching RFC7234 semantics for <del> key configurations.  Aggregators SHOULD favor long cache lifetimes to avoid frequent cache revalidation. </del> <ins> key configurations. </ins> Note: Long cache lifetimes may result in clients using stale HPKE keys; aggregators SHOULD continue to accept reports with old keys for <del> a reasonable period after key changes in order to avoid rejecting reports.  [[OPEN ISSUE: https://github.com/abetterinternet/prio- documents/issues/106]] </del> <ins> at least twice the cache lifetime in order to avoid rejecting reports. </ins> 4.2.2.

value in more than one report if the leader responds with status 200 and an empty body. <ins> The leader responds to requests with out-of-date "HpkeConfig.id" values, indicated by "EncryptedInputShare.config_id", with status 400 and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </ins> 4.2.3. Each UploadReq carries a list of extensions that clients may use to
Change:
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.

Discussion:
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:

10.1.  URIs <del> [1] https://github.com/abetterinternet/prio-documents/issues/102 </del> <ins> [1] https://github.com/abetterinternet/ppm-specification/issues/102 </ins> <del> [2] https://github.com/abetterinternet/prio-documents/issues/22 </del> <ins> [2] https://github.com/abetterinternet/ppm-specification/issues/22 </ins>
Change:
What PPM calls an "output share" is called an "aggregate share" in the VDAF draft. Furthermore, in the VDAF draft, an "output share" is what an aggregator recovers from running the MPC with its peers. This change fixes this ambiguity without changing the PPM protocol itself (modulo changing the info string for HPKE).
Squashed.
Thanks fellas!
Generally looks good. I would change the "agg" in the label if you can as it is confusing.LGTM, modulo typos

Discussion:
input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share <del> could not be recovered. </del> <ins> could not be computed. </ins> To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation <del> in order to validate their recovered output shares.  For example, </del> <ins> in order to validate their corresponding output shares.  For example, </ins> "prio3" includes a distributed zero-knowledge proof of the input's validity BBCGGI19 which the aggregators can jointly verify and reject the report if it cannot be verified.  However, they do not learn
Change:
While reviewing , NAME and I figured out a way to redefine so that invalid values cannot be represented[1]. The existing representation contains and , which means an interval could be defined with , which is invalid. Redefining as a start instant and a duration makes it impossible to represent invalid s (since is an unsigned integer). Additionally, this implicitly fixes a bug in the batch interval validation logic: we asserted that should be divisible by , but since is excluded from the , I think that was incorrect. Instead, should be divisible by . In any case, this is simpler with the new definition of : needs to be a multiple of . [1]: URL
Nice!

Discussion:
First the aggregator checks that the request's batch interval respects the boundaries defined by the PPM task's parameters. Namely, it checks that both "batch_interval.start" and <del> "batch_interval.end" are divisible by "min_batch_duration" and that "batch_interval.end - batch_interval.start >= min_batch_duration". Unless both these conditions are true, it aborts and alerts the peer with "invalid batch interval". </del> <ins> "batch_interval.duration" are divisible by "min_batch_duration" and that "batch_interval.duration >= min_batch_duration".  Unless both these conditions are true, it aborts and alerts the peer with "invalid batch interval". </ins> Next, the aggregator checks that the request respects the generic privacy parameters of the PPM task.  Let "X" denote the set of
Change:
Here are a few small editorial changes: Refer to TLS's "presentation language", per section 3 of the RFC. The output from the HPKE setup function is an encapsulated key, not an encapsulated context. The term context is defined as "A context is an implementation-specific structure...", whereas is alternately described as "an encapsulated KEM shared secret", an "encapsulated key", or a "KEM encapsulated key". Remove stray whitespace from a hyphenated word.
One non-blocking comment.

Discussion:
The following terms are used: <del> This document uses the protocol definition language of RFC8446. </del> <ins> This document uses the presentation language of RFC8446. </ins> 2.

"HpkeConfig" is the key config of the aggregator receiving the input share. <del> "enc" is the encapsulated HPKE context, used by the aggregator to </del> <ins> "enc" is the HPKE encapsulated key, used by the aggregator to </ins> decrypt its input share. "payload" is the encrypted input share.

where "pk" is the aggregator's public key, "task_id" is "Report.task_id" and "server_role" is a byte whose value is "0x01" if the aggregator is the leader and "0x00" if the aggregator is the <del> helper. "enc" is the encapsulated HPKE context and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </del> <ins> helper. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </ins> where "input_share" is the aggregator's input share and "nonce" and "extensions" are the corresponding fields of "Report".

"collector_hpke_config_id" is "collector_config.id" from the task parameters corresponding to "CollectReq.task_id". <del> "enc" is the encapsulated HPKE context, used by the collector to </del> <ins> "enc" is the HPKE encapsulated key, used by the collector to </ins> decrypt the aggregate share. "payload" is an encrypted "AggregateShare".

7.3. The following value [will be/has been] registered in the "IETF URN <del> Sub- namespace for Registered Protocol Parameter Identifiers" </del> <ins> Sub-namespace for Registered Protocol Parameter Identifiers" </ins> registry, following the template in RFC3553: Initial contents: The types and descriptions in the table in errors
Change:
The info strings used in HPKE context construction used the prefix "pda", referring to the old "Private Data Aggregation" name of this protocol. This commit also adds text instructing the collector how to decrypt the aggregate shares it receives and to use the VDAF's unsharding algorithm to obtain aggregate results.
Question for the reviewers: VDAF defines labels like (). Should we include the draft version number in info strings like this? e.g. ?

Discussion:
(see issue#57).  For example, how does a leader respond to a collect request if the helper drops out?] <ins> The collector then decrypts each aggregate share "share" using the following procedure: where "sk" is the HPKE secret key, "task_id" is "AggregateReq.task_id" and "server_role" is the role of the server that send the aggregate share ("0x01" for the leader and "0x00" for the helper). "batch_interval" is the "Interval" from the "CollectReq".  The collector then unshards the aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm. </ins> 4.4.1. Before an aggregator responds to a collect request or aggregate-share
Change:
CollectResp is paired with CollectReq; naming things this way matches other {Req, Resp} message pairs.

Discussion:
When both aggregators' shares are successfully obtained, the leader responds to subsequent HTTP GET requests to the collect job's URI <del> with HTTP status 200 OK and a body consisting of a "CollectResult": </del> <ins> with HTTP status 200 OK and a body consisting of a "CollectResp": </ins> "shares" is a vector of "EncryptedAggregateShare"s, as described in aggregate-share-request, except that for the leader's share,

CollectReq pa-collect: "message/ppm-collect-req" <del> CollectResult pa-collect: "message/ppm-collect-result" </del> <ins> CollectResp pa-collect: "message/ppm-collect-resp" </ins> The definition for each media type is in the following subsections.
Change:
While implementing upload today, I also noticed some inconsistencies between the handling of reports in the leader during the upload protocol and the helper

Discussion:
the HTTP server responds with an HTTP error status as described in errors. <del> If a fatal error is encountered while processing an HTTP request, </del> <ins> If a fatal error is encountered while processing an HTTP response, </ins> the HTTP client... [TODO: Figure out what behavior is called for here.  An HTTP request should be sent that conveys the error.]

FAILED without sending a message to the helper.  Otherwise it interprets "out" as follows.  If this is the last round of VDAF preparation phase, then "out" is the leader's output share, in which <del> case the leader finishes.  Otherwise, it interpresets "out" as the </del> <ins> case the leader finishes.  Otherwise, it interprets "out" as the </ins> tuple "(new_state, outbound)", where "new_state" is its new preparation state and "outbound" is its next VDAF messaage, and continues with "outbound" as its next VDAF message.  Either way, it

the tag.  If this check fails, it MUST abort with error "invalidHmac". <del> Next, it first checks that the sequence of Transition messages corresponds to the ReportShare sequence of the AggregateInitReq.  If any message appears out of order or is missing, or a transition has an unrecognized nonce, then the leader MUST abort with error </del> <ins> Next, it checks that the sequence of Transition messages corresponds to the ReportShare sequence of the AggregateInitReq.  If any message appears out of order or is missing, or a transition has an unrecognized nonce, then the leader MUST abort with error </ins> "unrecognizedMessage". Next, for each Transition, the leader proceeds as described in prep-
Change:
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
!

Discussion:
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
Change:
Adds definitions of error codes to section 3.1 for validation of batch intervals in or . Also adds an error code for leader to use when rejecting a report from too far in the future.
NAME I can't request review from you until you accept the invite to the ietf-wg-ppm organization but you should see this PR too!

Discussion:
The aggregator keeps track of the number of times each report was aggregated.  If any input share in "X" was added to at least "max_batch_lifetime" previous batches, then the aggregator aborts <del> and alerts the peer with error "privacyBudgetExceeded". </del> <ins> and alerts the peer with error "batchLifetimeExceeded". </ins> 4.7.
Change:
Defines more error types to represent various failure modes, updates protocol text to indicate when the new error types should be used, and affirms that the task ID should be encoded as base64url with no padding (since task ID has a fixed size).
NAME observes that we have an awkward MUST requirement on leaders buffering received reports: URL
We have some error codes like that aren't enumerated in the table in . We should bring that table up to date. While we're in there, I think and aren't the right types, since outdatedness or staleness aren't the only reasons that an HPKE config or report, respectively, could be rejected.
The error table was brought up to date by .
Looks great!

Discussion:
ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a <del> "taskid" member which contains the associated PPM task ID, encoded in Base 64 using the URL and filename safe alphabet with no padding as defined in sections 5 and 3.2 of RFC4648 (this value is always known, see task-configuration). </del> <ins> "taskid" member which contains the associated PPM task ID (this value is always known, see task-configuration), encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of RFC4648. </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For

comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the helpers enforce this as well; see collect-flow.)  In addition, the leader SHOULD abort the <del> upload protocol and alert the client with error "staleReport". </del> <ins> upload protocol and alert the client with error "reportTooLate". </ins> The leader MUST buffer reports while waiting to aggregate them.  The leader SHOULD NOT accept reports whose timestamps are too far in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If the leader rejects a report for this reason, it SHOULD abort the upload protocol <del> and alert the client with error "reportFromTheFuture". </del> <ins> and alert the client with error "reportTooEarly". </ins> 4.2.3.
Change:
Per NAME
NAME observes that we have an awkward MUST requirement on leaders buffering received reports: URL

Discussion:
as well; see collect-flow.)  In addition, the leader SHOULD abort the upload protocol and alert the client with error "reportTooLate". <del> The leader MUST buffer reports while waiting to aggregate them.  The </del> <ins> Leaders can buffer reports while waiting to aggregate them.  The </ins> leader SHOULD NOT accept reports whose timestamps are too far in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If the leader
Change:
All of the following are currently used to refer to 200 responses: status 200 HTTP 200 OK HTTP status 200 HTTP status 200 OK Would be nice to pick one and use it consistently.
I didn't check if this change is complete, in the sense of making all the language in the doc consistent, but it's at least self-consistent. !

Discussion:
in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize the task ID, then it responds with HTTP status code 404 <del> and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with HTTP status code 200 OK and an "HpkeConfig" value: </del> <ins> Not Found and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with HTTP status code 200 OK and an "HpkeConfig" value: </ins> [TODO: Allow aggregators to return HTTP status code 403 Forbidden in deployments that use authentication to avoid leaking information