jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-gpew-priv-ppm

Commentary: 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. ?
Paragraph (version B):
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.
Draft: draft-gpew-priv-ppm

Commentary: 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 .
Paragraph (version A):
This document uses the protocol definition language of RFC8446.
Paragraph (version B):
This document uses the presentation language of RFC8446.
Paragraph (version A):
"enc" is the encapsulated HPKE context, used by the aggregator to
decrypt its input share.
Paragraph (version B):
"enc" is the HPKE encapsulated key, used by the aggregator to
decrypt its input share.
Paragraph (version A):
"enc" is the encapsulated HPKE context, used by the collector to
decrypt the aggregate share.
Paragraph (version B):
"enc" is the HPKE encapsulated key, used by the collector to
decrypt the aggregate share.
Draft: draft-gpew-priv-ppm

Commentary: While reviewing , and I figured out a way to redefine so that invalid values can not 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 ] : 
 Nice !
Paragraph (version A):
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
"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".
Paragraph (version B):
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
"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".
Draft: draft-gpew-priv-ppm

Commentary: 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
Paragraph (version A):
In order to address this problem, the aggregators engage in a secure,
multi-party computation specified by the chosen VDAF I-D.draft-cfrg-
patton-vdaf in order to prepare a report for aggregation.  At the
beginning of this computation, each aggregator is in possession of an
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
could not be recovered.
Paragraph (version A):
To facilitiate this computation, the input shares generated by the
client include information used by the aggregators during aggregation
in order to validate their recovered output shares.  For example,
"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
anything about the individual report other than that it is valid.
Paragraph (version B):
In order to address this problem, the aggregators engage in a secure,
multi-party computation specified by the chosen VDAF I-D.draft-cfrg-
patton-vdaf in order to prepare a report for aggregation.  At the
beginning of this computation, each aggregator is in possession of an
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
could not be computed.
Paragraph (version B):
To facilitiate this computation, the input shares generated by the
client include information used by the aggregators during aggregation
in order to validate their corresponding output shares.  For example,
"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
anything about the individual report other than that it is valid.
Draft: draft-pda-protocol

Commentary: I think this is correct given the namespace reserved in . 
 Good catch !
Paragraph (version A):
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
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:acme:error:unrecognizedMessage".
Paragraph (version B):
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
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:ppm:error:unrecognizedMessage".
Draft: draft-pda-protocol

Commentary: 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   is quite what we want , but something ... recommendations ? 
 I 'm going to need a little more context to provide good advice . If we do n't need key consistency ( it does n'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 .
Paragraph (version A):
Where param is just the serialization of Param.
Paragraph (version B):
Where param is the serialization of Param.
Paragraph (version A):
Clients SHOULD follow the usual HTTP caching RFC7234 semantics for
key configurations.  Aggregators SHOULD favor long cache lifetimes to
avoid frequent cache revalidation.
Paragraph (version B):
Clients SHOULD follow the usual HTTP caching RFC7234 semantics for
key configurations.
Paragraph (version B):
Note: Long cache lifetimes may result in clients using stale HPKE
keys; aggregators SHOULD continue to accept reports with old keys for
at least twice the cache lifetime in order to avoid rejecting
reports.
Paragraph (version B):
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.
Draft: draft-pda-protocol

Commentary: -- is it better practice to define media types per protocol message , or to define a single media type for all protocol messages ? 
 Generally , if they 're different formats -- e.g. , they have different schema , or just different syntax -- they need different media types ( or an explicitly generic one like ) . If it 's one format that has different uses , you can give it a single media type and then switch contexts based upon internal flags . The real question , though , is whether you have any potential for use cases where it 's important for generic software that 's handling these messages to do different things based upon the media type . 
 I do n't think there 'd ever be generic software using these types ( beyond the HpkeConfig ? ) . Most messages are meant to be consumed by PPM and PPM alone . I moved protocol messages to the " message " registry space and kept the HpkeConfig in the application type space , and also left all intended usage fields as COMMON . I also an open issue to have someone more familiar with these registries give these allocation requests a review . this should be good to go based on the above . 
 Currently , DAP uses the following media types ( defined in section 7.1 ): Note that the first uses the top - level type , while the remainder use the top - level type . For consistency , I suggest we use the same top - level type for all messages . Which type is more appropriate ? Per : is for " either uninterpreted binary data or information to be processed by an application " is for " an encapsulated message " ; all of the motivating examples ( see section 5.2 ) are around encaspulating one message format inside another , or fragmenting a message into multiple chunks . provides further guidance that " multipart and message are composite types ; that is , they provide a means of encapsulating zero or more objects , each one a separate media type . " Given that DAP messages are not a method of encapsulating a message of a different type , I suggest that is the more appropriate top - level type to use . This is also supported by the rather large number of media types vs the relatively tiny number of media types in . ( this issue fell out of discussion on ) 
 Agreed , seems better . 
 The types were chosen in PR on a tentative basis , and marked with " OPEN ISSUE : Solicit review of these allocations from domain experts . " Based on the encapsulation reasoning , I agree that be most appropriate for our media types . 
 LGTM except for the he d.
Paragraph (version B):
The definition for each media type is in the following subsections.
Paragraph (version B):
Protocol message format evolution is supported through the definition
of new formats that are identified by new media types.
Paragraph (version B):
IANA [shall update / has updated] the "Media Types" registry at
https://www.iana.org/assignments/media-types with the registration
information in this section for all media types listed above.
Draft: draft-pda-protocol

Commentary: 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 :)
Paragraph (version A):
"nonce": A unique sequence of bytes used to ensure that two
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
generator.
Paragraph (version B):
"uuid": A unique sequence of bytes used to ensure that two
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
generator.
Draft: draft-pda-protocol

