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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
