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

Commentary:  will need some routine changes : [ x ] Update version tags for HPKE to ( ) [ x ] Bump VDAF-03 to 05 ( ) [ x ] Update change log ( ) [ x ] Run spell check ( )
Paragraph (version A):
After receiving the Helper's response, the Leader uses the
HpkeCiphertext to finialize a collection job (see collect-
finalization).
Paragraph (version B):
After receiving the Helper's response, the Leader uses the
HpkeCiphertext to finalize a collection job (see collect-
finalization).
Draft: draft-ietf-ppm-dap

Commentary: We need for this change to make sense . 
  will need some routine changes : [ x ] Update version tags for HPKE to ( ) [ x ] Bump VDAF-03 to 05 ( ) [ x ] Update change log ( ) [ x ] Run spell check ( )
Paragraph (version A):
Clarify security requirements for choosing VDAF verify key (#407,
#411).
Draft: draft-ietf-ppm-dap

Commentary: And while we 're at it , update an obsolete reference to Oblivious HTTP , which has long since been adopted by its WG . VDAF-05 is n't expected until Monday 3/13 , but we can get this change ready to go . 
  will need some routine changes : [ x ] Update version tags for HPKE to ( ) [ x ] Bump VDAF-03 to 05 ( ) [ x ] Update change log ( ) [ x ] Run spell check ( )
Paragraph (version A):
Client reports can contain auxiliary information such as source IP,
HTTP user agent or in deployments which use it, client authentication
information, which could be used by aggregators to identify
participating clients or permit some attacks on robustness.  This
auxiliary information could be removed by having clients submit
reports to an anonymizing proxy server which would then use Oblivious
HTTP I-D.thomson-http-oblivious to forward inputs to the DAP leader,
without requiring any server participating in DAP to be aware of
whatever client authentication or attestation scheme is in use.
Paragraph (version B):
Client reports can contain auxiliary information such as source IP,
HTTP user agent or in deployments which use it, client authentication
information, which could be used by aggregators to identify
participating clients or permit some attacks on robustness.  This
auxiliary information could be removed by having clients submit
reports to an anonymizing proxy server which would then use Oblivious
HTTP I-D.draft-ietf-ohai-ohttp-07 to forward inputs to the DAP
leader, without requiring any server participating in DAP to be aware
of whatever client authentication or attestation scheme is in use.
Draft: draft-ietf-ppm-dap

Commentary: During implementation of round skew recovery in Janus ( [ 1 ] ) , we noticed that the specification is unclear about what the helper should do if . This commit clarifies that this value is illegal and should be rejected . [ 1 ] : After handling , the helper 's aggregation job will be on round 0 , because the helper is waiting for the leader to send it the first - round broadcast prepare message , with which helper will advance to round 1 . So before this commit , the applicable statement in the text was : Which means the helper would have to retransmit its first - round prepare shares , which it had previously sent in response to . This is implementable but weird : if the leader dropped the response to , then it should recover by re - sending it ( I just wasted months of my life making sure that PUT to an aggregation job is idempotent ) . It seems simpler to me to just forbid round to be 0 .
Paragraph (version B):
If the "round" in the Leader's request is 0, then the Helper MUST
abort with an error of type "unrecognizedMessage".
Draft: draft-ietf-ppm-dap

Commentary: All references to " metadata " are now to " report_metadata " . References to " CollectReq " are now " CollectionReq " . References to " CollectResp " are now " Collection " . 
 The current version of the draft renames field " metadata " to " report_metadata " in the Report structure , but does not do the same renaming in the ReportShare and InputShareAad structures . I think this naming should be consistent , though I do n't have a preference between the alternatives . 
 Thanks for pointing this out ! Can you send prepare a PR ? 
 Fixed in 
 Thanks a bunch
Paragraph (version A):
Implementation note: The Leader considers a batch to be
collected once it has completed a collection job for a
CollectReq message from the Collector; the Helper considers a
batch to be collected once it has responded to an
AggregateShareReq message from the Leader.  A batches is
determined by query (query) conveyed in these messages.
Queries must satisfy the criteria covered in batch-validation.
These criteria are meant to restrict queries in a way make it
easy to determine wither a report pertains to a batch that was
collected.
Paragraph (version B):
Implementation note: The Leader considers a batch to be
collected once it has completed a collection job for a
CollectionReq message from the Collector; the Helper considers
a batch to be collected once it has responded to an
AggregateShareReq message from the Leader.  A batches is
determined by query (query) conveyed in these messages.
Queries must satisfy the criteria covered in batch-validation.
These criteria are meant to restrict queries in a way make it
easy to determine wither a report pertains to a batch that was
collected.
Paragraph (version A):
Before an Aggregator responds to a CollectReq or AggregateShareReq,
it must first check that the request does not violate the parameters
associated with the DAP task.  It does so as described here.
Paragraph (version B):
Before an Aggregator responds to a CollectionReq or
AggregateShareReq, it must first check that the request does not
violate the parameters associated with the DAP task.  It does so as
described here.
Paragraph (version A):
For a CollectReq containing a query of type "by_batch_id", the
Leader checks that the provided batch ID corresponds to a batch ID
it returned in a previous CollectResp for the task.
Paragraph (version B):
For a CollectionReq containing a query of type "by_batch_id", the
Leader checks that the provided batch ID corresponds to a batch ID
it returned in a previous Collection for the task.
Draft: draft-ietf-ppm-dap

Commentary: As of draft - irtf - cfrg - vdaf-05 ( not yet published ) , the random coins used for sharding are an explicit parameter of . Add this parameter and explasin how it is generated . 
 I believe this is the only API change we need to account for , correct ?
Paragraph (version A):
The last input comprises the randomness consumed by the sharding
algorithm.  The sharding randomness is a random byte string of length
specified by the VDAF.  The Client MUST generate this using a
cryptographicallly secure random number generator.
Paragraph (version B):
The last input comprises the randomness consumed by the sharding
algorithm.  The sharding randomness is a random byte string of length
specified by the VDAF.  The Client MUST generate this using a
cryptographically secure random number generator.
Draft: draft-ietf-ppm-dap

Commentary: The Leader now informs the Collector of what time interval is spanned by the reports aggregated into a collection , regardless of the query type . This is particularly useful for fixed size tasks as otherwise a Collector can only guess at the report times based on the timing of collection requests , but also useful in time interval tasks since the aggregated reports could span a smaller interval that what was requested ( e.g. , if the collector requested a one hour time interval , but reports only arrived during minutes 30 - 40 of that hour ) . 
 , the results of an aggregation are presented to the collector as : where is the encrypted form of . In the case of a time interval task , the collector will have explicitly requested collection over some interval of time , but in the case of a fixed size task , that aggregate result will have been compiled from a set of reports chosen by the leader . So the collector can only infer that the reports are from no later than when the collect request came in and no sooner than when the collector got the previous batch . DAP should explicitly tell the collector what time interval is covered by a collected batch . 
 One way to do this would be to amend . , it is defined as : We could add an to the case . However that is awkward because is also used in , so we have to make sure that there 's something cogent the leader could put there . Another , simpler choice is to simply add an field to , but the downside there is that this information is n't useful in the time interval case , because the collector already knows what time interval it queried over . 
 I 'm cool with adding an with the minimum and maximum timestamp of all reports in the batch . I think overloading is not the right approach , however , since this is meant to " partially determine " a batch of reports , where as the interval in our case is strictly informational . Unrelated follow question : if we define to be " the minimum and maximum timestamp of reports in the batch " then it 's possible that . I think this is OK , and might even be useful . 
 +1 to not including an in ; instead , I think it should be placed directly in . 
  ' point that the interval in could be tighter than what was in is compelling . I also now think we should put the in ( or , well , ) . I 'll draft this change and circulate it to the WG this week , as I would like to include it in draft-04 , which already includes a bunch of message definition changes .
Paragraph (version B):
The smallest interval of time that contains the timestamps of all
reports included in the batch, such that the interval's start and
duration are both multiples of the task's "time_precision"
parameter.  Note that in the case of a "time_interval" type query
(see query), this interval can be smaller than the one in the
corresponding "CollectionReq.query".
Draft: draft-ietf-ppm-dap

Commentary: This PR includes several text cleanups previously folded into : The upload section explicitly describes the call to An obsolete TODO in the aggregation section is removed Text that incorrectly instructed leaders to abort if the helper finishes aggregation is corrected .
Paragraph (version A):
If the type is "finished", then the leader aborts with
"unrecognizedMessage".  If the type is "continued", then the leader
proceeds as follows.
Paragraph (version B):
If the type is "finished" and the Leader's preparation of this report
share is also finished, then the report share is aggregated and can
now be collected (see collect-flow).  If the Leader is not finished,
then the report cannot be processed further and MUST be removed from
the candidate set.
Paragraph (version B):
If the Helper's "PrepareStep" is of type "continued", then the Leader
proceeds as follows.
Draft: draft-ietf-ppm-dap

Commentary: The current text is out - dated . Update it to account for multiple HPKE configs returned by the Aggregator .
Paragraph (version A):
the HPKE configuration specifies a KEM, KDF, or AEAD algorithm the
client does not recognize.
Paragraph (version B):
no HPKE config advertised by the aggregator specifies a supported
a KEM, KDF, or AEAD algorithm triple.
Draft: draft-ietf-ppm-dap

Commentary: Allows helpers to reject reports from too far in the future , matching the leader check detailed in " Upload Requests " . We add for this case , and allow the leader to try the report again later . Requires helpers to mark undecodable decrypted input shares as invalid with ( ) . 
 The DAP specification defines a number of error modes , which ultimately end up mapped to error codes defined in section 3.1 . Currently , the specified behavior does not describe how to treat message - deserialization failures , in any of client - aggregator , aggregator - aggregator , or collector - aggregator communications . We should consider specifying this . Initial thoughts : Moving to ( with a new error code ? ) or makes sense to me , for deserialization errors during the aggregation process . It 'd be very nice if one " bad " client report did n't fail the entire aggregation job , e.g. we should probably specify behavior that limits the " blast radius " of a badly - serialized message . We could leave this unspecified ; I suppose the risk is that different implementations might treat this error mode with different semantics ( e.g. some will fail a single report , some will fail the entirety of the aggregation job ) . 
 ( This fell out of discussion on ; FWIW , Janus will currently transition a report aggregation to if it fails to decode a message , though of course that 's just one implementation 's choice . )
Paragraph (version B):
Check that the decrypted input share can be decoded.  If not, the
input share MUST be marked as invalid with the error
"unrecognized_message".
Paragraph (version B):
Check if the report is too far into the future.  Implementors can
provide for some small leeway, usually no more than a few minutes,
to account for clock skew.  If a report is rejected for this
reason, the Aggregator SHOULD mark the input share as invalid with
the error "report_too_early".
Paragraph (version A):
The leader begins each round of continuation for a report share based
on its locally computed prepare message and the previous PrepareStep
from the helper.  If PrepareStep is of type "failed", then the leader
marks the report as failed and removes it from the candidate report
set and does not process it further.  If the type is "finished", then
the leader aborts with "unrecognizedMessage".  [[OPEN ISSUE: This
behavior is not specified.]] If the type is "continued", then the
leader proceeds as follows.
Paragraph (version B):
If the error is "ReportShareError.report_too_early", then the
leader MAY try to re-send the report in a later
"AggregateInitializeReq".
Paragraph (version B):
For any other error, the leader marks the report as failed,
removes it from the candidate report set and does not process it
further.
Paragraph (version B):
If the type is "finished", then the leader aborts with
"unrecognizedMessage".  If the type is "continued", then the leader
proceeds as follows.
Draft: draft-ietf-ppm-dap

Commentary: Section 4.2.2 : " Clients SHOULD NOT upload the same measurement value in more than one report if the leader responds with status 200 and an empty body . ” " Is a non - empty body understood to signal an error condition based on some other context ? What if the client got status 200 from the leader but a non - empty body ? Should the client retry as this text suggests ? I do n't know enough about HTTP semantics to know for sure , but it seems like specifying an empty body here is unnecessary . It seems fine to specify that the leader should send an empty body for 200 , but maybe be less strict on the consumption side and drop the empty body requirement ?
Paragraph (version A):
The leader responds to well-formed requests to "[leader]/upload" with
HTTP status code 200 OK and an empty body.  Malformed requests are
handled as described in errors.  Clients SHOULD NOT upload the same
measurement value in more than one report if the leader responds with
HTTP status code 200 OK and an empty body.
Paragraph (version B):
The leader responds to well-formed requests to "[leader]/upload" with
HTTP status code 200 OK.  Malformed requests are handled as described
in errors.  Clients SHOULD NOT upload the same measurement value in
more than one report if the leader responds with HTTP status code 200
OK.
Draft: draft-ietf-ppm-dap

Commentary: Note that this might need to be updated once we land .
Paragraph (version B):
Clarify requirements for enforcing anti-replay.  Namely, while it
is sufficient to detect repeeated report IDs, it is also enough to
detect repeated IDs and timestamps.
Paragraph (version B):
Clarify that extensions are mandatory to implement: If an
Aggregator does not recongize a ReportShare's extension, it must
reject it.
Paragraph (version B):
Clarify that Aggregators must reject any ReportShare with repeated
extension types.
Draft: draft-ietf-ppm-dap

Commentary: The server only supplies one config , so what happens if the server would support X22519 and P-256 ? We can fix this by having the server supply multiple configs . 
 This is probably a good idea . We could just change the payload of the response to to a sequence of messages rather than one . 
 As mentioned in , it might be useful to allow the client to advertise which algorithms it supports . This would increase the likelihood of successfully negotiating an a HPKE suite that both parties support . 
 should we try to tackle this in DAP-03 ? 
 I 'm game . One minor editorial nit .
Paragraph (version A):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).
The "OpenBase()" function is as specified in HPKE for the ciphersuite
indicated by the HPKE configuration.  If the leader supports multiple
HPKE configurations, it can use trial decryption with each
configuration.  If decryption fails, the aggregator marks the report
share as invalid with the error "hpke_decrypt_error".  Otherwise, the
aggregator outputs the resulting PlaintextInputShare
"plaintext_input_share".
Paragraph (version B):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).
The "OpenBase()" function is as specified in HPKE for the ciphersuite
indicated by the HPKE configuration.  If the leader supports multiple
HPKE configurations with non-distinct configuration identifiers, it
can use trial decryption with each configuration.  If decryption
fails, the aggregator marks the report share as invalid with the
error "hpke_decrypt_error".  Otherwise, the aggregator outputs the
resulting PlaintextInputShare "plaintext_input_share".
Draft: draft-ietf-ppm-dap

