draft-ietf-ppm-dap-16 early Httpdir review

Document: draft-ietf-ppm-dap
Title: Distributed Aggregation Protocol for Privacy Preserving Measurement
Reviewer: Darrel Miller
Review result: Almost Ready

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

Received on Sunday, 21 September 2025 22:49:50 UTC