jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ppm-dap

Commentary: please have another look 
 This seems useful , since it disambiguates " tasklifetime " and " batchlifetime " . The former , as i understand it , is a timestamp ; and the latter is a number of queries . cc/ for thoughtful review here
Paragraph (version A):
Next, the Aggregator checks that the batch has not been aggregated
too many times.  This is determined by the maximum number of times a
batch can be queried, "max_batch_query_count".  Unless the query has
been issued less than "max_batch_query_count" times, the Aggregator
MUST abort with error of type "batchLifetimeExceeded".
Paragraph (version B):
Next, the Aggregator checks that the batch has not been aggregated
too many times.  This is determined by the maximum number of times a
batch can be queried, "max_batch_query_count".  Unless the query has
been issued less than "max_batch_query_count" times, the Aggregator
MUST abort with error of type "batchQueriedTooManyTimes".
Draft: draft-ietf-ppm-dap

Commentary: The prepare_shares fields were always of type PrepareStep . To match the convention used for most other field names , I change the name of the field to match its type . ( There is no " PrepareShare " type . )
Paragraph (version A):
The order of AggregateContinueResp.prepare_shares MUST match that of
the PrepareStep values in "AggregateContinueReq.prepare_shares".  The
helper's response to the leader is an HTTP status code 200 OK whose
body is the AggregateContinueResp and media type is "message/dap-
aggregate-continue-resp".  The helper then awaits the next message
from the leader.
Paragraph (version B):
The order of AggregateContinueResp.prepare_steps MUST match that of
the PrepareStep values in "AggregateContinueReq.prepare_steps".  The
helper's response to the leader is an HTTP status code 200 OK whose
body is the AggregateContinueResp and media type is "message/dap-
aggregate-continue-resp".  The helper then awaits the next message
from the leader.
Draft: draft-ietf-ppm-dap

Commentary: Based on ( merge that first ) .
Paragraph (version B):
Define a new task configuration parameter, called the task
"expiration", that defines the lifetime of a given task.
Paragraph (version B):
Make "task_id" an optional parameter of the "/hpke_config"
endpoint.
Paragraph (version B):
Clarify when it is safe for an Aggregator to evict various data
artifacts from long-term storage.
Draft: draft-ietf-ppm-dap

Commentary: I - D Nits complains of outdated reference for : * * Obsolete normative reference : RFC 7234 ( Obsoleted by RFC 9111 ) We should update tit . 
 Thanks !
Paragraph (version A):
Clients SHOULD follow the usual HTTP caching RFC7234 semantics for
key configurations.
Paragraph (version B):
Clients SHOULD follow the usual HTTP caching RFC9111 semantics for
key configurations.
Draft: draft-ietf-ppm-dap

Commentary: let 's squash - then - merge this change . 
 contains a nice definition and discussion of the notions of privacy ( meaning protecting any individual client 's measurement from being seen ) and robustness ( meaning that the aggregates delivered to a collector are accurate aggregations over the inputs ) . DAP 's security considerations has definitions of privacy and correctness , and we refer to robustness and soundness in a few places . We should align our definitions with VDAF ( or just refer to VDAF 's definitions ) and consistently use the term " robustness " throughout DAP . 
 PR , please ! 
 I 'm going to get this done for draft-02 , hopefully early next week .
Paragraph (version A):
Privacy.  Clients trust that some aggregator is honest.  That is,
as long as at least one aggregator executes the protocol
faithfully, the parties learn nothing beyond the aggregate result
(i.e., the output of the aggregation function computed over the
honest measurements).
Paragraph (version A):
Correctness.  The collector trusts that the aggregators execute
the protocol correctly.  That is, as long as the aggregators
execute the protocol faithfully, a malicious client can skew the
aggregate result only by reporting a false (untruthful)
measurement.  The result cannot be influenced in any other way.
Paragraph (version B):
In the presence of this adversary, DAP aims to achieve the privacy
and robustness security goals described in VDAF's Security
Considerations section.
Draft: draft-ietf-ppm-dap

Commentary: Align with the latest VDAF draft . This requires two minor protocol changes : 02 a value called the " publicshare " to the VDAF syntax . This is to support Poplar1 ( and likely other schemes that need a similar extractability property ) . To accommodate this , the publicshare field has been to the Report and ReportShare structures and appended to the AAD for input share encryption . ( This may end up being useful for privacy . ) 02 the report count to the aggregate result computation . This is already passed to the Collector in the CollectResp , so we just need to update the aggregate result computation in the draft to match . 
 Rebased and pushed a minor update : The public share in Report and ReportStore now both have the same length prefix . 
 Rebased . 
 This will be VDAF-02 or 03 , depending on when we need to cut DAP-02 . 
 VDAF-03 is out , I will send a PR by end of week .
Paragraph (version A):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); and "agg_param" is the opaque aggregation
parameter distributed to the aggregtors by the collector.
Paragraph (version B):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); "agg_param" is the opaque aggregation
parameter distributed to the aggregtors by the collector;
"public_share" is the public share generated by the client and
distributed to each aggregator; and "input_share" is the aggregator's
input share.
Draft: draft-ietf-ppm-dap

