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

Adam Roach <adam@nostrum.com> Mon, 22 October 2018 22:47 UTC

Return-Path: <adam@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 0FEDE130EBC; Mon, 22 Oct 2018 15:47:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@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: <154024846005.13541.11907103981598035179.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 15:47:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jgfc0hW-c-ZCrGGT0_wWnz7hugQ>
Subject: [core] Adam Roach'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: Mon, 22 Oct 2018 22:47:48 -0000

Adam Roach 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:


Thanks for the work that everyone did on this document. I have one major
comment, and a couple of small editorial nits.

This document defines the use of the Max-Age option that is very different from
its originally defined use. It seems to me that the IANA registry entry for
Max-Age needs to be updated to reference this document in addition to RFC 7252.

Additionally, the original definition of Max–Age included a default value of 60
seconds. It is unclear, and somewhat ambiguous, whether that default is intended
to apply to this mechanism as well. Please add text explicitly indicating
whether a default applies. In any case, this document should have an indication
of what the client does if the response contains no max-age option.



This would benefit from having the COAP protocol named in the title.



>  the too frequent requests from the requesting client are the reason

Nit: "...too-frequent..."