Original text:
is derived from the PPM parameters as: <del> Where param is just the serialization of Param. </del>  4.2. Config.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: <del> [TODO: Decide whether to use the same config structure as OHTTP/ECH. This would add support for multiple cipher suites.] </del>  The client issues a key configuration request to "Param.leader_url" and "Param.helper_url".  It aborts if any of the following happen for the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize.  Clients SHOULD follow the usual HTTP caching RFC7234 semantics for <del> key configurations.  Aggregators SHOULD favor long cache lifetimes to avoid frequent cache revalidation. </del>  Note: Long cache lifetimes may result in clients using stale HPKE keys; aggregators SHOULD continue to accept reports with old keys for <del> a reasonable period after key changes in order to avoid rejecting reports.  [[OPEN ISSUE: https://github.com/abetterinternet/prio- documents/issues/106]] </del>  4.2.2. value in more than one report if the leader responds with status 200 and an empty body.  4.2.3. Each UploadReq carries a list of extensions that clients may use to

Reviewer comments:
It seems silly to have clients revalidating the HPKE key for each request, so we probably want some kind of caching. I'm not sure HTTP Caching is quite what we want, but something... NAME NAME recommendations?
I'm going to need a little more context to provide good advice. If we don't need key consistency (it doesn't appear so) and you only need correctness, then the client should just be able to talk directly to the collector and get keys periodically. HTTP caching works fine for that purpose. This would also need a rejection message so that the collector (or the leader on their behalf - the leader is more likely to learn about bad key identifiers before clients) can reject an out-of-date key in case the cache needs to be invalidated.
We do not need key consistency. The rejection message seems like a good idea.

Revised text:
is derived from the PPM parameters as:  <ins> Where param is the serialization of Param. </ins> 4.2. Config.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value:  <ins> [OPEN ISSUE: Decide whether to expand the width of the id, or support multiple cipher suites (a la OHTTP/ECH).] </ins> The client issues a key configuration request to "Param.leader_url" and "Param.helper_url".  It aborts if any of the following happen for the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <ins> Aggregators SHOULD use HTTP caching to permit client-side caching of this resource RFC5861.  Aggregators SHOULD favor long cache lifetimes to avoid frequent cache revalidation, e.g., on the order of days. Aggregators can control this cached lifetime with the Cache-Control header, as follows: </ins> Clients SHOULD follow the usual HTTP caching RFC7234 semantics for  <ins> key configurations. </ins> Note: Long cache lifetimes may result in clients using stale HPKE keys; aggregators SHOULD continue to accept reports with old keys for  <ins> at least twice the cache lifetime in order to avoid rejecting reports. </ins> 4.2.2. value in more than one report if the leader responds with status 200 and an empty body. <ins> The leader responds to requests with out-of-date "HpkeConfig.id" values, indicated by "EncryptedInputShare.config_id", with status 400 and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </ins> 4.2.3. Each UploadReq carries a list of extensions that clients may use to