Original text:
coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker). <del> In the presence of this adversary, DAP aims to achieve the following high-level secure aggregation goals: 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). 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. </del>  Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed [[OPEN ISSUE: The threat model for Prio -- as it's described in the original paper and BBCGGI19 -- considers <del> a malicious client (attacking soundness) </del>  a malicious subset of aggregators (attacking privacy).  In <del> particular, soundness isn't guaranteed if any one of the aggregators </del>  is malicious; in theory it may be possible for a malicious client and <del> aggregator to collude and break soundness.  Is this a contingency we </del>  need to address?  There are techniques in BBCGGI19 that account for this; we need to figure out if they're practical.]]

Reviewer comments:
NAME 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.

Revised text:
coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker).  <ins> In the presence of this adversary, DAP aims to achieve the privacy and robustness security goals described in VDAF's Security Considerations section. </ins> Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed [[OPEN ISSUE: The threat model for Prio -- as it's described in the original paper and BBCGGI19 -- considers  <ins> a malicious client (attacking robustness) </ins> a malicious subset of aggregators (attacking privacy).  In  <ins> particular, robustness isn't guaranteed if any one of the aggregators </ins> is malicious; in theory it may be possible for a malicious client and  <ins> aggregator to collude and break robustness.  Is this a contingency we </ins> need to address?  There are techniques in BBCGGI19 that account for this; we need to figure out if they're practical.]]