Original text:
and discontinue retrying. The Leader MUST ignore any report pertaining to a batch that has <del> already been collected.  (See input-share-batch-validation for </del>  details.)  Otherwise, comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the Helpers enforce this as well.)  The Leader MAY ignore any reports input-share-decryption. Check that the resulting input share is valid as described in <del> input-share-batch-validation. </del>  Initialize VDAF preparation as described in input-share-prep. input-share-decryption. Check that the resulting input share is valid as described in <del> input-share-batch-validation. </del>  Initialize VDAF preparation and initial outputs as described in input-share-prep. <del> [[OPEN ISSUE: consider moving the helper nonce check into #input- share-batch-validation]] </del>  Once the helper has processed each valid report share in "AggregateInitializeReq.report_shares", the helper then creates an of failure, the input share is marked as invalid with a corresponding ReportShareError error. <del> The validation checks are as follows. </del>  Check if the report has never been aggregated but is contained by a batch that has been collected.  If this check fails, the input aggregation parameter.  If this check fails, the input share MUST be marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request <del> and is therefore a replay.  An aggregator may also choose to mark an input share as invalid with the error "report-dropped" under the conditions prescribed in anti-replay. </del>  Depending on the query type for the task, additional checks may be applicable: "task_expiration" time, if so the Aggregator MAY mark the input share as invalid with the error "task-expired".  4.4.1.5. Input share preparation consists of running the preparation-state nonce is in this set, it either ignores it or aborts the upload sub- protocol as described in upload-flow.  A Helper who receives an encrypted input share whose nonce is in this set rejects the report <del> as described in input-share-batch-validation. </del>  [OPEN ISSUE: This has the potential to require aggreagtors to store nonce sests indefinitely.  See issue#180.] leaders must be at least as capable as helpers, where helpers are generally required to: <del> Support the collect protocol, which includes validating and </del>  aggregating reports; and Publish and manage an HPKE configuration that can be used for the them.  In particular, aggregators must store a batch as long as the batch has not been queried more than "max_batch_lifetime" times. However, it is not always necessary to store the reports themselves. <del> For schemes like Prio3 VDAF in which the input-validation protocol is only run once per report, each aggregator only needs to store its aggregate share for each possible batch interval, along with the number of times the aggregate share was used in a batch.  This is due to the requirement that the batch interval respect the boundaries defined by the DAP parameters.  (See batch-validation.) </del>  Furthermore, the aggregators must store data related to a task as long as the current time has not passed this task's

Reviewer comments:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .

Revised text:
and discontinue retrying. The Leader MUST ignore any report pertaining to a batch that has  <ins> already been collected.  (See early-input-share-validation for </ins> details.)  Otherwise, comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the Helpers enforce this as well.)  The Leader MAY ignore any reports input-share-decryption. Check that the resulting input share is valid as described in  <ins> early-input-share-validation. </ins> Initialize VDAF preparation as described in input-share-prep. input-share-decryption. Check that the resulting input share is valid as described in  <ins> early-input-share-validation. </ins> Initialize VDAF preparation and initial outputs as described in input-share-prep.  <ins> [[OPEN ISSUE: consider moving the helper nonce check into #early- input-share-validation]] </ins> Once the helper has processed each valid report share in "AggregateInitializeReq.report_shares", the helper then creates an of failure, the input share is marked as invalid with a corresponding ReportShareError error.  <ins> Before beginning the preparation step, Aggregators are required to perform the following generic checks. </ins> Check if the report has never been aggregated but is contained by a batch that has been collected.  If this check fails, the input aggregation parameter.  If this check fails, the input share MUST be marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request  <ins> and is therefore a replay. </ins> Depending on the query type for the task, additional checks may be applicable: "task_expiration" time, if so the Aggregator MAY mark the input share as invalid with the error "task-expired". <ins> Finally, if an Aggregator cannot determine if an input share is valid. it MUST mark the input share as invalid with error "report- dropped".  This situation arises if, for example, the Aggregator has evicted from long-term storage the state required to perform the check.  (See reducing-storage-requirements for details.) If all of the above checks succeed, the input share is not marked as invalid. </ins> 4.4.1.5. Input share preparation consists of running the preparation-state nonce is in this set, it either ignores it or aborts the upload sub- protocol as described in upload-flow.  A Helper who receives an encrypted input share whose nonce is in this set rejects the report  <ins> as described in early-input-share-validation. </ins> [OPEN ISSUE: This has the potential to require aggreagtors to store nonce sests indefinitely.  See issue#180.] leaders must be at least as capable as helpers, where helpers are generally required to:  <ins> Support the aggregate sub-protocol, which includes validating and </ins> aggregating reports; and Publish and manage an HPKE configuration that can be used for the them.  In particular, aggregators must store a batch as long as the batch has not been queried more than "max_batch_lifetime" times. However, it is not always necessary to store the reports themselves.  <ins> For schemes like Prio3 VDAF in which reports are verified only once, each aggregator only needs to store its aggregate share for each possible batch interval, along with the number of times the aggregate share was used in a batch.  This is due to the requirement that the batch interval respect the boundaries defined by the DAP parameters. (See batch-validation.) However, Aggregators are also required to implement several per- report checks that require retaining a number of data artificts.  For example, to detect replay attacks, it is necessary for each Aggregator to retain the set of nonces of reports that have been aggregated for the task so far.  Depending on the task lifetime and report upload rate, this can result in high storage costs.  To elliviate this burden, DAP allows Aggregators to drop this state as needed, so long as reports are droppped properly as described in early-input-share-validation.  Aggregators SHOULD take steps to mitigate the risk of dropping reports (e.g., by evicting the oldest data first). </ins> Furthermore, the aggregators must store data related to a task as long as the current time has not passed this task's