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

Klaus Hartke <hartke@projectcool.de> Sun, 04 November 2018 15:35 UTC

Return-Path: <hartke@projectcool.de>
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 4B580130E6A; Sun, 4 Nov 2018 07:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 61GsEsmk0JXf; Sun, 4 Nov 2018 07:35:35 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E14C130E2E; Sun, 4 Nov 2018 07:35:32 -0800 (PST)
Received: from mail-qk1-f169.google.com ([209.85.222.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJKR0-0001o7-RV; Sun, 04 Nov 2018 16:35:30 +0100
Received: by mail-qk1-f169.google.com with SMTP id r71so10771412qkr.10; Sun, 04 Nov 2018 07:35:30 -0800 (PST)
X-Gm-Message-State: AGRZ1gJ4AKZxcOIcRJyImvwhctHn3/mu7eJm3A+KPq84kArFYHNGKkN2 wtwWZ1nLSE/eYEtRhmcNqfBP8a/gCbz/891chNg=
X-Google-Smtp-Source: AJdET5fkKzGA351jsb5TUzWPSgDaqhDd2KxnQdNA9F2XTaB595I4g6mETC2f2QFfp+MWoWKKomlOqIwnVwNItKvAcxQ=
X-Received: by 2002:a37:455:: with SMTP id 82mr17540520qke.60.1541345729839; Sun, 04 Nov 2018 07:35:29 -0800 (PST)
MIME-Version: 1.0
References: <C886421F-B826-427F-B3E6-8B21EC99A474@tzi.org> <CAAzbHvbHUc=o-xN2V9kUHpMumznPZ72w8+3D+QNUM=jPkO=0RA@mail.gmail.com> <CAAzbHvbPwRVg0wzZ3JcjyHqLvpXe9yNaCxtjD6MQp5Uj0J6vwA@mail.gmail.com>
In-Reply-To: <CAAzbHvbPwRVg0wzZ3JcjyHqLvpXe9yNaCxtjD6MQp5Uj0J6vwA@mail.gmail.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Sun, 4 Nov 2018 16:34:58 +0100
X-Gmail-Original-Message-ID: <CAAzbHvZHAk1idjfcQw0c4iUoL0MXzWhd=h5Kk13gJ+oR44Ld=w@mail.gmail.com>
Message-ID: <CAAzbHvZHAk1idjfcQw0c4iUoL0MXzWhd=h5Kk13gJ+oR44Ld=w@mail.gmail.com>
To: "core@ietf.org WG" <core@ietf.org>, draft-ietf-core-hop-limit@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541345735; 9fe299d6;
X-HE-SMSGID: 1gJKR0-0001o7-RV
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jE9AQZTDdx6nV0nRxxFDc2Ek8RA>
Subject: [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: Sun, 04 Nov 2018 15:35:40 -0000

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