IETF Logo Mail Archive

Re: [core] draft-ietf-core-hop-limit-00

<mohamed.boucadair@orange.com> Mon, 05 November 2018 08:03 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 1C205130E50; Mon, 5 Nov 2018 00:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yTdYo2xgrkS1; Mon, 5 Nov 2018 00:03:41 -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 C5755130DD2; Mon, 5 Nov 2018 00:03:40 -0800 (PST)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 42pQDC0CnKz8tcV; Mon, 5 Nov 2018 09:03:39 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 42pQDB6Jf8z1xpN; Mon, 5 Nov 2018 09:03:38 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 09:03:38 +0100
From: mohamed.boucadair@orange.com
To: Klaus Hartke <hartke@projectcool.de>, "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-00
Thread-Index: AQHUdFQP5QIAzt/KB0qqQ5lsNmrhEqVA0DMA
Date: Mon, 05 Nov 2018 08:03:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E03CCED@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>
In-Reply-To: <CAAzbHvZHAk1idjfcQw0c4iUoL0MXzWhd=h5Kk13gJ+oR44Ld=w@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/8UKmm9VyQ9pGvndvfYZjQofHn8g>
Subject: Re: [core] draft-ietf-core-hop-limit-00
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: Mon, 05 Nov 2018 08:03:45 -0000

Hi Klaus, 

Thank you. FYI, we considered those comments when editing draft-ietf-core-hop-limit-00.

Early answers to these issues were made by Tiru at: https://mailarchive.ietf.org/arch/msg/core/giPOExiFuWDJdNtRY52g3dMkXAM. 

I do agree that (Allocating response code 5.06 for "Hop Limit Reached" is fine). We can suggest 5.06 when it comes to assigning TBA2 (during the IANA review process). 

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:core-bounces@ietf.org] De la part de Klaus Hartke
> Envoyé : dimanche 4 novembre 2018 16:35
> À : core@ietf.org WG; draft-ietf-core-hop-limit@ietf.org
> Objet : [core] draft-ietf-core-hop-limit-00
> 
> Hi authors of draft-ietf-core-hop-limit,
> 
> the draft was discussed a couple of times in the recent virtual
> interims of CoRE, but I'm not sure if the conclusions ever made it the
> mailing list.
> 
> We discussed the open questions from the August 29 virtual interim
> [1], with the following conclusions:
> 
> > * Would it be useful to have a general-purpose content format for
> > providing details of an alternate server, or is the information too
> > DOTS-specific?
> 
> In general, a general-purpose content format would be nice, but for
> now a DOTS-specific content format is fine.
> 
> > * Should a more specific media type than "application/cbor" be used?
> 
> Yes. (draft-ietf-dots-signal-channel now uses "application/dots+cbor".)
> 
> > * Is {elective, safe to forward, not part of the cache key} the right
> choice?
> > * Is {elective, safe to forward, part of the cache key} the better choice?
> 
> The option should be elective, safe-to-forward, and part of the cache
> key. If a cache understands the option, it should perform a
> greater-than-or-equals comparison instead of just checking for
> equality of the option value.
> 
> > * Is there a better number than 5.06? (HTTP 506 is: Variant Also
> > Negotiates [RFC2295])
> 
> Allocating response code 5.06 for "Hop Limit Reached" is fine, since
> "Variant Also Negotiates" is unlikely to make it into CoAP.
> 
> Best regards,
> Klaus
> 
> [1] https://www.ietf.org/mail-archive/web/core/current/msg09830.html
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

v2.23.0 | Report a Bug | By Email