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

[Christer Holmberg <[e-mail]>]

Hi,

Seems like I did a copy/paste error. Please skip Q3-Q6, the issues/questions will come later in the review.

Regards,

Christer



On 02/05/2020, 1.44, "last-call on behalf of Christer Holmberg via Datatracker" <[e-mail] on behalf of [e-mail]> 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?
    
    
    
    -- 
    last-call mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/last-call