Draft: draft-ietf-ppm-dap

Commentary: 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 ) . 
 observes that we have an awkward MUST requirement on leaders buffering received reports : 
 We have some error codes like that are n't enumerated in the table in . We should bring that table up to date . While we 're in there , I think and are n't the right types , since outdatedness or staleness are n'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 !
Paragraph (version A):
This list is not exhaustive.  The server MAY return errors set to a
URI other than those defined above.  Servers MUST NOT use the PPM URN
namespace for errors not listed in the appropriate IANA registry (see
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
"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).
Paragraph (version B):
This list is not exhaustive.  The server MAY return errors set to a
URI other than those defined above.  Servers MUST NOT use the PPM URN
namespace for errors not listed in the appropriate IANA registry (see
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
"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.
Paragraph (version A):
The leader MUST ignore any report whose nonce contains a timestamp
that falls in a batch interval for which it has received at least one
collect request from the collector.  (See collect-flow.)  Otherwise,
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
upload protocol and alert the client with error "staleReport".
Paragraph (version A):
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
and alert the client with error "reportFromTheFuture".
Paragraph (version B):
The leader MUST ignore any report whose nonce contains a timestamp
that falls in a batch interval for which it has received at least one
collect request from the collector.  (See collect-flow.)  Otherwise,
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
upload protocol and alert the client with error "reportTooLate".
Paragraph (version B):
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
and alert the client with error "reportTooEarly".