Original text:
2. <del> The protocol is executed by a large set of clients and a small set of servers.  Servers are referred to as . Each client's input to the protocol is a set of measurements (e.g., counts of some user behavior).  Given the input set of measurements "x_1, ..., x_n" held by "n" users, the goal of a protocol for privacy preserving measurement is to compute "y = F(p, x_1, ..., x_n)" for some function "F" while revealing nothing else about the measurements. </del>  This protocol is extensible and allows for the addition of new cryptographic schemes that implement the VDAF interface specified in VDAF.  Candidates include: <del> Prio3, which allows for aggregate statistics such as sum, mean, histograms, etc.  This class of VDAFs is based on Prio CGB17 and includes improvements described in BBCGGI19. </del>  <del> Poplar1, which allows for finding the most popular strings among a collection of clients (e.g., the URL of their home page) as well as counting the number of clients that hold a given string.  This VDAF is the basis of the Poplar protocol of BBCGGI21, which is designed to solve the heavy hitters problem in a privacy </del>  preserving manner. <del> This protocol is designed to work with schemes that use secret sharing.  Rather than sending its input in the clear, each client shards its measurements into a sequence of and sends an input share to each of the aggregators.  This provides two important properties: </del>  <del> It is impossible to deduce the measurement without knowing </del>  <del> of the shares. It allows the aggregators to compute the final output by first aggregating up their measurements shares locally, then combining the results to obtain the final output. </del>  2.1. <del> The overall system architecture is shown in pa-topology. </del>  [[OPEN ISSUE: This shows two helpers, but the document only allows one for now.  https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/ The main participants in the protocol are as follows: The basic unit of DAP is the "task" which represents a single <del> measurement (though potentially taken over multiple time windows). The definition of a task includes the following parameters: </del>  The type of each measurement. The aggregation function to compute (e.g., sum, mean, etc.). <del> The set of aggregators and necessary cryptographic keying material </del>  to use. The VDAF to execute, which to some extent is dictated by the 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>  <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>  <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>  <del> The leader distributes the shares to the helpers and orchestrates the </del>  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>  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>  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>  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>  to be aggregated or an indication that a valid output share could not be computed. 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 <del> validity BBCGGI19 which the aggregators can jointly verify and reject </del>  the report if it cannot be verified.  However, they do not learn anything about the individual report other than that it is valid. the measurement being taken.  For instance, to measure the time the user took performing a given task the proof might demonstrate that the value reported was within a certain range (e.g., 0-60 seconds). <del> By contrast, to report which of a set of N options the user select, the report might contain N integers and the proof would demonstrate that N-1 were 0 and the other was 1. </del>  It is important to recognize that "validity" is distinct from "correctness".  For instance, the user might have spent 30s on a task

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

Revised text:
2.  <ins> The protocol is executed by a large set of Clients and a small set of servers.  Servers are referred to as "Aggregators".  Each Client's input to the protocol is its measurement (or set of measurements, e.g., counts of some user behavior).  Given the input set of measurements "x_1, ..., x_n" held by "n" users, the goal of DAP is to compute "y = F(p, x_1, ..., x_n)" for some function "F" while revealing nothing else about the measurements.  We call "F" the "aggregation function". </ins> This protocol is extensible and allows for the addition of new cryptographic schemes that implement the VDAF interface specified in VDAF.  Candidates include:  <ins> Prio3 (VDAF), which allows for aggregate statistics such as sum, mean, histograms, etc. </ins>  <ins> Poplar1 (VDAF), which allows for finding the most popular strings uploaded by a set of Clients (e.g., the URL of their home page) as well as counting the number of Clients that hold a given string. This VDAF is the basis of the Poplar protocol of BBCGGI21, which is designed to solve the heavy hitters problem in a privacy </ins> preserving manner.  <ins> VDAFs rely on secret sharing to protect the privacy of the measurements.  Rather than sending its input in the clear, each client shards its measurements into a sequence of "input shares" and sends an input share to each of the Aggregators.  This provides two important properties: </ins>  <ins> Given only a subset of the input shares, it is impossible to deduce the plaintext measurement from which they were generated. </ins>  <ins> It allows the Aggregators to compute the aggregation function by first aggregating up their input shares locally into "aggregate shares", then combining the aggregate shares into the aggregate result. </ins> 2.1.  <ins> The overall system architecture is shown in dap-topology. </ins> [[OPEN ISSUE: This shows two helpers, but the document only allows one for now.  https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/ The main participants in the protocol are as follows: The basic unit of DAP is the "task" which represents a single  <ins> measurement process (though potentially taken over multiple time windows).  The definition of a task includes the following parameters: </ins> The type of each measurement. The aggregation function to compute (e.g., sum, mean, etc.).  <ins> The set of Aggregators and necessary cryptographic keying material </ins> to use. The VDAF to execute, which to some extent is dictated by the The minimum "batch size" of reports which can be aggregated. The rate at which measurements can be taken, i.e., the "minimum  <ins> batch duration". </ins>  <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>  <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>  <ins> The Leader distributes the shares to the Helpers and orchestrates the </ins> process of verifying them (see validating-inputs) and assembling them  <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  <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  <ins> computation, each Aggregator is in possession of an input share </ins> uploaded by the client.  At the end of the computation, each  <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. 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  <ins> validity BBCGGI19 which the Aggregators can jointly verify and reject </ins> the report if it cannot be verified.  However, they do not learn anything about the individual report other than that it is valid. the measurement being taken.  For instance, to measure the time the user took performing a given task the proof might demonstrate that the value reported was within a certain range (e.g., 0-60 seconds).  <ins> By contrast, to report which of a set of "N" options the user select, the report might contain "N" integers and the proof would demonstrate that "N-1" were "0" and the other was "1". </ins> It is important to recognize that "validity" is distinct from "correctness".  For instance, the user might have spent 30s on a task