Commentary: Based on ( merge that first ) . 
 As noted by in , we need to decide how to handle duplicate extensions . One simple idea is to treat duplicate extensions as decoding failures , i.e. , abort with " unrecognizedMessage " .
Paragraph (version A):
If the Report contains an unrecognized extension, then the Leader MAY
abort the upload request with error "unrecognizedMessage".  Note that
this behavior is not mandatory because it requires the Leader to
decrypt its input share.
Paragraph (version B):
If the Report contains an unrecognized extension, or of two
extensions have the same ExtensionType, then the Leader MAY abort the
upload request with error "unrecognizedMessage".  Note that this
behavior is not mandatory because it requires the Leader to decrypt
its input share.
Paragraph (version B):
Check if the ExtensionType of any two extensions in
PlaintextInputShare is the same.  If so, then the Aggregator MUST
mark the input share as invalid with error "unrecognized_message".
Draft: draft-ietf-ppm-dap

Commentary: I only tried searching for it , but all I found were places that it was used . This makes it difficult to determine which inputs are which . Which is the AAD , which is the plaintext , and which is the nonce ? Please also describe the inputs in text . Note that at least one of the code blocks that use this is too wide at 76 characters . 
 SealBase ( ) and  ( ) refer to the " single - shot APIs " from I notice that we do n't reference this explicitly . Would a reference suffice ?
