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

Ben Campbell <ben@nostrum.com> Sat, 03 November 2018 06:55 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE394129385; Fri, 2 Nov 2018 23:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 Y6alD0ixio8L; Fri, 2 Nov 2018 23:55:01 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4F67E127332; Fri, 2 Nov 2018 23:55:01 -0700 (PDT)
Received: from [10.42.10.6] (ip-91-232-239-173.texas.us.northamericancoax.com [173.239.232.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA36snF6085299 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 3 Nov 2018 01:54:52 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-91-232-239-173.texas.us.northamericancoax.com [173.239.232.91] claimed to be [10.42.10.6]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <81D232DE-12AD-4A4E-B5BC-E8E3DA27455C@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_684B442B-2E77-4B66-8AA8-1996EBCD58BB"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Sat, 3 Nov 2018 13:54:48 +0700
In-Reply-To: <B76A4686-BFF5-424B-A813-5C3C69B35BD9@ericsson.com>
Cc: "core-chairs@ietf.org" <core-chairs@ietf.org>, The IESG <iesg@ietf.org>, "core@ietf.org" <core@ietf.org>, "draft-ietf-core-too-many-reqs@ietf.org" <draft-ietf-core-too-many-reqs@ietf.org>
To: =?utf-8?Q?Ari_Ker=C3=A4nen?= <ari.keranen@ericsson.com>
References: <154033246253.31224.15896855788700700234.idtracker@ietfa.amsl.com> <BA369CA3-07FC-4F06-A84E-57BF4AE8D8E6@ericsson.com> <54D94C5C-F815-496B-B069-0887DF236B9A@nostrum.com> <B76A4686-BFF5-424B-A813-5C3C69B35BD9@ericsson.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dgkYRWBUUnqKJ4j51-4Zbj6Xxj0>
Subject: Re: [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
Precedence: list
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: Sat, 03 Nov 2018 06:55:04 -0000


> On Nov 1, 2018, at 7:50 AM, Ari Keränen <ari.keranen@ericsson.com>; wrote:
> 
> Hi Ben,
> 
> (Clipping out all except the remaining comment; see below)
> 
> On 24 Oct 2018, at 20.37, Ben Campbell <ben@nostrum.com>; wrote:
>>> On Oct 24, 2018, at 1:48 AM, Ari Keränen <ari.keranen@ericsson.com>; wrote:
>>> On 24 Oct 2018, at 1.08, Ben Campbell <ben@nostrum.com>; wrote:
>>> 
>>>> Ben Campbell has entered the following ballot position for
>>>> draft-ietf-core-too-many-reqs-05: No Objection
>>> [...]
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
> [...]
>>>> §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?
>>> 
>>> Client should not make assumptions, e.g., that it can safely keep increasing the request rate until it receives 4.29, even if a server supports that.
>> 
>> That seems kind of vague for a normative MUST NOT. How did clients pace requests prior to this? Are we asking them to do something different
> 
> Basic CoAP implementations using default values would have just a single request on fly, but more advanced implementation could have more e.g., based on RTT estimates. The key point here is that this error code should not be used to probe a limit the server can handle. So it’s not really any new behavior this draft is asking for, rather a hint that this code should *not* be used for this (probing) kind of “new behavior”.
> 
> What would you recommend instead of MUST NOT here? Would “should not” be more appropriate?

That would work for me.

Thanks!

Ben.