Commentary: This adds a field to collect responses with the number of reports that contributed to the aggregation . Collectors will likely want this count to aid in the interpretation of aggregate results . ( see ) There is also a change in draft - irtf - cfrg - vdaf-02 that opens the door for VDAFs that would require the report count during unsharding . ( see cfrg / draft - irtf - cfrg - vdaf ) Note that while this field is not part of the adjacent s , it will be protected by to the confidentiality of HTTPS and the leader - collector bearer token authentication . 
 I 'm open to pushing it into the ciphertext , but my thinking was that a tampered reportcount would only affect robustness , not privacy , and thus we only need to arrive at the correct reportcount when all aggregators follow the protocol . 
 can you please rebase ? Sorry ! 
 Collectors will want to know how many inputs are included in the aggregations they receive , for a number of reasons : they may wish to compute a mean over a privately aggregated sum , or track metrics on how many clients are providing inputs . struct should include a count of how many contributions went into an aggregation . 
 The linked PR only a to the structure , which communicates it to the helper . I 'm reopening this issue because the collector does not yet receive this information . In addition to the statistics - related motivation above , a recent PR to the VDAF spec , cfrg / draft - irtf - cfrg - vdaf , expects the number of reports to be available when unsharding . 
 This was completed in . 
 OK , seems reasonable to me .
Paragraph (version A):
The "encrypted_agg_shares" field is the vector of encrypted aggregate
shares.  They MUST appear in the same order as the aggregator
endpoints list of the task parameters.
Paragraph (version B):
"report_count" is the number of reports included in the
aggregation.
Paragraph (version B):
"encrypted_agg_shares" is the vector of encrypted aggregate
shares.  They MUST appear in the same order as the aggregator
endpoints list of the task parameters.
Draft: draft-ietf-ppm-dap

Commentary: The next VDAF draft is out . It includes some minor changes that we 'll need to adopt here .
Paragraph (version A):
"vdaf_verify_param" is the public VDAF parameter, and "agg_param" is
the opaque aggregation parameter.  If either step fails, the
aggregator marks the report as invalid with error "vdaf-prep-error".
Paragraph (version A):
Otherwise, the value "out" is interpreted as follows.  If this is the
last round of the VDAF, then "out" is the aggregator's output share.
Otherwise, "out" is the pair "(prep_state, prep_msg)".
Paragraph (version B):
"vdaf_verify_key" is the VDAF verification key shared by the
aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and
"0x01" for the helper); and "agg_param" is the opaque aggregation
parameter distributed to the aggregtors by the collector.
Paragraph (version B):
If either step fails, the aggregator marks the report as invalid with
error "vdaf-prep-error".  Otherwise, the value "out" is interpreted
as follows.  If this is the last round of the VDAF, then "out" is the
aggregator's output share.  Otherwise, "out" is the pair
"(prep_state, prep_msg)".
Paragraph (version A):
In the continuation phase, the leader drives the VDAF preparation of
each share in the candidate report set until the underlying VDAF
moves into a terminal state, yielding an output share for all
aggregators or an error.  This phase may involve multiple rounds of
interaction depending on the underlying VDAF parameters.  Each round
trip is initiated by the leader.
Paragraph (version B):
In the continuation phase, the leader drives the VDAF preparation of
each share in the candidate report set until the underlying VDAF
moves into a terminal state, yielding an output share for all
aggregators or an error.  This phase may involve multiple rounds of
interaction depending on the underlying VDAF.  Each round trip is
initiated by the leader.
Draft: draft-ietf-ppm-dap

