Original text:
The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for <del> particular hints indicated in its value.  Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure.  Its value MUST be an sh- list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </del>  For example: When a client receives an HTTP response advertising support for <del> Client Hints, it should process it as origin (RFC6454) opt-in to receive Client Hint header fields advertised in the field-value.  The opt-in MUST be delivered over a secure transport. For example, based on Accept-CH example above, a user agent could append the Sec-CH-Example and Sec-CH-Example-2 header fields to all same-origin resource requests initiated by the page constructed from the response. 3.2. Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server's origin (RFC6454). Accept-CH-Lifetime is a Structured Header I-D.ietf-httpbis-header- structure.  Its value MUST be sh-integer (Section 3.4 of I-D.ietf- httpbis-header-structure).  Its ABNF is: When a client receives an HTTP response that contains Accept-CH- Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be considered stale after response's age (RFC7234, section 4.2) is greater than the specified number of seconds.  The preference MUST be delivered over a secure transport, and MUST NOT be persisted for an origin that isn't HTTPS. For example, based on the Accept-CH and Accept-CH-Lifetime example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" for up to 86400 seconds (1 day), and use it for </del>  user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response.  This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins. <del> If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences. 3.2.1. </del>  When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate

Reviewer comments:
Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM

Revised text:
The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for  <ins> particular hints indicated in its value. Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header- structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis- header-structure).  Its ABNF is: </ins> For example: When a client receives an HTTP response advertising support for  <ins> provided list of Clients Hints, it SHOULD process it as origin (RFC6454) opt-in to receive Client Hint header fields advertised in the field-value, for subsequent same-origin requests. The opt-in MUST be delivered over a secure transport. The opt-in SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin, and MUST NOT be persisted for an origin that isn't HTTPS. For example, based on the Accept-CH example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" and use it for </ins> user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response.  This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins.  <ins> 3.1.1. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate