Re: [core] 🔔 WGLC of draft-ietf-core-too-many-reqs-02

Michael Koster <> Tue, 10 July 2018 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC1FE130FB8 for <>; Tue, 10 Jul 2018 07:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwYHcCwqSK0l for <>; Tue, 10 Jul 2018 07:01:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54BDE130FB7 for <>; Tue, 10 Jul 2018 07:01:09 -0700 (PDT)
Received: by with SMTP id r3-v6so7857604ywc.5 for <>; Tue, 10 Jul 2018 07:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fZ1gn5wnOxQVsPrTtUBm5ZgxeVxd4INVlra51Iwxsj0=; b=Zcq4za5FGNBX52uod20m/qxYBcVCYlw94RhXGvwmouW8kIhl/3B1p/EeroiQv+juW4 s+UDJc8Ix8ANEJCQqAgpfwEytdLzqc39yTJTfh0W+MnjZYLe+fv8Rwj47v+Iv1cdqsGI MIny7onZSDmxsIXwzc8QMsDDGemWSzZBZzqdK1nOjpJ9mc6IZvhWX00VLSxB4mEogUDC NslifYeWEiKoUMA1o64zI2sKWH5vzdBW79IADqdhZM6Hl5m9YpCEYedYVTFrQTGCOOhO ewlB6/B/WXWwve5yX3zrqpjhhQVZeUmdzy8rTvc6aaB8QHspPfp/nz0Zy01q7RWCVSDA FXxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fZ1gn5wnOxQVsPrTtUBm5ZgxeVxd4INVlra51Iwxsj0=; b=Xcuu/ipFGMLrWQ9AT7Qloq8L6vF/7v5isFAbGG1c1e9CENkKQwiYY2an0h2367e2d9 556ki+wn57B996YWrWv/8m9pZhpXyOHEAPSyGcympVSOW/eT9l3cyoAEtCpg8QrW3RTo qv/4SjQwslN18fBeO2Nl0uKpS+XXsu8fKS/GQdNOcAQZw8EivkRC9wTbKPHxE1F0D0kB jvuT5CoC7Z6cDWUUAAaQDEEJjgK/7gbosKhJ9OfyJIKeIV6Db1RS1Pg84nk7xKgOqnmY VgxyejYMh++VGD7UAXK6uKRTSZWtgZFEUXSsu3hkVpl80+6TxgrSNLRgSXYPMb3tfJo8 qa5A==
X-Gm-Message-State: APt69E0PxxoBS3JMrmoTVcmlbTXh8sXts48FGVtkmOq5FYiMtzagmwNi WyBPoBfgNMVY4VElkUhFQMg=
X-Google-Smtp-Source: AAOMgpeWAdA9h5HrmYeDnc8iOpb5EYA5r2GHxtr/PfxJYnluSuBAbkeM2rlta+vKMn/Sx1nc87Q+LQ==
X-Received: by 2002:a0d:f1c7:: with SMTP id a190-v6mr3439887ywf.321.1531231267714; Tue, 10 Jul 2018 07:01:07 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id z206-v6sm7837182ywa.97.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 07:01:06 -0700 (PDT)
From: Michael Koster <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1AA97119-49EB-403E-933F-15E90182BBCD"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 10 Jul 2018 07:01:04 -0700
In-Reply-To: <>
Cc: Jim Schaad <>, Core <>
To: =?utf-8?Q?Ari_Ker=C3=A4nen?= <>
References: <> <008c01d41462$44c26c90$ce4745b0$> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?=
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2018 14:01:13 -0000


I think it's out of scope for this draft to specify *how* the server determines there are too many requests, and similar related concerns.

The 4xx code indicates that the client can do something about it, and the proxy would indeed be a more confusing case. Surely there are other cases where the proxy needs to have a defined behavior in the face of things that can be retried. At least 4xx gives the proxy a chance to do something reasonable.

For example, the server could keep a ranking of the request rate from different clients and sending the TMR code preferentially to the higher ranking clients. But that may not be appropriate for all situations.

We want to keep the scope of the meaning of the code to be narrow, I think.

Best regrds,


> On Jul 10, 2018, at 2:10 AM, Ari Keränen <> wrote:
> Thank you for the review Jim!
> Please see inline.
>> On 5 Jul 2018, at 16.15, Jim Schaad < <>> wrote:
>> The draft looks fine to me.
>> The server gets to have a definition of what it means for something to be "too similar" for a request and there is no way for this standard to be communicated to the client.  Thus the client's idea that similar means 'the same payload' may not be the servers idea of 'any payload'.  I don't know how to fix this so I expect it to be ignored.
> While there is no good way to communicate that in generic fashion, and trying to design one here sounds a bit overkill, the “standard for similarity” can be part of the application. Hence client can have context information what is similar and what is not. And can eventually figure out from server’s reply that a request it sent was considered similar.
> The other alternative would be to define here explicitly and exclusively what is similar but that would restrict the use cases.
>> The document appears to say that this response code is for dealing with a single client.  That is the traffic metric is calculated individually for each client.  The proxy for each client presumably being source IP, port pair.  If the traffic metric is calculated for everybody then it should return 5.03.  If that is not the intent then this needs to be made clearer.
> If the server is able to use other information (e.g., security credentials / cookies of some sort) to make a separation per client, that could be used even via proxy. 
> I guess a key difference to 5.03 besides being per client, is that too-many-reqs is also per “similar requests / request type” whereas 5.03 implies that any request would be rejected. Does that make sense? 
>> Note that a client could get this as a response even on its first request if the path to the server goes through a proxy agent.
> Indeed. We could add a note about that to make it less unexpected.
> Cheers,
> Ari
> -----Original Message-----
>>> From: core <> On Behalf Of Carsten Bormann
>>> Sent: Monday, July 2, 2018 6:54 AM
>>> To: Core <>
>>> Subject: [core] 🔔 WGLC of draft-ietf-core-too-many-reqs-02
>>> Dear CoRE WG,
>>> during the London IETF, we said we want to quickly finish the spec of the
>>> response code 4.29 (too many requests).
>>> The author has now submitted a revised version dealing with the recent
>>> comments and believes it is ready for Working Group last call.
>>> A diff from the previous version is available at:
>>> The WGLC will end in exactly 336 hours so we can discuss the outcome at the
>>> CoRE WG meeting
>>> Grüße, Carsten
>>> PS.: A bonus for the first one who finds the one malformed sentence I found
>>> during chair review:
>>> You’ll get some Finnish Salmiakki at the Montreal meeting.
>>> _______________________________________________
>>> core mailing list
>> _______________________________________________
>> core mailing list
> _______________________________________________
> core mailing list
> <>
> <>