Original text:
ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a <del> "taskid" member which contains the associated PPM task ID, encoded in Base 64 using the URL and filename safe alphabet with no padding as defined in sections 5 and 3.2 of RFC4648 (this value is always known, see task-configuration). </del>  In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the helpers enforce this as well; see collect-flow.)  In addition, the leader SHOULD abort the <del> upload protocol and alert the client with error "staleReport". </del>  The leader MUST buffer reports while waiting to aggregate them.  The leader SHOULD NOT accept reports whose timestamps are too far in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If the leader rejects a report for this reason, it SHOULD abort the upload protocol <del> and alert the client with error "reportFromTheFuture". </del>  4.2.3.

Reviewer comments:
Defines more error types to represent various failure modes, updates protocol text to indicate when the new error types should be used, and affirms that the task ID should be encoded as base64url with no padding (since task ID has a fixed size).
NAME observes that we have an awkward MUST requirement on leaders buffering received reports: URL
We have some error codes like that aren't enumerated in the table in . We should bring that table up to date. While we're in there, I think and aren't the right types, since outdatedness or staleness aren't the only reasons that an HPKE config or report, respectively, could be rejected.
The error table was brought up to date by .
Looks great!

Revised text:
ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a  <ins> "taskid" member which contains the associated PPM task ID (this value is always known, see task-configuration), encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of RFC4648. </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For comparing the aggregate result to the previous aggregate result may result in a privacy violation.  (Note that the helpers enforce this as well; see collect-flow.)  In addition, the leader SHOULD abort the  <ins> upload protocol and alert the client with error "reportTooLate". </ins> The leader MUST buffer reports while waiting to aggregate them.  The leader SHOULD NOT accept reports whose timestamps are too far in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If the leader rejects a report for this reason, it SHOULD abort the upload protocol  <ins> and alert the client with error "reportTooEarly". </ins> 4.2.3.