Paragraph (version A):
where "pk" is the aggregator's public key; "server_role" is the Role
of the intended recipient ("0x02" for the leader and "0x03" for the
helper), "task_id" is the task ID, "metadata" is the report metadata,
and "input_share" is the Aggregator's input share.
Paragraph (version B):
where "pk" is the aggregator's public key; "server_role" is the Role
of the intended recipient ("0x02" for the leader and "0x03" for the
helper), "task_id" is the task ID, "metadata" is the report metadata,
and "input_share" is the Aggregator's input share.  The "SealBase()"
function is as specified in HPKE for the ciphersuite indicated by the
HPKE configuration.
Paragraph (version A):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).  If
decryption fails, the aggregator marks the report share as invalid
with the error "hpke_decrypt_error".  Otherwise, it outputs the
resulting "input_share".
Paragraph (version B):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).  If
decryption fails, the aggregator marks the report share as invalid
with the error "hpke_decrypt_error".  Otherwise, it outputs the
resulting "input_share".  The "OpenBase()" function is as specified
in HPKE for the ciphersuite indicated by the HPKE configuration.
Paragraph (version A):
where "pk" is the HPKE public key encoded by the collector's HPKE
key, "server_role" is "0x02" for the leader and "0x03" for a helper.
Paragraph (version B):
where "pk" is the HPKE public key encoded by the collector's HPKE
key, "server_role" is "0x02" for the leader and "0x03" for a helper.
The "SealBase()" function is as specified in HPKE for the ciphersuite
indicated by the HPKE configuration.
Paragraph (version B):
The "OpenBase()" function is as specified in HPKE for the ciphersuite
indicated by the HPKE configuration.
Draft: draft-ietf-ppm-dap

