Guidance for defining new batch modes

[cjpatton]

The contents of the Query and PartialBatchSelector structures depend on the task's batch mode. Future documents are allowed to add new batch modes, and they'll have to extend these structures some how. This document needs to provide some guidance on how exactly to do this.

The taskprov draft has a related problem, which we try to solve with a section like this (https://ietf-wg-ppm.github.io/draft-ietf-ppm-dap-taskprov/draft-ietf-ppm-dap-taskprov.html#section-8):

Extending this Document

The behavior of the taskbind extension may be extended by future documents that define:

1. A new DAP batch mode
2. A new VDAF
3. A new DP mechanisms

Such documents SHOULD include a section titled "Taskbind Considerations" that specifies an encoding of any configuration parameters associated with the DAP batch mode, VDAF, or DP mechanism. This encoding extends the BatchConfig structure, the VdafConfig structure, or the DpConfig structure respectively.

This may or may not be the best solution.

[branlwyd]

623 (currently in review) is likely to add a few things that every new batch mode will need to define:

• What the batch bucket identifier is (e.g. a time interval? an opaque batch ID?)
• How to map from an aggregation job/report share to a batch bucket identifier during the aggregation interaction
• How to map from a collection request to a set of batch bucket identifiers

[cjpatton]

Random thought: This probably requires making the Query and PartialBAtchSelector structures have tag-length-value extension points to make it easier for future documents to extend these. See https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap-taskprov/issues/85.

[cjpatton]

2024/10/24 interim: Add length prefixes for. Query and PartialBatchSelector so that we can always separate decoding logic from protocol logic. Also, add a section similar to what we did for extending taskprov.