Re: [core] AD review of draft-ietf-core-too-many-reqs-04

Ari Keränen <ari.keranen@ericsson.com> Fri, 17 August 2018 18:58 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 CFAE1130F01 for <core@ietfa.amsl.com>; Fri, 17 Aug 2018 11:58:42 -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 CwebVnHWXD_H for <core@ietfa.amsl.com>; Fri, 17 Aug 2018 11:58:41 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 C4A4B130E6A for <core@ietf.org>; Fri, 17 Aug 2018 11:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534532318; 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=rc1V/ySqAV1gfqfVHv+PJStYPu3hIESRvLt0zi/4hwk=; b=NOMOZuC63gPhX2AXygU2YEw31IQ3q4s8OtESoPu7XE6wZqRANR/Ql/w+m/07DJls +5WjGD5qOsBC9L3LDTN0/6bHMNg7aHs24Ri9pOTqxTXec1/otZ+AoTZmlaSftuEK 77Ujd1F0FTW3v3uEXaB1uMwEcFG1/r34EZqEUtvQVKg=;
X-AuditID: c1b4fb25-c43e39c0000020b7-c6-5b771ade1e02
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.53.08375.EDA177B5; Fri, 17 Aug 2018 20:58:38 +0200 (CEST)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 17 Aug 2018 20:58:38 +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; Fri, 17 Aug 2018 20:58:38 +0200
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= <ari.keranen@ericsson.com>
To: Carsten Bormann <cabo@tzi.org>, Alexey Melnikov <alexey.melnikov@isode.com>
CC: core <core@ietf.org>
Thread-Topic: [core] AD review of draft-ietf-core-too-many-reqs-04
Thread-Index: AQHUNXDVEysZvMMar0CGxcnJOD+dX6TCYhmAgAHKGgA=
Date: Fri, 17 Aug 2018 18:58:38 +0000
Message-ID: <751E4416-A51D-462C-9365-C9B378118DCE@ericsson.com>
References: <3b397c15-d016-a281-3b0a-3b956a982a80@isode.com> <7B349A43-A750-4A60-967F-9031F7A4A8D7@tzi.org>
In-Reply-To: <7B349A43-A750-4A60-967F-9031F7A4A8D7@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.153]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DC32DAF680E090458A3214D6C6EAE1A8@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2J7he49qfJog1UPrC1mrC6yODLlLqvF vrfrmR2YPZYs+cnkcarZ0GPaoswA5igum5TUnMyy1CJ9uwSujH19t1gL5khWdE+aztLAeEKi i5GTQ0LAROLulLcsXYxcHEICRxklJiw4yAqSEBL4xigxb04QRGIZo8Sl02+YQRJsArYST1r3 ARVxcIgIBEpcOBAJEmYWkJA4u/IwWK+wgKPEwqN3WUBsEQEnifn/2qBsK4kTByczgtgsAqoS S27fBxvJK2Av8WDbLjaQkUICuRK927RATE4Ba4nOZ/EgFYwCYhLfT61hgtgkLnHryXwmiPMF JJbsOc8MYYtKvHz8jxXCVpLYe+w6C8gYZgFNifW79CFarSU63r5ihrAVJaZ0P2SHOEBQ4uTM JywTGMVnIdkwC6F7FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMOoO bvmtuoPx8hvHQ4wCHIxKPLzKf8qihVgTy4orcw8xSnAwK4nwRi4HCvGmJFZWpRblxxeV5qQW H2KU5mBREud9aL45SkggPbEkNTs1tSC1CCbLxMEp1cBY6GlWoWutkmjf+XzOrbdn4lcfND0b t34x2wft7xUdvJr3J96yCJq2bkF7lcsLcdWne/acV1ypN9ehrCm5OWXydB1juSc9Oaz8x0W4 LyyOmb93Ktf0k0oCz7QXvJxYLySUaFHD2MbeXC9z6+j1aftdpi1KefLx55EFfLob/nPw/tDO StrC/1pfiaU4I9FQi7moOBEAOoRdlrYCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jIMTqd971YkbROADa5LvNWWfVZI>
Subject: Re: [core] AD review of draft-ietf-core-too-many-reqs-04
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: Fri, 17 Aug 2018 18:58:43 -0000


> On 16 Aug 2018, at 18.39, Carsten Bormann <cabo@tzi.org>; wrote:
> 
> On Aug 16, 2018, at 16:52, Alexey Melnikov <alexey.melnikov@isode.com>; wrote:
>> 
>> Hi,
>> 
>> This is a straightforward document, as it tracks HTTP functionality defined in RFC 6585.
>> 
>> I have one main question about the document: when comparing this document with its HTTP counterpart, the HTTP version is using the Retry-After header field, while this document is reusing the Max-Age option. (HTTP has both Retry-After and Age header fields)
>> 
>> RFC 7252 defines Max-Age as follows:
>> 
>> 5.10.5.  Max-Age
>> 
>>   The Max-Age Option indicates the maximum time a response may be
>>   cached before it is considered not fresh (see Section 5.6.1).
>> 
>>   The option value is an integer number of seconds between 0 and
>>   2**32-1 inclusive (about 136.1 years).  A default value of 60 seconds
>>   is assumed in the absence of the option in a response.
>> 
>>   The value is intended to be current at the time of transmission.
>>   Servers that provide resources with strict tolerances on the value of
>>   Max-Age SHOULD update the value before each retransmission. (See
>>   also Section 5.7.1.)
>> 
>> So my question is: why is it Ok to reuse Max-Age option and not define a new one, which is closer to the desired semantics? If this was already discussed on the mailing list, please Kindly point me to the relevant thread(s).
> 
> I think this is modeled after 5.03 in 7252:
> 
> 5.9.3.4.  5.03 Service Unavailable
> 
>   This Response Code is like HTTP 503 "Service Unavailable" but uses
>   the Max-Age Option in place of the "Retry-After" header field to
>   indicate the number of seconds after which to retry.
> 
> In both cases, the max-age limits the validity of the hold-off expressed by the response code.
> 
> Michael: Data lifetime doesn’t really enter here, as there is no data with either 4.29 or 5.03.

Indeed, IIRC that's where we got the inspiration from back in 2015 [1]. It was also discussed (/mentioned) in the IETF 93 CoRE WG session [2]. Minutes didn't have much details so probably there was no long debate on this though.


Cheers,
Ari


[1] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-02#section-7
[2] https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf (slide 68)