[core] Ben Campbell's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)

Ben Campbell <ben@nostrum.com> Tue, 23 October 2018 22:07 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF75130DD1; Tue, 23 Oct 2018 15:07:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-core-too-many-reqs@ietf.org, Carsten Bormann <cabo@tzi.org>, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154033246253.31224.15896855788700700234.idtracker@ietfa.amsl.com>
Date: Tue, 23 Oct 2018 15:07:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/fhqeGPcl7_RImPRM68Zgc5Kq8sY>
Subject: [core] Ben Campbell's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2018 22:07:42 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-core-too-many-reqs-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Hi, thanks for the work on this. I have a few comments, below:

I share Adam's concern about overloading Max-Age for this purpose. If anything,
the use in this document is specifying a minimum time interval, not a maximum
one. That is, this use not only overloads Max-Age, but does it in a
counter-intuitive way. Is there a reason not to define a new option?

§4: "A client MUST NOT rely on a server being able to send the 4.29
Response Code in an overload situation because an overloaded server
may not be able to reply at all to some requests."

Can you elaborate on the practical effect of that MUST NOT?