Re: [core] Interim meeting at 2018-08-29, draft-boucadair-core-hop-limit
Klaus Hartke <hartke@projectcool.de> Wed, 29 August 2018 16:19 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 C40BE130EBF for <core@ietfa.amsl.com>; Wed, 29 Aug 2018 09:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=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 GrWatmBsy_cB for <core@ietfa.amsl.com>; Wed, 29 Aug 2018 09:19:41 -0700 (PDT)
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 EB0EE130ED9 for <core@ietf.org>; Wed, 29 Aug 2018 09:19:40 -0700 (PDT)
Received: from mail-qt0-f174.google.com ([209.85.216.174]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fv3By-00037X-W9; Wed, 29 Aug 2018 18:19:39 +0200
Received: by mail-qt0-f174.google.com with SMTP id m13-v6so6430921qth.1 for <core@ietf.org>; Wed, 29 Aug 2018 09:19:38 -0700 (PDT)
X-Gm-Message-State: APzg51AjCPaiSUKinyHLxNs3efOw4nSZToBtzVMt0BaftGqbIyUEAQE4 Gwsq/vLXD+rlv9H2vskwti1Y7Lmn5CM6n6yFyWY=
X-Google-Smtp-Source: ANB0Vdahk6z4RdO9lv3yeVU9xTIug+V31pmw19WLJAgTrfjfxEpuQdKCQPTODFmvm5Mg0vsDk93qWcJ26t6fO3S8JxA=
X-Received: by 2002:a0c:818b:: with SMTP id 11-v6mr7298313qvd.129.1535559577975; Wed, 29 Aug 2018 09:19:37 -0700 (PDT)
MIME-Version: 1.0
References: <C886421F-B826-427F-B3E6-8B21EC99A474@tzi.org> <CAAzbHvbHUc=o-xN2V9kUHpMumznPZ72w8+3D+QNUM=jPkO=0RA@mail.gmail.com>
In-Reply-To: <CAAzbHvbHUc=o-xN2V9kUHpMumznPZ72w8+3D+QNUM=jPkO=0RA@mail.gmail.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Wed, 29 Aug 2018 18:19:01 +0200
X-Gmail-Original-Message-ID: <CAAzbHvbPwRVg0wzZ3JcjyHqLvpXe9yNaCxtjD6MQp5Uj0J6vwA@mail.gmail.com>
Message-ID: <CAAzbHvbPwRVg0wzZ3JcjyHqLvpXe9yNaCxtjD6MQp5Uj0J6vwA@mail.gmail.com>
To: "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1535559581; bfb67d9d;
X-HE-SMSGID: 1fv3By-00037X-W9
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/CJE9PdWQ62-X-qu5ZpZV7OhQGOk>
Subject: Re: [core] Interim meeting at 2018-08-29, draft-boucadair-core-hop-limit
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: Wed, 29 Aug 2018 16:19:51 -0000
Sorry for the short notice on the move to Jitsi; I tried to chase down the WebEx details but wasn't successful. We had a short meeting discussing the DOTS work. Attendees: Jim Schaad Peter van der Stok Klaus Hartke Minutes: 1.) 3.00 (Alternate Server) response code draft-ietf-dots-signal-channel-22 proposed a new response code, 3.00 Alternate Server. Since CoAP doesn't have redirects, draft-ietf-dots-signal-channel-23 now uses the existing 5.03 (Service Unavailable) response code instead, which seems to work well for the DOTS case based on the DOTS mailing list discussion. As before, the response payload provides the details of the alternate server. Open questions: * 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? * Should a more specific media type than "application/cbor" be used? 2.) Hop-Limit option draft-boucadair-core-hop-limit-00 has been extracted from draft-ietf-dots-signal-channel-22 and is now referenced by draft-ietf-dots-signal-channel-23. The most important part to get right are probably the option properties. Right now, the draft proposes option number 2, which means the option is elective and not safe to forward. If there is an intermediary in the loop that does not recognize the option, this also means that that intermediary would remove the option before forwarding the request, so that the request would loop forever. (This might not happen in the DOTS case, where every intermediary is expected to support the Hop-Limit option, but it would happen in the general case.) The option should therefore proabably be safe to forward. The lowest available option number for {elective, safe to forward, not part of the cache key} currently is 92. Open questions: * Is {elective, safe to forward, not part of the cache key} the right choice? 3.) 5.06 (Hop Limit Reached) response code A 5.06 response is returned when the hop limit reaches 0. It seems to make sense to have a dedicated response code for this case, as intermediaries are expected to extend the information in the payload and having a dedicated response code would simplify recognizing the payloads to modify. It might be noteworthy to point out that, like all error responses, a 5.06 response is cacheable. This means that, if there is a caching intermediary on the path that does not understand the Hop-Limit option and if the option is not part of the cache key, then retrying a request with a larger hop limit might result in a 5.06 response that was cached for an earlier request with a lower hop limit. If this behavior is undesirable, then the option should probably be part of the cache key when unrecognized. The lowest available option number for {elective, safe to forward, part of the cache key} currently is 16. Open questions: * Is {elective, safe to forward, part of the cache key} the better choice? * Is there a better number than 5.06? (HTTP 506 is: Variant Also Negotiates [RFC2295]) 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