Original text:
prevents additional reports from being aggregated after its batch has already been collected. <del> Check if the report has already been aggregated.  If this check fails, the input share is marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request 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>  If both checks succeed, the input share is not marked as invalid.

Reviewer comments:
Previously, report-replayed would be returned if the same client report was aggregated more than once. However, some VDAFs (e.g. poplar1) will require repeatedly aggregating a given client report with varying aggregation parameters. This commit relaxes the condition on which report-replayed will be returned to allow aggregating the same client report multiple times, as long as each aggregation has a distinct aggregation parameter.
This is odd because the aggregation parameter is opaque and it's not clear if any change to it should allow aggregating a report again. For example, if aggregation is allowed only once for privacy reasons but some kind of shared random number is needed as agg_param this will be an issue. I think checking if another aggregation is allowed has to be done depending on the VDAF and the task.
There is a separate check, under the section "Validating Batch Parameters", that each report is used in at most aggregate shares. This should be set to 1 for Prio3 and VDAFs like you describe. If for a task is 1, then the present change will make no difference, but if for a task is greater than one, we need this change in order to allow that second batch.
Currently, the report share error is returned "if the report has already been aggregated" (). Some VDAFs, like , will require repeatedly aggregating the same client reports with a varying aggregation parameter. I think the specification language would effectively block this use-case currently. I think the fix is to return a error if the report has already been aggregated with the same aggregation parameter. Note that this change would not allow a malicious leader to potentially aggregate a different set of reports with a different aggregation parameter: the existing error would be returned if a client attempted to upload another report after the first collection attempt. (Given the small size of the proposed fix, I'll send a PR shortly, but discussion on this issue/the WG mailing list takes precedence -- I'll update the PR to follow any changes from discussion.)
Thanks NAME -- this change LGTM.

Revised text:
prevents additional reports from being aggregated after its batch has already been collected.  <ins> Check if the report has already been aggregated with this aggregation parameter.  If this check fails, the input share is marked as invalid with the error "report-replayed".  This is the case if the report was used in a previous aggregate request 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. </ins> If both checks succeed, the input share is not marked as invalid.