Commentary: In IANA all media types seem to be of " application " type instead of " message " type , this PR is to align the mismatch in the protocol description and adapt to the media types specified in IANA . 
 Nice catch !
Paragraph (version A):
Let "[aggregator]" denote the helper's API endpoint.  The leader
sends a POST request to "[aggregator]/aggregate" with its
AggregateInitializeReq message as the payload.  The media type is
"message/dap-aggregate-initialize-req".
Paragraph (version B):
Let "[aggregator]" denote the helper's API endpoint.  The leader
sends a POST request to "[aggregator]/aggregate" with its
AggregateInitializeReq message as the payload.  The media type is
"application/dap-aggregate-initialize-req".
Paragraph (version A):
The helper's response to the leader is an HTTP status code 200 OK
whose body is the AggregateInitializeResp and media type is "message/
dap-aggregate-initialize-resp".
Paragraph (version B):
The helper's response to the leader is an HTTP status code 200 OK
whose body is the AggregateInitializeResp and media type is
"application/dap-aggregate-initialize-resp".
Paragraph (version A):
For each aggregator endpoint "[aggregator]" in
"AggregateContinueReq.task_id"'s parameters except its own, the
leader sends a POST request to "[aggregator]/aggregate" with
AggregateContinueReq as the payload and the media type set to
"message/dap-aggregate-continue-req".
Paragraph (version B):
For each aggregator endpoint "[aggregator]" in
"AggregateContinueReq.task_id"'s parameters except its own, the
leader sends a POST request to "[aggregator]/aggregate" with
AggregateContinueReq as the payload and the media type set to
"application/dap-aggregate-continue-req".
Paragraph (version A):
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.
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 "application/dap-
aggregate-continue-resp".  The helper then awaits the next message
from the leader.