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

Mark Nottingham <mnot@mnot.net> Fri, 02 July 2021 06:05 UTC

Return-Path: <mnot@mnot.net>
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 49CA53A0B8A for <gen-art@ietfa.amsl.com>; Thu, 1 Jul 2021 23:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=l/xIPwwa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vo8Nn/Uf
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 PGUGgiBWnKdw for <gen-art@ietfa.amsl.com>; Thu, 1 Jul 2021 23:05:34 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE983A0B88 for <gen-art@ietf.org>; Thu, 1 Jul 2021 23:05:33 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 43BCA5C0037; Fri, 2 Jul 2021 02:05:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 02 Jul 2021 02:05:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=b 90wm+B5YTkEgdnNjZod90TdxptEyYydr4a1nLLjy4g=; b=l/xIPwwa2Mmrdu9Zj cxq5rmAQPxH30gy57JtWZjW/yA2igrPgBs121V9HWvagXUPh9IgQ4R9IkrHNIQBQ qB+uDqTxVhKx2X7rKIwRETSzNQrUOCO/l1MVLL3bnnJ1ojFyrOW57ErUD0f3VZ8E uZ86mKPdqlktgucaSRhi6W9o8Qg1q52kCHaNvfJBO6KOP78cvP6lxYX9OJq5/zJz VIitTWL4AhkvgpASH+xCM4n0rSJLVGbCRDEW7BwEtMdph8IdxKkubFM0ANhWwpB/ qrKgg1zpg1MEBGFYlA+m5JaBSDcATjsyw8JLam4x70/LX3yWAmIGthK1JLi44Nmh 54VEQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=b90wm+B5YTkEgdnNjZod90TdxptEyYydr4a1nLLjy 4g=; b=Vo8Nn/Uf3Vi+1Mvy6qlxYdjIdM+UZHDZ+es+7CoYY8U7TeMRdNkOBf2Z4 Q8D7AVOcg4nau0JSl1zta8j7xCQvPxg/EI9FJplJkgp+TZis8c7w44wBMXlglc5T QlI1OI6pVkHR1ZQtK0/KN9f/0ygZSCDqHwpF15kHs+j8roMOFbuvXGdSpZQBJd4l QAV1OKMC14TBpcqs/x/0fBq2lRpMrRRNeEuG0wb8M+QALMO+xTtIMTUdB+XFDkWa IkJqDvPh32RhWw/qCFDpWXiMqCqRm5aZJSzZbBVbn9jm2M4ytwYl/6mAZ4xBE6vW uGHBReVblOW/Xxw+HNmZF8Oys/DOw==
X-ME-Sender: <xms:qqzeYFfb4hi8SWRnyapk68kPQ3dvkrxQpS7-BZodq7VjqUVq3ct5og> <xme:qqzeYDOq0VfFqUQzKck0PijdZ0m4cEI90ROddHvLze0Skqn89HBsbr2sG4fCUB3AM hVEW7psO430T99hWw>
X-ME-Received: <xmr:qqzeYOihk9u3DDSvHECk3wQrr6JEdmMU-BBGSKUl-R12ZtXje9bH0zJ8ljdVo3LOR3-GXjzfiOHRdzIfUopswptY8gvT_ICfM8wqtRubG9CWj5CByNWKbXZp>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeijedguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeu teetnecuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:qqzeYO_LFdhFEu5qpsjSkhml4WrLqqtfu8V95PxjWvh5Dv17Cctn_Q> <xmx:qqzeYBtTGBXc7Mo5mbymXqG-V03aUHZQwwe0bjOyyChV-BCBDQ4awA> <xmx:qqzeYNFA0F3wsYwZXeMuD6SA2VA2eLlhyeE4VloRPilq90NuDFq2dQ> <xmx:rKzeYLLskP0wiUDDHcBl07WSuPuqpLOjJNU4G7XsgxTZD0rjJvbt0w>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 2 Jul 2021 02:05:29 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <e8c8b750-0f10-c462-3bd2-525770aaf51f@alum.mit.edu>
Date: Fri, 2 Jul 2021 16:05:26 +1000
Cc: General Area Review Team <gen-art@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E5C07AE-AB5B-4909-8A3B-C3EDBCDAF540@mnot.net>
References: <e8c8b750-0f10-c462-3bd2-525770aaf51f@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/TKQV83JXhqu0VfZMAbk7EdoRgiI>
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, 02 Jul 2021 06:05:39 -0000

Hi Paul,

Thanks for the review; I've added the WG mailing list to the CC.

> On 2 Jul 2021, at 2:55 am, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> 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.

It's not required; conceivably, there's value in knowing that a cache was merely present. As the spec states, all parameters are OPTIONAL.


> 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?

No - 'ttl' is how fresh a response is in a cache when it's served; recording it helps to determine how old the response was at each step. As the spec says:

"When adding a value to the Cache-Status header field, caches SHOULD preserve the existing field value, to allow debugging of the entire chain of caches handling the request."


> 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.

There's a registration template in Section 4, referenced from the IANA considerations. 


> 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?

OK. I've changed 'are' to 'have been'.

Thanks again for the review,


--
Mark Nottingham   https://www.mnot.net/