Commentary: Previously , report - replayed would be returned if the same client report was aggregated more than once . However , some VDAFs ( e.g. poplar1 ) will require repeatedly aggregating a given client report with varying aggregation parameters . This commit relaxes the condition on which report - replayed will be returned to allow aggregating the same client report multiple times , as long as each aggregation has a distinct aggregation parameter . 
 This is odd because the aggregation parameter is opaque and it 's not clear if any change to it should allow aggregating a report again . For example , if aggregation is allowed only once for privacy reasons but some kind of shared random number is needed as agg_param this will be an issue . I think checking if another aggregation is allowed has to be done depending on the VDAF and the task . 
 There is a separate check , under the section " Validating Batch Parameters " , that each report is used in at most aggregate shares . This should be set to 1 for Prio3 and VDAFs like you describe . If for a task is 1 , then the present change will make no difference , but if for a task is greater than one , we need this change in order to allow that second batch . 
 Currently , the report share error is returned " if the report has already been aggregated " ( ) . Some VDAFs , like , will require repeatedly aggregating the same client reports with a varying aggregation parameter . I think the specification language would effectively block this use - case currently . I think the fix is to return a error if the report has already been aggregated with the same aggregation parameter . Note that this change would not allow a malicious leader to potentially aggregate a different set of reports with a different aggregation parameter : the existing error would be returned if a client attempted to upload another report after the first collection attempt . ( Given the small size of the proposed fix , I 'll send a PR shortly , but discussion on this issue / the WG mailing list takes precedence -- I 'll update the PR to follow any changes from discussion . ) 
 Thanks -- this change LGTM .
Paragraph (version A):
Check if the report has already been aggregated.  If this check
fails, the input share is marked as invalid with the error
"report-replayed".  This is the case if the report was used in a
previous aggregate request and is therefore a replay.  An
aggregator may also choose to mark an input share as invalid with
the error "report-dropped" under the conditions prescribed in
anti-replay.
Paragraph (version B):
Check if the report has already been aggregated with this
aggregation parameter.  If this check fails, the input share is
marked as invalid with the error "report-replayed".  This is the
case if the report was used in a previous aggregate request and is
therefore a replay.  An aggregator may also choose to mark an
input share as invalid with the error "report-dropped" under the
conditions prescribed in anti-replay.
Draft: draft-ietf-ppm-dap

Commentary: This fixes a reference that was pointing at the wrong section . The behavior relating to is under " Input Share Validation " .
Paragraph (version A):
To detect replay attacks, each aggregator keeps track of the set of
nonces pertaining to reports that were previously aggregated for a
given task.  If the leader receives a report from a client whose
nonce is in this set, it simply ignores it.  A helper who receives an
encrypted input share whose nonce is in this set replies to the
leader with an error as described in collect-flow.
Paragraph (version B):
To detect replay attacks, each aggregator keeps track of the set of
nonces pertaining to reports that were previously aggregated for a
given task.  If the leader receives a report from a client whose
nonce is in this set, it simply ignores it.  A helper who receives an
encrypted input share whose nonce is in this set replies to the
leader with an error as described in input-share-batch-validation.
Draft: draft-ietf-ppm-dap

Commentary: This is a follow - up to , removing a few dangling references to the helper state blob .
Paragraph (version A):
In order to allow the helpers to retain minimal state, the helper can
attach a state parameter to its response, with the leader returning
the state value in the next request, thus offloading the state to the
leader.  This state value MUST be cryptographically protected as
described in agg-init.
Paragraph (version A):
Implement some form of batch-to-report index, as well as inter-
and intra-batch replay mitigation storage, which includes some way
of tracking batch report size with optional support for state
offloading.  Some of this state may be used for replay attack
mitigation.  The replay mitigation strategy is described in anti-
replay.
Paragraph (version B):
Implement some form of batch-to-report index, as well as inter-
and intra-batch replay mitigation storage, which includes some way
of tracking batch report size.  Some of this state may be used for
replay attack mitigation.  The replay mitigation strategy is
described in anti-replay.
Paragraph (version A):
Store helper state.
Draft: draft-ietf-ppm-dap

