Re: [Gen-art] Genart last call review of draft-ietf-httpbis-client-hints-13

Christer, thanks for your review. Yoav, thanks for addressing the comments. I entered a No Objection ballot.

Alissa

> On May 1, 2020, at 6:44 PM, Christer Holmberg via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-httpbis-client-hints-13
> Reviewer: Christer Holmberg
> Review Date: 2020-05-01
> IETF LC End Date: 2020-05-08
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is easy to read, and I understand the general concept of
> the mechansim. However, I have a number of questions, some related to the
> usage, which I think need to be clarified, and some more editorial.
> 
> Q3:
> 
> Section 2.1. describes sending of Client Hints, based on Accept-CH, and Section
> 3.1. defines the Accept-CH header field.
> 
> But, there is no guidance on what a client does BEFORE it receives Accept-CH. I
> assume it does not include support of any features.
> 
> Also, there is no guidance on what a client does if it does NOT receive
> Accept-CH (because the server does not support it). Will it then send another
> request and include supported features ? What if it is too late, and the server
> has already made choises?
> 
> I think some client behavior guidance would be useful.
> 
> ---
> 
> Q4:
> 
> Related to Q3, there is not server procedure on when Accept-CH is sent to the
> client.
> 
> ---
> 
> Q5:
> 
> Related to Q4, what happens if a server receives hints that it does not
> understand, or does not support?
> 
> ---
> 
> Q6:
> 
> Section 3.1 says:
> 
>   “It SHOULD be persisted and bound to the origin to enable delivery of Client
>   Hints on subsequent requests to the server's origin.”
> 
> …and the subsequent text then gives an example.
> 
> First, what is the time scope of “subsequent requests”? A session? An hour? A
> day? For how long does the client need to remember the Accept-CH header field
> value for a given origin server?
> 
> Second, the procedure does not seem to take into account that certain aspects,
> e.g., network characteristics, may change between when requests are sent to an
> origin server.
> 
> -------
> 
> Major issues:
> 
> MaQ1:
> 
> Section 2.1. describes sending of Client Hints, based on Accept-CH, and Section
> 3.1. defines the Accept-CH header field.
> 
> First, there is no guidance on what a client does BEFORE it receives Accept-CH.
> I assume it does not include support of any features.
> 
> Second, there is no guidance on what a client does if it does NOT receive
> Accept-CH (because the server does not support it). Will it then send another
> request and include supported features ? What if it is too late, and the server
> has already made choises?
> 
> I think some client behavior guidance would be useful.
> 
> ---
> 
> MaQ2:
> 
> Related to Q3, there is not server procedure on when Accept-CH is sent to the
> client. Also, can an Accept-CH with updated information be sent?
> 
> ---
> 
> MaQ3:
> 
> Related to MaQ2, what happens if a server receives hints that it does not
> understand, or does not support?
> 
> ---
> 
> MaQ4:
> 
> Section 3.1 says:
> 
>   “It SHOULD be persisted and bound to the origin to enable delivery of Client
>   Hints on subsequent requests to the server's origin.”
> 
> …and the subsequent text then gives an example.
> 
> First, what is the time scope of “subsequent requests”? A session? An hour? A
> day? For how long does the client need to remember the Accept-CH header field
> value for a given origin server?
> 
> Second, the procedure does not seem to take into account that certain aspects,
> e.g., network characteristics, may change between when requests are sent to an
> origin server.
> 
> --------
> 
> Minor issues:
> 
> MiQ1:
> 
> Section 1 described that proactive content negotiation allows servers to
> silently fingerprint the user agent.
> 
> But, later in the Section it is described that Client Hints also allow a server
> the perform fingerprinting, and the Security Considerations also say that there
> is really no difference.
> 
> So, does Section 1 need to talk about fingerprinting at all?
> 
> ---
> 
> MiQ2:
> 
> The 4th last paragraph of Section 1 says:
> 
>   “It also defines guidelines for content negotiation mechanisms that use it,
>   colloquially referred to as Client Hints.”
> 
> The 2nd last paragraph of Section 1 says:
> 
>   “This document defines Client Hints, a framework that enables servers
>     to opt-in to specific proactive content negotiation features,
>     adapting their content accordingly.”
> 
> The 2nd last pargraph also talks about “usage of infrastructure”, which I don’t
> really understand. I assume you mean the Client Hints framework?
> 
> First, I think the text in the 4th last paragraph should be replaced by the
> text in the 2nd last paragraph.
> 
> Second, I think the text introducing the framework should come BEFORE the text
> introducing the Accept-CH header field.
> 
> Something like:
> 
>   "This document defines Client Hints, a framework that enables servers
>   to opt-in to specific proactive content negotiation features,
>   adapting their content accordingly. This document also defines a new
>   response header, Accept-CH, that allows an origin server to explicitly
>   ask that clients send these headers in requests.
> 
>   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.
> 
>   The document does not define specific usages of Client Hints. Such usages
>   Need to be defined in their respective specifications.
> 
>   One example of such usage is the User Agent Client Hints [UA-CH]."
> 
> -------
> 
> Nits/editorial comments:
> 
> EdQ1:
> 
> The document uses both “client” and “user agent” terminology. Is there a reason
> for that, or could one be picked?
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art