Change:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq

Discussion:
The following messages are defined in this section and are used to aggregate a number of reports simultaneously: <del> [CP: Since these parameters are required for all variants, I think we should consider moving task_id and job_id to precede the message type.] </del> As discussed in aggregation-flow, the leader may choose to shard the task of aggregating a large number of reports into any number of sub- batches.  The process of aggregating the reports in a leader-defined

order to initialize the process of preparing a set of reports for aggregation.  It is structured as follows: <del> The message contains the PPM task ID, the aggregation job ID assigned by the leader, an opaque, VDAF-specific aggregation parameter, and the helper's report shares. </del> <ins> The message contains an opaque, VDAF-specific aggregation parameter and the helper's report shares. </ins> To construct an AggregateInitReq, the leader begins by picking a sequence of reports, all of which MUST pertain to the same PPM task

Next, the leader extracts its own report shares and computes the initial preparation state for each as described in prep-start.  It then removes from the report sequence any report for which the <del> transition state is FAILED. </del> <ins> transition state is FAILED.  If the resulting sequence is empty, then the leader halts without issuing a request. </ins> Let "[aggregator]" denote the helper's API endpoint.  The leader extracts the sequence of report shares for "[aggregator]" and sends

payload. After verifying the authentication tag as described in aggregate- <del> message-auth, the helper handles the AggregateInitReq by computing the initial preparation state for each ReportShare in </del> <ins> message-auth, the helper first checks that the nonces in "AggregateInitReq.seq" are all distinct.  If two ReportShare messages have the same nonce, then the helper MUST abort with error "unrecognizedMessage".  Next, the helper handles the AggregateInitReq by computing the initial preparation state for each ReportShare in </ins> "AggregateInitReq.seq" as described in prep-start.  It then constructs an AggregateResp:

Next, it checks that the sequence of Transition messages corresponds to the ReportShare sequence of the AggregateInitReq.  If any message <del> appears out of order or is missing, or a transition has an unrecognized nonce, then the leader MUST abort with error "unrecognizedMessage". </del> <ins> appears out of order, is missing, has an unrecognized nonce, or if two messages have the same nonce, then the leader MUST abort with error "unrecognizedMessage". </ins> Next, for each Transition, the leader proceeds as described in prep- leader.  If any state transition results in INVALID, this indicates

Finally, the leader removes from the report sequence any report for which the corresponding state is FAILED and proceeds as described in <del> the next section. </del> <ins> the next section, even if the sequence is empty. </ins> 4.4.4.2.

advance the preparation state of each report being aggregated.  This message is defined as follows: <del> The contents are the PPM task ID, the aggregation job ID, and the sequence of Transition messages corresponding to the report sequence being aggregated.  The sequences MUST have the same order. </del> <ins> The message consists of a sequence of Transition messages corresponding to the report sequence being aggregated.  The sequences MUST have the same order. </ins> Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with an Aggregate message of type "agg_cont_req" with payload AggregateContinueReq. After verifying the authentication tag as described in aggregate- <del> message-auth, the helper processes the AggregateContinueReq as follows.  It first scans "AggregateContinueReq.seq" to check for any reports that may have been dropped by the leader in the previous step. </del> <ins> message-auth, the helper begins by scanning "AggregateContinueReq.seq" to check for any reports that may have been dropped by the leader in the previous step. </ins> Next, the helper processes the Transition messages from the leader. <del> If any leader Transition contains an unrecognized nonce, the Helper sends a Transition with "tran_type = failed" and "TransitionError = unrecognized-nonce".  [CP: It may be better to go to abort rather than just fail, since this s tentamount to sending a malformed aggregate request.]  If any Transition appears out-of-order, the helper MUST abort with error "unrecognizedMessage". </del> <ins> If any message appears out of order or has an unrecognized nonce, or if any two messages have the same nonce, then the helper MUST abort with error "unrecognizedMessage". </ins> <del> Next, it constructs a transition as described in prep-helper.  If any state transition results in INVALID, the helper MUST abort with error "unrecognizedMessage". </del> <ins> Next, the helper processes each Transition as described in prep- helper.  If any state transition results in INVALID, the helper MUST abort with error "unrecognizedMessage". </ins> Next, the helper constructs an AggregateResp containing its next <del> flight of Transition messages and it updated state.  The messages </del> <ins> flight of Transition messages and its updated state.  The messages </ins> MUST appear in the same order as "AggregateContinueReq.seq".  The helper's response is an HTTP 200 OK whose body is the AggregateResp. <ins> The leader processes this message as described in aggregate-init- request. </ins> 4.4.4.3.