Original text:
To generate the report, the client begins by initializing the report nonce.  Specifically, the client first sets "Nonce.rand" to 16 random bytes output from a cryptographically secure random number generator. <del> It then sets "Nonce.time" to the current UNIX time rounded down to the nearest multiple of "min_batch_duration".  This truncation is done to ensure that the report's timestamp cannot be used to link the report back to the originating client. </del>  The client then finishes the report generation by sharding its measurement into a sequence of input shares as specified by the VDAF

Reviewer comments:
We might want to consider renaming to something based on what it's actually doing, which is helping with replay protection. Maybe ?
~Wait, what? Replay is enforced on the basis of Nonce in its entirety, which currently consists of a (1) timestamp and (2) a random value.~ Chatted to clear this up in Slack
Not sure if DAP enforces precision of : But with fine-grained timestamp, it is easier for attacker to associate a report with the user sent that report. For example, if timestamp is accurate to second, and leader is compromised, attacker can compare users that uploaded at a given second (perhaps from a routing server) and reports' timestamp, then figure out if a particular user has contributed to a task. With a coarse-grained timestamp, however, we can minimise this threat with a secure routing server. Anti-replay can still be satisfied with the UUID part of Nonce.
This is a valid concern. One reasonable change would be to modify the report timestamp to align with the batch window start (minbatchduration), and then bump the size of the nonce to offset the increase change of collisions. Specifically, this would mean we update the Nonce like so: NAME would this work? NAME NAME NAME thoughts?
NAME I think this should work.
Great! I'll prep a PR.
I would add the can also be of any length, so aligning Nonce with it will make it coarse-grained for use cases where is large, say in hours, but won't be as effective for very small , but I think that should probably be addressed separately.
I'm happy with this change, though 16 bytes will be sufficient since clients are supposed to choose this at random. (Note that we chose 32 bytes for the various "IDs" (i.e., task ID, aggregation-job ID) because we anticipated some deployments using a hash of something as the ID.
Yep
We currently have an open issue for tracking the consensus protocol needed for this system to work. In working through this text, we should make note of what sort of synchronization we assume between different participants of the system.
In the 3/17 design call we agreed that for purposes of the design doc and probably the initial deployments of Prio, we would assume that shared parameters (e.g., arithmetic circuits, primes, aggregation identifiers) would be exchanged between all parties (i.e., clients, aggregators, collector, leader) before the start of the protocol over some unspecified secure channel. However, eventually, it should be possible for a client that wishes to use Prio to programmatically: discover participating servers (i.e., a directory of aggregators) discover the capabilities of participating servers (i.e., what algorithms do they support for secret sharing or validity proofs or aggregations? What optional protocol features do they support?) configure a Prio aggregation (i.e., select some number of aggregation servers, getting a unique handle, configuring field size, etc.)
One thing that's still TBD is how to choose the joint randomness. It could be as simple as having the leader choose a seed for a PRG and distributing it to the aggregators over secure channels. It could be as complicated as querying at some point after the shares are received by the aggregators.
To close the loop on this issue: the PDA parameters are distributed to all entities out-of-band.
Chris W. and I hashed this out . Chris convinced me that as written, the rounding of is optional for the client, and aggregators don't need to do anything special to handle unrounded nonces: if that happens aggregators can still use the unrounded nonce to correctly identify a bucket to put the report in, so this is something that a client should do in order to improve privacy, but nothing breaks if they fail to. With that in mind, I don't think we need new text to explain what aggregators should do with nonces that aren't rounded correctly, nor does the new text for the client need a MUST.

Revised text:
To generate the report, the client begins by initializing the report nonce.  Specifically, the client first sets "Nonce.rand" to 16 random bytes output from a cryptographically secure random number generator.  <ins> It then sets "Nonce.time" to the number of seconds elapsed since the start of the UNIX epoch, rounded down to the nearest multiple of "min_batch_duration".  This truncation is done to ensure that the report's timestamp cannot be used to link the report back to the originating client. </ins> The client then finishes the report generation by sharding its measurement into a sequence of input shares as specified by the VDAF