Re: [core] đź”” WGLC of draft-ietf-core-too-many-reqs-02

Ari Keränen <ari.keranen@ericsson.com> Tue, 10 July 2018 09:10 UTC

Return-Path: <ari.keranen@ericsson.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 E03CC130E14 for <core@ietfa.amsl.com>; Tue, 10 Jul 2018 02:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.331
X-Spam-Level:
X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 ydpD4b-Nd22K for <core@ietfa.amsl.com>; Tue, 10 Jul 2018 02:10:39 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A9813112B for <core@ietf.org>; Tue, 10 Jul 2018 02:10:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531213837; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RSoYNHcdNaQoaGk04esYhpKeimgYSmy+6295culwrLE=; b=Njkm0WAmpLbv/DkMm2s4DM3kSA1/hcQo538iev/xnqtk+rKNzaTyVhoe1oAhsOp4 N5NBopZ2gL1/aSejTfS/+ssKraAqyGaN76Glm4Qiu+EqHGbN0R+1oVF9vOMhmtOr Ebl7NVGlIxrxMisxuwbQ3zggHOdzkUvyx6zNysR0vBA=;
X-AuditID: c1b4fb3a-9e9ff700000079c1-96-5b44780d0ff3
Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.92.31169.D08744B5; Tue, 10 Jul 2018 11:10:37 +0200 (CEST)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 10 Jul 2018 11:10:37 +0200
Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Tue, 10 Jul 2018 11:10:37 +0200
From: Ari Keränen <ari.keranen@ericsson.com>
To: Jim Schaad <ietf@augustcellars.com>
CC: Core <core@ietf.org>
Thread-Topic: [core] đź”” WGLC of draft-ietf-core-too-many-reqs-02
Thread-Index: AQHUFGJQqjwNHnXwzEeGTHHM9wZN/aSIMvZO
Date: Tue, 10 Jul 2018 09:10:37 +0000
Message-ID: <69958BDF-BE66-4504-8E0B-C63BC8B89EC1@ericsson.com>
References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org>, <008c01d41462$44c26c90$ce4745b0$@augustcellars.com>
In-Reply-To: <008c01d41462$44c26c90$ce4745b0$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7kS5vhUu0wexlUhb73q5ntlg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx9OFJpoI5yhVvVp9hbGBcodTFyMkhIWAi cWnCVOYuRi4OIYGjjBLHt61lh3C+MUrMefgEKrOMUeLz/qvMIC1sArYST1r3sYLYIgLqEltX 32QCsZkFJCSmTm4EiwsL5Ei0H1zGDlGTK/Hrwj1GCNtI4tmjdWBzWARUJbafPAVm8wrYS1w9 9BysXkggT2Lp7PssIDangIPElNevwHoZBcQkvp9aA7VLXOLWk/lMEC8ISCzZc54ZwhaVePn4 H9ANHEA1mhLrd+lDlCtKTOl+yA6xSlDi5MwnLBMYRWchmTQLoWMWko5ZSDoWMLKsYhQtTi0u zk03MtJLLcpMLi7Oz9PLSy3ZxAiMk4NbflvtYDz43PEQowAHoxIPr2qZS7QQa2JZcWXuIUYJ DmYlEV6DHOdoId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxOaRZRQgLpiSWp2ampBalFMFkmDk6p Bkb1fPFX3s9WzhP6FHOBaVODPp/gva+XLCctlNaP81jyqmR6w5UCk6faTR/lxOv/ruxKVqpQ Xc1k/r/+xKuVm5XFrWpjNv6J3MniJHepK0z/xpncXQ87dj6NW5rgdWRyZeeXY0/eTNFfvCBp teJP0d/GTrWG8rMXv9L5sK1pSYRWo22u6LLjbluUWIozEg21mIuKEwFxRVtOjwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/cO2eAFZ57gjkVvCYGe0h9Yj5TeE>
Subject: Re: [core] đź”” WGLC of draft-ietf-core-too-many-reqs-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 09:10:51 -0000

Thank you for the review Jim!

Please see inline.

> On 5 Jul 2018, at 16.15, Jim Schaad <ietf@augustcellars.com> 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 <core-bounces@ietf.org> On Behalf Of Carsten Bormann
>> Sent: Monday, July 2, 2018 6:54 AM
>> To: Core <core@ietf.org>
>> 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.
>> 
>> https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02
>> A diff from the previous version is available at:
>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-02
>> 
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core