Commentary: 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 .
Paragraph (version A):
Input validity proof forging.  Any aggregator can collude with a
malicious client to craft a proof share that will fool honest
aggregators into accepting invalid input.
Paragraph (version B):
Input validity proof forging.  Any aggregator can collude with a
malicious client to craft a proof that will fool honest
aggregators into accepting invalid input.
Paragraph (version A):
This capability is no stronger than any aggregator's ability to
forge validity proof shares in collusion with a malicious
client.
Paragraph (version B):
This capability is no stronger than any aggregator's ability to
forge validity proof in collusion with a malicious client.
Paragraph (version A):
The table below lists parameters that meet these criteria at various
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.
Paragraph (version B):
The table below lists parameters that meet these criteria at various
levels of security.  The "size" column indicates the number of bits
required to represent elements of the field.
Draft: draft-pda-protocol

Commentary: This is just converting to defn . list format . I 'm going to submit a separate PR to clean up the contents .
Paragraph (version A):
Aggregation function: The function computed over the users'
inputs.
Paragraph (version A):
Aggregator: An endpoint that runs the input-validation protocol
and accumulates input shares.
Paragraph (version A):
Batch: A set of reports that are aggregated into an output.
Paragraph (version A):
Batch size: The minimum number of reports in a batch.
Paragraph (version A):
Batch window: The minimum time difference between the oldest and
newest report in a batch (in seconds).
Paragraph (version A):
Client: The endpoint from which a user sends data to be
aggregated, e.g., a web browser.
Paragraph (version A):
Collector: The endpoint that receives the output of the
aggregation function.  It also specifies the parameters of the
protocol.
Paragraph (version A):
False input: An input that is valid, but incorrect.  For example,
if the data being gathered is whether or not users have clicked on
a particular button, a client could report clicks when none
occurred.
Paragraph (version A):
Input: The measurement (or measurements) emitted by a client,
before any encryption or secret sharing scheme is applied.
Paragraph (version A):
Input share: one of the shares output by feeding an input into a
secret sharing scheme.  Each share is to be transmitted to one of
the participating aggregators.
Paragraph (version A):
Input validation protocol: The protocol executed by the client and
aggregators in order to validate the client's input without
leaking its value to the aggregators.
Paragraph (version A):
Invalid input: An input for which the input validation protocol
fails.  For example, if the input is meant to be a bit vectors,
then "[2, 1, 0]" is invalid.
Paragraph (version A):
Measurement: A single value (e.g., a count) being reported by a
client.  Multiple measurements may be grouped into a single
protocol input.
Paragraph (version A):
Leader: A distinguished aggregator that coordinates input
validation and data collection.
Paragraph (version A):
Output: A reduction over the inputs, for instance a statistical
aggregation, which is of interest to a collector.  This is the
output of the aggregation function.
Paragraph (version A):
Output share: The share of an output emitted by an aggregator.
Output shares can be reassembled by the leader into the final
output.
Paragraph (version A):
Prio v1: Mozilla's Origin Telemetry project [1].
Paragraph (version A):
Prio v2: Contact tracing project by Apple, Google, and ISRG.
Paragraph (version A):
Proof: A value generated by the client and used by the aggregators
to verify the client's input.
Paragraph (version A):
Proof share: A share of a proof, used by an aggregator during the
input-validation protocol.
Paragraph (version A):
Report: Uploaded to the leader from the client.  A report contains
the secret-shared and encrypted input and proof.
Paragraph (version A):
Server: An aggregator or collector.
Paragraph (version A):
See #22 [2] for discussion.
Paragraph (version B):
See #22 [1] for discussion.
Draft: draft-pda-protocol

