Draft: draft-ietf-ppm-dap

Commentary: Historically , the Nonce included a time component . Now that the time component is split out & Nonce is effectively an opaque identifier , ReportID is clearer & more closely matches similar identifiers ( TaskID , AggregationJobID , BatchID ) . 
 Note this PR includes a single wire - format change : had its fields reordered so that the comes first , since the ID is the primary identifier . I am happy to revert this part of the PR if folks would prefer a purely - editorial PR . 
 LGTM . Any thoughts on replacing and with a Nonce so then it has both ? 
 I 'm pretty happy leaving & as separate fields -- for practical purposes , IMO binds them together closely enough ( along with the report extensions ) . Conceptually , DAP is changing such that the primary identifier for a report is its opaque ID ( with this PR , called ) . Previously , the primary identifier for a report was . The technical aspects of this change were made by cjpatton in his changes to introduce tasks . If we do decide to introduce a struct that is effectively , I 'd prefer if it was called something other than -- while we do expect that this value is a " value to be used only once " , it 's no longer used as a nonce in any cryptographic operations . And I 'd argue there 's no better justification to call the report ID ( or ) a nonce than , say , the aggregation job ID / batch ID / task ID . That is , IMO " report ID " more accurately names what this type is than " nonce " -- " nonce " is not technically incorrect , just less clear . 
 Currently , the DAP specification has a number of opaque values used to identify some DAP entity : ( identifying a client report ) ( identifying a task ) ( identifying an aggregation job ) ( identifying a batch ) 's name differs from the rest . I think this is because , historically , the nonce also included a time component . Now that the time component has been split out , I think we could rename to for clarity of purpose . Thoughts ? ( and I probably do n't need to say this , but there is no reason to push this into DAP-02 -- it could easily land in DAP-03 instead . ) 
 Yup , I think this is a good idea ! I 'm tempted to say let 's stick this in 02 , since it 's editorial , but it 's actually somewhat invasive because we use the term " nonce set " in so many places . If you want to send a PR , I 'd review it . But we should make sure there 's broad consensus before merging . 
 Nice change Yeah I think this is a big win :) good idea
Paragraph (version A):
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 report IDs 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
alleviate this burden, DAP allows Aggregators to drop this state as
needed, so long as reports are dropped 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).
Paragraph (version B):
However, Aggregators are also required to implement several per-
report checks that require retaining a number of data artifacts.  For
example, to detect replay attacks, it is necessary for each
Aggregator to retain the set of report IDs 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
alleviate this burden, DAP allows Aggregators to drop this state as
needed, so long as reports are dropped 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).