Re: [Gen-art] Gen-ART Last Call review of draft-ietf-httpbis-cache-header-08

Lars Eggert <lars@eggert.org> Fri, 06 August 2021 08:34 UTC

Return-Path: <lars@eggert.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9643A24C8; Fri, 6 Aug 2021 01:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxVsQYuEVKyE; Fri, 6 Aug 2021 01:34:05 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1C73A24C4; Fri, 6 Aug 2021 01:34:02 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:b0b1:974:c10e:6775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 139106003D5; Fri, 6 Aug 2021 11:33:55 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1628238835; bh=cO35Oo6GoiQdI5AF6Pp1VnaZEQaYELRdmQpQ12IyWrE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=y+XTWEc9ebnGsha7rm0SMxhqT/BY2sPOXpJAopgwaDCibSaMsObwpKXqQlExIYb5X NYNXgGLbWls46yCH0YPcgGnDI2xQh1KrHrhUW0mV06hLfdBZtA4QEg9EH872/nLgbI 8FBLDBhpuCZJ7lvBJYM9Q3FbrLaoOgTPao9/64Yw=
From: Lars Eggert <lars@eggert.org>
Message-Id: <88AC99F1-4A4F-4CE7-888D-AFC4A11D2148@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C3A58D0C-3E06-4A2A-8687-CD1991B47D5E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 6 Aug 2021 11:33:54 +0300
In-Reply-To: <e8c8b750-0f10-c462-3bd2-525770aaf51f@alum.mit.edu>
Cc: draft-ietf-httpbis-cache-header.all@ietf.org, General Area Review Team <gen-art@ietf.org>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <e8c8b750-0f10-c462-3bd2-525770aaf51f@alum.mit.edu>
X-MailScanner-ID: 139106003D5.A503D
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/GGYuUy2TAaVClgQenf1YOgEQsa8>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-httpbis-cache-header-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 08:34:11 -0000

Paul, thank you for your review and thank you all for the following discussion. I have entered a No Objection ballot for this document.

Lars


> On 2021-7-1, at 19:55, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> 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-cache-header-08
> Reviewer: Paul Kyzivat
> Review Date: 2021-07-07
> IETF LC End Date: 2021-07-01
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> General:
> 
> What I read in Security Considerations section scares me, but I'm not competent to express an opinion. I am going to leave this to the security review.
> 
> Issues:
> 
> Major: 0
> Minor: 4
> Nits:  0
> 
> 1) Minor: Is a hit or fwd parameter required?
> 
> Is it required that an entry contain one of "hit" or "fwd"? Section 2.1 makes it clear that you can't use both, but is less clear that one of them must be included. But logically it seems that an entry without either wouldn't be very useful.
> 
> I suggest that this be stated explicitly.
> 
> 2) Minor: ttl for other caches
> 
> I'm not clear about the following in section 3:
> 
>   Going through two separate layers of caching, where the cache closest
>   to the origin responded to an earlier request with a stored response,
>   and a second cache stored that response and later reused it to
>   satisfy the current request:
> 
>   Cache-Status: OriginCache; hit; ttl=1100,
>                 "CDN Company Here"; hit; ttl=545
> 
> When "CDN Company Here" replies with a hit is it responsible for updating the ttl for the OriginCache? (Based on the time that has elapsed since it cached the value.) If not, does that ttl have any relevance?
> 
> 3) Minor: registration of parameters
> 
> IMO the process of registration is underspecified.
> 
> For one thing, IANA is not instructed as to what the registry itself should look like. Given that a specification document is optional, the registry presumably must contain everything specified by the template in section 4 for new parameter registrations. But the instructions for pre-populating the registry from section 2 would mean copying a *lot* free formatted text into the registry.
> 
> ISTM that it would be more straightforward to always require a specification and have the IANA registry refer to it.
> 
> Alternatively, you could have different templates for registering with/without a specification and different registry formats for each.
> 
> I suggest you provide IANA with a template for the registry, and provide authors of extension parameters with a template for what should be included in a specification document.
> 
> 4) Minor: Applicability of this header field is confusing
> 
> Section 2 says:
> 
>   The Cache-Status header field is only applicable to responses that
>   are generated by an origin server.  An intermediary SHOULD NOT append
>   a Cache-Status member to responses that it generates, even if that
>   intermediary contains a cache, except when the generated response is
>   based upon a stored response (e.g., a 304 Not Modified or 206 Partial
>   Content).
> 
> The use of "are" implies to me that the cache received the response from the origin server just now. Using "were" (or even more explicit language) would tell me that this was a response received by the cache either now or in the past.
> 
> Also, IIUC the cache can't ever really distinguish if it received a response from the origin server or another cache. So how can it know if this response *ever* was created by the origin server? All it can know is that it received it from a server closer to the origin.
> 
> Can you clarify the language?
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art