Original text:
requests.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints. <del> Client Hints mitigate the performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and the privacy concerns of passive fingerprinting by requiring explicit opt-in and disclosure of required headers by the server through the use of the Accept-CH response header. </del>  <del> This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly.  However, it does not define any specific features that will use that infrastructure.  Those features will be defined in their respective specifications. </del>  One example of such a feature is the User Agent Client Hints feature UA-CH.

Reviewer comments:
LGTM! thx
Some of this is very nit-picky; feel free to do what you like with it... ^ There's something weird going on with tense in this sentence. "Such techniques are expensive... are not portable... and make it hard..." The third doesn't fit with the first two. "Client Hints mitigate the performance concerns..." probably just "Client Hints mitigate performance concerns..." Likewise for "the privacy concerns" below. "This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly." --> "This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly." as a normative reference probably isn't going to fly, given its status. Why is it normative? maybe instead: Be aware that HTTP doesn't require presence of when proactive conneg is in use; if the response is truly uncacheable, it isn't necessary. maybe instead: instead: BTW, nothing is said about precedence between the two different mechanisms; separate issue? The reference to 6454 is spurious, and it's pretty indirect. Perhaps: It's kind of weird to have this list just appear. Perhaps turn these into prose? Put "For example" above the example to introduce it. Limits CH to just "optimisation." Probably should just be:
Thanks for reviewing! :) PR underway The here is conditional on cacheability. Is that OK? We're now considering removing http-equiv support for this: URL Maybe it's best to simply remove that reference here?
Ah, I missed that, sorry. WRT http-equiv; that might be best, then.

Revised text:
requests.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints.  <ins> Client Hints mitigate performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and privacy concerns of passive fingerprinting by requiring explicit opt-in and disclosure of required headers by the server through the use of the Accept-CH response header. </ins>  <ins> This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly.  However, it does not define any specific features that will use that infrastructure.  Those features will be defined in their respective specifications. </ins> One example of such a feature is the User Agent Client Hints feature UA-CH.