Commentary: AggregateShareReq should have an aggregation parameter field instead of aggregation job ID . 
 Thanks for spotting this !
Paragraph (version A):
"job_id" is the ID of the aggregation job.
Paragraph (version B):
"agg_param", an aggregation parameter for the VDAF being executed.
Draft: draft-ietf-ppm-dap

Commentary: Per 
 observes that we have an awkward MUST requirement on leaders buffering received reports :
Paragraph (version A):
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
and alert the client with error "reportTooEarly".
Paragraph (version B):
Leaders can 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
and alert the client with error "reportTooEarly".
Draft: draft-gpew-priv-ppm

Commentary: The only language I can find in the document that prescribes serialization is in Section 1.2 ( please point out if I missed anything ): We intend this statement to be prescriptive , i.e. , encoding / decoding of messages is as defined in RFC8446 . Another valid interpretation might be " we define the fields of each message following the conventions of RFC8446 , but leaving encoding / decoding unspecified " . I think it would help to refine this statement a bit . WDYTA : 
 SGTM FWIW ( this was our interpretation , and I think it makes sense to clarify ) 
 Yeah , this seems like a fine clarification . I do n't think it was under specified before , but more information for those unfamiliar with TLS - style encoding does n't hurt .
Paragraph (version A):
This document uses the presentation language of RFC8446.
Paragraph (version B):
This document uses the presentation language of RFC8446 to define
messages in the PPM protocol.  Encoding and decoding of these
messages as byte strings also follows RFC8446.
Draft: draft-gpew-priv-ppm

Commentary: Would be helpful to readers if this reference was fixed in the Editor 's Copy : [ I - D.draft - cfrg - patton - vdaf ] " BROKEN REFERENCE " . 
 Maybe change each reference to ? That way it 'll render like in the text , which reads a bit nicer .
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 computed.
Paragraph (version B):
In order to address this problem, the aggregators engage in a secure,
multi-party computation specified by the chosen VDAF 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.
Draft: draft-gpew-priv-ppm

Commentary: 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 . 
 I ca n't request review from you until you accept the invite to the ietf - wg - ppm organization but you should see this PR too !
Paragraph (version A):
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
and alerts the peer with error "privacyBudgetExceeded".
Paragraph (version B):
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
and alerts the peer with error "batchLifetimeExceeded".
Draft: draft-gpew-priv-ppm

Commentary: Extracted and slightly modified from . 
 ( Build failure appears to be some GitHub API issue . ) 
 Ah , this looks like we 're hitting the patch for I 'll check if the upstream template repository has a fix . 
 Thanks 
 !
Paragraph (version A):
A unique identifier for the VDAF being used for the task.
Paragraph (version B):
A unique identifier for the VDAF instance used for the task,
including the type of measurement associated with the task.
Draft: draft-gpew-priv-ppm

Commentary: Section 3.1 says to include the PPM task ID in a field on the problem details JSON object , but the task ID may be any 32 byte value , and may not be representable as a Unicode string . I propose that we base64 - encode the task ID here to resolve this .
Paragraph (version A):
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, encoded
with base64 RFC4648 (this value is always known, see task-
configuration).
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, encoded
with base64 using the standard alphabet RFC4648 (this value is always
known, see task-configuration).
Draft: draft-gpew-priv-ppm

Commentary: While implementing upload today , I also noticed some inconsistencies between the handling of reports in the leader during the upload protocol and the helper
Paragraph (version A):
If either of these operations fails, then the leader moves to state
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
case the leader finishes.  Otherwise, it interpresets "out" as the
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
moves to state WAITING.
Paragraph (version B):
If either of these operations fails, then the leader moves to state
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
case the leader finishes.  Otherwise, it interprets "out" as the
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
moves to state WAITING.
Paragraph (version A):
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
"unrecognizedMessage".
Paragraph (version B):
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
"unrecognizedMessage".