Commentary: ACME has a pretty well defined error structure , including RFC 8707 problem documents . We should look at adopting that . 
 Fixed by
Paragraph (version A):
where "task_id" is the associated PPM task (this value is always
known, see task-configuration) and "payload" contains a string
indicating the error that occurred.  When sent by an aggregator in
response to an HTTP request, the response status is 400.  When sent
in a request to an aggregator, the URL is always
"[aggregator]/error", where "[aggregator]" is the URL of the
aggregator endpoint.
Paragraph (version A):
The following list defines a set of common errors.
Paragraph (version A):
The message type for the payload of each request and response is
unique for a given URL.  If ever a client, aggregator, or
collector receives a request or response to a request with a
malformed payload, then the receiver aborts and alerts the peer
with "unrecognized message".
Paragraph (version A):
Each POST request to an aggregator contains a "TaskID".  If the
aggregator does not recognize the task, i.e., it can't find a
"Param" for which the derived task ID matches the "TaskID", then
it aborts and alerts the peer with "unrecognized task".
Paragraph (version B):
Errors can be reported in PPM both at the HTTP layer and within
challenge objects as defined in iana-considerations.  PPM servers can
return responses with an HTTP error response code (4XX or 5XX).  For
example, if the client submits a request using a method not allowed
in this document, then the server MAY return status code 405 (Method
Not Allowed).
Paragraph (version B):
This list is not exhaustive.  The server MAY return errors set to a
URI other than those defined above.  Servers MUST NOT use the PPM URN
namespace for errors not listed in the appropriate IANA registry (see
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
"taskid" member which contains the associated PPM task ID (this value
is always known, see task-configuration).
Paragraph (version B):
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
example, an "error of type 'unrecognizedMessage'" refers to an error
document with "type" value
"urn:ietf:params:acme:error:unrecognizedMessage".
Paragraph (version B):
Initial contents: The types and descriptions in the table in errors
above, with the Reference field set to point to this specification.
Draft: draft-pda-protocol

Commentary: Removes some TODOs , clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl , and amends collect protocol so that leader output shares are encrypted to collector 's HPKE config . Several response structures no longer have or fields if the appropriate task ( and hence and hence ) can be inferred from the request . 
 I want to address in this PR as well , so downgrading to draft for now . 
 This is ready ; please review at your convenience . 
 Thank you for the review , This picked up some merge conflicts so I will wait for all of changes to land and then rebase . 
 You should be able to rebase now . I am mostly done . 
 Rebased , reordered , ready for re - review 
 This seems to be a dupe fo -- can we close ? 
 Per discussion in the call today , I think this issue is about updating the various PDU definitions to allow for multiple helpers . For instance , currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle 1 helper , which probably involves more rounds of communication . I 'm going to grab this issue because I ran into which I think is related , so I 'll fix both . 
 Right now only the helper 's output share for a batch of reports is encrypted to the collector . We previously agreed that all input shares should be encrypted to the corresponding aggregator ( ) . It makes sense to encrypt the leader 's output share for the same reasons we discussed there . Along the way , the message format should be made to accommodate multiple helpers , as we did for the input shares . 
 Fixed in . Making " the message format [ ... ] accommodate multiple helpers " is specifically tracked in and resolved by .
Paragraph (version B):
"collector_config": The HPKE configuration of the collector
(described in key-config).  Putting the collector's HPKE
configuration directly in "struct PPMParam" absolves collectors of
the burden of operating an HTTP server.  See #102 [1] for
discussion.
Paragraph (version A):
where "pk" is the HPKE public key encoded by the collector's HPKE key
configuration and "output_share" is its serialized output share.
This encryption prevents the leader from learning the actual result,
as it only has its own share and not the helper's share, which is
encrypted for the collector.
Paragraph (version B):
"collector_hpke_config_id" is "collector_config.id" from the
"Param" corresponding to "CollectReq.task_id".
Paragraph (version B):
"enc" is the encapsulated HPKE context, used by the collector to
decrypt the output share.
Paragraph (version B):
"encrypted_output_share" is an encrypted "OutputShare", whose
structure is given below.
Paragraph (version B):
"leader_share" and "helper_share" are "EncryptedOutputShare"s as
described in output-share-request, except that the "task_id",
"batch_start", and "batch_end" used to encrypt the "OutputShare"
are obtained from the "CollectReq".
Paragraph (version A):
See #22 [1] for discussion.
Paragraph (version B):
See #22 [2] for discussion.