Original text:
When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can <del> treat it as a signal that the server is interested in receiving </del>  specified request header fields that match the advertised field- <del> values; subsequent requests initiated to the same server and, optionally any subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in, can include the request header fields that match the advertised field-values. </del>  For example, based on Accept-CH example above, a user agent could <del> append DPR, Width, Viewport-Width, and Downlink header fields to all </del>  subresource requests initiated by the page constructed from the <del> response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </del>  2.2.2.  When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can

Reviewer comments:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Revised text:
When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can  <ins> treat it as a signal that the application is interested in receiving </ins> specified request header fields that match the advertised field-  <ins> values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field- values. </ins> For example, based on Accept-CH example above, a user agent could  <ins> append DPR, Width, and Viewport-Width header fields to all </ins> subresource requests initiated by the page constructed from the  <ins> response. </ins> 2.2.2. <ins> Servers can ask the client to remember an origin-wide Accept-CH preference for a specified period of time to enable delivery of Client Hints on all subsequent requests to the origin, and on subresource requests initiated as a result of processing a response from the origin. The field-value indicates that the Accept-CH preference should be considered stale after its age is greater than the specified number of seconds. For example, based on the Accept-CH and Accept-CH-Lifetime example above, a user agent could persist an origin-wide Accept-CH preference for up to 86400 seconds (1 day).  Then, if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR and Viewport-Width in this example) to the request and any subresource requests initiated as a result of processing a response from same origin. 2.2.3. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can