Original text:
subsequent HTTP GET requests to the collect job URI with an HTTP error status and a problem document as described in errors. <del> The collector may send an HTTP DELETE request to the collect job URI, </del>  to which the leader MUST respond with HTTP status 204 No Content. The leader MAY respond with HTTP status 204 No Content for requests to a collect job URI which has not received a DELETE request, for

Reviewer comments:
The previous wording required the leader to store collect results until the collector sent an explicit DELETE request to the collect job's URI. Now, the relevant text is reworded to allow the leader to remove collect results for other reasons (for example, a leader can now garbage-collect old results after a suitable period of time). This fell out of discussion on .
OK -- I left the motivating example out as I didn't want to be too prescriptive to implementations. I would also be interested in comments from folks more experienced with RFC writing; I've added the motivating example for now.
When the Collector issues a collect request to the Leader, the Leader responds with a URI the Collector can poll later on to get the (encrypted) aggregate result. This is done via an HTTP GET to the collect URI returned by the Leader. My understanding is that the Leader is free to remove the aggregate results from storage thereafter. (See URL for discussion.) The spec doesn't require this request to be authenticated, so it's possible for someone to cause the Leader to delete this state before the Collector has a chance to fetch it. This issue can be solved by: requiring the Leader to store results for some period of time; making the collect URI hard to predict (e.g., by sticking a random number in the URI string); or requiring authentication for this endpoint. (2.) seems easiest to implement, but may be tricky to spell. Any thoughts on this?
That's not what says: That text is consistent with . So I argue the current situation is (1). We do have to solve the problem of how long a leader can wait before tossing collect results -- or maybe we don't, since ACME doesn't bother to. But we could use this issue to discuss that question. re: (2): I think we should avoid as much as possible imposing requirements on the construction of URIs and relative paths[^1]. An implementation should feel free to generate unpredictable collect job URIs (Janus randomly generates a v4 UUID) but I don't think DAP should mandate it, just so we don't have to write the text to spell it out. re: (3): I have a hard time imagining a deployment where the endpoint and collect job URIs wouldn't be authenticated[^2], but my position on authn in DAP is that we shouldn't specify anything, allowing implementations to use any authn scheme they want that is composable with HTTP. At most we ought to state requirements (e.g., "the channel between aggregators must be mutually authenticated and confidential") but avoid mandating how those requirements are met (e.g., "the aggregators must use mTLS"). which in turn guides clients to the URIs to hit to create orders, or accounts, or whatever. That said, we shouldn't do exactly what ACME does because (1) AFAIK the BCP that mandated this part of ACME's design has been revised and (2) forcing a directory lookup (that is, an extra HTTP round trip) every time an ACME subscriber wants to issue a new cert (roughly once per 90 days) is not so bad, but forcing a directory lookup every time a DAP client wants to upload a measurement seems wasteful. [^2]: For argument's sake: maybe a deployment wants to make the results of some aggregation public, but in such settings, the collector could combine the aggregate shares into results and then stick them into a CDN instead of making it the leader's problem. Not to mention that the collector is probably most capable of transforming aggregate results into some other format that's better suited for public consumption.
I agree with this. I don't think DAP should specify or even mandate authentication, for the reasons Tim mentioned, but also because the aggregate outputs are encrypted only to the intended collector. Giving those encrypted aggregate shares to an unauthorized party seems fine based on the properties of HPKE.
FWIW, the current DAP spec text: implies (at least to my reading) that the leader must indeed retain the results until an explicit is sent from the collector but inconsistent (IMO) with the current specification text. If I'm not missing anything, I can prep a small PR fixing this up. , the leader could choose to send a representation indicating that the results are gone; but strictly following the text of DAP, the leader would still be required to retain the results. Given that these results would be inaccessible from an outside observer, this is a somewhat academic distinction -- IMO another good reason to make a change here.
NAME we took a change here to improve the text discussing how long leaders should hold on to collect job results, and I think questions about authentication of the collect job URIs is captured by . Are there any outstanding concerns about whether polling collect job URIs causes state changes?
Nope :)
Approved as this change achieves the intended mechanical purpose, though I agree with Simon's point about clarity, and others more experienced in the RFC writing style might comment further.

Revised text:
subsequent HTTP GET requests to the collect job URI with an HTTP error status and a problem document as described in errors.  <ins> The collector can send an HTTP DELETE request to the collect job URI, </ins> to which the leader MUST respond with HTTP status 204 No Content. The leader MAY respond with HTTP status 204 No Content for requests to a collect job URI which has not received a DELETE request, for