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

Benjamin Kaduk <kaduk@mit.edu> Tue, 23 October 2018 19:56 UTC

Return-Path: <kaduk@mit.edu>
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 B5C93130E71; Tue, 23 Oct 2018 12:56:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
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: <154032461873.31236.9757655812218106074.idtracker@ietfa.amsl.com>
Date: Tue, 23 Oct 2018 12:56:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/CvGs9ygC3JPcfECARgk6BHLnIU0>
Subject: [core] Benjamin Kaduk'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 19:56:59 -0000

Benjamin Kaduk 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:


Section 3

It may be appropriate to explicitly reiterate that "The 4.29 response code is
only returned to the client(s) sending requests too frequently; if other
clients are sending requests that cannot be served due to server overload,
the 5.03 response code is more appropriate."

   If a client repeats a request that was answered with 4.29 before Max-
   Age time has passed, it is possible the client did not recognize the
   error code and the server MAY respond with a more generic error code
   (e.g., 5.03).

Isn't it also possible that the additional requests were already in flight
when the 4.29 was generated?  (It's unclear whether that needs to be
specifcially mentioned in the document.)

Section 5

As per the previous comment, a server that erroneously returns 4.29 to too
many (i.e., including well-behaving) clients would unnecessarily DoS the
well-behaved clients.

It may be appropriate to reference the RFC 7252 security considerations as
continuing to apply.