Original text:
to ensure that each report appears at most once in a batch.  (See anti-replay.)  "encrypted_input_shares" contains the encrypted input shares of each of the aggregators. status 200 and an empty body.  Malformed requests are handled as described in pa-error-common-aborts.  3.4. [TODO: Decide if and how the collector's request is authenticated.] corresponding to a unique client report.  Sub-requests are structured as follows: <del> The "time" and "jitter" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report. [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The remainder of the structure is dedicated to the protocol-specific request parameters. </del>  In order to provide replay protection, the leader is required to send aggregate sub-requests in ascending order, where the ordering on sub- 9. <del> TODO </del>  10.  References

Reviewer comments:
One possible extension would be an opaque blob to carry client attestation information (for ), if desired. The current set is empty, but I suspect we'll need freedom to extend here as this gets used without totally changing the protocol version. If folks are generally supportive of this, it should probably land after , which touches and renames PDAUploadReq to PDAReport.
Both (1) and (2) are external to the protocol. The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report, as is done here. This is done in the change. This is not meant to close the attestation issue. It's meant to give us the mechanics to address it later.
Right you are. What threw me off was the following statement: The "then these extensions are required to be echoed..." makes it sound as if they're not echoed, which they are. I'm happy with this PR modulo fixing this statement.

Revised text:
to ensure that each report appears at most once in a batch.  (See anti-replay.) <ins> "extensions" is a list of extensions to be included in the Upload flow; see upload-extensions. </ins> "encrypted_input_shares" contains the encrypted input shares of each of the aggregators. status 200 and an empty body.  Malformed requests are handled as described in pa-error-common-aborts. <ins> 3.3.3. Each PAUploadReq carries a list of extensions that clients may use to convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form: "extension_type" indicates the type of extension, and "extension_data" contains information specific to the extension. </ins> 3.4. [TODO: Decide if and how the collector's request is authenticated.] corresponding to a unique client report.  Sub-requests are structured as follows:  <ins> The "time", "jitter", and "extensions" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report.  [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The remainder of the structure is dedicated to the protocol-specific request parameters. </ins> In order to provide replay protection, the leader is required to send aggregate sub-requests in ascending order, where the ordering on sub- 9.  <ins> 9.1. This document requests creation of a new registry for extensions to the Upload protocol.  This registry should contain the following columns: [TODO: define how we want to structure this registry when the time comes] </ins> 10.  References