Re: [core] draft-ietf-core-hop-limit-01
<mohamed.boucadair@orange.com> Wed, 12 December 2018 06:41 UTC
Return-Path: <mohamed.boucadair@orange.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 ECB8E131129; Tue, 11 Dec 2018 22:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 oTWvTMwDdziM; Tue, 11 Dec 2018 22:41:37 -0800 (PST)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BE6131125; Tue, 11 Dec 2018 22:41:37 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 43F6fQ75gzz5xtJ; Wed, 12 Dec 2018 07:41:34 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 43F6fQ6771z3wbJ; Wed, 12 Dec 2018 07:41:34 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0415.000; Wed, 12 Dec 2018 07:41:34 +0100
From: mohamed.boucadair@orange.com
To: Klaus Hartke <hartke@projectcool.de>
CC: "core@ietf.org WG" <core@ietf.org>, "draft-ietf-core-hop-limit@ietf.org" <draft-ietf-core-hop-limit@ietf.org>
Thread-Topic: [core] draft-ietf-core-hop-limit-01
Thread-Index: AQHUkVePf7vrJIA96EubEQVyy8DF/qV5pHCQ///00oCAAQ0A0A==
Date: Wed, 12 Dec 2018 06:41:34 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E057537@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <C886421F-B826-427F-B3E6-8B21EC99A474@tzi.org> <CAAzbHvbHUc=o-xN2V9kUHpMumznPZ72w8+3D+QNUM=jPkO=0RA@mail.gmail.com> <CAAzbHvbPwRVg0wzZ3JcjyHqLvpXe9yNaCxtjD6MQp5Uj0J6vwA@mail.gmail.com> <CAAzbHvZHAk1idjfcQw0c4iUoL0MXzWhd=h5Kk13gJ+oR44Ld=w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAAzbHvZE+MjvUCLx5c0T-05mgWs=RmtkwOEntXGi9u5HEMt=5w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAAzbHva5__dPkE2s05fOayx-jf3EBpk3C8=jODKptg0J6q_Jbw@mail.gmail.com>
In-Reply-To: <CAAzbHva5__dPkE2s05fOayx-jf3EBpk3C8=jODKptg0J6q_Jbw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/GkXTRuAye_1qXCOWG2qZOE_FaX4>
Subject: Re: [core] draft-ietf-core-hop-limit-01
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: Wed, 12 Dec 2018 06:41:40 -0000
Hi Klaus, Please see inline. Cheers, Med > -----Message d'origine----- > De : Klaus Hartke [mailto:hartke@projectcool.de] > Envoyé : mardi 11 décembre 2018 16:30 > À : BOUCADAIR Mohamed TGI/OLN > Cc : core@ietf.org WG; draft-ietf-core-hop-limit@ietf.org > Objet : Re: [core] draft-ietf-core-hop-limit-01 > > Mohamed Boucadair wrote: > > Actually, given that we didn't receive a follow up from your side, we > thought you are OK with our replies at: > > > > https://mailarchive.ietf.org/arch/msg/core/8UKmm9VyQ9pGvndvfYZjQofHn8g > > Apologies for not getting back to you earlier. > > > in which we reminded the following: > > > > == > > * Is {elective, safe to forward, not part of the cache key} the right > choice? > > > > Response> Yes, will update hop-limit option. > > == > > As noted in > https://mailarchive.ietf.org/arch/msg/core/jE9AQZTDdx6nV0nRxxFDc2Ek8RA > , the outcome of the CoRE virtual interims was that the option should > be elective, safe-to-forward, and part of the cache. > > > > Here is some proposed text: > > > > > > OLD: > > > > > > The Hop-Limit option is safe to forward. That is, a CoAP proxy which > > > does not understand the Hop-Limit option should forward it on. > > > > > > NEW: > > > > > > The Hop-Limit option is safe to forward. That is, a CoAP proxy which > > > does not understand the Hop-Limit option should forward it on. The > > > option is also part of the cache in this case. That is, a CoAP proxy > > > which does not understand the Hop-Limit option must not use a stored > > > response unless the value of the Hop-Limit option in the presented > > > request is equal to the value of the Hop-Limit option in the request > > > used to obtain the stored response. > > > > > > > [Med] Isn't weird to have a requirement for a proxy which does not > understand the option? > > Yes. But it's not a new requirement, just what RFC 7252 specifies for > options classified as safe-to-forward and part-of-the-cache-key. Feel > free to clarify the proposed text to better reflect that. > [Med] What about the following NEW wording: The Hop-Limit option is safe to forward. That is, a CoAP proxy which does not understand the Hop-Limit option should forward it on. The option is also part of the cache. As such, a CoAP proxy must follow the recommendations in Section 5.7.1 of [RFC7252] for caching. > > > OLD: > > > > > > Otherwise, each intermediate proxy, which understands the Hop-Limit > > > option, involved in the handling of a CoAP message MUST decrement > > > the Hop-Limit option value by 1 prior to forwarding upstream if this > > > parameter exists. > > > > > > NEW: > > > > > > Otherwise, a CoAP proxy which understands the Hop-Limit option MUST > > > decrement the value of the option by 1 prior to forwarding it. A > > > CoAP proxy which understands the Hop-Limit option MUST NOT use a > > > stored response unless the value of the Hop-Limit option in the > > > presented request is less than or equal to the value of the > > > Hop-Limit option in the request used to obtain the stored response. > > > > [Med] Idem as above. Wouldn't be simple to maintain the design we have in - > 01? > > The option properties of safe-to-forward and part-of-the-cache-key > only apply to the case where an intermediary does not understand the > option, so the draft needs to be specific about the case when it is > understood. > [Med] Deal. > Best regards, > Klaus
- [core] Interim meeting at 2018-08-29, draft-bouca… Carsten Bormann
- Re: [core] Interim meeting at 2018-08-29, draft-b… Klaus Hartke
- Re: [core] Interim meeting at 2018-08-29, draft-b… Klaus Hartke
- [core] draft-ietf-core-hop-limit-00 Klaus Hartke
- Re: [core] draft-ietf-core-hop-limit-00 mohamed.boucadair
- [core] draft-ietf-core-hop-limit-01 Klaus Hartke
- Re: [core] draft-ietf-core-hop-limit-01 mohamed.boucadair
- Re: [core] draft-ietf-core-hop-limit-01 Klaus Hartke
- Re: [core] draft-ietf-core-hop-limit-01 mohamed.boucadair
- Re: [core] draft-ietf-core-hop-limit-01 Klaus Hartke
- Re: [core] draft-ietf-core-hop-limit-01 mohamed.boucadair