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