This is a HTTPDIR review of https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-16. As I do not have background in these privacy preserving techniques, my review is limited to the HTTP aspects of the document. ## 3 Message Transport This section was useful to understand the way HTTP is used in this protocol. I wonder if the section would be more appropriately titled "HTTP Usage". It may be worth considering extracting some of the text from 4.3 that discusses resource URL construction and moving it to this section. It would also be useful to qualify if the URLs are constructed in a RFC6570 compliant way, as that appears to be the case but is not explicitly stated. ## 4.3 Resources The section on handling asynchronous requests seems more appropriate in section 3 as it is not specific to any particular resource. I would recommend using the 202 status code to indicate asynchronous handling rather than relying on an empty body to communicate that behaviour as it is more consistent with common HTTP usage. This would require updating the following text: > The HTTP server responds the same way as it did to the initial request until either the resource is ready Polling of the resource provided by the Location header using GET would return a 204 status code until the resource is ready, at which point it would return a 200 with a body. ## 4.5.1 HPKE Configuration This HTTP interaction is straightforward and clearly defined, although it caught me by surprise because it was not mentioned in section 4.3 Resources. ## 4.5.2 Upload Request As "reports" is one of the defined resources in section 4.3, it would be useful to clarify what HTTP methods are supported on the resource. This section talks about using POST to create/upload a report, but it is not clear if it is possible to perform a GET on the resource. I am assuming not, but as the methods are being introduced on a scenario by scenario basis it is not clear without verifying the whole document. The use of the 200 status code when there are report uploads with errors will potentially cause confusion. The 207 "multi-status" code could be used when there are is at least one failed report upload. It is not clear to me whether the response payload should be empty if there are no errors or if there should be a ReportUploadStatus with an empty status array. The example of a successful upload suggests that the response body should be empty. It might be worth considering renaming the response message to UploadErrors instead of UploadResponse to clarify that it will only contain ReportUploadStatus information for failures. ## 4.6.2 Aggregate Initialization The use of PUT to {helper}/tasks/{task-id}/aggregation_jobs/{aggregation-job-id} is appropriate for enabling idempotent creation of aggregation jobs. However, it is not clear how a client would know the task-id and aggregation-job-id to use for the request. The use of PUT implies that the client is in control of the identifier, but there is no guidance on how to create or acquire suitable identifiers. The examples demonstrate use of GET on the resource URL returned in the Location header when the response is asynchronous. However it is not clear if GET can be called on this resource when the resource is created synchronously. Is it required to provide the correct step query parameter? What happens if the step is not included? If the initialization request creates a new aggregation job then the response should be a 201 status code rather than 200. nit: Figure 3 uses parameter names that are not quite consistent with the names documented in this section. e.g. prep_init vs prepare_inits > The AggregationJobResp.prepare_resps field must include exactly the same report IDs in the same order as the Leader's AggregationJobInitReq. Otherwise, the Leader MUST abort the aggregation job. How is "abort the aggregation job" achieved? If that is using the DELETE method described in 4.6.4, then it would be good to call that out as the description in 4.6.4 talks about cleaning up abandoned jobs which seems different. ## 4.6.3 Aggregate Continuation Using POST to continue an aggregation job is a little unusual. It might be worth considering using PUT with `step` as a query parameter to make it clear that the operation is idempotent and align with the way a step is communicated during asynchronous initialization. e.g. `PUT {helper}/tasks/{task-id}/aggregation_jobs/{aggregation-job-id}?step=2` This would remove the need to include step in the request body and makes it more clear to intermediaries when a request is being retried. ## 4.6.4 Aggregation job Deletion A 204 response status should be used to indicate an empty response body. ## 4.7.1 Collection Job Initialization Ideally, the response to a successful creation would be a 201 status code rather than 200. ## 4.7.2 Collection Job Deletion A 204 response status should be used to indicate an empty response body. ## 4.7.3 Obtaining Aggregate Shares Same feedback about status codes as previous sections. ## 9.1 Protocol Message Media Types The document currently defines ten different media types. My assumption is that most implementations will need to support all of these media types. I would strongly consider defining a single media type and a parameter such as `message` to distinguish the different message types. e.g. `application/dap; message=hpke-config-list` I do not see value in making distinct media type registrations as it does not seem like they could be used independently. This will simplify IANA registration and if there are future major versions of the protocol it will be easier to content negotation for the version. ## General Feedback The HTTP usage described by the document is compliant with RFC9110, if a little unique at times. The primary challenge to the reader is that the description of the HTTP "interface" is intertwined with the description of the implementation of the services. This makes it harder to understand the HTTP aspects of the protocol. There would be value in extracting the HTTP usage into a separate section that describes the resources, their URLs, methods, status codes, and payloads. This would allow the content that describes the processing of the messages to simply refer to the interface aspects. An alternative approach would be to include an appendix with an OpenAPI description of the leader and helper API surfaces as a non-normative reference. regards, Darrel Miller