Change:
"proto": The PA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters. <del> [TODO: Decide how the "PAParam" is configured.  Like the task, this will need to be authenticated by the collector.] </del> <ins> Each task has a unique _task id_ derived from the PA parameters: </ins> <del> [OPEN ISSUE: Is there just one PAParam for each PATask, or do we want to allow PAParam to change overtime?] </del> <ins> The task id is derived using the following procedure.  [TODO: Specify derivation of the task ID.] </ins> <del> 3.1.3. </del> <ins> 3.1.2. </ins> Our protocol uses HPKE for public-key encryption I-D.irtf-cfrg-hpke. Each aggregator specifies the HPKE public key that clients use to

Discussion:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information.

So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.