Change:
The minimum "batch size" of reports which can be aggregated. The rate at which measurements can be taken, i.e., the "minimum <del> batch window". </del> <ins> batch duration". </ins> <del> These parameters are distributed out of band to the clients and to the aggregators.  They are distributed by the collecting entity in some authenticated form.  Each task is identified by a unique 32-byte ID which is used to refer to it in protocol messages. </del> <ins> These parameters are distributed out of band to the Clients and to the Aggregators.  They are distributed by the Collector in some authenticated form.  Each task is identified by a unique 32-byte ID which is used to refer to it in protocol messages. </ins> <del> During the duration of the measurement, each client records its own value(s), packages them up into a report, and sends them to the leader.  Each share is separately encrypted for each aggregator so that even though they pass through the leader, the leader is unable to see or modify them.  Depending on the measurement, the client may only send one report or may send many reports over time. </del> <ins> During the duration of the task, each Client records its own measurement value(s), packages them up into a report, and sends them to the leader.  Each share is separately encrypted for each Aggregator so that even though they pass through the Leader, the Leader is unable to see or modify them.  Depending on the task, the Client may only send one report or may send many reports over time. </ins> <del> The leader distributes the shares to the helpers and orchestrates the </del> <ins> The Leader distributes the shares to the Helpers and orchestrates the </ins> process of verifying them (see validating-inputs) and assembling them <del> into a final measurement for the collector.  Depending on the VDAF, it may be possible to incrementally process each report as it comes in, or may be necessary to wait until the entire batch of reports is received. </del> <ins> into a final aggregate result for the Collector.  Depending on the VDAF, it may be possible to incrementally process each report as it comes in, or may be necessary to wait until the entire batch of reports is received. </ins> 2.2. An essential task of any data collection pipeline is ensuring that the data being aggregated is "valid".  In DAP, input validation is complicated by the fact that none of the entities other than the <del> client ever sees the values for individual clients. </del> <ins> Client ever sees that client's plaintext measurement. </ins> 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 <del> computation, each aggregator is in possession of an input share </del> <ins> computation, each Aggregator is in possession of an input share </ins> uploaded by the client.  At the end of the computation, each <del> aggregator is in possession of either an "output share" that is ready </del> <ins> Aggregator is in possession of either an "output share" that is ready </ins> to be aggregated or an indication that a valid output share could not be computed.

Discussion:
Based on .
NAME can you please rebase? Some of the changes we improved on in now appear here.
Rebased.