From nobody Sat Dec 1 11:05:53 2018 Return-Path: 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 E03E6130E2A for ; Sat, 1 Dec 2018 11:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 LmGXzlW2BNc5 for ; Sat, 1 Dec 2018 11:05:49 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6F1130E23 for ; Sat, 1 Dec 2018 11:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wB1J5e4l017962 for ; Sat, 1 Dec 2018 20:05:46 +0100 (CET) Received: from [192.168.217.114] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 436gh45w4kz1Bqf; Sat, 1 Dec 2018 20:05:40 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 565383938.168669-73fa25b2f43404c655f38025ce5502e1 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 1 Dec 2018 20:05:39 +0100 Message-Id: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CoRE @ IETF103: Summary and Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2018 19:05:52 -0000 The chairs have uploaded draft minutes for the two CoRE meetings at = IETF103: https://datatracker.ietf.org/meeting/103/materials/minutes-103-core As usual, this starts with a summary of what happened, followed by more = detailed minutes (which may not be quite as detailed this time as we had = problems with the Etherpad). Please send fixes and updates to core-chairs@ietf.org or to the mailing = list. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 5 04:18:02 2018 Return-Path: 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 AA44A130E77 for ; Wed, 5 Dec 2018 04:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 AZo0sVvVDbZ9 for ; Wed, 5 Dec 2018 04:17:48 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC15130E27 for ; Wed, 5 Dec 2018 04:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wB5CHdun001802 for ; Wed, 5 Dec 2018 13:17:44 +0100 (CET) Received: from client-0070.vpn.uni-bremen.de (client-0070.vpn.uni-bremen.de [134.102.107.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 438yRR1Cytz1Bqf; Wed, 5 Dec 2018 13:17:39 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 565705056.305339-08e93d9d199d68db7e2368d40dd44e0f Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 5 Dec 2018 13:17:38 +0100 Message-Id: <2E82C032-312F-4031-AE45-13D56868D8C3@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CoRE Virtual Interims between IETF103 and IETF104 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 12:18:01 -0000 Between IETF102 and IETF103, we had a number of WebEx calls (virtual = interim meetings) of the WG. In Bangkok, we said we were going to continue this, again maybe = alternately to the bi-weekly calls that the CBOR WG has. The CBOR WG = has now chosen their dates, which are Wednesday 1800Z to 1900Z, starting = from 2018-12-19. So we would be starting on 2018-12-26 (probably not), or then = 2019-01-09: Day: every other Wednesday beginning on 9 January Dates: 9, 23 Jan; 6, 20 Feb; 6, 20 March Time: 18:00 to 19:00 UTC=20 (10:00..11:00 PST except for 2019-03-20, 19:00..20:00 CET, =E2=80=A6) Since that would leave us without any interim this year, we are = proposing to add =E2=9E=94 Thu 2018-12-20, 1600Z..1700Z (08:00 PST, 17:00 CET, =E2=80=A6) as a single-use exception (probably with a focus on the resource = directory). All meetings will be on the IETF WebEx, details to be announced. Unless there is a major problem with this plan, we=E2=80=99ll now ask = the secretariat to announce it. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 5 07:07:14 2018 Return-Path: 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 21BD0126C01 for ; Wed, 5 Dec 2018 07:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com 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 21cG28gO411k for ; Wed, 5 Dec 2018 07:07:00 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 474E8126DBF for ; Wed, 5 Dec 2018 07:07:00 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id y1so13553636wmi.3 for ; Wed, 05 Dec 2018 07:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=20AldBhDnaKv6ISt6r+bat9yCKQSqH60poantmP/8pE=; b=0CINFj6zxrvBFMEJFE3OBrvdijK8qdU6Y+pLsecjR4ib5SxqHYe8KBuOHVDvkbApOs PpF4R+yFHRtIzCNk9MNADbEo5OxeUP459Mzt67wdoGqH1ue5kKoU1+SeeTDWqyUXpLKw s7vrVhkkRtjNvxm6FG3S1bKJ3ij3tAavAARIYDaNmUEhM2+OmMS2lHC922p164ipgZti HvI0kc7IZ/jsCqEhZyt330sUAoUVyUP5/i1d4TYQuRMgnVH2Qf4GNNr5UAPr8tH3H63d OKnvxoClG1Jg5+MJpfcBMOrv4p/v7yLhAofQlV5T/DkbwRjvBfSDZKiRy3obxpeGXi6F sVYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=20AldBhDnaKv6ISt6r+bat9yCKQSqH60poantmP/8pE=; b=tRaGi6OHtJ3R8Eq18wsSRJ69TGkrDl8dupSsAkrzOEVW3SaEKfdyU32S1ZJpEBgyNS ElsJgLErZS/HXVv4N/wGI9FnX0/tkkCCrCj35UOQA5WCT6j149Tr7kzYOxJE+N/8HEel rsIZzMseSFdbfoTE6fFgNnLRHnfqLAF/Xhxi+qcUTjvFvLefzokS6QubrORmoNZhjXmr 87okrkeS3DHXzyN3UnEY0D9EIFbuJyOJQHbvlfk9l/uRU9WAcWvwo5BolzeD9wOYkPlH a6VaedftXuo044Nvx8Ctt6Le63oXpPFnsmxfu4IY+gyCF/EYI+agOJvYQ3q03+oDdlaj KgeA== X-Gm-Message-State: AA+aEWYqD1MnrjhVlvXatXZcFxtfMzxdeW5fMZKVW7CKW2NH+h1RB6xt OfuIOiz9MfSHYzal3s1dlvTrmRJJk4v5TJL47kJInVrLaCOYRQ== X-Google-Smtp-Source: AFSGD/XvUmTzXlBu5gRzAzQDXH6VbhvlIJHf3gZ/HEw9dGPxPum833zMTtocs4sce/hBn1XPXjSDZC5Tdh31Xke8S/s= X-Received: by 2002:a1c:bb42:: with SMTP id l63mr15468277wmf.47.1544022418283; Wed, 05 Dec 2018 07:06:58 -0800 (PST) MIME-Version: 1.0 From: ivaylo petrov Date: Wed, 5 Dec 2018 16:06:32 +0100 Message-ID: To: core@ietf.org Cc: draft-ietf-core-sid@ietf.org Content-Type: multipart/alternative; boundary="000000000000c47b19057c47bb4d" Archived-At: Subject: [core] Discussion about draft-ietf-core-sid - IANA Specification required sub-registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 15:07:12 -0000 --000000000000c47b19057c47bb4d Content-Type: text/plain; charset="UTF-8" Dear all, We have been working on -05 of the draft-ietf-core-sid draft (the work-in-progress version is available here ). During the discussion, Michel Veillette proposed to add a new sub-section of the IANA considerations dedicated on the "Specification required" portion of the SIDs from "IANA SID Mega-Range Registry". This subsection specifies what will be the necessary information for each entry in the sub-registry. The proposed fields are: * The SID range entry point. * The SID range size. * The YANG module name. * The name of the standard organization * The specification identifier or URI Do you consider that we need to change something in that list? Best regards, Ivaylo Petrov P.S: I agree with the proposal and find the provided list sufficient. --000000000000c47b19057c47bb4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We have been working on -05 of the=C2=A0draft-ietf-core-sid draft (= the work-in-progress version is available here). During= the discussion, Michel=C2=A0Veillette proposed to add a new sub-section of= the IANA considerations dedicated on the "Specification required"= ; portion of the SIDs from "IANA SID Mega-Range Registry". This s= ubsection specifies what will be the necessary information for each entry i= n the sub-registry. The proposed fields are:

* The SID range entry point.
* The SID range size.
* The YANG module name.
*= The name of the standard organization
* The specification identifier or URI

Do you consider that we need to c= hange something in that list?

=
Best=C2=A0regards,
Ivaylo Petrov

P.S: I agree with the proposal and find the provided list= sufficient.

--000000000000c47b19057c47bb4d-- From nobody Thu Dec 6 06:19:48 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FA4124C04; Thu, 6 Dec 2018 06:19:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154410598605.3321.300399115927378553@ietfa.amsl.com> Date: Thu, 06 Dec 2018 06:19:46 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2018-12-20 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:19:47 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2018-12-20 from 16:00 to 17:00 UTC. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 104. The exact timing for the 2019 meetings is still to be decided; the present meeting is an exceptional date for 2018. Most likely main subject for the December meeting is the completion of the CoRE Resource Directory, draft-ietf-core-resource-directory. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the option of connection directly from your browser if your browser supports it. Information about remote participation: WebEx details will be sent to the mailing list before each call. From nobody Thu Dec 6 15:26:34 2018 Return-Path: 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 8AE2B130F35 for ; Thu, 6 Dec 2018 15:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SIFdu_eLl4jz for ; Thu, 6 Dec 2018 15:26:27 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69851130E5A for ; Thu, 6 Dec 2018 15:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wB6NQGpa018178 for ; Fri, 7 Dec 2018 00:26:21 +0100 (CET) Received: from [192.168.217.102] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 439sDS35lXz1Bqf; Fri, 7 Dec 2018 00:26:16 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 565831574.019737-932dbf9349cbd9383ca00cd4a894bd7d Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 7 Dec 2018 00:26:15 +0100 Message-Id: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] The CoAP protocol is the next big thing for DDoS attacks | ZDNet X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 23:26:33 -0000 CoAP is making some waves in a not so nice way: > = https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-= ddos-attacks/ = The potential for amplification in a UDP-based protocol of course is not = news. =20 We wrote about that in the RFC: https://tools.ietf.org/html/rfc7252#section-11.3 Still, the attention this is getting may be a good occasion to examine = how CoAP has been implemented by the platforms that make themselves = exploitable as DDoS amplifiers. (And the amplification issue will be exploited by outlets that claim = that it can be used to =E2=80=9Cremotely control IoT endpoints by = leveraging security issues=E2=80=9D, as e.g.: = https://futureiot.tech/top-iot-protocols-mqtt-coap-have-major-flaws-warns-= trend-micro/ Of course, if it becomes the fashion to make CoAP servers without = security available to the Internet at large, this might even be true.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Dec 6 21:27:26 2018 Return-Path: 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 CAF4912875B for ; Thu, 6 Dec 2018 21:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 SfbnS24PWaxp for ; Thu, 6 Dec 2018 21:27:23 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212E81277C8 for ; Thu, 6 Dec 2018 21:27:23 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Dec 2018 21:22:19 -0800 From: Jim Schaad To: Date: Thu, 6 Dec 2018 21:27:14 -0800 Message-ID: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdSN7JL4UBoA1h0PSFKeNXctutRlCw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 05:27:25 -0000 I am unsure how to get to the correct answer in this case. I do a multicast get to /.well-known/core The response comes back on a unicast address with relative URIs and without an anchor. I resolve the relative URI against ??? At this point I am supposed to resolve against the origin of the target URI, but from my understanding this would be the multicast address which is probably the wrong answer but may not be. It would depend if this is a really a multicast resource or is just a unicast resource. However I am not sure where the hint is going to be deep in my code that I should resolve against the return address rather than against the query address. I would know that using the return address is wrong in the event that the query went first to a proxy or gateway before going to the correct location. Jim From nobody Fri Dec 7 01:26:05 2018 Return-Path: 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 823F1128766 for ; Fri, 7 Dec 2018 00:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 d5UmMGkmTh_N for ; Fri, 7 Dec 2018 00:43:19 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4784124BF6 for ; Fri, 7 Dec 2018 00:43:19 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 330DCB81302; Fri, 7 Dec 2018 00:43:09 -0800 (PST) To: Akbar.Rahman@InterDigital.com, esko.dijk@philips.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: esko.dijk@iotconsultancy.nl, core@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181207084309.330DCB81302@rfc-editor.org> Date: Fri, 7 Dec 2018 00:43:09 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 07 Dec 2018 01:26:03 -0800 Subject: [core] [Editorial Errata Reported] RFC7390 (5569) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 08:43:22 -0000 The following errata report has been submitted for RFC7390, "Group Communication for the Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5569 -------------------------------------- Type: Editorial Reported by: Esko Dijk Section: 6.2 Original Text ------------- Esko Dijk ("Esko.Dijk@Philips.com") Corrected Text -------------- Esko Dijk ("Esko.Dijk@iotconsultancy.nl") Notes ----- Change of contact email address due to change of employer Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7390 (draft-ietf-core-groupcomm-25) -------------------------------------- Title : Group Communication for the Constrained Application Protocol (CoAP) Publication Date : October 2014 Author(s) : A. Rahman, Ed., E. Dijk, Ed. Category : EXPERIMENTAL Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Sat Dec 8 14:59:07 2018 Return-Path: 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 3D6F3130F46 for ; Sat, 8 Dec 2018 14:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 OKJ7T0aFDLg4 for ; Sat, 8 Dec 2018 14:59:03 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F761126CB6 for ; Sat, 8 Dec 2018 14:59:03 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 8 Dec 2018 14:53:59 -0800 From: Jim Schaad To: Date: Sat, 8 Dec 2018 14:58:54 -0800 Message-ID: <017201d48f49$99516560$cbf43020$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdSPSDJOPJliJThyS9uMRvYItj19qA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 22:59:05 -0000 I have been looking at implementing Anycast along side of Multicast. I am trying to figure out if Anycast is supposed to have the response on the Anycast address like Unicast does, or if it should be returned on a Unicast address. There is no clear guidance on this in RFC 7252. Among the things that RFC 7252 says is that coaps can be implemented using Anycast. However, given that the routing could be changed at any time, for example in the middle of the DTLS handshake or processing blocks, it makes any sense to return on the Anycast address. Is there anybody who has looked at this or wants to provide guidance? Jim From nobody Sat Dec 8 15:12:39 2018 Return-Path: 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 2DC98130F88 for ; Sat, 8 Dec 2018 15:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Q9EWcrPwPDYi for ; Sat, 8 Dec 2018 15:12:35 -0800 (PST) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7D0130F80 for ; Sat, 8 Dec 2018 15:12:35 -0800 (PST) Received: from [67.219.250.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.us-west-2.aws.symcld.net id 82/37-08749-1EF4C0C5; Sat, 08 Dec 2018 23:12:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRWlGSWpSXmKPExsVyvPxAhO5Df54 Ygx3r1Cz2vV3PbLF6+nc2ByaPjXOms3ksWfKTKYApijUzLym/IoE148CvuUwFb3kr9t1Mb2C8 yN3FyMUhJLCdUaLh1zamLkZODjYBS4kd72aygtgiAh4Ss5tWMoLYwgIqEs2/VrNDxFUlFi7bx AZhG0kc/d4D1ssCVPN/7UywOC9Q75Vr88DqhQTsJV4dPAcW5xRwkJi4oY8ZxGYUEJP4fmoNWC +zgLjErSfzwWwJAQGJJXvOM0PYohIvH/9jhagxkPjy/jYLhK0tsWzha2aIXYISJ2c+YZnAKDg LyahZSFpmIWmZhaRlASPLKkaLpKLM9IyS3MTMHF1DAwNdQ0MjXUNjQ11DI0u9xCrdRL3SYt3y 1OISXSO9xPJiveLK3OScFL281JJNjMAISClobtzBuGdF+iFGSQ4mJVHera+5YoT4kvJTKjMSi zPii0pzUosPMWpwcAh0PFl1gVGKJS8/L1VJgveGH0+MkGBRanpqRVpmDjBGYUolOHiURHg7Qd K8xQWJucWZ6RCpU4y6HG/m/pjBLAQ2Q0qclxEY8UICIEUZpXlwI2Dp4hKjrJQwLyMDA4MQT0F qUW5mCar8K0ZxDkYlYd6XIKt4MvNK4Da9AjqCCeiInC1MIEeUJCKkpBoYWR2Esm6YHpk//3Qt 46Uphl8uPWhsfxIQYcNqG7Y2IoB9V9alnZt9V5/kCOiesUC2NySTq/ed4baY/+KZNZN3Ni+Pi pj9MMS2yTr+/r6z296L17yzEuU8kN1mZXPJQTRGnM3N7GsVi0ZFMftphaWuXms5Tn9eOvdDF5 fG9/8NupXvJnSKSeYosRRnJBpqMRcVJwIA/PYJCxIDAAA= X-Env-Sender: thirou@CONVERGENCEWIRELESS.COM X-Msg-Ref: server-14.tower-327.messagelabs.com!1544310752!1418014!1 X-Originating-IP: [199.119.192.88] X-SYMC-ESS-Client-Auth: outbound-route-from=fail X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30635 invoked from network); 8 Dec 2018 23:12:33 -0000 Received: from out001.apptixemail.net (HELO out001.apptixemail.net) (199.119.192.88) by server-14.tower-327.messagelabs.com with AES256-SHA encrypted SMTP; 8 Dec 2018 23:12:33 -0000 Received: from AUSP01DAG0302.collaborationhost.net ([169.254.2.90]) by AUSP01MHUB19.collaborationhost.net ([10.2.69.121]) with mapi id 14.03.0195.001; Sat, 8 Dec 2018 17:11:04 -0600 From: "Timothy L. Hirou" To: Jim Schaad , "core@ietf.org" Thread-Topic: [core] Anycast and CoRE Thread-Index: AdSPSDJOPJliJThyS9uMRvYItj19qAAAxfVo Date: Sat, 8 Dec 2018 23:11:03 +0000 Message-ID: <20181208231238.6213717.23904.35672@convergencewireless.com> References: <017201d48f49$99516560$cbf43020$@augustcellars.com> In-Reply-To: <017201d48f49$99516560$cbf43020$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 23:12:39 -0000 Timothy L. Hirou Founder Convergence Wireless, Inc. 23 Corporate Plaza Drive, Suite 100 Newport Beach, CA 92660 (800) 519-9820 Office (949) 258-5592 Fax thirou@convergencewireless.com www.convergencewireless.com=FD Privileged And Confidential Communication This electronic transmission, and= any documents attached hereto, (a) are protected by the Electronic Communi= cations privacy Act (18 USC =A7=A7 2510- 2521),(b) may contain confidential= and or legally privileged information , and (c) are for the sole use of th= e intended recipient(s) named above. If you have received this electronic = message in error, please notify the sender and delete the electronic messag= e and destroy any physical copies of the information that may have been gen= erated. Any disclosure, copying, distribution, or use of the contents of th= e information received in error is strictly prohibited. Original Message From: Jim Schaad Sent: Saturday, December 8, 2018 2:57 PM To: core@ietf.org Subject: [core] Anycast and CoRE I have been looking at implementing Anycast along side of Multicast. I am trying to figure out if Anycast is supposed to have the response on the Anycast address like Unicast does, or if it should be returned on a Unicast address. There is no clear guidance on this in RFC 7252. Among the things that RFC 7252 says is that coaps can be implemented using Anycast. However= , given that the routing could be changed at any time, for example in the middle of the DTLS handshake or processing blocks, it makes any sense to return on the Anycast address. Is there anybody who has looked at this or wants to provide guidance? Jim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Dec 10 15:15:54 2018 Return-Path: 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 BBFEA13130D for ; Mon, 10 Dec 2018 15:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gu9aH9BrEfz9 for ; Mon, 10 Dec 2018 15:15:50 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 6DF3A13130F for ; Mon, 10 Dec 2018 15:15:50 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id 80so5698401pge.4 for ; Mon, 10 Dec 2018 15:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tTYkAgVJL+aiSdz/lDoN0AMB5OAC1F9BFJrVGZmNYjM=; b=TYr7uffpmoO5khJ7L21nO9xbOupuR2DQGhS7zC+5woYHpB+GfwKz8fiBRxfJqDji0W 6X3BXoFEj/jWHxHXd+bslYabXdquy/76z846C9jxG2qb/D4mSePOp/bL46HlpLAovkYr ohRaLycLACDs9pf3kaDcn/AzFVSkzKvtA+MJvkIaEDr00ZH5H6tfwtP4EUa0vmvBDIWr KjhOCtfkd6d+2+oU0d3Xsxtpo3vPD7e+O8ve67W5s5Vg3X5joTsHPFKwcgYKtXeXeSlq qUUMIc9FEjfZjvJjxJx7nW+sfWP7TvSs1D7eNlLrH3AcaY3YyRWa3icYZrd1+jqsozMY gPcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tTYkAgVJL+aiSdz/lDoN0AMB5OAC1F9BFJrVGZmNYjM=; b=l5rxEAO88C1z84JO5ULqNwFvSSQOsK4j0JRdSTKeDNO1oeZ4Te/LCxvO7Qxc4HcjPX vtYumTSJQpoXm7C3vRj7shXzjYH/9JOUuyScrUBh3GBjk8VRu8vmG4kG6CeDr4sKGElk gjJ0Y9ZnzbTDpK/ejvmwMKa0Oe1GlFD4DJ9vR3er7wAr2qflD4CPndNr//lNl4qSntfY is41zFwSNoJ42/4d5HyN2pKdoCebK5NMYJuvr9IjNVm+SsONvpzh+jadFaCKuaLkvA+N 4COVOYtHUUDBLP7sKrVYAFMB0DljgwIYf2azgAEbpDJ9QMN8xch+TDRq5E+TuvKPK9om gWhQ== X-Gm-Message-State: AA+aEWZaona/xJbdgiB2HPoq+qAFRtfdh+ANM6U4knF455VoIHjBU8wN gRxUjsvc2n8XFJ0J47GiMpUSePX7 X-Google-Smtp-Source: AFSGD/WpIrl9vhXrTCbspZIkaj3jB9Pnf61nYYlQV/yHpPNwcKi9PXTOoqYf/UOtMhCGqOkG4przBQ== X-Received: by 2002:a65:6094:: with SMTP id t20mr12434985pgu.285.1544483749574; Mon, 10 Dec 2018 15:15:49 -0800 (PST) Received: from ?IPv6:2601:646:8d00:1cc3:a117:18de:5a85:6646? ([2601:646:8d00:1cc3:a117:18de:5a85:6646]) by smtp.gmail.com with ESMTPSA id g28sm21266225pfd.100.2018.12.10.15.15.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Dec 2018 15:15:48 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CBD79E02-9B6E-42BE-8D9E-C8F37C2A8CF7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Robert Quattlebaum In-Reply-To: Date: Mon, 10 Dec 2018 15:15:41 -0800 Message-Id: <10BF243B-C808-4217-990A-D93C4D17A718@gmail.com> References: To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] The CoAP protocol is the next big thing for DDoS attacks | ZDNet X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:15:53 -0000 --Apple-Mail=_CBD79E02-9B6E-42BE-8D9E-C8F37C2A8CF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If NoSec modes become (remain?) popular, it may be warranted to develop = some sort of stateless handshake to be used only for NoSec modes, in = order to nullify the amplification factor. What I'm imagining would look = something like this: A client sends a normal request to a server. The server responds with "4.01 UNAUTHORIZED" along with a single new = required/no-cache-key option "Handshake" with a two-byte value which is = opaque to the client. The response would have no token or body, in order = to make the response as small as possible. The client re-sends the request to the server with the same "Handshake" = option and value. The server verifies the handshake value is correct for the client's = ip/port and handles the request normally. Note that in the above scenario, the handshake happens per-hop rather = than end-to-end. This seems like it would be fairly easy to implement. It wouldn't reduce = the packet count, but it would eliminate the amplification factor. = Client implementations would remain fully compatible with servers that = don't implement this handshake. Thoughts? -- RQ > On Dec 6, 2018, at 3:26 PM, Carsten Bormann wrote: >=20 > CoAP is making some waves in a not so nice way: >=20 >> = https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-= ddos-attacks/ = >=20 > The potential for amplification in a UDP-based protocol of course is = not news. =20 > We wrote about that in the RFC: >=20 > https://tools.ietf.org/html/rfc7252#section-11.3 >=20 > Still, the attention this is getting may be a good occasion to examine = how CoAP has been implemented by the platforms that make themselves = exploitable as DDoS amplifiers. >=20 > (And the amplification issue will be exploited by outlets that claim = that it can be used to =E2=80=9Cremotely control IoT endpoints by = leveraging security issues=E2=80=9D, as e.g.: > = https://futureiot.tech/top-iot-protocols-mqtt-coap-have-major-flaws-warns-= trend-micro/ > Of course, if it becomes the fashion to make CoAP servers without = security available to the Internet at large, this might even be true.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_CBD79E02-9B6E-42BE-8D9E-C8F37C2A8CF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = NoSec modes become (remain?) popular, it may be warranted to develop = some sort of stateless handshake to be used only for NoSec modes, in = order to nullify the amplification factor. What I'm imagining would look = something like this:
  1. A = client sends a normal request to a server.
  2. The server = responds with "4.01 UNAUTHORIZED" along with a single new = required/no-cache-key option "Handshake" with a two-byte value which is = opaque to the client. The response would have no token or body, in order = to make the response as small as possible.
  3. The client = re-sends the request to the server with the same "Handshake" option and = value.
  4. The server verifies the handshake value is = correct for the client's ip/port and handles the request = normally.
Note that in the above scenario, the = handshake happens per-hop rather than end-to-end.

This seems like it would = be fairly easy to implement. It wouldn't reduce the packet count, but it = would eliminate the amplification factor. Client implementations would = remain fully compatible with servers that don't implement this = handshake.

Thoughts?

-- RQ

On = Dec 6, 2018, at 3:26 PM, Carsten Bormann <cabo@tzi.org> = wrote:

CoAP is making some waves in a not so nice way:

https://www.zdnet.com/article/the-coap-protocol-is-the-next-big= -thing-for-ddos-attacks/ <https://www.zdnet.com/article/the-coap-protocol-is-the-next-big= -thing-for-ddos-attacks/>

The potential for amplification in a UDP-based protocol of = course is not news.  
We wrote about that in the = RFC:

https://tools.ietf.org/html/rfc7252#section-11.3

Still, the attention this is getting may be a = good occasion to examine how CoAP has been implemented by the platforms = that make themselves exploitable as DDoS amplifiers.

(And the amplification issue will be exploited by outlets = that claim that it can be used to =E2=80=9Cremotely control IoT = endpoints by leveraging security issues=E2=80=9D, as e.g.:
https://futureiot.tech/top-iot-protocols-mqtt-coap-have-major-f= laws-warns-trend-micro/
Of course, if it becomes the = fashion to make CoAP servers without security available to the Internet = at large, this might even be true.)

Gr=C3=BC=C3= =9Fe, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_CBD79E02-9B6E-42BE-8D9E-C8F37C2A8CF7-- From nobody Mon Dec 10 15:44:35 2018 Return-Path: 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 08183129C6B for ; Mon, 10 Dec 2018 15:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mnkrX4FvvwzQ for ; Mon, 10 Dec 2018 15:44:32 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A060129C6A for ; Mon, 10 Dec 2018 15:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBANiNVR002032; Tue, 11 Dec 2018 00:44:28 +0100 (CET) Received: from [192.168.217.102] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43DKRV6VpYz1Bqf; Tue, 11 Dec 2018 00:44:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <10BF243B-C808-4217-990A-D93C4D17A718@gmail.com> Date: Tue, 11 Dec 2018 00:44:21 +0100 Cc: core X-Mao-Original-Outgoing-Id: 566178260.3614891-d77c1278c252516e0ac6b90fc6401b5c Content-Transfer-Encoding: quoted-printable Message-Id: <1B757039-3283-4A41-8147-173E901C5F6C@tzi.org> References: <10BF243B-C808-4217-990A-D93C4D17A718@gmail.com> To: Robert Quattlebaum X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] The CoAP protocol is the next big thing for DDoS attacks | ZDNet X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:44:34 -0000 On Dec 11, 2018, at 00:15, Robert Quattlebaum = wrote: >=20 > option "Handshake"=20 Hi Robert, you might want to have a look at = https://tools.ietf.org/html/draft-ietf-core-echo-request-tag#section-2 which defines a similar =E2=80=9CEcho=E2=80=9D option. This could indeed be used for validating IP address ownership of the = requester. I still think that https://tools.ietf.org/html/rfc7252#section-11.3 tells a server implementer what to do, but if that cannot be done, = =E2=80=9CEcho=E2=80=9D may be another way to reduce amplification = factors. Of course, it means that the state machine of all clients now = needs to be more complicated. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 10 18:23:02 2018 Return-Path: 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 AF6FE126CC7; Mon, 10 Dec 2018 18:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 0_g0RAH0k59p; Mon, 10 Dec 2018 18:22:58 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55036128D68; Mon, 10 Dec 2018 18:22:58 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Dec 2018 18:17:53 -0800 From: Jim Schaad To: CC: Date: Mon, 10 Dec 2018 18:22:48 -0800 Message-ID: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdSQ3PYM1bz/vMt1Qp6I1pzWuFt+hw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 02:23:01 -0000 * In section 5.3, I don't understand why the rule exists that if the attribute values are different then the location of the registration needs to be changed. It seems that this could lead to some interesting conflicts in behavior depending on what messages are used. For example (content omitted for clarity): POST /rd?ep=e1&foo=over Res: 2.01 Created Location-Path: /rd/4001 POST /rd?ep=e1&foo=under Res: 2.01 Created Location-Path: /rd/4002 As opposed to: POST /rd?ep=e1&foo=over Res: 2.01 Created Location-Path: /rd/4001 POST /rd/4001?foo=under Res: 2.01 Changed * In Section 5.3 - What is the correct behavior if the RD is configured to recognize an endpoint, but the endpoint supplies a different name? Is this an error or does one of them override? * In section 5.3.1 - I assume it would be an error to include the base attribute - perhaps this should be explicit? * In section 5.3.1 - When doing simple registration, I do not believe that it should be a requirement that the result MUST be returned prior to doing the query. This allows for situations where the EP believes itself to be registered when in fact is is not because the query to /.well-known/core failed for some reason. Additionally, the EP no longer has a cue as to when it can shut down because it does not know how long it will be before the RD performs the query operation. If this is done inline then both of these situations are addressed. ( I have previously registered this complaint. Also this is how my implementation works.) * In section 5.3.1 - A valid response code might be 4.XX - method not supported if this functionality is disabled. I am not sure what the "or is empty" means for the 4.04 response code. Which one is empty, the RD or the EP? * In section 5.3.1 - Is the RD responsible for dealing with resource-link items which would not make sense by doing full resolutions on everything or re-writing them? * In section 5.4.1 - s/lt,con/lt,base/ * In section 5.4.1 - Description of 4.04 failure - I think this should be 'may have been garbage collected' as I believe from previous text that one should be able to refresh an expired registration. * In section 6.4 - The example is missing the rt="core.rd-ep" attribute. It appears to be required from the second paragraph. * In section 6.4 - Can you give an example of a "Links to endpoints"? The only one that I can think of is 'base'. * General - Should there be a value for lt which means infinite? Jim From nobody Tue Dec 11 00:59:05 2018 Return-Path: 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 479FE12F18C; Tue, 11 Dec 2018 00:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 CTAzrVA_6wY9; Tue, 11 Dec 2018 00:59:02 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900B312F1A5; Tue, 11 Dec 2018 00:59:02 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 881D152AA; Tue, 11 Dec 2018 08:59:01 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:152:355:379:582:599:960:962:967:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1534:1541:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2528:2559:2562:2692:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3872:3874:4321:4362:5007:6117:6119:6261:6657:6659:6678:7875:7903:8603:10004:10400:10848:11232:11657:11658:11914:12740:12895:13071:13139:13439:13972:14093:14096:14180:14721:21060:21080:21433:21451:21611:21627:30025:30041:30054:30076, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: nerve65_6bda4bc4a8d22 X-Filterd-Recvd-Size: 4032 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf05.hostedemail.com (Postfix) with ESMTPA; Tue, 11 Dec 2018 08:59:01 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_673203570d2710b421650e9f54087f24" Date: Tue, 11 Dec 2018 09:59:00 +0100 From: Peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 08:59:04 -0000 --=_673203570d2710b421650e9f54087f24 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Jim, thanks, for the questions. One explanation for one question. Jim Schaad schreef op 2018-12-11 03:22: > * In section 5.3, I don't understand why the rule exists that if the > attribute values are different then the location of the registration needs > to be changed. It seems that this could lead to some interesting conflicts > in behavior depending on what messages are used. For example (content > omitted for clarity): > > POST /rd?ep=e1&foo=over > > Res: 2.01 Created > Location-Path: /rd/4001 > > POST /rd?ep=e1&foo=under > > Res: 2.01 Created > Location-Path: /rd/4002 > > As opposed to: > > POST /rd?ep=e1&foo=over > > Res: 2.01 Created > Location-Path: /rd/4001 > > POST /rd/4001?foo=under > > Res: 2.01 Changed > > > The feeling was that a first ep having done the earlier registration /rd/4001 > should not be able to manipulate the 2nd registration by a 2nd ep, by removing /rd/4001 > and having a registration /rd/4002 only known to 2nd ep. > --=_673203570d2710b421650e9f54087f24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Jim,

thanks, for the questions.
One explanation for one = question.

Jim Schaad schreef op 2018-12-11 03:22:

= *  In section 5.3, I don't understand why the rule exists that if the<= br /> attribute values are different then the location of the registration = needs
to be changed.   It seems that this could lead to som= e interesting conflicts
in behavior depending on what messages are us= ed.  For example  (content
omitted for clarity):

POST /rd?ep=3De1&foo=3Dover

Res: 2.01 Created
Locat= ion-Path: /rd/4001

POST /rd?ep=3De1&foo=3Dunder

= Res: 2.01 Created
Location-Path: /rd/4002

As opposed to:=

POST /rd?ep=3De1&foo=3Dover

Res: 2.01 Created<= br /> Location-Path: /rd/4001

POST /rd/4001?foo=3Dunder
Res: 2.01 Changed

<pvds>
The feeling was that a = first ep having done the earlier registration /rd/4001 
should no= t be able to manipulate the 2nd registration by a 2nd ep, by removing /rd/4= 001
and having a registration /rd/4002 only known to 2nd ep.
<= /pvds>





--=_673203570d2710b421650e9f54087f24-- From nobody Tue Dec 11 05:43:47 2018 Return-Path: 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 8B3D41200B3; Tue, 11 Dec 2018 05:43:45 -0800 (PST) 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 R9oCMkYSGIcy; Tue, 11 Dec 2018 05:43:44 -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 0D6F6126BED; Tue, 11 Dec 2018 05:43:43 -0800 (PST) Received: from mail-qk1-f180.google.com ([209.85.222.180]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gWiK4-0006hH-83; Tue, 11 Dec 2018 14:43:40 +0100 Received: by mail-qk1-f180.google.com with SMTP id 131so8574713qkd.4; Tue, 11 Dec 2018 05:43:40 -0800 (PST) X-Gm-Message-State: AA+aEWbeR/tZfIlAvaQML1ZDtTSjtnTwzmwlXWWrz0B3oizaHJrQjrBw Lkz9O/LT3G60wPDq1ewSUrvCFLytmsUQ4spZV6I= X-Google-Smtp-Source: AFSGD/VCN36gUjURxc5kn5aTCpAoFNHMshvJjuDI7czogP3yP42rlFFiUrE/fsPiQn0c++q1MSQtmnyPIq03NL4ikaI= X-Received: by 2002:a37:a5d1:: with SMTP id o200mr14294616qke.328.1544535819143; Tue, 11 Dec 2018 05:43:39 -0800 (PST) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Klaus Hartke Date: Tue, 11 Dec 2018 14:43:03 +0100 X-Gmail-Original-Message-ID: Message-ID: To: draft-ietf-core-hop-limit@ietf.org Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1544535824; 851de493; X-HE-SMSGID: 1gWiK4-0006hH-83 Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 13:43:45 -0000 Hi draft-ietf-core-hop-limit authors, I have taken a brief look at -01. It seems the draft still doesn't reflect the latest discussions relating to caching. 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. 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. OLD: +--------+---+---+---+---+------------------+-----------+ | Number | C | U | N | R | Name | Reference | +--------+---+---+---+---+------------------+-----------+ | TBA2 | | | x | | Hop-Limit | [RFCXXXX] | +--------+---+---+---+---+------------------+-----------+ NEW: +--------+---+---+---+---+------------------+-----------+ | Number | C | U | N | R | Name | Reference | +--------+---+---+---+---+------------------+-----------+ | TBA2 | | | | | Hop-Limit | [RFCXXXX] | +--------+---+---+---+---+------------------+-----------+ Best regards, Klaus From nobody Tue Dec 11 07:18:30 2018 Return-Path: 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 5C3F9127333; Tue, 11 Dec 2018 07:18:28 -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 4e5_KxB91QzN; Tue, 11 Dec 2018 07:18:26 -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 55FF11271FF; Tue, 11 Dec 2018 07:18:26 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 43Dk9D53Zgz7xN5; Tue, 11 Dec 2018 16:18:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 43Dk9D3smdz3wbH; Tue, 11 Dec 2018 16:18:24 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0415.000; Tue, 11 Dec 2018 16:18:24 +0100 From: To: Klaus Hartke CC: "core@ietf.org WG" , "draft-ietf-core-hop-limit@ietf.org" Thread-Topic: [core] draft-ietf-core-hop-limit-01 Thread-Index: AQHUkVePf7vrJIA96EubEQVyy8DF/qV5pHCQ Date: Tue, 11 Dec 2018 15:18:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 15:18:28 -0000 Hi Klaus,=20 Actually, given that we didn't receive a follow up from your side, we thoug= ht you are OK with our replies at:=20 https://mailarchive.ietf.org/arch/msg/core/8UKmm9VyQ9pGvndvfYZjQofHn8g=20 in which we reminded the following: =3D=3D * Is {elective, safe to forward, not part of the cache key} the right choic= e? Response> Yes, will update hop-limit option. =3D=3D Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de Klaus Hartke > Envoy=E9=A0: mardi 11 d=E9cembre 2018 14:43 > =C0=A0: draft-ietf-core-hop-limit@ietf.org > Cc=A0: core@ietf.org WG > Objet=A0: [core] draft-ietf-core-hop-limit-01 >=20 > Hi draft-ietf-core-hop-limit authors, >=20 > I have taken a brief look at -01. It seems the draft still doesn't > reflect the latest discussions relating to caching. >=20 > Here is some proposed text: >=20 > OLD: >=20 > 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. >=20 > NEW: >=20 > 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. >=20 [Med] Isn't weird to have a requirement for a proxy which does not understa= nd the option? =20 > OLD: >=20 > 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. >=20 > NEW: >=20 > 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? >=20 > OLD: >=20 > +--------+---+---+---+---+------------------+-----------+ > | Number | C | U | N | R | Name | Reference | > +--------+---+---+---+---+------------------+-----------+ > | TBA2 | | | x | | Hop-Limit | [RFCXXXX] | > +--------+---+---+---+---+------------------+-----------+ >=20 > NEW: >=20 > +--------+---+---+---+---+------------------+-----------+ > | Number | C | U | N | R | Name | Reference | > +--------+---+---+---+---+------------------+-----------+ > | TBA2 | | | | | Hop-Limit | [RFCXXXX] | > +--------+---+---+---+---+------------------+-----------+ >=20 > Best regards, > Klaus >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Dec 11 07:30:36 2018 Return-Path: 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 AB9DF130DEE; Tue, 11 Dec 2018 07:30:32 -0800 (PST) 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 KF1vVPu5sPuh; Tue, 11 Dec 2018 07:30:30 -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 E2035130E0F; Tue, 11 Dec 2018 07:30:29 -0800 (PST) Received: from mail-qk1-f181.google.com ([209.85.222.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gWjzO-0003ur-Ts; Tue, 11 Dec 2018 16:30:27 +0100 Received: by mail-qk1-f181.google.com with SMTP id y78so8778102qka.12; Tue, 11 Dec 2018 07:30:26 -0800 (PST) X-Gm-Message-State: AA+aEWa/9ne6IJpJB4nhxkG0RXRxd4rq0GNL99ybXNWps1QYv18OI2Ux gbw7OhirXE7Tr0P7HW/XENzEjxjO2BZKHqwirL0= X-Google-Smtp-Source: AFSGD/VzWBJha3C4pHWjvmLQ5xntdERmD/Q1NRhrzXutvu/D3tVDzLhUeM3392EE0MBSuayxioCjz0NMOTTt605a0vs= X-Received: by 2002:a37:455:: with SMTP id 82mr15033719qke.60.1544542225810; Tue, 11 Dec 2018 07:30:25 -0800 (PST) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Klaus Hartke Date: Tue, 11 Dec 2018 16:29:49 +0100 X-Gmail-Original-Message-ID: Message-ID: To: mohamed.boucadair@orange.com Cc: "core@ietf.org WG" , draft-ietf-core-hop-limit@ietf.org Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1544542229; 6fdb8e19; X-HE-SMSGID: 1gWjzO-0003ur-Ts Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 15:30:35 -0000 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. > > 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. Best regards, Klaus From nobody Tue Dec 11 09:41:35 2018 Return-Path: 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 14AD6130EC1; Tue, 11 Dec 2018 09:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 4Z10GbHZ_1WB; Tue, 11 Dec 2018 09:41:32 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B1E130EB8; Tue, 11 Dec 2018 09:41:31 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 09:36:04 -0800 From: Jim Schaad To: CC: , References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> In-Reply-To: Date: Tue, 11 Dec 2018 09:41:01 -0800 Message-ID: <035e01d49178$b08a3e60$119ebb20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_035F_01D49135.A2688500" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMTxjR7df64heLt4gs0blLr1Spp0AE6nRS3ovGPqpA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 17:41:34 -0000 ------=_NextPart_000_035F_01D49135.A2688500 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Peter van der Stok =20 Sent: Tuesday, December 11, 2018 12:59 AM To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org Subject: Re: Questions and comments against the github version =20 Hi Jim, thanks, for the questions. One explanation for one question. Jim Schaad schreef op 2018-12-11 03:22: * In section 5.3, I don't understand why the rule exists that if the attribute values are different then the location of the registration = needs to be changed. It seems that this could lead to some interesting = conflicts in behavior depending on what messages are used. For example (content omitted for clarity): POST /rd?ep=3De1&foo=3Dover Res: 2.01 Created Location-Path: /rd/4001 POST /rd?ep=3De1&foo=3Dunder Res: 2.01 Created Location-Path: /rd/4002 As opposed to: POST /rd?ep=3De1&foo=3Dover Res: 2.01 Created Location-Path: /rd/4001 POST /rd/4001?foo=3Dunder Res: 2.01 Changed The feeling was that a first ep having done the earlier registration = /rd/4001=20 should not be able to manipulate the 2nd registration by a 2nd ep, by = removing /rd/4001 and having a registration /rd/4002 only known to 2nd ep. [JLS] The only problem with this is that the query of endpoints needs to = be changed so that the endpoint locations are not returned. Once the = query is done then the location is known to a 2nd ep. ------=_NextPart_000_035F_01D49135.A2688500 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Peter = van der Stok <stokcons@bbhmail.nl>
Sent: Tuesday, = December 11, 2018 12:59 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-core-resource-directory@ietf.org; = core@ietf.org
Subject: Re: Questions and comments against the = github version

 

Hi = Jim,

thanks, for the questions.
One explanation for one = question.

Jim Schaad = schreef op 2018-12-11 03:22:

*  In section = 5.3, I don't understand why the rule exists that if the
attribute = values are different then the location of the registration needs
to = be changed.   It seems that this could lead to some = interesting conflicts
in behavior depending on what messages are = used.  For example  (content
omitted for = clarity):

POST /rd?ep=3De1&foo=3Dover

Res: 2.01 = Created
Location-Path: /rd/4001

POST = /rd?ep=3De1&foo=3Dunder

Res: 2.01 Created
Location-Path: = /rd/4002

As opposed to:

POST = /rd?ep=3De1&foo=3Dover

Res: 2.01 Created
Location-Path: = /rd/4001

POST /rd/4001?foo=3Dunder

Res: 2.01 = Changed

<pvds>
The feeling was that a first ep having = done the earlier registration /rd/4001 
should not be able to = manipulate the 2nd registration by a 2nd ep, by removing /rd/4001
and = having a registration /rd/4002 only known to 2nd = ep.
</pvds>

[JLS] The only = problem with this is that the query of endpoints needs to be changed so = that the endpoint locations are not returned.=C2=A0 Once the query is = done then the location is known to a 2nd = ep.


------=_NextPart_000_035F_01D49135.A2688500-- From nobody Tue Dec 11 22:41:41 2018 Return-Path: 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: To: Klaus Hartke CC: "core@ietf.org WG" , "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: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 06:41:40 -0000 SGkgS2xhdXMsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBLbGF1cyBIYXJ0a2UgW21haWx0bzpo YXJ0a2VAcHJvamVjdGNvb2wuZGVdDQo+IEVudm95w6nCoDogbWFyZGkgMTEgZMOpY2VtYnJlIDIw MTggMTY6MzANCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiBDY8KgOiBjb3Jl QGlldGYub3JnIFdHOyBkcmFmdC1pZXRmLWNvcmUtaG9wLWxpbWl0QGlldGYub3JnDQo+IE9iamV0 wqA6IFJlOiBbY29yZV0gZHJhZnQtaWV0Zi1jb3JlLWhvcC1saW1pdC0wMQ0KPiANCj4gTW9oYW1l ZCBCb3VjYWRhaXIgd3JvdGU6DQo+ID4gQWN0dWFsbHksIGdpdmVuIHRoYXQgd2UgZGlkbid0IHJl Y2VpdmUgYSBmb2xsb3cgdXAgZnJvbSB5b3VyIHNpZGUsIHdlDQo+IHRob3VnaHQgeW91IGFyZSBP SyB3aXRoIG91ciByZXBsaWVzIGF0Og0KPiA+DQo+ID4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9jb3JlLzhVS21tOVZ5UTlwR3ZuZHZmWVpqUW9mSG44Zw0KPiANCj4gQXBv bG9naWVzIGZvciBub3QgZ2V0dGluZyBiYWNrIHRvIHlvdSBlYXJsaWVyLg0KPiANCj4gPiBpbiB3 aGljaCB3ZSByZW1pbmRlZCB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gPT0NCj4gPiAqIElzIHtl bGVjdGl2ZSwgc2FmZSB0byBmb3J3YXJkLCBub3QgcGFydCBvZiB0aGUgY2FjaGUga2V5fSB0aGUg cmlnaHQNCj4gY2hvaWNlPw0KPiA+DQo+ID4gUmVzcG9uc2U+IFllcywgd2lsbCB1cGRhdGUgaG9w LWxpbWl0IG9wdGlvbi4NCj4gPiA9PQ0KPiANCj4gQXMgbm90ZWQgaW4NCj4gaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3JlL2pFOUFRWlREZHg2blYwblJ4eEZEYzJFazhS QQ0KPiAsIHRoZSBvdXRjb21lIG9mIHRoZSBDb1JFIHZpcnR1YWwgaW50ZXJpbXMgd2FzIHRoYXQg dGhlIG9wdGlvbiBzaG91bGQNCj4gYmUgZWxlY3RpdmUsIHNhZmUtdG8tZm9yd2FyZCwgYW5kIHBh cnQgb2YgdGhlIGNhY2hlLg0KPiANCj4gPiA+IEhlcmUgaXMgc29tZSBwcm9wb3NlZCB0ZXh0Og0K PiA+ID4NCj4gPiA+IE9MRDoNCj4gPiA+DQo+ID4gPiAgICBUaGUgSG9wLUxpbWl0IG9wdGlvbiBp cyBzYWZlIHRvIGZvcndhcmQuIFRoYXQgaXMsIGEgQ29BUCBwcm94eSB3aGljaA0KPiA+ID4gICAg ZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgSG9wLUxpbWl0IG9wdGlvbiBzaG91bGQgZm9yd2FyZCBp dCBvbi4NCj4gPiA+DQo+ID4gPiBORVc6DQo+ID4gPg0KPiA+ID4gICAgVGhlIEhvcC1MaW1pdCBv cHRpb24gaXMgc2FmZSB0byBmb3J3YXJkLiBUaGF0IGlzLCBhIENvQVAgcHJveHkgd2hpY2gNCj4g PiA+ICAgIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIEhvcC1MaW1pdCBvcHRpb24gc2hvdWxkIGZv cndhcmQgaXQgb24uIFRoZQ0KPiA+ID4gICAgb3B0aW9uIGlzIGFsc28gcGFydCBvZiB0aGUgY2Fj aGUgaW4gdGhpcyBjYXNlLiBUaGF0IGlzLCBhIENvQVAgcHJveHkNCj4gPiA+ICAgIHdoaWNoIGRv ZXMgbm90IHVuZGVyc3RhbmQgdGhlIEhvcC1MaW1pdCBvcHRpb24gbXVzdCBub3QgdXNlIGEgc3Rv cmVkDQo+ID4gPiAgICByZXNwb25zZSB1bmxlc3MgdGhlIHZhbHVlIG9mIHRoZSBIb3AtTGltaXQg b3B0aW9uIGluIHRoZSBwcmVzZW50ZWQNCj4gPiA+ICAgIHJlcXVlc3QgaXMgZXF1YWwgdG8gdGhl IHZhbHVlIG9mIHRoZSBIb3AtTGltaXQgb3B0aW9uIGluIHRoZSByZXF1ZXN0DQo+ID4gPiAgICB1 c2VkIHRvIG9idGFpbiB0aGUgc3RvcmVkIHJlc3BvbnNlLg0KPiA+ID4NCj4gPg0KPiA+IFtNZWRd IElzbid0IHdlaXJkIHRvIGhhdmUgYSByZXF1aXJlbWVudCBmb3IgYSBwcm94eSB3aGljaCBkb2Vz IG5vdA0KPiB1bmRlcnN0YW5kIHRoZSBvcHRpb24/DQo+IA0KPiBZZXMuIEJ1dCBpdCdzIG5vdCBh IG5ldyByZXF1aXJlbWVudCwganVzdCB3aGF0IFJGQyA3MjUyIHNwZWNpZmllcyBmb3INCj4gb3B0 aW9ucyBjbGFzc2lmaWVkIGFzIHNhZmUtdG8tZm9yd2FyZCBhbmQgcGFydC1vZi10aGUtY2FjaGUt a2V5LiBGZWVsDQo+IGZyZWUgdG8gY2xhcmlmeSB0aGUgcHJvcG9zZWQgdGV4dCB0byBiZXR0ZXIg cmVmbGVjdCB0aGF0Lg0KPiANCg0KW01lZF0gV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIE5FVyB3 b3JkaW5nOg0KDQogICBUaGUgSG9wLUxpbWl0IG9wdGlvbiBpcyBzYWZlIHRvIGZvcndhcmQuICBU aGF0IGlzLCBhIENvQVAgcHJveHkgd2hpY2gNCiAgIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIEhv cC1MaW1pdCBvcHRpb24gc2hvdWxkIGZvcndhcmQgaXQgb24uICBUaGUNCiAgIG9wdGlvbiBpcyBh bHNvIHBhcnQgb2YgdGhlIGNhY2hlLiAgQXMgc3VjaCwgYSBDb0FQIHByb3h5IG11c3QgZm9sbG93 DQogICB0aGUgcmVjb21tZW5kYXRpb25zIGluIFNlY3Rpb24gNS43LjEgb2YgW1JGQzcyNTJdIGZv ciBjYWNoaW5nLg0KDQoNCj4gPiA+IE9MRDoNCj4gPiA+DQo+ID4gPiAgICBPdGhlcndpc2UsIGVh Y2ggaW50ZXJtZWRpYXRlIHByb3h5LCB3aGljaCB1bmRlcnN0YW5kcyB0aGUgSG9wLUxpbWl0DQo+ ID4gPiAgICBvcHRpb24sIGludm9sdmVkIGluIHRoZSBoYW5kbGluZyBvZiBhIENvQVAgbWVzc2Fn ZSBNVVNUIGRlY3JlbWVudA0KPiA+ID4gICAgdGhlIEhvcC1MaW1pdCBvcHRpb24gdmFsdWUgYnkg MSBwcmlvciB0byBmb3J3YXJkaW5nIHVwc3RyZWFtIGlmIHRoaXMNCj4gPiA+ICAgIHBhcmFtZXRl ciBleGlzdHMuDQo+ID4gPg0KPiA+ID4gTkVXOg0KPiA+ID4NCj4gPiA+ICAgIE90aGVyd2lzZSwg YSBDb0FQIHByb3h5IHdoaWNoIHVuZGVyc3RhbmRzIHRoZSBIb3AtTGltaXQgb3B0aW9uIE1VU1QN Cj4gPiA+ICAgIGRlY3JlbWVudCB0aGUgdmFsdWUgb2YgdGhlIG9wdGlvbiBieSAxIHByaW9yIHRv IGZvcndhcmRpbmcgaXQuIEENCj4gPiA+ICAgIENvQVAgcHJveHkgd2hpY2ggdW5kZXJzdGFuZHMg dGhlIEhvcC1MaW1pdCBvcHRpb24gTVVTVCBOT1QgdXNlIGENCj4gPiA+ICAgIHN0b3JlZCByZXNw b25zZSB1bmxlc3MgdGhlIHZhbHVlIG9mIHRoZSBIb3AtTGltaXQgb3B0aW9uIGluIHRoZQ0KPiA+ ID4gICAgcHJlc2VudGVkIHJlcXVlc3QgaXMgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIHRoZSB2YWx1 ZSBvZiB0aGUNCj4gPiA+ICAgIEhvcC1MaW1pdCBvcHRpb24gaW4gdGhlIHJlcXVlc3QgdXNlZCB0 byBvYnRhaW4gdGhlIHN0b3JlZCByZXNwb25zZS4NCj4gPg0KPiA+IFtNZWRdIElkZW0gYXMgYWJv dmUuIFdvdWxkbid0IGJlIHNpbXBsZSB0byBtYWludGFpbiB0aGUgZGVzaWduIHdlIGhhdmUgaW4g LQ0KPiAwMT8NCj4gDQo+IFRoZSBvcHRpb24gcHJvcGVydGllcyBvZiBzYWZlLXRvLWZvcndhcmQg YW5kIHBhcnQtb2YtdGhlLWNhY2hlLWtleQ0KPiBvbmx5IGFwcGx5IHRvIHRoZSBjYXNlIHdoZXJl IGFuIGludGVybWVkaWFyeSBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZQ0KPiBvcHRpb24sIHNvIHRo ZSBkcmFmdCBuZWVkcyB0byBiZSBzcGVjaWZpYyBhYm91dCB0aGUgY2FzZSB3aGVuIGl0IGlzDQo+ IHVuZGVyc3Rvb2QuDQo+IA0KDQpbTWVkXSBEZWFsLiANCg0KPiBCZXN0IHJlZ2FyZHMsDQo+IEts YXVzDQo= From nobody Wed Dec 12 00:21:26 2018 Return-Path: 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 4F1BD1294D0; Wed, 12 Dec 2018 00:21:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u8G9IxZo62VI; Wed, 12 Dec 2018 00:21:21 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB76612D4EF; Wed, 12 Dec 2018 00:21:21 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id F1285181D3368; Wed, 12 Dec 2018 08:21:19 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:152:355:379:582:599:800:960:962:967:973:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2527:2528:2551:2553:2559:2562:2692:2892:2894:3138:3139:3140:3141:3142:3353:3586:3865:3866:3867:3868:3870:3871:3872:3874:4117:4321:5007:6117:6119:6261:6298:6657:6659:6678:7576:7875:7903:8583:8603:8957:9080:9545:10004:10400:10848:11232:11657:11658:11914:12043:12050:12740:12895:13139:13436:13439:13846:13972:14180:14181:14721:21060:21080:21433:21451:21611:21625:30025:30041:30054:30075:30076:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: hair87_7ffd1a35bb252 X-Filterd-Recvd-Size: 6681 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf10.hostedemail.com (Postfix) with ESMTPA; Wed, 12 Dec 2018 08:21:19 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_16e6b6139de2df309f8963ed836a69e9" Date: Wed, 12 Dec 2018 09:21:19 +0100 From: Peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <035e01d49178$b08a3e60$119ebb20$@augustcellars.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <035e01d49178$b08a3e60$119ebb20$@augustcellars.com> Message-ID: <4ea547c2c838536e260fd222651ae446@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 08:21:25 -0000 --=_16e6b6139de2df309f8963ed836a69e9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Jim Schaad schreef op 2018-12-11 18:41: > FROM: Peter van der Stok > SENT: Tuesday, December 11, 2018 12:59 AM > TO: Jim Schaad > CC: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > SUBJECT: Re: Questions and comments against the github version > > Hi Jim, > > thanks, for the questions. > One explanation for one question. > > Jim Schaad schreef op 2018-12-11 03:22: > >> * In section 5.3, I don't understand why the rule exists that if the >> attribute values are different then the location of the registration needs >> to be changed. It seems that this could lead to some interesting conflicts >> in behavior depending on what messages are used. For example (content >> omitted for clarity): >> >> POST /rd?ep=e1&foo=over >> >> Res: 2.01 Created >> Location-Path: /rd/4001 >> >> POST /rd?ep=e1&foo=under >> >> Res: 2.01 Created >> Location-Path: /rd/4002 >> >> As opposed to: >> >> POST /rd?ep=e1&foo=over >> >> Res: 2.01 Created >> Location-Path: /rd/4001 >> >> POST /rd/4001?foo=under >> >> Res: 2.01 Changed >> >> >> The feeling was that a first ep having done the earlier registration /rd/4001 >> should not be able to manipulate the 2nd registration by a 2nd ep, by removing /rd/4001 >> and having a registration /rd/4002 only known to 2nd ep. >> >> >> [JLS] The only problem with this is that the query of endpoints needs to be changed so that the endpoint locations are not returned. Once the query is done then the location is known to a 2nd ep. >> >> >> Is true. >> The above statement is not about security and hiding information. >> It is to prevent non-malicious unwanted mistakes. >> --=_16e6b6139de2df309f8963ed836a69e9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Jim Schaad schreef op 2018-12-11 18:41:

 

 

From: Peter van der Stok <stokco= ns@bbhmail.nl>
Sent: Tuesday, December 11, 2018 1= 2:59 AM
To: Jim Schaad <ietf@augustcellars.com>=
Cc: draft-ietf-core-resource-directory@ietf.org; cor= e@ietf.org
Subject: Re: Questions and comments agains= t the github version

 

Hi Jim,

thanks, for the questions.
One ex= planation for one question.

Ji= m Schaad schreef op 2018-12-11 03:22:

*  In section 5.3, I don't= understand why the rule exists that if the
attribute values are diffe= rent then the location of the registration needs
to be changed.  =  It seems that this could lead to some interesting conflicts
in b= ehavior depending on what messages are used.  For example  (conte= nt
omitted for clarity):

POST /rd?ep=3De1&foo=3Dover
Res: 2.01 Created
Location-Path: /rd/4001

POST /rd= ?ep=3De1&foo=3Dunder

Res: 2.01 Created
Location-Path: /= rd/4002

As opposed to:

POST /rd?ep=3De1&foo=3Dove= r

Res: 2.01 Created
Location-Path: /rd/4001

POST= /rd/4001?foo=3Dunder

Res: 2.01 Changed

<pvds><= br />The feeling was that a first ep having done the earlier registration /= rd/4001 
should not be able to manipulate the 2nd registration by= a 2nd ep, by removing /rd/4001
and having a registration /rd/4002 onl= y known to 2nd ep.
</pvds>

[JLS] The only problem with this is that the query of endpoints needs= to be changed so that the endpoint locations are not returned.  Once = the query is done then the location is known to a 2nd ep.=

<pvds>
Is true.
The above statement is not abou= t security and hiding information.
It is to prevent non-malicious unwa= nted mistakes.
</pvds>

--=_16e6b6139de2df309f8963ed836a69e9-- From nobody Wed Dec 12 00:51:28 2018 Return-Path: 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 3AB07131140; Wed, 12 Dec 2018 00:51:27 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 6S_uvaoJI8i8; Wed, 12 Dec 2018 00:51:25 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0DD1310FF; Wed, 12 Dec 2018 00:51:24 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 505E4182CED5B; Wed, 12 Dec 2018 08:51:21 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:152:355:379:582:599:960:962:967:968:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2528:2559:2562:2692:2894:2902:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3870:3871:3872:3874:4250:4321:4641:5007:6117:6261:6657:6659:6678:7875:7903:8603:10004:10400:10848:11232:11657:11658:11914:12663:12740:12895:13071:13139:13439:13972:14093:14096:14180:14181:14721:21060:21080:21433:21451:21627:21819:30012:30021:30029:30041:30054:30076, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:24, LUA_SUMMARY:none X-HE-Tag: pig83_630434dfb033f X-Filterd-Recvd-Size: 5687 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA; Wed, 12 Dec 2018 08:51:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_43dca035534e5af9f5bb003da483c992" Date: Wed, 12 Dec 2018 09:51:19 +0100 From: Peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 08:51:27 -0000 --=_43dca035534e5af9f5bb003da483c992 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Jim, Some reactions to some of your other questions Jim Schaad schreef op 2018-12-11 03:22: > * In Section 5.3 - What is the correct behavior if the RD is configured to > recognize an endpoint, but the endpoint supplies a different name? Is this > an error or does one of them override? > > > Recognizing an endpoint falls under the category "use of security context"? > as described under ep parameter specfication. > I am afraid security context is not defined in this draft. > Possibly remove this phrase from the ep? > > > * In section 5.3.1 - I assume it would be an error to include the base > attribute - perhaps this should be explicit? > > The text says: "the base attribute is not accepted to keep the registration interface simple" > Looks sufficient to me. > > > * In section 5.3.1 - A valid response code might be 4.XX - method not > supported if this functionality is disabled. I am not sure what the "or is > empty" means for the 4.04 response code. Which one is empty, the RD or the > EP? > > > "or is empty" is about response from simple ep to RD > meaning the /.well-known/core of the server ep is empty. > I am not sure to understand the 4.XX remark though. > > > * In section 5.3.1 - Is the RD responsible for dealing with resource-link > items which would not make sense by doing full resolutions on everything or > re-writing them? > > > For me a difficult question. "making sense" is very context/application dependent. > The less the RD decides about validity of link contents, the better I feel. > > > * In section 5.4.1 - s/lt,con/lt,base/ > > > Thanks, missed that one. > > > Many thanks, > Other questions, suggestions in next e-mail --=_43dca035534e5af9f5bb003da483c992 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Jim,

Some reactions to some of your other questions

Jim Schaad schreef op 2018-12-11 03:22:

=

*  In Section 5.3 - What is the correct behavior if the R= D is configured to
recognize an endpoint, but the endpoint supplies a= different name?  Is this
an error or does one of them override?=

<pvds>
Recognizing an endpoint falls under the categ= ory "use of security context"?
as described under ep parameter specfic= ation.
I am afraid security context is not defined in this draft.
Possibly remove this phrase from the ep? 
</pvds>
* In section 5.3.1 - I assume it would be an error to include the base<= br /> attribute - perhaps this should be explicit?
<pvds>
T= he text says: "the base attribute is not accepted to keep the registration = interface simple"
Looks sufficient to me.
</pvds>



* In section 5.3.1 - A valid response code might be 4.XX - m= ethod not
supported if this functionality is disabled.  I am not= sure what the "or is
empty" means for the 4.04 response code.  = Which one is empty, the RD or the
EP?

<pvds>
"= or is empty" is about response from simple ep to RD
meaning the /.well= -known/core of the server ep is empty.
I am not sure to understand the= 4.XX remark though.
</pvds>

* In section 5.3.1 - Is= the RD responsible for dealing with resource-link
items which would = not make sense by doing full resolutions on everything or
re-writing = them?

<pvds>
For me a difficult question. "making sen= se" is very context/application dependent.
The less the RD decides abo= ut validity of link contents, the better I feel.
</pvds>
* In section 5.4.1 - s/lt,con/lt,base/

<pvds>
Th= anks, missed that one.
</pvds>

Many thanks,
Othe= r questions, suggestions in next e-mail





=

--=_43dca035534e5af9f5bb003da483c992-- From nobody Wed Dec 12 01:56:13 2018 Return-Path: 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 9875B13114C; Wed, 12 Dec 2018 01:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 iBjZQji4z4Lm; Wed, 12 Dec 2018 01:56:06 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140082.outbound.protection.outlook.com [40.107.14.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EC7131164; Wed, 12 Dec 2018 01:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OMFYLULLxIhznPV2Yk+LtcMTDrqfHia5tRh+boqMbh4=; b=LyZSBl/XvWYzN1t54gUEvmhSP30lJre4Bki73oRqtqPfmrU3pJT9cXCouIbvXiopP3jWfGYTaAAP7XwKd5zFhaw3A8c5fimUliE3Exo/WIDfP7IM3zJNXbxB/c/OXR0OSEhxZXr0X/cV3Iksasrot2DLcziGyJFCx6jcl8dUcGY= Received: from VI1PR08MB3710.eurprd08.prod.outlook.com (20.178.14.78) by VI1PR08MB0784.eurprd08.prod.outlook.com (10.164.93.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.19; Wed, 12 Dec 2018 09:55:58 +0000 Received: from VI1PR08MB3710.eurprd08.prod.outlook.com ([fe80::4c40:190:4ae6:de16]) by VI1PR08MB3710.eurprd08.prod.outlook.com ([fe80::4c40:190:4ae6:de16%3]) with mapi id 15.20.1404.026; Wed, 12 Dec 2018 09:55:58 +0000 From: Lauri Piikivi To: "consultancy@vanderstok.org" , Jim Schaad CC: "draft-ietf-core-resource-directory@ietf.org" , "core@ietf.org" Thread-Topic: [core] Questions and comments against the github version Thread-Index: AdSQ3PYM1bz/vMt1Qp6I1pzWuFt+hwAUsuoAABI7MYAAHr5/gAADEJ5U Date: Wed, 12 Dec 2018 09:55:58 +0000 Message-ID: References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <035e01d49178$b08a3e60$119ebb20$@augustcellars.com>, <4ea547c2c838536e260fd222651ae446@bbhmail.nl> In-Reply-To: <4ea547c2c838536e260fd222651ae446@bbhmail.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Lauri.Piikivi@arm.com; x-originating-ip: [40.119.148.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR08MB0784; 6:s+NsSF++r9Rwc/hosmf6leOGfi5cGuEpCZkVThZcx7JoJR1akK2tpqRmtNsiHUt6XUtRNxts0qaNAnHi0NRxx2aYs5yT7SB8c08Jhgcg1MZ0KTTfRlp4yfDs0y1sY5JslSHY3qogd0e5kFjyxlr1DCQ4p/0ZqePc2NFyvUUB4XdwSqRlVIjvfsO78LdmKsOX1vMG1J2kQeSqKDx8LZuFYS1qQ+cg8wYBeJlAA2vnoC3Byd/Ra56ZXz3drvDDpSSTCBplQ4UGzHRrN1BzAJ2vplWB+GpIAd2CZ5mCGhOe9B0ZJYONWftcH1aGyE4/T/RDwuuLGwuoYmJCsbhFMgE5gTLI4NR11Ea1ipZddVFpxgjqbsXDlrpC+T0H2TPRXFzcOKKnTZN/3qGtw/VYuiOpJOVTzybvIXetDfpbDMVJ5KMP+bQ+db4Mfbop4gJ1Ur0FbqAUDn7IGqC9hBtCVcXz0A==; 5:TGnjoWJwRUqYkOT5swaZHYGHUtbVNMIDaQs0NvP1rUNwU5g96PPTKMTh5mW1jAVHw/qnvC2smW0SJCTsVpkNHfv8r/i7M4MQesdSvI+C1YxwfdGtjEaVksSdI09Rz7rNNPrtL25UJZPUypLvubyGSKIXePA6PnivAIbHZl+pXEU=; 7:LqgT2VIUX9PmICaXeJlkpUSfOso1Ke7TZBxnKWy2ZX/0D5RFf6jEuKk7/uq/HDyVPbARe1eVblODdt5KcXHyXJoFZAxHr0o3dR+tCCDexCMH+QmMEm/7zxer8Im/mu8x1nFQy3FBKXNDXl1ElP2Akg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9e5fc2dd-9caa-4fc5-0cba-08d66018040a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR08MB0784; x-ms-traffictypediagnostic: VI1PR08MB0784: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231472)(944501520)(52105112)(2017080701022)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR08MB0784; BCL:0; PCL:0; RULEID:; SRVR:VI1PR08MB0784; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(346002)(39860400002)(396003)(189003)(199004)(25584004)(40434004)(25786009)(54896002)(9686003)(6306002)(97736004)(236005)(7696005)(102836004)(186003)(86362001)(5660300001)(72206003)(33656002)(81156014)(81166006)(8936002)(8676002)(4001150100001)(6246003)(99286004)(476003)(316002)(54906003)(110136005)(71190400001)(71200400001)(26005)(53936002)(486006)(4326008)(76176011)(256004)(55016002)(14444005)(5024004)(53546011)(446003)(6506007)(11346002)(105586002)(7736002)(74316002)(93886005)(106356001)(14454004)(68736007)(3846002)(6116002)(229853002)(478600001)(45080400002)(66066001)(606006)(2906002)(6436002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB0784; H:VI1PR08MB3710.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Zx0Xv37Z9NGxfIT3+sK34rpUvtGqwZd5i9I4DtDGvAPEOYNYnj8aNGbITbsu0IKWoKbPjCwFeSoG4/bf21rD3KMtR4muMWXs7IX4rAZa3qkM18x8SxZnPjQTPT0yqAlsAwCGNV14BWMPhr4VQqyao6eU+RDx8eFIxV9MnH459WvyaYW2t+HyEb1sE/rB48KCKrakmlk3DhVj8y6SLQUd2i6sQgcMZjSElqW3SDae8/q/VGpO6N+LYRzAI5CHhKlMeu1zxz7TbSCUGLSRnfr8tIfbSgzjWxnm7l+OllxXD9qhU4UuzjStg6NPxodrE+fx spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR08MB37106E3F129E5012E9737D0CEBA70VI1PR08MB3710eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e5fc2dd-9caa-4fc5-0cba-08d66018040a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2018 09:55:58.1432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB0784 Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 09:56:11 -0000 --_000_VI1PR08MB37106E3F129E5012E9737D0CEBA70VI1PR08MB3710eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I just want to verify that the endpoint identity, and related access contro= l is part of the question below. If a EP publishes itself in rd, no other e= p, based on adequate authenticaiton, can overwrite it. If an earlier regist= ered EP makes a new registration to the RD, where it does not include the l= ocation in the path, is an indication that the EP may have reset or otherwi= se wants a new registration (e.g. Due to changed attributes) in the rd. Another ep trying to post to another ep=92s url should get an error. This r= equires authenticaiton. If there is adeqaute authenticaiton, and access control to the publishing, = then retrieving all the eps is not a problem. Sincerely, - Lauri Get Outlook for iOS ________________________________ From: core on behalf of Peter van der Stok Sent: Wednesday, December 12, 2018 8:21 AM To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org Subject: Re: [core] Questions and comments against the github version Jim Schaad schreef op 2018-12-11 18:41: From: Peter van der Stok Sent: Tuesday, December 11, 2018 12:59 AM To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org Subject: Re: Questions and comments against the github version Hi Jim, thanks, for the questions. One explanation for one question. Jim Schaad schreef op 2018-12-11 03:22: * In section 5.3, I don't understand why the rule exists that if the attribute values are different then the location of the registration needs to be changed. It seems that this could lead to some interesting conflict= s in behavior depending on what messages are used. For example (content omitted for clarity): POST /rd?ep=3De1&foo=3Dover Res: 2.01 Created Location-Path: /rd/4001 POST /rd?ep=3De1&foo=3Dunder Res: 2.01 Created Location-Path: /rd/4002 As opposed to: POST /rd?ep=3De1&foo=3Dover Res: 2.01 Created Location-Path: /rd/4001 POST /rd/4001?foo=3Dunder Res: 2.01 Changed The feeling was that a first ep having done the earlier registration /rd/40= 01 should not be able to manipulate the 2nd registration by a 2nd ep, by remov= ing /rd/4001 and having a registration /rd/4002 only known to 2nd ep. [JLS] The only problem with this is that the query of endpoints needs to be= changed so that the endpoint locations are not returned. Once the query i= s done then the location is known to a 2nd ep. Is true. The above statement is not about security and hiding information. It is to prevent non-malicious unwanted mistakes. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR08MB37106E3F129E5012E9737D0CEBA70VI1PR08MB3710eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

I just want to verify that the endpoint iden= tity, and related access control is part of the question below. If a EP pub= lishes itself in rd, no other ep, based on adequate authenticaiton, can ove= rwrite it. If an earlier registered EP makes a new registration to the RD, where it does not include the locat= ion in the path, is an indication that the EP may have reset or otherwise w= ants a new registration (e.g. Due to changed attributes) in the rd.

Another ep trying to post to another ep=92s = url should get an error. This requires authenticaiton.  

If there is adeqaute authenticaiton, and acc= ess control to the publishing, then retrieving all the eps is not a problem= .

Sincerely,
- Lauri


Get Outlook for iOS
From: cor= e <core-bounces@ietf.org> on behalf of Peter van der Stok <stokcon= s@bbhmail.nl>
Sent: Wednesday, December 12, 2018 8:21 AM
To: Jim Schaad
Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org
Subject: Re: [core] Questions and comments against the github versio= n
 

Jim Schaad schreef op 2018-12-11 18:41:

 

 

From: Peter van der Stok <stokco= ns@bbhmail.nl>
Sent: Tuesday, December 11, 2018 12:59 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf= .org
Subject: Re: Questions and comments against the github ver= sion

 

Hi Jim,

thanks, for the questions.
One explanation for one question.

Jim S= chaad schreef op 2018-12-11 03:22:

*  In section 5.3, I don't unde= rstand why the rule exists that if the
attribute values are different then the location of the registration needs<= br> to be changed.   It seems that this could lead to some interestin= g conflicts
in behavior depending on what messages are used.  For example  (c= ontent
omitted for clarity):

POST /rd?ep=3De1&foo=3Dover

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd?ep=3De1&foo=3Dunder

Res: 2.01 Created
Location-Path: /rd/4002

As opposed to:

POST /rd?ep=3De1&foo=3Dover

Res: 2.01 Created
Location-Path: /rd/4001

POST /rd/4001?foo=3Dunder

Res: 2.01 Changed

<pvds>
The feeling was that a first ep having done the earlier registration /rd/40= 01 
should not be able to manipulate the 2nd registration by a 2nd ep, by remov= ing /rd/4001
and having a registration /rd/4002 only known to 2nd ep.
</pvds>

[JLS] The only problem with this is that the = query of endpoints needs to be changed so that the endpoint locations are n= ot returned.  Once the query is done then the location is known to a 2= nd ep.

<pvds>
Is true.
The above statement is not about security and hiding information.
It is to prevent non-malicious unwanted mistakes.
</pvds>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR08MB37106E3F129E5012E9737D0CEBA70VI1PR08MB3710eurp_-- From nobody Wed Dec 12 04:58:49 2018 Return-Path: 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 8D11B126F72; Wed, 12 Dec 2018 04:58:47 -0800 (PST) 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 T5KizrpNqC_d; Wed, 12 Dec 2018 04:58:46 -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 D8AA1126DBF; Wed, 12 Dec 2018 04:58:45 -0800 (PST) Received: from mail-qk1-f173.google.com ([209.85.222.173]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gX467-0001R2-81; Wed, 12 Dec 2018 13:58:43 +0100 Received: by mail-qk1-f173.google.com with SMTP id o125so10646623qkf.3; Wed, 12 Dec 2018 04:58:43 -0800 (PST) X-Gm-Message-State: AA+aEWZ8xJ1WliKGp38oqkPpZA9L5FwrmN3wH1OB19e9RUyGAmhauHLC X5DbVYkxL445Pjul+jkDGGuBOo/37izIO5mhaLc= X-Google-Smtp-Source: AFSGD/WkduTzNaexHbzeDM1AouBEMe7W3Y4Lls8KTur/wBw9qI+rR8RQYOjqrm1ZP6ElZ9+b5xwgzf4GcHfSSrrWfso= X-Received: by 2002:a37:a84b:: with SMTP id r72mr18605921qke.2.1544619522169; Wed, 12 Dec 2018 04:58:42 -0800 (PST) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E057537@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E057537@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Klaus Hartke Date: Wed, 12 Dec 2018 13:58:06 +0100 X-Gmail-Original-Message-ID: Message-ID: To: mohamed.boucadair@orange.com Cc: "core@ietf.org WG" , draft-ietf-core-hop-limit@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1544619525; 2d29173b; X-HE-SMSGID: 1gX467-0001R2-81 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 12:58:47 -0000 Mohamed Boucadair wrote: > 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 ... key. > As such, a CoAP proxy ... which does not understand the Hop-Limit option ... > must follow > the recommendations in Section 5.7.1 of [RFC7252] for caching. >> 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. > > Deal. =F0=9F=91=8D Klaus From nobody Wed Dec 12 05:15:51 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 645EC130E61; Wed, 12 Dec 2018 05:15:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <154462054136.814.770796701594834187@ietfa.amsl.com> Date: Wed, 12 Dec 2018 05:15:41 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-hop-limit-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 13:15:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Hop Limit Option Authors : Mohamed Boucadair Tirumaleswar Reddy Jon Shallow Filename : draft-ietf-core-hop-limit-02.txt Pages : 6 Date : 2018-12-12 Abstract: The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-hop-limit-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-hop-limit-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-hop-limit-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 12 05:17:22 2018 Return-Path: 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 3CC27130E0F; Wed, 12 Dec 2018 05:17:10 -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 Ntrz21yU9LHr; Wed, 12 Dec 2018 05:17:07 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884E3130DFF; Wed, 12 Dec 2018 05:17:07 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 43FHQn6WtFz7vQK; Wed, 12 Dec 2018 14:17:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 43FHQn5lKXz5vMq; Wed, 12 Dec 2018 14:17:05 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0415.000; Wed, 12 Dec 2018 14:17:05 +0100 From: To: Klaus Hartke CC: "core@ietf.org WG" , "draft-ietf-core-hop-limit@ietf.org" Thread-Topic: [core] draft-ietf-core-hop-limit-01 Thread-Index: AQHUkVePf7vrJIA96EubEQVyy8DF/qV5pHCQ///00oCAAQ0A0IAAWvEAgAAVt8A= Date: Wed, 12 Dec 2018 13:17:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E057967@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E03CCED@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E056CF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E057537@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 13:17:20 -0000 SGkgS2xhdXMsIA0KDQpXb3JrcyBmb3IgbWUuIA0KDQotMDIgaW1wbGVtZW50cyB5b3VyIGNvbW1l bnRzLiBUaGFuayB5b3UuIA0KDQpDaGFpcnM6IHBsZWFzZSBjb25zaWRlciBhIFdHTEMgZm9yIHRo ZSBkcmFmdC4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZcKgOiBLbGF1cyBIYXJ0a2UgW21haWx0bzpoYXJ0a2VAcHJvamVjdGNvb2wuZGVdDQo+ IEVudm95w6nCoDogbWVyY3JlZGkgMTIgZMOpY2VtYnJlIDIwMTggMTM6NTgNCj4gw4DCoDogQk9V Q0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiBDY8KgOiBjb3JlQGlldGYub3JnIFdHOyBkcmFmdC1p ZXRmLWNvcmUtaG9wLWxpbWl0QGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbY29yZV0gZHJhZnQt aWV0Zi1jb3JlLWhvcC1saW1pdC0wMQ0KPiANCj4gTW9oYW1lZCBCb3VjYWRhaXIgd3JvdGU6DQo+ ID4gV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIE5FVyB3b3JkaW5nOg0KPiA+DQo+ID4gICAgVGhl IEhvcC1MaW1pdCBvcHRpb24gaXMgc2FmZSB0byBmb3J3YXJkLiAgVGhhdCBpcywgYSBDb0FQIHBy b3h5IHdoaWNoDQo+ID4gICAgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgSG9wLUxpbWl0IG9wdGlv biBzaG91bGQgZm9yd2FyZCBpdCBvbi4gIFRoZQ0KPiA+ICAgIG9wdGlvbiBpcyBhbHNvIHBhcnQg b2YgdGhlIGNhY2hlDQo+IA0KPiAuLi4ga2V5Lg0KPiANCj4gPiBBcyBzdWNoLCBhIENvQVAgcHJv eHkNCj4gDQo+IC4uLiB3aGljaCBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBIb3AtTGltaXQgb3B0 aW9uIC4uLg0KPiANCj4gPiBtdXN0IGZvbGxvdw0KPiA+ICAgIHRoZSByZWNvbW1lbmRhdGlvbnMg aW4gU2VjdGlvbiA1LjcuMSBvZiBbUkZDNzI1Ml0gZm9yIGNhY2hpbmcuDQo+IA0KPiA+PiBUaGUg b3B0aW9uIHByb3BlcnRpZXMgb2Ygc2FmZS10by1mb3J3YXJkIGFuZCBwYXJ0LW9mLXRoZS1jYWNo ZS1rZXkNCj4gPj4gb25seSBhcHBseSB0byB0aGUgY2FzZSB3aGVyZSBhbiBpbnRlcm1lZGlhcnkg ZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUNCj4gPj4gb3B0aW9uLCBzbyB0aGUgZHJhZnQgbmVlZHMg dG8gYmUgc3BlY2lmaWMgYWJvdXQgdGhlIGNhc2Ugd2hlbiBpdCBpcw0KPiA+PiB1bmRlcnN0b29k Lg0KPiA+DQo+ID4gRGVhbC4NCj4gDQo+IPCfkY0NCj4gDQo+IEtsYXVzDQo= From nobody Wed Dec 12 12:43:55 2018 Return-Path: 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 7F4CA130F5C for ; Wed, 12 Dec 2018 12:43:53 -0800 (PST) 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, 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 scd2tKxnk0iK for ; Wed, 12 Dec 2018 12:43:50 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A090E1276D0 for ; Wed, 12 Dec 2018 12:43:49 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id EADE44243D; Wed, 12 Dec 2018 21:43:46 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id EC6396B; Wed, 12 Dec 2018 21:43:45 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C8B052F; Wed, 12 Dec 2018 21:43:45 +0100 (CET) Received: (nullmailer pid 1820 invoked by uid 1000); Wed, 12 Dec 2018 20:43:45 -0000 Date: Wed, 12 Dec 2018 21:43:45 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20181212204344.GA665@hephaistos.amsuess.com> References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 20:43:54 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 06, 2018 at 09:27:14PM -0800, Jim Schaad wrote: > I am unsure how to get to the correct answer in this case. >=20 > I do a multicast get to /.well-known/core > The response comes back on a unicast address with relative URIs and witho= ut > an anchor. > I resolve the relative URI against ??? You resolve against (in RFC6690 link format: the origin of) the URI of the requested resource, which in the CoAP case is constructed from the request Uri-* options (RFC7252 section 6.5), but with the IP literal of the multicast request as per section 8.2 (last paragraph before 8.2.1; "and any links embedded in the representation"). (I wouldn't have known the exact reference either, had I not outlined it at [1]). Best regards Christian [1]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-17#appe= ndix-B.1.1 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --opJtzjQTFsWo+cga Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwRcv0ACgkQOY0REtOk veFCNg/+NZqhYVINKPL/avag8WLm84Ox/A6RZJvzfX4QbPc/RxiijsCuptte2HCZ v/BEMFwhGQ3HIvxEyNuo77zCm2K/UU8Sa+AWOoX7zKohDxudc5qDp+BifHm6hyvV bA3AMaAtLVypSe61xTPCN54MbRHpGxk5rqbqzNqiWi/sEFJx1xWt0gLNR7zWxmm1 loheTedkF3r4MCtfa9HD9XKr5Ba2AwjnMB61MNIGn4gXPEG6zhDbsNVbtyEMYwbF HfB7GXTC2Cy/QCu6JwlQEb2VubI3W12FAgudwFalwqk2WkjP76acJMrRDnCW4L4l g5o7UgRrSKnmsjCDfzw0acv5Ylt3lZaUhZfEL1TuFNVkx6gur6HkS08fAQjI2gJx alecmJAmPs2QoZ75eguhJ70WGD/Rkii7CiihvtsaleCOUcbk+zwn9ABE8LMstlug Nyedx1HiKJVtD8zXEVTJPL8pUz7l9GXhNY57xdoOOfeTwdWy2jQHNKNSaX1xOG7w rvnIHiAjgY5CnY19tchm86yrldgi9qB3quO4bEpcjDXvdRkHgmPwxJALPwj3scAl MRwVoBZddR2GLuk9uiLN2Mck7Yhw+tPUQFXm1rSlGtSLRljAbcmcxj8pqOk6pJYd Zm/XMe4a8lSn3/8NrMYrnPQiN3Fouedrx0Gtwi2hD9RmwvfZtAw= =SJOl -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From nobody Wed Dec 12 12:59:01 2018 Return-Path: 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 898F4130F75 for ; Wed, 12 Dec 2018 12:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 R9RvvB_FOj8s for ; Wed, 12 Dec 2018 12:58:57 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0282B130F82 for ; Wed, 12 Dec 2018 12:58:55 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 96CDE4243D; Wed, 12 Dec 2018 21:58:53 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D73796B; Wed, 12 Dec 2018 21:58:52 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 68E3F2F; Wed, 12 Dec 2018 21:58:52 +0100 (CET) Received: (nullmailer pid 3215 invoked by uid 1000); Wed, 12 Dec 2018 20:58:51 -0000 Date: Wed, 12 Dec 2018 21:58:51 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20181212205851.GB665@hephaistos.amsuess.com> References: <017201d48f49$99516560$cbf43020$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <017201d48f49$99516560$cbf43020$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 20:58:59 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2018 at 02:58:54PM -0800, Jim Schaad wrote: > I am trying to figure out if Anycast is supposed to have the response > on the Anycast address like Unicast does, or if it should be returned > on a Unicast address. I can't offer guidence, just my .02=E2=82=AC: The client may not know that it's talking to a multicast server. Therefore, the client would not correlate any messages from a unicast address. As for the block-wise transport, the effects would not be too bad: If it's a stateless transfer, all is fine. If the anycast servers have a magic backplane that distributes incomplete transfer states, likewise. Otherwise, the transmission needs to be restarted. Can't say much about DTLS, but in OSCORE that'd be an ideal use case for the appendix B2 protocol. When the route flips, the client will get a 4.01 once and continue exchanging data with the protocol's Req2 message. Best regards Christian --=20 There's always a bigger fish. -- Qui-Gon Jinn --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwRdocACgkQOY0REtOk veFilRAA0zfFW1cGmItlwmEtbjszzrHCWDruNquyKnZaW/WIR1GqmznjYOLcZVLl rSu+CSqY5BGJVVu+w5N/w4v8QKbnI097cpz90Gt9Kzyt7MWSpPiYFCuo31qS9xoz d0p8ZlCCnvowgsry6VXR0HC48+M8gsmrN0gVEi3KX5fC+WjpTl70qQCrx+GbCZTV C0vFNreyZrZo+FiyNiXZoHj9vzDgZKVZg4x11DsAWZqWKL+ThPBgDeUjm9hB6CTL yNpj6xnqfE2lRW+qafWGfdTLgafoZN525fGdUyklYO+jDgzswFbDArDgDZXsg7rG H9ZNrkoBz9TOsLXF70o0mjhu8HMgh0aOChQ5YIJyo1MAW1sMhwyy71H2QXMmBYbO rGy4lLjXEcx2ZHn7xFikz4219x609B9qO4IQEnoe+Nw0GASVQsnZ0yWgyM4n7rwT i4N0P9jKhQaCoMz++4s1K3xB+QKbWeIsZ1meYNeCIQp1+cc5MAfTg1DhOlUIEQVS 9O7RJNSBwWDlpA7aFYpxgS5odi+NAwyz1NyfUoK4SnmFfwe0zItlKxXG3/dfwIHo wioM1WqOsOqdrSXuFyosYilYvWmxWLvYimzsGiFqFIOIEWKdVM4OoRoCp3J9xd0k 6wiFZxmrURfI2TQkIiGp5a8Y/XkMO7pPRZ3H/WKTxJOBigyV36Q= =Jbk7 -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From nobody Wed Dec 12 13:14:35 2018 Return-Path: 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 A906E130F1B for ; Wed, 12 Dec 2018 13:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wp6FlFipi3Dm for ; Wed, 12 Dec 2018 13:14:31 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCAB130FCE for ; Wed, 12 Dec 2018 13:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBCLDoK2010402; Wed, 12 Dec 2018 22:13:55 +0100 (CET) Received: from [192.168.217.102] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43FV0s63kfz1Br6; Wed, 12 Dec 2018 22:13:49 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20181212205851.GB665@hephaistos.amsuess.com> Date: Wed, 12 Dec 2018 22:13:48 +0100 Cc: Jim Schaad , core@ietf.org X-Mao-Original-Outgoing-Id: 566342026.662764-cf1317c641a55f36cb72a9bb06d45fe1 Content-Transfer-Encoding: quoted-printable Message-Id: <1B93F08B-F6A1-4624-BFF6-3EDB8E67D9F3@tzi.org> References: <017201d48f49$99516560$cbf43020$@augustcellars.com> <20181212205851.GB665@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 21:14:34 -0000 Hi Jim, hi Christian, I think the assumption here was that the anycast address is usable as a = unicast address. So the server can reply from the same address that it got the request on = (as it always should if it has multiple addresses, which is almost = always true in IPv6). The special exception for multicast is not = invoked (and not needed). Of course, there is an assumption here that the routing won=E2=80=99t = change quickly enough that the reply is swallowed by a BCP38-like = mechanism. If that happens, I=E2=80=99d say this is like any other = routing-instability induced packet loss, and for a piggybacked response = the client will simply retransmit. If the anycast goes through an ECMP-like mechanism, multiple requests in = a block-wise transfer would still go to the same server. If there is = completely random distribution, well, you get what you sowed=E2=80=A6 (That is the general load balancer problem.) Gr=C3=BC=C3=9Fe, Carsten > On Dec 12, 2018, at 21:58, Christian Ams=C3=BCss = wrote: >=20 > Signed PGP part > On Sat, Dec 08, 2018 at 02:58:54PM -0800, Jim Schaad wrote: >> I am trying to figure out if Anycast is supposed to have the response >> on the Anycast address like Unicast does, or if it should be returned >> on a Unicast address. >=20 > I can't offer guidence, just my .02=E2=82=AC: >=20 > The client may not know that it's talking to a multicast server. > Therefore, the client would not correlate any messages from a unicast > address. >=20 > As for the block-wise transport, the effects would not be too bad: > If it's a stateless transfer, all is fine. If the anycast servers have = a > magic backplane that distributes incomplete transfer states, likewise. > Otherwise, the transmission needs to be restarted. >=20 > Can't say much about DTLS, but in OSCORE that'd be an ideal use case = for > the appendix B2 protocol. When the route flips, the client will get a > 4.01 once and continue exchanging data with the protocol's Req2 = message. >=20 > Best regards > Christian >=20 > --=20 > There's always a bigger fish. > -- Qui-Gon Jinn >=20 >=20 From nobody Wed Dec 12 14:54:57 2018 Return-Path: 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 BFAE4130F24 for ; Wed, 12 Dec 2018 14:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 msHG0IYPNfIi for ; Wed, 12 Dec 2018 14:54:53 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42781312B9 for ; Wed, 12 Dec 2018 14:54:52 -0800 (PST) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 14:49:21 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= CC: References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> In-Reply-To: <20181212204344.GA665@hephaistos.amsuess.com> Date: Wed, 12 Dec 2018 14:54:18 -0800 Message-ID: <04f001d4926d$9eac0070$dc040150$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKvYJd64JVfgBoXic1Peu5LlKMP+QGj0uT4o7j0zLA= Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 22:54:56 -0000 > -----Original Message----- > From: Christian Ams=FCss > Sent: Wednesday, December 12, 2018 12:44 PM > To: Jim Schaad > Cc: core@ietf.org > Subject: Re: [core] /.well-known/core and multicast addresses >=20 > On Thu, Dec 06, 2018 at 09:27:14PM -0800, Jim Schaad wrote: > > I am unsure how to get to the correct answer in this case. > > > > I do a multicast get to /.well-known/core The response comes back on = a > > unicast address with relative URIs and without an anchor. > > I resolve the relative URI against ??? >=20 > You resolve against (in RFC6690 link format: the origin of) the URI of = the > requested resource, which in the CoAP case is constructed from the = request > Uri-* options (RFC7252 section 6.5), but with the IP literal of the multicast > request as per section 8.2 (last paragraph before 8.2.1; "and any = links > embedded in the representation"). >=20 > (I wouldn't have known the exact reference either, had I not outlined = it at [1]). I was rather afraid that this was the case. So just to be specific = because this is the context that I ran across the issue. As a client I am looking for an RD to register with. So I send the = request: Req: GET coap://[MCD1]/.well-known/core?rt=3Dcore.rd* I get back one or more responses with the following links: Res: 2.05 Content ;rt=3D"core.rd";ct=3D40, ;rt=3D"core.rd-lookup-ep";ct=3D40, ;rt=3D"core.rd-lookup-res";ct=3D40, (Note this is an example that is copied straight out of the RD draft.) I am now going to register myself by sending a registration request: Req: POST coap://[MCD1] /rd?ep=3Dnode1 Content-Format: 40 Payload: ;ct=3D41;rt=3D"temperature-c";if=3D"sensor"; anchor=3D"coap://spurious.example.com:5683", ;ct=3D41;rt=3D"light-lux";if=3D"sensor" As a response I could get: 1. Zero or more success responses, and=20 2. Zero or more failure responses Since multicast is defined as not needing to return any error messages = (such as a 4.01 Unauthorized). I am going to assume that nobody would say = that the server has nothing "useful to respond (e.g., if it only has an empty payload or an error response)" given that while there is no payload = there is a returned location path. Life could be really interesting if, for example, the get on /.well-known/core is supported as a multicast request but none of the RD functionality is. I would kind of expect that this would generally be = the case, but can see cases where the this would not be the case. It is the = way that I had planned to implement. If there was a rule that only resources available on the query address = were returned then that would defeat the purpose of doing the query to find a = RD service. On the other hand if the RD does not recognize that it needs = to do return fully resolved href fields in this case there would also seem to = be a problem. I am unaware of any such text for /.well-known/core but that = does not mean that it does not exist. Jim >=20 > Best regards > Christian >=20 > [1]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-17#appendi= x- > B.1.1 >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Wed Dec 12 14:58:39 2018 Return-Path: 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 2606E130F29 for ; Wed, 12 Dec 2018 14:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 pcPkEU8XMPQL for ; Wed, 12 Dec 2018 14:58:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442D0130F24 for ; Wed, 12 Dec 2018 14:58:36 -0800 (PST) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 14:53:27 -0800 From: Jim Schaad To: =?utf-8?Q?'Christian_Ams=C3=BCss'?= CC: References: <017201d48f49$99516560$cbf43020$@augustcellars.com> <20181212205851.GB665@hephaistos.amsuess.com> In-Reply-To: <20181212205851.GB665@hephaistos.amsuess.com> Date: Wed, 12 Dec 2018 14:58:24 -0800 Message-ID: <04f401d4926e$313c4bc0$93b4e340$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGaQDm3ahWv+IpE48JP95kmLAjOJQC6+azTpeqDdvA= Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 22:58:38 -0000 > -----Original Message----- > From: Christian Ams=C3=BCss > Sent: Wednesday, December 12, 2018 12:59 PM > To: Jim Schaad > Cc: core@ietf.org > Subject: Re: [core] Anycast and CoRE >=20 > On Sat, Dec 08, 2018 at 02:58:54PM -0800, Jim Schaad wrote: > > I am trying to figure out if Anycast is supposed to have the = response > > on the Anycast address like Unicast does, or if it should be = returned > > on a Unicast address. >=20 > I can't offer guidence, just my .02=E2=82=AC: >=20 > The client may not know that it's talking to a multicast server. > Therefore, the client would not correlate any messages from a unicast = address. >=20 > As for the block-wise transport, the effects would not be too bad: > If it's a stateless transfer, all is fine. If the anycast servers have = a magic > backplane that distributes incomplete transfer states, likewise. > Otherwise, the transmission needs to be restarted. Would this potentially have a problem if one is using ETag for = correlation? I would not assume that the ETag values would be the same = on both servers. I think you might be in a situation where you need to = restart the block transfer from scratch. >=20 > Can't say much about DTLS, but in OSCORE that'd be an ideal use case = for the > appendix B2 protocol. When the route flips, the client will get a > 4.01 once and continue exchanging data with the protocol's Req2 = message. I guess this is a case where one would expect that the same credentials = would be on all of the anycast machines since otherwise one would not be = able to do this roll over. You might get a 4.01 and need to get a new = token from the AS instead. Jim >=20 > Best regards > Christian >=20 > -- > There's always a bigger fish. > -- Qui-Gon Jinn From nobody Wed Dec 12 15:01:47 2018 Return-Path: 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 257BC130F81 for ; Wed, 12 Dec 2018 15:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 j1nGphoJnOdO for ; Wed, 12 Dec 2018 15:01:43 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B277130F24 for ; Wed, 12 Dec 2018 15:01:43 -0800 (PST) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 14:56:35 -0800 From: Jim Schaad To: 'Carsten Bormann' , =?utf-8?Q?'Christian_Ams=C3=BCss'?= CC: References: <017201d48f49$99516560$cbf43020$@augustcellars.com> <20181212205851.GB665@hephaistos.amsuess.com> <1B93F08B-F6A1-4624-BFF6-3EDB8E67D9F3@tzi.org> In-Reply-To: <1B93F08B-F6A1-4624-BFF6-3EDB8E67D9F3@tzi.org> Date: Wed, 12 Dec 2018 15:01:31 -0800 Message-ID: <04f501d4926e$a10abb80$e3203280$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGaQDm3ahWv+IpE48JP95kmLAjOJQC6+azTAWayhEKl308M8A== Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 23:01:45 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Wednesday, December 12, 2018 1:14 PM > To: Christian Ams=C3=BCss > Cc: Jim Schaad ; core@ietf.org > Subject: Re: [core] Anycast and CoRE >=20 > Hi Jim, > hi Christian, >=20 > I think the assumption here was that the anycast address is usable as = a unicast > address. > So the server can reply from the same address that it got the request = on (as it > always should if it has multiple addresses, which is almost always = true in IPv6). > The special exception for multicast is not invoked (and not needed). >=20 > Of course, there is an assumption here that the routing won=E2=80=99t = change quickly > enough that the reply is swallowed by a BCP38-like mechanism. If that > happens, I=E2=80=99d say this is like any other routing-instability = induced packet loss, and > for a piggybacked response the client will simply retransmit. It was not clear to me that this was the case that routing does not = change unless there is "a problem" or something because "radically = different" in the response times. One cannot really test this on IPv4 = since it is not supported and I don't think I can do it in IPv6 because = I don't have smart enough routers to be able to do this. Jim >=20 > If the anycast goes through an ECMP-like mechanism, multiple requests = in a > block-wise transfer would still go to the same server. If there is = completely > random distribution, well, you get what you sowed=E2=80=A6 (That is = the general load > balancer problem.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Dec 12, 2018, at 21:58, Christian Ams=C3=BCss = > wrote: > > > > Signed PGP part > > On Sat, Dec 08, 2018 at 02:58:54PM -0800, Jim Schaad wrote: > >> I am trying to figure out if Anycast is supposed to have the = response > >> on the Anycast address like Unicast does, or if it should be = returned > >> on a Unicast address. > > > > I can't offer guidence, just my .02=E2=82=AC: > > > > The client may not know that it's talking to a multicast server. > > Therefore, the client would not correlate any messages from a = unicast > > address. > > > > As for the block-wise transport, the effects would not be too bad: > > If it's a stateless transfer, all is fine. If the anycast servers = have > > a magic backplane that distributes incomplete transfer states, = likewise. > > Otherwise, the transmission needs to be restarted. > > > > Can't say much about DTLS, but in OSCORE that'd be an ideal use case > > for the appendix B2 protocol. When the route flips, the client will > > get a > > 4.01 once and continue exchanging data with the protocol's Req2 = message. > > > > Best regards > > Christian > > > > -- > > There's always a bigger fish. > > -- Qui-Gon Jinn > > > > From nobody Wed Dec 12 16:31:15 2018 Return-Path: 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 F14A913135F for ; Wed, 12 Dec 2018 16:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 og8hoT0tw0T3 for ; Wed, 12 Dec 2018 16:31:12 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E442F131362 for ; Wed, 12 Dec 2018 16:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBD0UioA015333; Thu, 13 Dec 2018 01:30:49 +0100 (CET) Received: from [192.168.217.102] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43FZN36DnCz1Br6; Thu, 13 Dec 2018 01:30:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <04f401d4926e$313c4bc0$93b4e340$@augustcellars.com> Date: Thu, 13 Dec 2018 01:30:42 +0100 Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , core@ietf.org X-Mao-Original-Outgoing-Id: 566353840.974189-bd775d3deb3f742542df8f965f25bace Content-Transfer-Encoding: quoted-printable Message-Id: <8148AFE0-B0CC-4045-908C-40E9A4EF2FE3@tzi.org> References: <017201d48f49$99516560$cbf43020$@augustcellars.com> <20181212205851.GB665@hephaistos.amsuess.com> <04f401d4926e$313c4bc0$93b4e340$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Anycast and CoRE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 00:31:14 -0000 On Dec 12, 2018, at 23:58, Jim Schaad wrote: > Would this potentially have a problem if one is using ETag for = correlation? I would not assume that the ETag values would be the same = on both servers. I think you might be in a situation where you need to = restart the block transfer from scratch. Multiple servers that share an anycast address need to behave like a = single server, as far as that is practical. (The client cannot help here as it does not even know the IP address is = an anycast one.) So, when using block-wise, they need to generate consistent ETags. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Dec 13 06:42:26 2018 Return-Path: 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 54C6E12785F for ; Thu, 13 Dec 2018 06:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3syxi2_Y7BDW for ; Thu, 13 Dec 2018 06:42:17 -0800 (PST) Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586DD1252B7 for ; Thu, 13 Dec 2018 06:42:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FdAAAO4PJb/xwBYJliGgEBAQEBAgEBA?= =?us-ascii?q?QEHAgEBAQGBZYFbKWZwOYN4iHeLHYFgLZkwDSUJhD4Cg24iOBIBAwEBAgEBAgI?= =?us-ascii?q?CaRwMgmpNPgEBAQEBAQEBASQBAQEBAQEjAg03LQEFIw8BBTwFECMCAiYCAkcQB?= =?us-ascii?q?g0BBQIBAYMdAYIAAQ+nPoEvhUCEVwUJAYEBil0dgVc/gRABJ4I9g0kBAQIBgUg?= =?us-ascii?q?CgxiCVwKLCJRnBwKBEYEJBIRciicGGIFYiAAFhx8BiWSDVYpdgV0igVUzGiSDO?= =?us-ascii?q?4IkAxd/AQgEhSKCMIU/PgEyAQEKjASCTAEB?= X-IPAS-Result: =?us-ascii?q?A2FdAAAO4PJb/xwBYJliGgEBAQEBAgEBAQEHAgEBAQGBZYF?= =?us-ascii?q?bKWZwOYN4iHeLHYFgLZkwDSUJhD4Cg24iOBIBAwEBAgEBAgICaRwMgmpNPgEBA?= =?us-ascii?q?QEBAQEBASQBAQEBAQEjAg03LQEFIw8BBTwFECMCAiYCAkcQBg0BBQIBAYMdAYI?= =?us-ascii?q?AAQ+nPoEvhUCEVwUJAYEBil0dgVc/gRABJ4I9g0kBAQIBgUgCgxiCVwKLCJRnB?= =?us-ascii?q?wKBEYEJBIRciicGGIFYiAAFhx8BiWSDVYpdgV0igVUzGiSDO4IkAxd/AQgEhSK?= =?us-ascii?q?CMIU/PgEyAQEKjASCTAEB?= X-IronPort-AV: E=Sophos;i="5.56,253,1539640800"; d="scan'208";a="12281842" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 15:42:13 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAADN3/Jb/xBhWMBiGwEBAQEDAQEBB?= =?us-ascii?q?wMBAQGBZYFbgQ9PITmDeIh3jSqZMA0lhEcChA84EgEDAQECAQECbRwMhT0BBSM?= =?us-ascii?q?PAQU8BRAjAgImAgJHEAYNAQUCAQGDHQGCAQ+nPYEvhUCEVwUJAYEBil2BdD+BE?= =?us-ascii?q?AEngj2DSQEBAgGBSAKDGIJXAosIlGcHAoERgQkEhFyKJwYYgViIAAWHHwGJZIN?= =?us-ascii?q?Vil2BXSGBVTMaJIM7giQDF38BCASFIoIwhT8+AzABAQqMBIJMAQE?= X-IronPort-AV: E=Sophos;i="5.56,253,1539640800"; d="scan'208";a="19250564" Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/AES256-SHA; 13 Dec 2018 15:42:13 +0100 Received: from [10.144.89.145] (10.80.233.50) by FGDEMUCIMP11EXC.ads.fraunhofer.de (10.80.232.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Dec 2018 15:40:12 +0100 To: CC: =?UTF-8?Q?G=c3=b6ran_Selander?= , =?UTF-8?Q?=27Christian_M=2e_Ams=c3=bcss=27?= , , , Stefan Hristozov , References: <20181011110943.GE31858@hephaistos.amsuess.com> <3E80C9C0-E03A-4EAE-8CAD-8063DC93C1A5@ericsson.com> <2608c3f9-907f-6f22-2c9e-bef30f9c0ef3@aisec.fraunhofer.de> <53AFBD47-6D9D-47FA-82E5-F1C8F5DC6F1F@ericsson.com> From: Jaro Fietz Message-ID: <3f288e89-ea41-5da5-ddb1-f5eada5a39cc@aisec.fraunhofer.de> Date: Thu, 13 Dec 2018 15:40:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <53AFBD47-6D9D-47FA-82E5-F1C8F5DC6F1F@ericsson.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.200.1013-24278.002 X-TM-AS-Result: No--15.530200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Archived-At: Subject: [core] OSCORE: Status Update on the C Implementation of an OSCORE Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 14:42:21 -0000 Hey everyone, after I've received several follow-up mails about my minimal C implementation of an OSCORE server on top of the embedded OS Zephyr, I've decided to give everyone an update on my progress. I've implemented a subset of the OSCORE Draft Version 14 in C, leaving out most optional features. My implementation provides a minimal working OSCORE server for an embedded board (in my case the 96 Boards BLE Nitrogen). It is based on Zephyr as the underlying embedded operating system but should be easily adaptable to other needs. The implementation is now finished feature wise. Key derivation was tested against the Appendix C.1.2 testcase from the specification [1]. Additionally, the server successfully responds to the OSCORE Test_1a [1] (executed with aiocoap's plugtest script). I haven't performed other tests, but this should be good enough to exchange simple encrypted messages. I'm currently in the works of open sourcing the project. I expect the source code to be published on github mid to late January. I hope that this will be quick enough for RIOT. I'll write to the ML once the source code is available (or only to individual people in case this information isn't relevant to the ML). BR, Jaro [1]: https://tools.ietf.org/html/draft-ietf-core-object-security-14#appendix-C.1.2 [2]: https://ericssonresearch.github.io/OSCOAP/test-spec5.html#test-1a On 11/26/18 3:18 PM, Göran Selander wrote: > Hi Jaro, > > Thanks for the update! > > I understand you can't promise anything here. The question I got was for a C-implementation which was not tailored for a particular constrained platform OS, like what exists for Contiki NG and Open WSN. For your information, the people I talked to at RIOT wants to start after the new year holidays, so anything available around that time would be very welcome. > > Thanks, > Göran > > > On 2018-11-26, 14:39, "Jaro Fietz" wrote: > > Hello Göran, > > we are planning on open-sourcing the C implementation, I'm in the works > of filling in the paperwork. Currently I'm in the bugfixing stage, so > the code isn't functional quite yet. Once I have a minimal working > example and we have the go-ahead for open-sourcing it, I'll let you > know. I hope that it'll happen within the next month, but can't > guarantee anything. > > BR, > Jaro > > On 11/23/18 4:04 PM, Göran Selander wrote: > > Hello Jaro, > > > > I'm curious about the continued story of one of the questions from Christian, below. > > > > On 2018-10-11, 14:42, "core on behalf of Jaro Fietz" wrote: > > > > Hello Christian, > > > > thanks for your quick answer, it clarified the second of my questions. > > > > On 10/11/18 1:09 PM, Christian Amsüss wrote: > > > The expectation is that the shortest (zero-length) ID would be used in > > > cases wherever that's beneficial, eg. when a constrained device > > > primarily utilizes one context in which it is addressed as a server. > > This is an interesting optimization. I'm not too sure about the actual > > benefits though. To me this would only result in the constrained nodes > > being able to shave off a few bytes of allocation when constructing the > > response and saving their sender_id to persistent storage. > > > You briefly had me worried I got it wrong myself -- but the > > > left-trimming that's happenign is on the sequence numbers, not on the > > > sender IDs. > > Sorry, I must have skipped incorrectly over the tuple construction. > > Reading through it again, your code is, of course, correct :) > > > Slightly off topic: Would that happen to be a freely licensed > > > implementation? If so, I know of an embedded operating system project > > > that would love to hear about this. > > I'm implementing OSCORE on top of zephyr (not integrated into it) for an > > embedded board. Currently it isn't open source, but I asked my advisor, > > who'll forward the request to the supervisor. > > Judging from your github history I expect you ask for RIOT-OS? :) > > > > Have you decided about open source? I also got question from people working RIOT-OS __ > > > > BR > > Göran > > > > > > > > > > > From nobody Fri Dec 14 02:33:48 2018 Return-Path: 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 DD076127AC2 for ; Fri, 14 Dec 2018 02:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.781 X-Spam-Level: X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Z9AHf3F9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YCGB0IyX 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 DI3d4vDVAfvs for ; Fri, 14 Dec 2018 02:33:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6819912426E for ; Fri, 14 Dec 2018 02:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544783621; x=1547375621; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DvuALtRLxv2+F/VojcX4XbL5Z34KR6yxa19Q+iGGXFk=; b=Z9AHf3F92noI7DdxS1p14mO2ydwT7syDHSvM3k+JnAkT2f6NKsMa3NRadG55gK6C GmOTDNIRR8ySCZvOKvL4TYYJn2jepHwpvpJOrupDNMM3hOnzMmczeINBAPmU2z21 x3XGxe4BSPmMYibNUSfm1V3ggV337L/OqQHN5L/NUBw=; X-AuditID: c1b4fb30-41b3a9e00000355c-14-5c1387053634 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 26.ED.13660.507831C5; Fri, 14 Dec 2018 11:33:41 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Dec 2018 11:33:40 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Dec 2018 11:33:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DvuALtRLxv2+F/VojcX4XbL5Z34KR6yxa19Q+iGGXFk=; b=YCGB0IyX0t3eysZTLlSwvJiv9Q31uNvE76+zutMBQnD1w/DEW93XBhTN13giXmnZEjQxBvufv7hpi4o4yzHYzM4Xeq1OCtvPbyg/nVtj/muERaONnRMYDWRRTB/0h3X0amJG98G7JM0nlvShTHplBF0yHNwhm3IGBzk8ub5tWp4= Received: from AM6PR07MB4822.eurprd07.prod.outlook.com (20.177.190.219) by AM6PR07MB5352.eurprd07.prod.outlook.com (20.177.198.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.11; Fri, 14 Dec 2018 10:33:40 +0000 Received: from AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d]) by AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d%5]) with mapi id 15.20.1446.006; Fri, 14 Dec 2018 10:33:39 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jaro Fietz , "core@ietf.org" CC: =?utf-8?B?J0NocmlzdGlhbiBNLiBBbXPDvHNzJw==?= , Francesca Palombini , "martin.striegel@aisec.fraunhofer.de" , Stefan Hristozov , "jaro.fietz@gmx.de" Thread-Topic: OSCORE: Status Update on the C Implementation of an OSCORE Server Thread-Index: AQHUkvIR/OT3z7quJk6jkgnrIEBquKV+G9CA Date: Fri, 14 Dec 2018 10:33:39 +0000 Message-ID: <6A66D31F-EC70-438E-8243-94FC5171863D@ericsson.com> References: <20181011110943.GE31858@hephaistos.amsuess.com> <3E80C9C0-E03A-4EAE-8CAD-8063DC93C1A5@ericsson.com> <2608c3f9-907f-6f22-2c9e-bef30f9c0ef3@aisec.fraunhofer.de> <53AFBD47-6D9D-47FA-82E5-F1C8F5DC6F1F@ericsson.com> <3f288e89-ea41-5da5-ddb1-f5eada5a39cc@aisec.fraunhofer.de> In-Reply-To: <3f288e89-ea41-5da5-ddb1-f5eada5a39cc@aisec.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181109 x-originating-ip: [192.176.1.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB5352; 6:mgW0VXxhZ97ogRnmThGuRKahyCRv4dS73n4o6RK+JqJv/n/FbNi+4vH1uU+S4ZxmjPQvTV3OJu0YQsbI0yoT9j9wGDyva3lDAAsl3sGHavAEffDRGaCzQLZf15dF5LlXJpewKqv8rJ9EikyS3Nlg+62XDV1YYUYF7s8dQn0VhU/E9mF342Q6stggsLYrRSDo4HEoR06uHQXi/HFPKN6j5ykMVn9yVYBHpm2INBMMY1J0leenmxOpypBATVsV8PgMHPX813sbaxOYv2w2rDO3XAiPc2FKswB1i92+pn1Sk8HqFbauk5VCw0lPTlG/VWIeMIpg8pMXAFxdTG6K+tEWRaY+jJlhJgTrV08MitOznKQAcHE88nskw24skAxw7fWXYjZIzudUiBuW6OLkZjVWNAyWrWpPfe3cuFblRpeJMYsO5Ub2j8BQwSF4N/4CDKKUWzQG+sJVpZYYK68cviO9Ug==; 5:J9peV9ZPosQZPTdMAUx8tP6e3+6rU1BTNRlPE8z/jfBfmdsZS2A23qVxM7fXdKcu9x97B82EcQIoQh1xwC1uFzIWAv4qMAYFdRjr2KJVMfY1pcVk8TSQNnTnHrgwpZDY+2FWai7ubZ86P2vWQjr6SRwUJcyCUBWTYM2kTvdiYyw=; 7:6XaSdF2uMCHc6e60kZu8o3++N2j9wHrm8jNVV+zoyiSytn/IW6o2ssg2jfv/9SyhDWswnJ83cQeRxvOhxKAiucqZ7HexTj0pxS0ZgBy1DJn6YfkW5xkiKcuxmgrRBdtbJIFgLYtZticFIvRW86umTQ== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(366004)(39860400002)(396003)(189003)(199004)(51914003)(53754006)(7736002)(6486002)(476003)(305945005)(966005)(15650500001)(2616005)(76176011)(68736007)(229853002)(3846002)(6116002)(4001150100001)(6246003)(6436002)(33656002)(58126008)(25786009)(93886005)(486006)(85182001)(6512007)(316002)(8676002)(83716004)(53546011)(6306002)(71190400001)(71200400001)(5660300001)(66066001)(14454004)(81166006)(81156014)(66574011)(97736004)(26005)(82746002)(186003)(54906003)(8936002)(110136005)(102836004)(14444005)(256004)(36756003)(446003)(11346002)(2906002)(85202003)(106356001)(86362001)(99286004)(2501003)(105586002)(4326008)(6506007)(53936002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5352; H:AM6PR07MB4822.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: 412a9c0a-913e-4448-c949-08d661af9ca3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB5352; x-ms-traffictypediagnostic: AM6PR07MB5352: authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231475)(944501520)(52105112)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051); SRVR:AM6PR07MB5352; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5352; x-forefront-prvs: 08864C38AC received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zNAplV+grF4ZHv5LPEK81ZyVrbVudTPp/CHNDr4PQ/oO/mRK2BRArU/sSietpUW2wNMsbC7fx8Wl2y854ZTD5z5qIfHOddI5Rv43OD81VGEDRZepvY4YMy9AvO4afulo9ZzPEU8osgh4jGY8irsCOiaHQFLjpugR5TN3dtnSOY33EuXlwt6H/cci2hLzIbDkTjPUa5knaNv7oIWHOKKeKyXFL3rkJpHCCEJWYTSabIV0pjIgiDRRglymW592u23iMOiWvYZ+BU4F4BzxKGOLCNrl2DCE2xYZpCMQptQN5zOWbBqJFKjSAU4xt/UFiZqY spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6BA871C05BC5D740A53725D8DB0ABC72@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 412a9c0a-913e-4448-c949-08d661af9ca3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 10:33:39.3883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5352 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUiTcRjH+e09fJVWP6fmoyLUwD8SPMkaYWUYNTok+6OkxFz6ost5sJnl EUzNjqmlppRzXmRmas55pKYpWiSK4lFKWanpwIO0ovKmcnsX9N/neb7f54KHIQS1lD0jjYpl 5VESmZC2IPMDmq64UDetAt1Lyh1E7c13SFH7gpYQzU4k06KUah0SNS/1kKJ366VmPrS4Qv2R Fqs61yjxt+9B4rKyVd4p8pyFdygrk8axcrcDwRbhtS+rqJhR0dWq0mVaiTR7VcicAbwbhnRp hApZMAL8CoFmrMAULCG4PdZmZnAJcBkPtIuxBoHEWQQMD28gzpXHA934Q1MwhaByJZdnKKHx YZhUThnZGp+GhuwRymAicBMPFt+MGPtaYT/omF8mOZM/tG80II49IW9o2sgkdgJdim7TzzB8 fBCeFcq4YQUENGcVGfuY46Mwk6mnDYzwdljurTYOJrAtjOmLedylGMraBgiObWBu+jdlYBvs Bmm9d824/A7orligOXaE4eJ042WAR2nQD42aTB7Q/aSD4IQJGopTxylOOAl9ddkUJwwiaO3P MVU4w+LsCI9bLwhSapSmERGgmcxEWchT/d+26s1LCbwLtM/duLQYapQDZhzvhNz0z0bmY0vo ydeTJYiqRDYKVnExMszT05WVS0MUiugo1yg2tg5t/lFnw7p7M5qbOdSFMIOEW/hVyVaBAkoS p4iP7ELAEEJr/pm0zRQ/VBKfwMqjL8gvy1hFF3JgSKEtf0NgGSjAYZJYNoJlY1j5P5XHmNsr ke9Z/77HdvWdg97ahsTFBM38+dBtfrBn9FriUsGjCZf+xv0tf177fpA+/VS4ctz1fpKXX731 JVXQvox7asuVAN9VVVu19r1z5/Ufc7Llxhde5aJ44sTs263HmlBGy5dxp1/R3qkz0Q8kdWrp kVC71hDHJGERzffRl+asfU39eSv4hpBUhEs8nAm5QvIX6mRZrkMDAAA= Archived-At: Subject: Re: [core] OSCORE: Status Update on the C Implementation of an OSCORE Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 10:33:47 -0000 SGVsbG8gSmFybywNCg0KR3JlYXQgbmV3cywgdGhhbmtzIGZvciBzaGFyaW5nIHRoaXMhIFBsZWFz ZSBrZWVwIHVzIHVwZGF0ZWQgb24gdGhlIHByb2dyZXNzLg0KDQpCZXN0IHJlZ2FyZHMsDQpHw7Zy YW4NCg0K77u/T24gMjAxOC0xMi0xMywgMTU6NDIsICJKYXJvIEZpZXR6IiA8amFyby5maWV0ekBh aXNlYy5mcmF1bmhvZmVyLmRlPiB3cm90ZToNCg0KICAgIEhleSBldmVyeW9uZSwNCiAgICANCiAg ICBhZnRlciBJJ3ZlIHJlY2VpdmVkIHNldmVyYWwgZm9sbG93LXVwIG1haWxzIGFib3V0IG15IG1p bmltYWwgQyANCiAgICBpbXBsZW1lbnRhdGlvbiBvZiBhbiBPU0NPUkUgc2VydmVyIG9uIHRvcCBv ZiB0aGUgZW1iZWRkZWQgT1MgWmVwaHlyLCANCiAgICBJJ3ZlIGRlY2lkZWQgdG8gZ2l2ZSBldmVy eW9uZSBhbiB1cGRhdGUgb24gbXkgcHJvZ3Jlc3MuIEkndmUgaW1wbGVtZW50ZWQgDQogICAgYSBz dWJzZXQgb2YgdGhlIE9TQ09SRSBEcmFmdCBWZXJzaW9uIDE0IGluIEMsIGxlYXZpbmcgb3V0IG1v c3Qgb3B0aW9uYWwgDQogICAgZmVhdHVyZXMuIE15IGltcGxlbWVudGF0aW9uIHByb3ZpZGVzIGEg bWluaW1hbCB3b3JraW5nIE9TQ09SRSBzZXJ2ZXIgZm9yIA0KICAgIGFuIGVtYmVkZGVkIGJvYXJk IChpbiBteSBjYXNlIHRoZSA5NiBCb2FyZHMgQkxFIE5pdHJvZ2VuKS4gSXQgaXMgYmFzZWQgDQog ICAgb24gWmVwaHlyIGFzIHRoZSB1bmRlcmx5aW5nIGVtYmVkZGVkIG9wZXJhdGluZyBzeXN0ZW0g YnV0IHNob3VsZCBiZSANCiAgICBlYXNpbHkgYWRhcHRhYmxlIHRvIG90aGVyIG5lZWRzLg0KICAg IA0KICAgIFRoZSBpbXBsZW1lbnRhdGlvbiBpcyBub3cgZmluaXNoZWQgZmVhdHVyZSB3aXNlLiBL ZXkgZGVyaXZhdGlvbiB3YXMgDQogICAgdGVzdGVkIGFnYWluc3QgdGhlIEFwcGVuZGl4IEMuMS4y IHRlc3RjYXNlIGZyb20gdGhlIHNwZWNpZmljYXRpb24gWzFdLiANCiAgICBBZGRpdGlvbmFsbHks IHRoZSBzZXJ2ZXIgc3VjY2Vzc2Z1bGx5IHJlc3BvbmRzIHRvIHRoZSBPU0NPUkUgVGVzdF8xYSBb MV0gDQogICAgKGV4ZWN1dGVkIHdpdGggYWlvY29hcCdzIHBsdWd0ZXN0IHNjcmlwdCkuIEkgaGF2 ZW4ndCBwZXJmb3JtZWQgb3RoZXIgDQogICAgdGVzdHMsIGJ1dCB0aGlzIHNob3VsZCBiZSBnb29k IGVub3VnaCB0byBleGNoYW5nZSBzaW1wbGUgZW5jcnlwdGVkIG1lc3NhZ2VzLg0KICAgIA0KICAg IEknbSBjdXJyZW50bHkgaW4gdGhlIHdvcmtzIG9mIG9wZW4gc291cmNpbmcgdGhlIHByb2plY3Qu IEkgZXhwZWN0IHRoZSANCiAgICBzb3VyY2UgY29kZSB0byBiZSBwdWJsaXNoZWQgb24gZ2l0aHVi IG1pZCB0byBsYXRlIEphbnVhcnkuIEkgaG9wZSB0aGF0IA0KICAgIHRoaXMgd2lsbCBiZSBxdWlj ayBlbm91Z2ggZm9yIFJJT1QuIEknbGwgd3JpdGUgdG8gdGhlIE1MIG9uY2UgdGhlIHNvdXJjZSAN CiAgICBjb2RlIGlzIGF2YWlsYWJsZSAob3Igb25seSB0byBpbmRpdmlkdWFsIHBlb3BsZSBpbiBj YXNlIHRoaXMgaW5mb3JtYXRpb24gDQogICAgaXNuJ3QgcmVsZXZhbnQgdG8gdGhlIE1MKS4NCiAg ICANCiAgICBCUiwNCiAgICBKYXJvDQogICAgDQogICAgWzFdOiANCiAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0xNCNhcHBlbmRp eC1DLjEuMg0KICAgIFsyXTogaHR0cHM6Ly9lcmljc3NvbnJlc2VhcmNoLmdpdGh1Yi5pby9PU0NP QVAvdGVzdC1zcGVjNS5odG1sI3Rlc3QtMWENCiAgICANCiAgICBPbiAxMS8yNi8xOCAzOjE4IFBN LCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQogICAgPiBIaSBKYXJvLA0KICAgID4NCiAgICA+IFRo YW5rcyBmb3IgdGhlIHVwZGF0ZSENCiAgICA+DQogICAgPiBJIHVuZGVyc3RhbmQgeW91IGNhbid0 IHByb21pc2UgYW55dGhpbmcgaGVyZS4gVGhlIHF1ZXN0aW9uIEkgZ290IHdhcyBmb3IgYSBDLWlt cGxlbWVudGF0aW9uIHdoaWNoIHdhcyBub3QgdGFpbG9yZWQgZm9yIGEgcGFydGljdWxhciBjb25z dHJhaW5lZCBwbGF0Zm9ybSBPUywgbGlrZSB3aGF0IGV4aXN0cyBmb3IgQ29udGlraSBORyBhbmQg T3BlbiBXU04uIEZvciB5b3VyIGluZm9ybWF0aW9uLCB0aGUgcGVvcGxlIEkgdGFsa2VkIHRvIGF0 IFJJT1Qgd2FudHMgdG8gc3RhcnQgYWZ0ZXIgdGhlIG5ldyB5ZWFyIGhvbGlkYXlzLCBzbyBhbnl0 aGluZyBhdmFpbGFibGUgYXJvdW5kIHRoYXQgdGltZSB3b3VsZCBiZSB2ZXJ5IHdlbGNvbWUuDQog ICAgPg0KICAgID4gVGhhbmtzLA0KICAgID4gR8O2cmFuDQogICAgPg0KICAgID4NCiAgICA+IE9u IDIwMTgtMTEtMjYsIDE0OjM5LCAiSmFybyBGaWV0eiIgPGphcm8uZmlldHpAYWlzZWMuZnJhdW5o b2Zlci5kZT4gd3JvdGU6DQogICAgPg0KICAgID4gICAgICBIZWxsbyBHw7ZyYW4sDQogICAgPiAg ICAgIA0KICAgID4gICAgICB3ZSBhcmUgcGxhbm5pbmcgb24gb3Blbi1zb3VyY2luZyB0aGUgQyBp bXBsZW1lbnRhdGlvbiwgSSdtIGluIHRoZSB3b3Jrcw0KICAgID4gICAgICBvZiBmaWxsaW5nIGlu IHRoZSBwYXBlcndvcmsuIEN1cnJlbnRseSBJJ20gaW4gdGhlIGJ1Z2ZpeGluZyBzdGFnZSwgc28N CiAgICA+ICAgICAgdGhlIGNvZGUgaXNuJ3QgZnVuY3Rpb25hbCBxdWl0ZSB5ZXQuIE9uY2UgSSBo YXZlIGEgbWluaW1hbCB3b3JraW5nDQogICAgPiAgICAgIGV4YW1wbGUgYW5kIHdlIGhhdmUgdGhl IGdvLWFoZWFkIGZvciBvcGVuLXNvdXJjaW5nIGl0LCBJJ2xsIGxldCB5b3UNCiAgICA+ICAgICAg a25vdy4gSSBob3BlIHRoYXQgaXQnbGwgaGFwcGVuIHdpdGhpbiB0aGUgbmV4dCBtb250aCwgYnV0 IGNhbid0DQogICAgPiAgICAgIGd1YXJhbnRlZSBhbnl0aGluZy4NCiAgICA+ICAgICAgDQogICAg PiAgICAgIEJSLA0KICAgID4gICAgICBKYXJvDQogICAgPiAgICAgIA0KICAgID4gICAgICBPbiAx MS8yMy8xOCA0OjA0IFBNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQogICAgPiAgICAgID4gSGVs bG8gSmFybywNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IEknbSBjdXJpb3VzIGFib3V0IHRo ZSBjb250aW51ZWQgc3Rvcnkgb2Ygb25lIG9mIHRoZSBxdWVzdGlvbnMgZnJvbSBDaHJpc3RpYW4s IGJlbG93Lg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gT24gMjAxOC0xMC0xMSwgMTQ6NDIs ICJjb3JlIG9uIGJlaGFsZiBvZiBKYXJvIEZpZXR6IiA8Y29yZS1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBqYXJvLmZpZXR6QGFpc2VjLmZyYXVuaG9mZXIuZGU+IHdyb3RlOg0KICAgID4g ICAgICA+DQogICAgPiAgICAgID4gICAgICBIZWxsbyBDaHJpc3RpYW4sDQogICAgPiAgICAgID4N CiAgICA+ICAgICAgPiAgICAgIHRoYW5rcyBmb3IgeW91ciBxdWljayBhbnN3ZXIsIGl0IGNsYXJp ZmllZCB0aGUgc2Vjb25kIG9mIG15IHF1ZXN0aW9ucy4NCiAgICA+ICAgICAgPg0KICAgID4gICAg ICA+ICAgICAgT24gMTAvMTEvMTggMTowOSBQTSwgQ2hyaXN0aWFuIEFtc8O8c3Mgd3JvdGU6DQog ICAgPiAgICAgID4gICAgICA+IFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBzaG9ydGVzdCAo emVyby1sZW5ndGgpIElEIHdvdWxkIGJlIHVzZWQgaW4NCiAgICA+ICAgICAgPiAgICAgID4gY2Fz ZXMgd2hlcmV2ZXIgdGhhdCdzIGJlbmVmaWNpYWwsIGVnLiB3aGVuIGEgY29uc3RyYWluZWQgZGV2 aWNlDQogICAgPiAgICAgID4gICAgICA+IHByaW1hcmlseSB1dGlsaXplcyBvbmUgY29udGV4dCBp biB3aGljaCBpdCBpcyBhZGRyZXNzZWQgYXMgYSBzZXJ2ZXIuDQogICAgPiAgICAgID4gICAgICBU aGlzIGlzIGFuIGludGVyZXN0aW5nIG9wdGltaXphdGlvbi4gSSdtIG5vdCB0b28gc3VyZSBhYm91 dCB0aGUgYWN0dWFsDQogICAgPiAgICAgID4gICAgICBiZW5lZml0cyB0aG91Z2guIFRvIG1lIHRo aXMgd291bGQgb25seSByZXN1bHQgaW4gdGhlIGNvbnN0cmFpbmVkIG5vZGVzDQogICAgPiAgICAg ID4gICAgICBiZWluZyBhYmxlIHRvIHNoYXZlIG9mZiBhIGZldyBieXRlcyBvZiBhbGxvY2F0aW9u IHdoZW4gY29uc3RydWN0aW5nIHRoZQ0KICAgID4gICAgICA+ICAgICAgcmVzcG9uc2UgYW5kIHNh dmluZyB0aGVpciBzZW5kZXJfaWQgdG8gcGVyc2lzdGVudCBzdG9yYWdlLg0KICAgID4gICAgICA+ ICAgICAgPiBZb3UgYnJpZWZseSBoYWQgbWUgd29ycmllZCBJIGdvdCBpdCB3cm9uZyBteXNlbGYg LS0gYnV0IHRoZQ0KICAgID4gICAgICA+ICAgICAgPiBsZWZ0LXRyaW1taW5nIHRoYXQncyBoYXBw ZW5pZ24gaXMgb24gdGhlIHNlcXVlbmNlIG51bWJlcnMsIG5vdCBvbiB0aGUNCiAgICA+ICAgICAg PiAgICAgID4gc2VuZGVyIElEcy4NCiAgICA+ICAgICAgPiAgICAgIFNvcnJ5LCBJIG11c3QgaGF2 ZSBza2lwcGVkIGluY29ycmVjdGx5IG92ZXIgdGhlIHR1cGxlIGNvbnN0cnVjdGlvbi4NCiAgICA+ ICAgICAgPiAgICAgIFJlYWRpbmcgdGhyb3VnaCBpdCBhZ2FpbiwgeW91ciBjb2RlIGlzLCBvZiBj b3Vyc2UsIGNvcnJlY3QgOikNCiAgICA+ICAgICAgPiAgICAgID4gU2xpZ2h0bHkgb2ZmIHRvcGlj OiBXb3VsZCB0aGF0IGhhcHBlbiB0byBiZSBhIGZyZWVseSBsaWNlbnNlZA0KICAgID4gICAgICA+ ICAgICAgPiBpbXBsZW1lbnRhdGlvbj8gSWYgc28sIEkga25vdyBvZiBhbiBlbWJlZGRlZCBvcGVy YXRpbmcgc3lzdGVtIHByb2plY3QNCiAgICA+ICAgICAgPiAgICAgID4gdGhhdCB3b3VsZCBsb3Zl IHRvIGhlYXIgYWJvdXQgdGhpcy4NCiAgICA+ICAgICAgPiAgICAgIEknbSBpbXBsZW1lbnRpbmcg T1NDT1JFIG9uIHRvcCBvZiB6ZXBoeXIgKG5vdCBpbnRlZ3JhdGVkIGludG8gaXQpIGZvciBhbg0K ICAgID4gICAgICA+ICAgICAgZW1iZWRkZWQgYm9hcmQuIEN1cnJlbnRseSBpdCBpc24ndCBvcGVu IHNvdXJjZSwgYnV0IEkgYXNrZWQgbXkgYWR2aXNvciwNCiAgICA+ICAgICAgPiAgICAgIHdobyds bCBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvIHRoZSBzdXBlcnZpc29yLg0KICAgID4gICAgICA+ICAg ICAgSnVkZ2luZyBmcm9tIHlvdXIgZ2l0aHViIGhpc3RvcnkgSSBleHBlY3QgeW91IGFzayBmb3Ig UklPVC1PUz8gOikNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IEhhdmUgeW91IGRlY2lkZWQg YWJvdXQgb3BlbiBzb3VyY2U/IEkgYWxzbyBnb3QgcXVlc3Rpb24gZnJvbSBwZW9wbGUgd29ya2lu ZyBSSU9ULU9TIF9fDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiBCUg0KICAgID4gICAgICA+ IEfDtnJhbg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPg0KICAgID4g ICAgICA+DQogICAgPiAgICAgIA0KICAgID4gICAgICANCiAgICA+DQogICAgDQogICAgDQoNCg== From nobody Fri Dec 14 02:59:46 2018 Return-Path: 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 6E09112D84D for ; Fri, 14 Dec 2018 02:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.781 X-Spam-Level: X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dsrOzeJ7; dkim=pass (1024-bit key) header.d=ericsson.com header.b=atjpXFFT 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 OACR6jnkjJba for ; Fri, 14 Dec 2018 02:59:42 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C738A127AC2 for ; Fri, 14 Dec 2018 02:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544785179; x=1547377179; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eB4Y1RwD7hO4VwC60VKNUiMhatVPUa1y4neS5P5BWes=; b=dsrOzeJ7xHS/+arTo900Vx04g3Mt5i1DUBuZUaA+L7kXN0kdRm2LD7RkFAEifvo9 drdmUfhWIdEct3vYT9Vxi90jRrGRBIbWM1nxmXYQHSbXyPZQ8CaxEqNR39IWUc+i v7kPMLChlTIEjoXSNJL/6Dcb/Xn6Y2fl02WxGdw53yM=; X-AuditID: c1b4fb25-da1ff70000005ff7-3e-5c138d1b21e0 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.54.24567.B1D831C5; Fri, 14 Dec 2018 11:59:39 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Dec 2018 11:59:39 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Dec 2018 11:59:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eB4Y1RwD7hO4VwC60VKNUiMhatVPUa1y4neS5P5BWes=; b=atjpXFFTQ75ykPR4U5lM55L2KU47/HYXC/QxY/u50wTlSXtpDZpfKteuE7UG7xljnrw0qxVmnIf29Ya6L3ACwF6ul7qMg6EkWknmzdA7Ve76gD0fe6YJaPmkMsrO26ghb32zTOaAIXrmudIffZAPQ/KoGoaizNYc5wHP6GMQYvU= Received: from AM6PR07MB4822.eurprd07.prod.outlook.com (20.177.190.219) by AM6PR07MB5158.eurprd07.prod.outlook.com (20.177.198.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.9; Fri, 14 Dec 2018 10:59:38 +0000 Received: from AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d]) by AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::3d6f:cb36:583b:269d%5]) with mapi id 15.20.1446.006; Fri, 14 Dec 2018 10:59:38 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: Groupcomm for CoAP (RFC 7390) implementations Thread-Index: AQHUk5wb1rHWGBZAhU287Ez7+Sa8FQ== Date: Fri, 14 Dec 2018 10:59:38 +0000 Message-ID: <9F1B592D-E78C-4E2F-8402-EF029CAC1421@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181109 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB5158; 6:OKt9p87pkcmL1Mw4RwsjMhBLtOB3XTNSpp96nRrWQKbY/d72j4oJi6i14WetP/qoR5i+fyfsNvBXguaXtGOzEWXk5wjMOz40/O9uN2TOFX07ySr3cWguQndGqBQcLd8lSkE4D0xhyc/qPx/Yu6PE9lAlZdeGqrrbvVaIkm6rOMMp+UnZPegUvRERrXrr+71fwyUico2oL+eTwUVGuIG3fdsLv/5R902X89b3vqrdkZPBs82S1CfkB32Ne/6cCVLRfLFs9CNgyJ2DywlpCow8biuueHbaPyPFg0tseJHGuipBEu5zJr674GlUcVFeM94opRAyaH0W/qzooS+eCIAhhroMCNZ2JykMzYv3Md08Y/5J5nofLfsbesglJNLY+1L+9NBUOOjqvsSTYCEt0srYArSaw9GaB2s6aLW7l/4phmMJHfI8kO+58R2L32fh3BSlODqlzKtl2W9cCSvjnPXC+Q==; 5:3nVDChmzoaPYTuViXz2O0NfOvaks2yP0fe4UnkyT7U/PzubFtU2tK8zVXdBMzwguN/AkCgtOKHQKVQSsvpSu9i7qtqPD38oRGFXvVsbFGNz4l2wzqWN6GiXjDw7qnlHaLuV7PgT/J+J8g1xl4VbgEo8HpjcWiRnz9TeBiEOGlRY=; 7:QQIMPxos4NopW7AA3f7ld4thuJalEa9QOgGpmRwLnQbuJxbwyr7eqUyjuwcjm+34A9cO/aA/T3CriSQ9YlcY5mUHGJKdXiFsRfYKD2iE1NC5On7YhrAJrSx19ojfBw4sRC/1w0cWwQMgGv8NzJuo6A== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ac4584f3-2c85-4f0f-238c-08d661b33e1d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB5158; x-ms-traffictypediagnostic: AM6PR07MB5158: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3231475)(944501520)(4982022)(52105112)(3002001)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5158; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5158; x-forefront-prvs: 08864C38AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(136003)(346002)(366004)(189003)(199004)(97736004)(36756003)(85182001)(102836004)(5640700003)(2906002)(6506007)(105586002)(966005)(86362001)(14454004)(2351001)(316002)(82746002)(305945005)(33656002)(85202003)(106356001)(93376004)(6486002)(71200400001)(7736002)(186003)(83716004)(71190400001)(558084003)(68736007)(8676002)(25786009)(1730700003)(81156014)(81166006)(6306002)(99286004)(256004)(8936002)(53936002)(6436002)(6116002)(3846002)(486006)(478600001)(2616005)(5660300001)(476003)(58126008)(6916009)(6512007)(2501003)(26005)(66066001)(15302535012); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5158; H:AM6PR07MB4822.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NH9xuXFZ5X2B/H2BpzxU7CSxAmwJqlegWPHw4grDik5yv3sgF7msyFCJl/x90VcBB2VodeZ/UuhuAnQZwdczldcDXKGl6J7YY0pIIopTEVfKguVImgxUDicU88b3zdjTWr9RYeI+vS8H/6BPlhVy8m8s2j6+aTyqP0/6cCuEyprQxsJ867R/3RH9YE3CIg3rKeF8mdj5qYqy8bnkjlkUGZ6chkxjk49solPtd62Arh4HuD3vpRKc24tO5lGNcE3xOtjd66amXbsP0R80vhuIQEq+pZgAcyFXFLpyiLWhvUPJrppwOow3TyT4izKt6I46 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac4584f3-2c85-4f0f-238c-08d661b33e1d X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 10:59:38.7150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5158 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XbOtuNw9Dk137RCV0IJXsoII7ECA0mEogsmI5t50LE5bcck i3Qp/qFDXKh/eCkvbVpqSaYpppIjFUVSU1NL8jaTyIlBas5hbTsn6L/f8zzv+/I98FGEJJ/v TSnU6bRGLVdJBSKyLLadCfQpdJeFFOtOhfVYmomzKMpg2OZdRHGi8ERapcigNcERN0XJa5PL KG2Nd7dk1cjXIjOvALlQgE/Aixo9vwCJKAl+j8C6PIxYsYnAsrZKssLAg+qndUKHILGegPX+ PwI2KeaBrbSCE4sIqpuNzssCHAnz2kUne+BD8Hr4B3KwOz4J07XdJOufBmPrbwHLQfB2rJvv YBL7w5ypwj5DUWJ8BiZXbjtshPfC1lCT8ySBveCzuYorgcHQNUKw7Anfl3adZzxxMOQNFQnZ 3RuQ81IrYGd8YeCZheMD8LFK5+wM+JMAWnoGuSAQ1ktLuaMxYMzpErBDowimxyx8NggA6+YA x0r4ZZvgXnQQGgoXSHZhgYCi/D4u2A+vvjZxwS4fKnqnhHoUXP5fpXJ7awIfheZOzo6CJx/0 BMt+UKJbEDpYjN1gsMxMViN+A/JkaCYhJel4aBCtUdximFR1kJpOb0H2D9LbuuPfgcZXz5kQ ppDUVRz90F0m4cszmMwUEwKKkHqIr+XZLXGiPPMerUmN19xR0YwJ+VCk1Etsk7jJJDhJnk4r aTqN1vxLeZSLtxbFqpoe33dt69uCmZpJI1P1bifsZ6U4IlphVV4SqawxM7bMsDrt4dEL6rQj 2Z371LP6/oardED70CPl9W9f/N7Mh9ZfLlmWZGu7dq9oxjt898yuwPTGtiw+rja8cyTe+Dyk dj5ybqO+LWQmayrX4FqZkGs+36gs18VmNeoeLE1ISSZZfiyA0DDyv8W3MEYcAwAA Archived-At: Subject: [core] Groupcomm for CoAP (RFC 7390) implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 10:59:44 -0000 QWxsLA0KDQpEb2VzIGFueW9uZSBrbm93IGlmIHRoZXJlIGlzIGEgbGlzdCBvZiBDb0FQIGltcGxl bWVudGF0aW9ucyBzdXBwb3J0aW5nIFJGQyA3MzkwIChHcm91cCBDb21tdW5pY2F0aW9uIGZvciBD b0FQKT8gDQoNCmh0dHA6Ly9jb2FwLnRlY2hub2xvZ3kvIG1lbnRpb25zIFJGQyA3MzkwIHVuZGVy ICJzcGVjaWZpY2F0aW9ucyIgYnV0IEkgZGlkbid0IGZpbmQgYW55dGhpbmcgdW5kZXIgImltcGxl bWVudGF0aW9ucyIuDQoNClRoYW5rcw0KR8O2cmFuDQogDQoNCg== From nobody Fri Dec 14 03:18:27 2018 Return-Path: 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 6C6211310CB for ; Fri, 14 Dec 2018 03:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZR_p-Xd1x7h6 for ; Fri, 14 Dec 2018 03:18:23 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42713130F85 for ; Fri, 14 Dec 2018 03:18:22 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BEECF4248B; Fri, 14 Dec 2018 12:18:19 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id CD65BDB; Fri, 14 Dec 2018 12:18:18 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AD5C134A; Fri, 14 Dec 2018 12:18:17 +0100 (CET) Received: (nullmailer pid 20708 invoked by uid 1000); Fri, 14 Dec 2018 11:18:17 -0000 Date: Fri, 14 Dec 2018 12:18:17 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20181214111816.GA19507@hephaistos.amsuess.com> References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> <04f001d4926d$9eac0070$dc040150$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <04f001d4926d$9eac0070$dc040150$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 11:18:25 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2018 at 02:54:18PM -0800, Jim Schaad wrote: > I was rather afraid that this was the case. So just to be specific becau= se > this is the context that I ran across the issue. >=20 > As a client I am looking for an RD to register with. So I send the reque= st: >=20 > Req: GET coap://[MCD1]/.well-known/core?rt=3Dcore.rd* >=20 > I get back one or more responses with the following links: >=20 > Res: 2.05 Content > ;rt=3D"core.rd";ct=3D40, > ;rt=3D"core.rd-lookup-ep";ct=3D40, > ;rt=3D"core.rd-lookup-res";ct=3D40, >=20 > (Note this is an example that is copied straight out of the RD draft.) >=20 > I am now going to register myself by sending a registration request: >=20 > Req: POST coap://[MCD1]/rd?ep=3Dnode1 Nope -- you're following a reference, and the base URI already contains the IP literal that sent the response. Therefore, your registration POST already goes to a unicast address. > Since multicast is defined as not needing to return any error messages (s= uch > as a 4.01 Unauthorized). I don't think that's a general rule. A server MAY pretend it didn't get the message if there's nothing usefult o respond, but the decision is made per application, and it's only the .well-known/core discovery that says that a no-match should not be reported. A "2.04 Changed" is useful. As said, this won't affect regular registration anyway due to the path discovery lookup step that bakes in the unicast address. In simple registration, a POST to a multicast can happen; there, I'd expect that the simple client goes into "I'm good for $LIFETIME" mode whenever it receives the first 2.04. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwTkXUACgkQOY0REtOk veFUShAAuJp5NAzQ78K8ZN4ECg3qUb5WiWEOPPyTJYmSoBOl0mWsbV320T+UQDqE v+6ZDa0cK1/MEfDS9HZis42kN4PecX/0YF9fsyTQUr8tJ0rBD9AM8JL+UNSyo8O0 1Ua23j9+UVxUYNmAMFvoZR9RmnBY+GAyAz7gw5GRGPmUzbpmhnLedX8GvAE8KMdu ydRTpBTP5CEXLPs5VCghnQImFtETYiVy2csd4Lk3SMA4IOThQMolRC2yqE4Uyf/J CHe7RImQwyu9hK1xI42PV8JN58Rf7iSIAOGZUoJs9Qyh/VU5jHrSRZEM/aLxM0vs T62kC+6QHoRuDcboW/uiZqcTGlsidaarlfRS8U1/U7srEpWD8Eiu5EBGI7Pe2/BW 6WGQNOs8kEdSnG4R4U+dksOOJ+kyv0GG2nfq3pv4rW+dt9BMrJh+UJyvbmMbnfiI xgmrpqZW/n3FSsw54vicb9DrbGfu5oScRdf7iXcMOSDgxV30hb9r5R+M7x3SRCM/ 9W59bWTP8N+bv/DFTBfLRjzBMPCZNvRCJF8gU1kqeiJNvcETOccFzTIUYOwvoM4m vYJtDfneVlU4FJjCiJJbLwC6ZiriFlDceFQDFdYG7/5r3kz5ERz7gs9wGwksWech HRCF5pqrDkmrgJMoxR6wMmzYBA13TxqdNjQLaH0ttzOvSxagqqo= =4R5a -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From nobody Fri Dec 14 03:27:12 2018 Return-Path: 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 6BD22130DCC for ; Fri, 14 Dec 2018 03:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8NoBNdPxDM_o for ; Fri, 14 Dec 2018 03:27:08 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95DF130F85 for ; Fri, 14 Dec 2018 03:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBEBQpCa011824; Fri, 14 Dec 2018 12:26:56 +0100 (CET) Received: from sev.informatik.uni-bremen.de (sev.informatik.uni-bremen.de [134.102.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43GStg60HQz1Br6; Fri, 14 Dec 2018 12:26:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20181212204344.GA665@hephaistos.amsuess.com> Date: Fri, 14 Dec 2018 12:26:54 +0100 Cc: Jim Schaad , core@ietf.org X-Mao-Original-Outgoing-Id: 566479612.85866-9e28f906c67de91acfbec0f4dfd5921d Content-Transfer-Encoding: quoted-printable Message-Id: References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 11:27:10 -0000 On Dec 12, 2018, at 21:43, Christian Ams=C3=BCss = wrote: >=20 > You resolve against (in RFC6690 link format: the origin of) the URI of > the requested resource, which in the CoAP case is constructed from the > request Uri-* options (RFC7252 section 6.5), but with the IP literal = of > the multicast request as per section 8.2 (last paragraph before 8.2.1; > "and any links embedded in the representation"). That may be worded a bit confusing. =46rom the horse=E2=80=99s mouth: For the purposes of interpreting the Location-* options and any links embedded in the representation, the request URI (i.e., the base URI relative to which the response is interpreted) is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding. End of https://tools.ietf.org/html/rfc7252#section-8.2 =E2=80=94 as you = noted. Link that leads you almost there: = https://tools.ietf.org/html/rfc7252#page-67 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 14 08:57:00 2018 Return-Path: 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 2E71C131153 for ; Fri, 14 Dec 2018 08:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 k39ROc9MGbJE for ; Fri, 14 Dec 2018 08:56:57 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8F3131107 for ; Fri, 14 Dec 2018 08:56:56 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Dec 2018 08:51:46 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= CC: References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> <04f001d4926d$9eac0070$dc040150$@augustcellars.com> <20181214111816.GA19507@hephaistos.amsuess.com> In-Reply-To: <20181214111816.GA19507@hephaistos.amsuess.com> Date: Fri, 14 Dec 2018 08:56:42 -0800 Message-ID: <002101d493cd$fe4f5de0$faee19a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKvYJd64JVfgBoXic1Peu5LlKMP+QGj0uT4AfzUiKQBfZRyjKOf6A/g Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 16:56:59 -0000 > -----Original Message----- > From: Christian Ams=FCss > Sent: Friday, December 14, 2018 3:18 AM > To: Jim Schaad > Cc: core@ietf.org > Subject: Re: [core] /.well-known/core and multicast addresses >=20 > On Wed, Dec 12, 2018 at 02:54:18PM -0800, Jim Schaad wrote: > > I was rather afraid that this was the case. So just to be specific > > because this is the context that I ran across the issue. > > > > As a client I am looking for an RD to register with. So I send the request: > > > > Req: GET coap://[MCD1]/.well-known/core?rt=3Dcore.rd* > > > > I get back one or more responses with the following links: > > > > Res: 2.05 Content > > ;rt=3D"core.rd";ct=3D40, > > ;rt=3D"core.rd-lookup-ep";ct=3D40, > > ;rt=3D"core.rd-lookup-res";ct=3D40, > > > > (Note this is an example that is copied straight out of the RD = draft.) > > > > I am now going to register myself by sending a registration request: > > > > Req: POST coap://[MCD1]/rd?ep=3Dnode1 >=20 > Nope -- you're following a reference, and the base URI already contains > the IP literal that sent the response. Therefore, your registration = POST already > goes to a unicast address. I don't see how you got to here. In you previous message you said: " You resolve against ... the origin of) the URI of the requested = resource ... the IP literal of the multicast request as per section 8.2" Now you are saying that you use the unicast response. I was assuming = that the request address is what is going to be used when I wrote this up. Jim >=20 > > Since multicast is defined as not needing to return any error = messages > > (such as a 4.01 Unauthorized). >=20 > I don't think that's a general rule. A server MAY pretend it didn't = get the > message if there's nothing usefult o respond, but the decision is made = per > application, and it's only the .well-known/core discovery that says = that a no- > match should not be reported. A "2.04 Changed" is useful. >=20 > As said, this won't affect regular registration anyway due to the path discovery > lookup step that bakes in the unicast address. >=20 > In simple registration, a POST to a multicast can happen; there, I'd expect that > the simple client goes into "I'm good for $LIFETIME" mode whenever it receives > the first 2.04. >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Fri Dec 14 09:14:45 2018 Return-Path: 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 88FED13116F for ; Fri, 14 Dec 2018 09:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ot9EvdoFHzHQ for ; Fri, 14 Dec 2018 09:14:41 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D69131177 for ; Fri, 14 Dec 2018 09:14:40 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id DFF7B42493; Fri, 14 Dec 2018 18:14:36 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5FE4CDB; Fri, 14 Dec 2018 18:14:35 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 20BF834A; Fri, 14 Dec 2018 18:14:35 +0100 (CET) Received: (nullmailer pid 25179 invoked by uid 1000); Fri, 14 Dec 2018 17:14:34 -0000 Date: Fri, 14 Dec 2018 18:14:34 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20181214171434.GB19507@hephaistos.amsuess.com> References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> <04f001d4926d$9eac0070$dc040150$@augustcellars.com> <20181214111816.GA19507@hephaistos.amsuess.com> <002101d493cd$fe4f5de0$faee19a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: <002101d493cd$fe4f5de0$faee19a0$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 17:14:44 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2018 at 08:56:42AM -0800, Jim Schaad wrote: > I don't see how you got to here. In you previous message you said: >=20 > " You resolve against ... the origin of) the URI of the requested resour= ce > .... the IP literal of the multicast request as per section 8.2" >=20 > Now you are saying that you use the unicast response. I was assuming that > the request address is what is going to be used when I wrote this up. My apologies -- what Carsten pointed out as me having "worded confusingly" is what I'd call plain wrong. The base address contains the IP literal of the source address of the response, which is a unicast address. Should read through mails once more before sending them. c --=20 There's always a bigger fish. -- Qui-Gon Jinn --qcHopEYAB45HaUaB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwT5PcACgkQOY0REtOk veFQLA//Xs1AkYlGzXgcfXBVbEMDjW7z75LoCF2U50TsGBu7ClllbUUG5/lIvCb1 LdWk01aB9fKjF0IIMJyrIhnoXsBIFr4Oryg23Q/Y9Q9zeVHNaueNdk10tk/GnMgW nTxbJA9/zhkUrBfSN4z97F+o9n2vyf5xTRoSjAl/uxH0VHdfBreTZeqP5HvadQ1B 7eR+eYEGlxwWuUzaK6W5WcEtLVRYU5czOegzJ0HQcynQPzsKo9CdjSsSVYOxWTdL Pb9EPjtZsv2tzdExvruMJmRhlWId4GJdqKjQ9PqyyK2+gyIj4LPM16h+yJK0Sona iVq6+y+tXi6U/pdIKcXkAvAeEGj4l2TuVkBylqslifFQdlTGShquMvjEzQ9HAb7k tWdvQEWC/wEcA/FvIYkRFqrCGV9jwlWvBuGePVfb5c+f37fRR5iOgEAtFFWptzy4 FBUZawMKoydRxsO7H3cInXb2kZHVlrDo9PF4leL/JDGS7GO3aHuNoxywp3f8RVSp deIpfKi6HUY+c5ZUK8wTDr83zxxrAlvfEYtkJaJOxuA5OEEAA13tphwyYjdWhSGt COStTvr/wqvxuCkYF9qYrLb6BtUZIe2SMsVfoNsO+0eCJD28laDMfAp4Y6XFSiki 1Np0uC1PgfR7D37nAsN/8v6eAY9zRx4iHqUuB/XYiZdzWjXBdbQ= =rTLu -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From nobody Sun Dec 16 05:33:45 2018 Return-Path: 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 36F4A126CB6; Sun, 16 Dec 2018 05:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] 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 Pcnf7m-UOvxm; Sun, 16 Dec 2018 05:33:40 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917F5124D68; Sun, 16 Dec 2018 05:33:39 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5C68342500; Sun, 16 Dec 2018 14:33:33 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 578E94D; Sun, 16 Dec 2018 14:33:31 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E81D934A; Sun, 16 Dec 2018 14:33:30 +0100 (CET) Received: (nullmailer pid 19481 invoked by uid 1000); Sun, 16 Dec 2018 13:33:30 -0000 Date: Sun, 16 Dec 2018 14:33:30 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org Message-ID: <20181216133329.GE22665@hephaistos.amsuess.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wchHw8dVAp53YPj8" Content-Disposition: inline In-Reply-To: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 13:33:44 -0000 --wchHw8dVAp53YPj8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, Peter, (trying to wrap up all the comments that have been exchanged here) On Mon, Dec 10, 2018 at 06:22:48PM -0800, Jim Schaad wrote: > * In section 5.3, I don't understand why the rule exists that if the > attribute values are different then the location of the registration needs > to be changed. It seems that this could lead to some interesting confli= cts > in behavior depending on what messages are used. Frankly, I don't understand why those rules need to be here in the first place -- from my PoV the only thing that matters is CoAP idempotency (ie. identical messages that arrive with no other related operations inbetween have the same result). Peter, any concrete ideas on how to clean them up -- preferably in a way that they don't speak of "updates"? (My alternative would be: "The following rules" and their items, and state that "Any Registration that has the same endpoint name and sector ('ep' and 'd' values) as a previously active one implicitly deletes that registration." -- the idempotency rule stays intact and allows some optimizations in terms of retransmission, but for everything else everyone pretty please use the Location returned, whatever that is.) > * In Section 5.3 - What is the correct behavior if the RD is configured = to > recognize an endpoint, but the endpoint supplies a different name? Is th= is > an error or does one of them override? 4.01 Unauthorized. Were the credentials valid for any other ep, the server could not "recognize" the endpoint; thus it follows that the credentials are not good enough to create a registration with the given ep value. > * In section 5.3.1 - I assume it would be an error to include the base > attribute - perhaps this should be explicit? (pvds): > The text says: "the base attribute is not accepted to keep the > registration interface simple" > Looks sufficient to me. Agreed. I'd expect 4.00 Bad Request, but whoever sends that is already in violation of the interface. > * In section 5.3.1 - When doing simple registration, I do not believe that > it should be a requirement that the result MUST be returned prior to doing > the query. See https://github.com/core-wg/resource-directory/issues/186 > * In section 5.3.1 - A valid response code might be 4.XX - method not > supported if this functionality is disabled. I am not sure what the "or = is > empty" means for the 4.04 response code. Which one is empty, the RD or t= he > EP?=20 The 4.04 is an error here IMO that has been reitrated time and again in the context of link format lookups (an empty list of links is distinct =66rom an absent list!); fixed. > * In section 5.3.1 - Is the RD responsible for dealing with resource-link > items which would not make sense by doing full resolutions on everything = or > re-writing them? (pvds) > For me a difficult question. "making sense" is very context/application d= ependent. > The less the RD decides about validity of link contents, the better I fee= l. It is generally demanded of the base URI that it "MUST be suitable as a base URI to resolve any relative references given in the registration". For regular registration that's explicit in the base parameter description, for simple that follows from the registrant needing to provide RFC6690 discovery (which doesn't work if links can't be resolved). If URIs make no sense, then that's the registrant's fault, and I don't see how the RD could tell whether they do. If the URIs can't be resolved (though I'm not sure the 3986 process defines any error condition at all), then I'd treat that as equivalent to any other syntax error in the submitted links (and either silently fail or return Bad Request depending on what comes out of the above on when the response is sent.) > * In section 5.4.1 - s/lt,con/lt,base/ Thanks, fixed. > * In section 5.4.1 - Description of 4.04 failure - I think this should be > 'may have been garbage collected' as I believe from previous text that one > should be able to refresh an expired registration. Should say "may have been removed (explicitly or after its expiration)"; that removal could have been explicit or as a concequence of an overly long expiration. Fixed. > * In section 6.4 - The example is missing the rt=3D"core.rd-ep" attribute= =2E It > appears to be required from the second paragraph. Thanks, fixed (also on other locations). > * In section 6.4 - Can you give an example of a "Links to endpoints"? The > only one that I can think of is 'base'. >=20 > * General - Should there be a value for lt which means infinite? I think there should at least be a value for "as long as this TCP or WebSocket connection is open" -- which primarily makes sense with an additional "and please build a base name for me and act as a forward proxy" parameter. Both can be covered using extensions. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --wchHw8dVAp53YPj8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwWVCYACgkQOY0REtOk veFOqw//TyibkAxGVFF5wIAApzTLl+oz1EenaKE8XUky3Gfcl3tjJ3KmAikIGoBf 5K+Q2fT/DbBmXCqu7nPBsEuWyGpSAnnQo8Ne7VIeCqj1wHnFh9Ln0YPxn/9sbWak sQAe9LOrzoJncATAjzwodwxhyo8EIfNM0xdqw6b1EqnynnWmb1PjDg9CyDJQ2sAZ aZ51MnBe8+NGFp/DyX+cbEzzMwRX9YtIvZZ+A98bQzfyQvdayMM1SY56g4E3rnN+ DkAtb3v9fSs/hsKoCkx7FFqgPLBhmj9GlG05njpTEHgzO7iLiVH9MiPnBN9RHBUP rM52W+OvrY7eramwpw5WuVMXTg4kARF+eQ8tGesVlZutwe504OlJGawQR6erTHjd Rbjr6QDDbm2JViApzboVPPa03Y3CtPKSA8Z1X1RIWOjYTL4hDpxI3EYsBn6vlGME k5W3NwfQvvxy1WLamHY9Nq6RW8/0r8FbLvin21EDPDcEyQs13xdoMzm3P/b+T2Df QBlMhMBkK1BPZuG+kuJKayyAIpoYN+onjAdH7aIX4UzNs9gRg1WmMuVmKWv9KnXl Q+o+rOOI2uZYeYG5k/5JeIna2xk4fRd5ZOs8hexhFamaJgCod0MRXeFN3wD58odV V8Oktwdd6yEq2Ie+sGuwJtbsATx7ZsnPf89vvTGMte3nH4srxG0= =iOPa -----END PGP SIGNATURE----- --wchHw8dVAp53YPj8-- From nobody Sun Dec 16 12:08:43 2018 Return-Path: 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 7624C12D4F2; Sun, 16 Dec 2018 12:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 44fbfYQefQAV; Sun, 16 Dec 2018 12:08:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB6A12D4EF; Sun, 16 Dec 2018 12:08:36 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 16 Dec 2018 12:02:58 -0800 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_M._Ams=FCss'?= CC: , References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <20181216133329.GE22665@hephaistos.amsuess.com> In-Reply-To: <20181216133329.GE22665@hephaistos.amsuess.com> Date: Sun, 16 Dec 2018 12:07:56 -0800 Message-ID: <010e01d4957b$0a717230$1f545690$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMTxjR7df64heLt4gs0blLr1Spp0AElK4Gtovo8ypA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2018 20:08:42 -0000 > -----Original Message----- > From: Christian M. Ams=FCss > Sent: Sunday, December 16, 2018 5:34 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org > Subject: Re: Questions and comments against the github version >=20 > Hello Jim, Peter, >=20 > (trying to wrap up all the comments that have been exchanged here) >=20 > On Mon, Dec 10, 2018 at 06:22:48PM -0800, Jim Schaad wrote: > > * In section 5.3, I don't understand why the rule exists that if = the > > attribute values are different then the location of the registration needs > > to be changed. It seems that this could lead to some interesting conflicts > > in behavior depending on what messages are used. >=20 > Frankly, I don't understand why those rules need to be here in the = first place -- > from my PoV the only thing that matters is CoAP idempotency (ie. = identical > messages that arrive with no other related operations inbetween have = the > same result). >=20 > Peter, any concrete ideas on how to clean them up -- preferably in a = way that > they don't speak of "updates"? >=20 > (My alternative would be: "The following rules" and their items, and = state that > "Any Registration that has the same endpoint name and sector ('ep' and = 'd' > values) as a previously active one implicitly deletes that = registration." -- the > idempotency rule stays intact and allows some optimizations in terms = of > retransmission, but for everything else everyone pretty please use the Location > returned, whatever that is.) >=20 > > * In Section 5.3 - What is the correct behavior if the RD is > > configured to recognize an endpoint, but the endpoint supplies a > > different name? Is this an error or does one of them override? >=20 > 4.01 Unauthorized. Were the credentials valid for any other ep, the = server > could not "recognize" the endpoint; thus it follows that the = credentials are not > good enough to create a registration with the given ep value. Ok, I can accept this. >=20 > > * In section 5.3.1 - I assume it would be an error to include the = base > > attribute - perhaps this should be explicit? >=20 > (pvds): > > The text says: "the base attribute is not accepted to keep the > > registration interface simple" > > Looks sufficient to me. >=20 > Agreed. I'd expect 4.00 Bad Request, but whoever sends that is already = in > violation of the interface. >=20 > > * In section 5.3.1 - When doing simple registration, I do not = believe > > that it should be a requirement that the result MUST be returned = prior > > to doing the query. >=20 > See https://github.com/core-wg/resource-directory/issues/186 >=20 > > * In section 5.3.1 - A valid response code might be 4.XX - method = not > > supported if this functionality is disabled. I am not sure what the > > "or is empty" means for the 4.04 response code. Which one is empty, > > the RD or the EP? >=20 > The 4.04 is an error here IMO that has been reitrated time and again = in the > context of link format lookups (an empty list of links is distinct = from an absent > list!); fixed. >=20 > > * In section 5.3.1 - Is the RD responsible for dealing with > > resource-link items which would not make sense by doing full > > resolutions on everything or re-writing them? >=20 > (pvds) > > For me a difficult question. "making sense" is very = context/application > dependent. > > The less the RD decides about validity of link contents, the better = I feel. >=20 > It is generally demanded of the base URI that it "MUST be suitable as = a base > URI to resolve any relative references given in the registration". > For regular registration that's explicit in the base parameter description, for > simple that follows from the registrant needing to provide RFC6690 discovery > (which doesn't work if links can't be resolved). >=20 > If URIs make no sense, then that's the registrant's fault, and I don't = see how the > RD could tell whether they do. >=20 > If the URIs can't be resolved (though I'm not sure the 3986 process defines any > error condition at all), then I'd treat that as equivalent to any = other syntax error > in the submitted links (and either silently fail or return Bad Request depending > on what comes out of the above on when the response is sent.) My issue was not with the question of can the URI be referenced, but the vague memory that I had where there were some things that one could have that would make sense in terms of /.well-known/core but did not make any sense when the same links were delivered from a RD. It may be that by always returning fully resolved URIs we have dealt with this problem and = I am just having bad memory echoes. >=20 > > * In section 5.4.1 - s/lt,con/lt,base/ >=20 > Thanks, fixed. >=20 > > * In section 5.4.1 - Description of 4.04 failure - I think this = should > > be 'may have been garbage collected' as I believe from previous text > > that one should be able to refresh an expired registration. >=20 > Should say "may have been removed (explicitly or after its = expiration)"; that > removal could have been explicit or as a concequence of an overly long > expiration. Fixed. >=20 > > * In section 6.4 - The example is missing the rt=3D"core.rd-ep" > > attribute. It appears to be required from the second paragraph. >=20 > Thanks, fixed (also on other locations). >=20 > > * In section 6.4 - Can you give an example of a "Links to = endpoints"? > > The only one that I can think of is 'base'. > > > > * General - Should there be a value for lt which means infinite? >=20 > I think there should at least be a value for "as long as this TCP or WebSocket > connection is open" -- which primarily makes sense with an additional = "and > please build a base name for me and act as a forward proxy" parameter. Both > can be covered using extensions. I was thinking in terms of the CT case for the small system that Peter = had referenced to for simple registration. If the CT can go in and say that this is good forever and does not need to leave some system around that = is going to need to do refresh of the registration information since it is = not ever expected to change. I recognize the inherent risks in that a = device may be taken out of service and the registration not removed but I think = it may be a simple system optimization. Jim >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Mon Dec 17 02:38:37 2018 Return-Path: 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 9F5AE130E19 for ; Mon, 17 Dec 2018 02:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 89Nbhsv4KjCz for ; Mon, 17 Dec 2018 02:38:33 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDBF12D4F2 for ; Mon, 17 Dec 2018 02:38:33 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id CBCC2182CF671; Mon, 17 Dec 2018 10:38:31 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:968:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2553:2559:2562:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:5007:6261:6657:6659:6678:7576:7903:8603:9177:10004:10400:10848:11232:11658:11914:12043:12663:12740:12895:13071:13095:13846:13972:14093:14096:14180:14181:14721:21060:21080:21324:21433:21451:21611:21627:30003:30054:30063:30076:30083:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: judge41_10351c7ae3711 X-Filterd-Recvd-Size: 5503 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf13.hostedemail.com (Postfix) with ESMTPA; Mon, 17 Dec 2018 10:38:31 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1c547507ad83ab41094ee44d86d751eb" Date: Mon, 17 Dec 2018 11:38:30 +0100 From: Peter van der Stok To: Jim Schaad Cc: =?UTF-8?Q?=27Christian_Ams=C3=BCss=27?= , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <002101d493cd$fe4f5de0$faee19a0$@augustcellars.com> References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> <04f001d4926d$9eac0070$dc040150$@augustcellars.com> <20181214111816.GA19507@hephaistos.amsuess.com> <002101d493cd$fe4f5de0$faee19a0$@augustcellars.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 10:38:36 -0000 --=_1c547507ad83ab41094ee44d86d751eb Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Christian, It might make sense to complement the example to remove the issue cited by Jim. What do you think? Peter > -----Original Message----- > From: Christian Amsüss > On Wed, Dec 12, 2018 at 02:54:18PM -0800, Jim Schaad wrote: > >> I was rather afraid that this was the case. So just to be specific >> because this is the context that I ran across the issue. >> >> As a client I am looking for an RD to register with. So I send the request: >> Req: GET coap://[MCD1]/.well-known/core?rt=core.rd* >> >> I get back one or more responses with the following links: >> >> Res: 2.05 Content >> ;rt="core.rd";ct=40, >> ;rt="core.rd-lookup-ep";ct=40, >> ;rt="core.rd-lookup-res";ct=40, >> >> (Note this is an example that is copied straight out of the RD draft.) >> >> I am now going to register myself by sending a registration request: >> >> Req: POST coap://[MCD1]/rd?ep=node1 > > Nope -- you're following a reference, and the base URI already contains > the IP literal that sent the response. Therefore, your registration POST already > goes to a unicast address. I don't see how you got to here. In you previous message you said: " You resolve against ... the origin of) the URI of the requested resource .... the IP literal of the multicast request as per section 8.2" --=_1c547507ad83ab41094ee44d86d751eb Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Christian,

It might make sense to complement the example t= o remove the issue cited by Jim.
What do you think?

Peter

-----Original Message-----
From: Christian Ams&u= uml;ss <chri= stian@amsuess.com

On Wed, Dec 12, 2018 at 02:54:18PM -0800,= Jim Schaad wrote:
I was rather afraid that this was the case.  So j= ust to be specific
because this is the context that I ran across the = issue.

As a client I am looking for an RD to register with. &nb= sp;So I send the

request:


Req: GET coap://[MCD1]/.well-known/core?rt=3Dco= re.rd*

I get back one or more responses with the following link= s:

Res: 2.05 Content
</rd>;rt=3D"core.rd";ct=3D40,<= br /> </rd-lookup/ep>;rt=3D"core.rd-lookup-ep";ct=3D40,
</rd= -lookup/res>;rt=3D"core.rd-lookup-res";ct=3D40,

(Note this i= s an example that is copied straight out of the RD draft.)

I am= now going to register myself by sending a registration request:

  Req: POST coap://[MCD1]/rd?ep=3Dnode1

Nope -- you're following a </rd> reference, and the base URI a= lready

contains

the IP literal that sent the response. Therefore, your= registration POST

already

goes to a unicast address.


I don't see how you got to here.  In you previous message yo= u said:

" You resolve against  ... the origin of) the URI = of the requested resource
.... the IP literal of the multicast reques= t as per section 8.2"


--=_1c547507ad83ab41094ee44d86d751eb-- From nobody Mon Dec 17 02:53:50 2018 Return-Path: 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 1B1A61293FB; Mon, 17 Dec 2018 02:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 k5Yd8MAkV32N; Mon, 17 Dec 2018 02:53:46 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2944E129C6A; Mon, 17 Dec 2018 02:53:46 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id CEAD5100E86C6; Mon, 17 Dec 2018 10:53:44 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:152:355:371:372:379:582:599:960:962:967:968:973:988:989:1152:1189:1221:1260:1313:1314:1345:1359:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2198:2199:2527:2528:2553:2559:2562:2692:2895:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3868:3870:3871:3872:3874:4118:4605:5007:6117:6119:6261:6657:6659:6678:7875:7903:8603:8828:10004:10400:10848:11232:11657:11658:11914:12043:12295:12663:12679:12740:12895:13071:13139:13439:13972:14096:14180:14721:21060:21063:21080:21433:21451:21627:30025:30029:30045:30054:30070:30076:30090:30091, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:29, LUA_SUMMARY:none X-HE-Tag: trade35_38cb0f58b103 X-Filterd-Recvd-Size: 7818 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA; Mon, 17 Dec 2018 10:53:44 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_149439b74e93c17a26088ab30c74b5cf" Date: Mon, 17 Dec 2018 11:53:43 +0100 From: Peter van der Stok To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: Jim Schaad , draft-ietf-core-resource-directory@ietf.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20181216133329.GE22665@hephaistos.amsuess.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <20181216133329.GE22665@hephaistos.amsuess.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 10:53:48 -0000 --=_149439b74e93c17a26088ab30c74b5cf Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi JIm, Christian, Just my hesitant 2 cents below, given my earlier explanation on this subject. > Hello Jim, Peter, > > (trying to wrap up all the comments that have been exchanged here) > > On Mon, Dec 10, 2018 at 06:22:48PM -0800, Jim Schaad wrote: * In section 5.3, I don't understand why the rule exists that if the > attribute values are different then the location of the registration needs > to be changed. It seems that this could lead to some interesting conflicts > in behavior depending on what messages are used. > Frankly, I don't understand why those rules need to be here in the first > place -- from my PoV the only thing that matters is CoAP idempotency > (ie. identical messages that arrive with no other related operations > inbetween have the same result). > > Peter, any concrete ideas on how to clean them up -- preferably in a way > that they don't speak of "updates"? > > (My alternative would be: "The following rules" and their items, and > state that "Any Registration that has the same endpoint name and sector > ('ep' and 'd' values) as a previously active one implicitly deletes that > registration." -- the idempotency rule stays intact and allows some > optimizations in terms of retransmission, but for everything else > everyone pretty please use the Location returned, whatever that is.) Original text: "The following rules apply for an for an update identified by a given (ep, d) value pair: o when the parameter values of the Update generate the same attribute values as already present, the location of the already existing registration is returned. o when for a given (ep, d) value pair the update generates attribute values which are different from the existing one, the existing registration is removed and a new registration with a new location is created. o when the (ep, d) value pair of the update is different from any existing registration, a new registration is generated." New text: "The following rules apply for a registration-request targeting a given (ep, d) value pair: o when the (ep, d) value pair of the registration-request is different from any existing registration, a new registration is generated." o when the (ep, d) value pair of the registration-request is equal to an existing registration, the content of the existing registration is replaced with the content of the registration-request" Better? Peter --=_149439b74e93c17a26088ab30c74b5cf Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi JIm, Christian,

Just my hesitant 2 cents below, given my e= arlier explanation on this subject.

Hello Jim, Peter,

(trying to wrap up all t= he comments that have been exchanged here)

On Mon, Dec 10, 2018= at 06:22:48PM -0800, Jim Schaad wrote:
*  In section 5.3, I don't understand why the rul= e exists that if the
attribute values are different then the location= of the registration needs
to be changed.   It seems that t= his could lead to some interesting conflicts
in behavior depending on= what messages are used.

Frankly, I don't understand why those rules need to be here in the f= irst
place -- from my PoV the only thing that matters is CoAP idempot= ency
(ie. identical messages that arrive with no other related operat= ions
inbetween have the same result).

Peter, any concrete= ideas on how to clean them up -- preferably in a way
that they don't= speak of "updates"?

(My alternative would be: "The following r= ules" and their items, and
state that "Any Registration that has the = same endpoint name and sector
('ep' and 'd' values) as a previously a= ctive one implicitly deletes that
registration." -- the idempotency r= ule stays intact and allows some
optimizations in terms of retransmis= sion, but for everything else
everyone pretty please use the Location= returned, whatever that is.)


<pvds>
Original text:

"The following rules apply for an for an update identified by a given (e= p, d)
   value pair:

   o  when= the parameter values of the Update generate the same
  &nb= sp;   attribute values as already present, the location of the al= ready
      existing registration is returne= d.

   o  when for a given (ep, d) value pair th= e update generates attribute
      values wh= ich are different from the existing one, the existing
  &nb= sp;   registration is removed and a new registration with a new l= ocation
      is created.

 = ;  o  when the (ep, d) value pair of the update is different from= any
      existing registration, a new regi= stration is generated."

New text:
"The following rules apply for a registration-request = targeting a given (ep, d)
   value pair:
&= nbsp;o  when the (ep, d) value pair of the registration-request  = is different from any
      existing re= gistration, a new registration is generated."
o&nb= sp; when the (ep, d) value pair of the registration-request is equal to an<= /span>
      existing registration, the= content of the existing registration is replaced with the content of the r= egistration-request"

Better?
</pvds>

Peter
--=_149439b74e93c17a26088ab30c74b5cf-- From nobody Mon Dec 17 03:04:46 2018 Return-Path: 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 2C7941294D7; Mon, 17 Dec 2018 03:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] 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 jfdaVBIDT17H; Mon, 17 Dec 2018 03:04:42 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B681286E7; Mon, 17 Dec 2018 03:04:42 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id AE1424250B; Mon, 17 Dec 2018 12:04:39 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D06E74D; Mon, 17 Dec 2018 12:04:38 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 64F2D6A; Mon, 17 Dec 2018 12:04:38 +0100 (CET) Received: (nullmailer pid 17987 invoked by uid 1000); Mon, 17 Dec 2018 11:04:38 -0000 Date: Mon, 17 Dec 2018 12:04:38 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: consultancy@vanderstok.org Cc: Jim Schaad , draft-ietf-core-resource-directory@ietf.org, core@ietf.org Message-ID: <20181217110437.GK14467@hephaistos.amsuess.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <20181216133329.GE22665@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="enGqbSaueFq5omEL" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 11:04:44 -0000 --enGqbSaueFq5omEL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, Jim, On Mon, Dec 17, 2018 at 11:53:43AM +0100, Peter van der Stok wrote: > Just my hesitant 2 cents below, given my earlier explanation on this > subject. > > New text: > [...] > Better? To me, yes. I've added "the content *and parameters* of [...] are replaced" and merged that in. Thanks Christian --=20 I love it when a draft comes together. -- Hannibal Smith (quoted freely) --enGqbSaueFq5omEL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwXgsEACgkQOY0REtOk veGfcA/7Bh8ZCN82fHyhE/OWEXfI2p2vdvuE49Cee6IVa21BWXqSLL5dz0Lvbob7 ZOU6XmBNOuAOvqGt5Sa/fFZ/9FFjZ5d7+xDM48PCjKAgvDIAZee0+FKXHb5Vgs5r j6U8TPTjfXiGDYar26iLjpJy/VRMcEMA8wYpJ0/SbcDF7JcvN+6O/X41vPhwARS/ A+jAml7E8GByY7qH2te5sL9oqXoT41wmblhcNTXEWocfAggVI+zFBRePxjt5Kk1+ 8yUmQ5dOORPLWJKBFs/cKFSUsDnKRthUjfqCxaj6I/Y7Grcoh1UUHCRuOHYgJdJA w2vzRa47vEFeGtF2xlF3zR/tQBId/f3HxaDT+fwkggSeiJo0V+uKlk+7PognDKSb vDD4SjynuZo1tX8Hbm5n94/dXTOJGyb4Hh+4m/3J7wQj7I/KdpVFcKvIvwFyqLuG ENrVALnpreWlKnNUD7pmdFDG4gGN92QKlH7/1kc3mlGKLi/Rp1+Tp2oP+gptkTAC R/JC9BiwppK+oipUwNnro8zgF4s+HEgaurnB+/aohpZQe35pTc1DtnL8sIdOGzZd I6dYMYsPNnOgyyTVyEkMJReqS+FgxpWazlO2UB7aiga0j+1xorDGkqXguZUys/oG 2h7C7EW3q6CArcniA3HHwrlhbbCh+JZODRquWhLPc51yV6gh8lQ= =xye5 -----END PGP SIGNATURE----- --enGqbSaueFq5omEL-- From nobody Mon Dec 17 05:50:10 2018 Return-Path: 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 ED84D128D68 for ; Mon, 17 Dec 2018 05:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tEty4YgCiQjm for ; Mon, 17 Dec 2018 05:50:04 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E13128766 for ; Mon, 17 Dec 2018 05:50:02 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 074114250B; Mon, 17 Dec 2018 14:49:58 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1B6354D; Mon, 17 Dec 2018 14:49:57 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9A9D334A; Mon, 17 Dec 2018 14:49:56 +0100 (CET) Received: (nullmailer pid 4377 invoked by uid 1000); Mon, 17 Dec 2018 13:49:56 -0000 Date: Mon, 17 Dec 2018 14:49:56 +0100 From: 'Christian =?iso-8859-1?Q?Ams=FCss'?= To: consultancy@vanderstok.org Cc: Jim Schaad , core@ietf.org Message-ID: <20181217134955.GA3694@hephaistos.amsuess.com> References: <004301d48ded$8487b9c0$8d972d40$@augustcellars.com> <20181212204344.GA665@hephaistos.amsuess.com> <04f001d4926d$9eac0070$dc040150$@augustcellars.com> <20181214111816.GA19507@hephaistos.amsuess.com> <002101d493cd$fe4f5de0$faee19a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] /.well-known/core and multicast addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 13:50:08 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 17, 2018 at 11:38:30AM +0100, Peter van der Stok wrote: > > Req: POST coap://[MCD1]/rd?ep=3Dnode1 > > It might make sense to complement the example to remove the issue cited > by Jim. > What do you think? We already have an example on that in there: In B.1/B.2 a GET is sent to a multicast .well-known/core, and the sender's IP literal is replaced in for further resolution steps. Best regards Christian --=20 Yesterday is history, tomorrow is a mystery, and today is a gift. That is why it is called the present. -- ancient saying --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwXqYIACgkQOY0REtOk veGq/g/+KqeYdJ3VXlfnTDvUbciuQyye+SPpmBrG5JkhUiwvQRznog/JKsdgRBI3 axZS5/mIW/r4U95VaJvUcpdTh6cCuEKOYAPYMJg/JX7M2fZtCziU1mdl9RW8UjXO 9LAwXbqGDwRQyTRPh78emBnvdHilUAOChWN+ehqTbQVmkHDF3WADAuIJYyYsnxg3 UcPztAqgagiL5QPwlh5tEUmtNMhybBXU5VYKbOzj7368AVLsTctFg92gADEjY7er 0uQi1gTdhixoJ/P6xMMZtdXL1KahQk84qg02CwARLVuPPRmmpRYfurBR2ld042K3 l8HMaTXhIY6TWMea7uTpJcc9DKWIXsGXJW88qAZR52ShsT72bn/ML2hUyiqgNods 8/DRkfu/KrgtePrcE8bGLlXkZIIIA025aE/sIgoH01B/ON/nYS1YouF/Q+W+y/+v 3kGwRuud/pB/6OFyUFjSPOsp/JaiSiReDXHf0+yBPaRIrajCU3pFrDrXJGnPLTRZ ZnyRMJy6idwRMo8JsUeoWSdgcX6TnA4+uVnAPpO7r2+UGsbKhaV03nX7IWqxPxfD c9N6CEB6ZFOfHc7QnTpR1PrL90M2nODY30FrcEK/ZiYf4PGrfuHTyRva5+og9ENa ci/OhgrC0cWrlPynB65LoYvUIhNdqxAznPfvKNlN6gepYeR4RWI= =lnqR -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From nobody Mon Dec 17 14:46:48 2018 Return-Path: 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 9331912D4E6 for ; Mon, 17 Dec 2018 14:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ao8E656N6Qx5 for ; Mon, 17 Dec 2018 14:46:44 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019FD126C01 for ; Mon, 17 Dec 2018 14:46:43 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id EFFBC4251D for ; Mon, 17 Dec 2018 23:46:40 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F2E754D for ; Mon, 17 Dec 2018 23:46:38 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8419934A for ; Mon, 17 Dec 2018 23:46:38 +0100 (CET) Received: (nullmailer pid 26064 invoked by uid 1000); Mon, 17 Dec 2018 22:46:37 -0000 Date: Mon, 17 Dec 2018 23:46:37 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20181217224636.GA20914@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] My wishlist for corr-clar X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 22:46:47 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten and CoRE, while there's no established workflow for adding to core-corr-clar, here are a few items I've collected and think would make good additions to that document: * A name for the path-less URI constructed from doing role reversal. RD would have been easier to write with this, and any role reversal is easier to argue about with it too, for example in OSCORE. * A statement on whether that can always be done even if the resulting URI can not be used by anyone else, or might not even have a proper URI representation (coap+tcp://...:ephemeral-port/ for the former, the address of the browser side of a websocket in for the latter). I've sketched up some strawman text (with potential not only better naming but also completely contrary statements) below. * The text from lwig-coap defining the "block key" * echo-request-tag uses a slightly updated version of this (even though not naming it) that elective NoCacheKey options are not described as part of the "block key" (as they could safely be served by an intermediary if all else matches). (Anyway, the lwig-coap text could be a starting point.) * Observation: Anything can cancel implicitly RFC7641 leaves it open how a new request on an active observation token should be processed if it's neither a registration update (which could only vary th ETag set) nor an explicit deregistration. Practically speaking, the server needs to assume that the client has lost any state it had of the observation (for otherwise it would have followed the protocol) and thus treat the old observation as cancelled and process whatever is in the new observation. corr-clar might be a good place to talk about this and pave the way towards sanctioning it. (In effect, that'd mean that anything in an observation can be changed by an observation update -- the server would treat it as a new registraiton anyway if it so wishes.) Has there been any progress on moving corr-clar towards WG adoption, or on its procedural side (how section status w/rt WG consensus is managed)? Best regards Christian --- Strawman text for the constructed URI: 2.2 RFC7252-1.2 Terminology: RFC7252 hints at the possibility for role reversal in Section 9.1.1 by suggesting that the DTLS client should also act as the CoAP client, and RFC8323 accordingly distinguishes between a CoAP client and a connection initiator (however often they may coincide) in Section 3.3. They do not contain considerations for the URIs that'd describe resources on the DTLS client or connection initiator side. : Role-Reversal URI The Role-Reversal URI of a request is a URI based on which resources hosted by the endpoint that sent the request are named. Its construction depends on the protocol used. For CoAP over UDP, DTLS, TCP, TLS and WebSockets, the Role-Reversal URI is constructed by following RFC7252 Section 6.5 and RFC8323 Section 8.7, but with no CoAP options present, and using the source rather than destination address and port. For CoAP over TCP, TLS and WebSockets, that results in an address that is not generally usable (because opening such a connection would not succeed), but can still be used locally for the duration of the connection. Such URIs should not be used outside the host on which the Role-Reversal URI was generated, or for a longer than the connection persists. For CoAP over DTLS, TLS and secure WebSockets, the credentials presented by the Connection Initiator may be insufficient to justify using that connection as to access resources hosted on it. If applications use Role-Reversal URIs over secure protocols, they need to describe under which circumstances those URIs are usable. When used with IPv6, the source address can be a link-local address that requires a zone identifier to be disambiguated between several interfaces. A zone identifier is expressed following RFC 6874, and like Role-Reversal URIs in connection-based protocols can not be used outside the host which generated it. Note that a client can not express resources under its Role-Reversal URI in request payloads as relative references, as these requests's base URIs are ... [probably anonymous, with the application stepping in? the target URI?]. Resources on Role-Reversal URIs must be announced using relative references that use application-dpendant base URIs, or (preferably) perform resource discovery. {{I-D.core-resource-directory}} uses the Role-Reversal URI as the default value for the "base" registration parameter, and described explicitly there as it predates this definition. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwYJ0kACgkQOY0REtOk veEXpg//e5zToUgHFefS4qEcpC3buxREKnY/6/SZHSPrFtHDaV6UV8APyFZBqE3t 9psfPU4AgZgy24AL9cTP+ULFNGt9+GzTTRZtCAkE3vBZcvgwhLykJF28/mDH/ZVb Fhjd7jAG8PhsHqAWJyynhOtLW04JsFVTTEu9QnyIc9H3IQDHYPiIlDBOHlohLbKa Lhuu04YhVAM/h27F1FRz/K7qWQFlRTBWoz1Ydij99Sbe2w6T0axLqQgjOyoqXTpV xDcGHox7lZ9Pj4lBicDGpcjFPA/Klp8qLoVQdAmG6XQQab8kGs/DbadxEKISV3Lg 6ZH6Uq1uyOujCyiqNUMs3AuXmnoggHRxUrYBg/wp1k+uI11X5+VltXVUhCDDd5J5 pVRiBW5WEB0V0DpnT1vu+OlB7La8bMtklyYk1yK1TAwLoKw2DRHl0PzyyzUWVI92 I8jWB/dz2s/081CFeM/QPeIjXnu5/tPZSs2ceVS8lMjuyvSnzBP5riJ5kwMTKAT5 5TCHzoF3R4FNgOTIUF/atP+hQLLBHm3zw75ES8lWm/gza05gjMPFwGyMAFC1NnlY g/KzupZBiljm2BZJvefW8QjeX7NeXBArAUPtAYAW25sH0Kc/P2dIL+GvbSyxTqyB z/sKeaynoZfNvZ6y4CwAKWlhEjiHutRC9pbRi3YDT8Mx8L08Llw= =/j1p -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From nobody Wed Dec 19 00:39:58 2018 Return-Path: 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 3704A130DC8 for ; Wed, 19 Dec 2018 00:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OzvqQOaRoKou for ; Wed, 19 Dec 2018 00:39:54 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3AC12008A for ; Wed, 19 Dec 2018 00:39:54 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6D3F74253F; Wed, 19 Dec 2018 09:39:50 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C3F38D7; Wed, 19 Dec 2018 09:39:47 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6B10F6A; Wed, 19 Dec 2018 09:39:47 +0100 (CET) Received: (nullmailer pid 31450 invoked by uid 1000); Wed, 19 Dec 2018 08:39:47 -0000 Date: Wed, 19 Dec 2018 09:39:46 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Lauri Piikivi Cc: "core@ietf.org" Message-ID: <20181219083946.GA30229@hephaistos.amsuess.com> References: <02dd01d490f8$6aea0dc0$40be2940$@augustcellars.com> <035e01d49178$b08a3e60$119ebb20$@augustcellars.com> <4ea547c2c838536e260fd222651ae446@bbhmail.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Questions and comments against the github version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 08:39:57 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Lauri, On Wed, Dec 12, 2018 at 09:55:58AM +0000, Lauri Piikivi wrote: > If a EP publishes itself in rd, no other ep, based on adequate > authenticaiton, can overwrite it. If an earlier registered EP makes a > new registration to the RD, where it does not include the location in > the path, is an indication that the EP may have reset or otherwise > wants a new registration (e.g. Due to changed attributes) in the rd. Yes. > Another ep trying to post to another ep=E2=80=99s url should get an error. > This requires authenticaiton. An new ep trying to post to an old ep's registration URL is what I'd call "registration hijacking". It is not allowed, but begs the question of how the RD would know that the hijacking endpoint is actually different from the original one. If the credentials are suitable, the only assumption the RD can make is that the "new" endpoint is the same as the old one, and that it has only just switched its network address. Otherwise, the RD would reject the operation with 4.01 Unauthorized. Best regards Christian --=20 The detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods. [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979. -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP) --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlwaA88ACgkQOY0REtOk veGB3hAAng1/6DBNy917MZNA4VwN8OuLzud89oXesuFcD7tlrbtPJGEHAhwXSQk4 trCMV5CMXi9oAqiHAkf4i2nH52ZVwMIQWoKgfMcXgjnRfhel4/GVejb1PbftKCce WnPHuxEVo/kfSIb7YVQESGgZTV7FV+rG3CbpQw1tOqeYISp+MufJ0ueaO0rcoeIv V/8TfMkzueU38CwXmufVz/OiePkZ5aajJk251g/8DWu1B1jmRr9zVUB4LkALMOO8 4d8KdVCDMHi4sGorXWwMSFPWoOp+SRp1haHaeiM70223HiTWRtWtI7Rc4v17wgK/ gbao1Ucql/gBgMdh0KZFy+XHX/MZ24yfmcA5aCbxm/dsdtrFk8GgJVg1im1YBdIS JMwp5/S4csZiCs+819K2DY/1XtyafbiLoGaXiWa9KjoELR/UBN7xtYOUxOPE7OuS sTnQwJVa7RosCZbn+wja6WOM3FD3ga5DlOiT+IInY9+JAFcZOWfo5VRqJ25DjEwZ P1FQ+bg4RDH2LeQiAhg9w+h+xtjNaGmYA4NBEj6lhKP5Kmlaf6T/VGLckbvh8x/x iULsSdVLlimXERXhxuAQ7VV444Wlnb2b4IY2Oaq+FnYdmAC/afWPj/THpqWepkl+ ItqdyIpwRxBm7phJeX/NzzZ5Fu+XiKIWvDoz254MX33cSN2TfRo= =fRc2 -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From nobody Wed Dec 19 04:44:53 2018 Return-Path: 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 91E4D130934 for ; Wed, 19 Dec 2018 04:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uni-bremen.de 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 cf-APg8tnvTG for ; Wed, 19 Dec 2018 04:44:49 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5F612D4ED for ; Wed, 19 Dec 2018 04:44:48 -0800 (PST) Received: from uni-bremen.de (webmail-1.zfn.uni-bremen.de [134.102.50.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 12DC020545 for ; Wed, 19 Dec 2018 13:44:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=dkim; t=1545223487; bh=aY6t6Yhn/dxxWJ7/EhReIz7Q+Lo7cnJMknVVUn+NUBU=; h=To:Date:From; b=GB5B7nk/IpgwkvxNabkTJWIEXpQuVmGOBdUqgSbK7RlsaF6tmIYSxLCLO74VMayn1 iAWQ6vtcgW0f5kppqpC/3T74FkoPYT+R02cyBvp3se9cvEhXiLP4wzEHiQmnrJ/DXW X9n/x1gLKPEk90mQolK8pISWfWKvMVjltLq7WEgU= To: core@ietf.org Date: Wed, 19 Dec 2018 13:44:46 +0100 Message-ID: <003601d49798$9f720560$de561020$@uni-bremen.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01D497A1.013757C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdSXlyfitLTYq4C+RQKoT4wMzRZNjw== Content-Language: de User-Agent: Horde Application Framework 5 From: Shantanoo Desai Archived-At: Subject: [core] [senML] Adding more semantic information in to senML measurements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 12:44:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01D497A1.013757C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, I wish to add a bit more context semantically to the measurements in senML, viz. if I have a sensor node that provides me Environmental data like temperature, humidity, pressure in the following way: [ { "bn": "urn:dev:mac:aabbccddee/env/", "n": "temperature", "u": "Cel", "v": 23.3 }, { "n": "humidity", "u": "%RH", "v": 30 }, { "n": "pressure", "u": "Pa", "v": 100013 } ] This provides me information about the sensor node's environmental data acquisition however it provides me no information about where this sensor is placed for e.g. "outside"/"inside"/"car"/"gate1". When it comes to indoor localization there are no gps coordinates and hence adding some context to the SenML base-record does not seem to be a bad idea. However the RFC mentions nothing pertaining to some additional meta-data. Is it recommended to use "vs" in the base record to add such information or is there something I should look for somewhere else? Regards, Shan ------=_NextPart_000_0037_01D497A1.013757C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I wish to add a bit more context = semantically to the measurements in senML, viz. if I have a sensor node = that provides me Environmental data like temperature, humidity, pressure = in the following way:

 

[

  {

      “bn”: = “urn:dev:mac:aabbccddee/env/”,

      = “n”: “temperature“,

       = “u“: “Cel“,

       = “v“: 23.3

  },

  {

     = “n”: “humidity”,

      = “u”: “%RH”,

      = “v”: 30

  },

  {

     “n”: = “pressure”,

      “u”: = “Pa”,

      “v”: = 100013

  }

]

 

This provides me information about the sensor node’s = environmental data acquisition however it provides me no information = about where this sensor is placed for e.g. = “outside”/”inside”/”car”/”gate1= ”. When it comes to indoor localization there are no gps = coordinates and hence adding some context to the SenML base-record does = not seem to be a bad idea. However the RFC mentions nothing pertaining = to some additional meta-data.

 

Is it recommended to use = “vs” in the base record to add such information or is there = something I should look for somewhere else?

 

 

Regards,

 

Shan

------=_NextPart_000_0037_01D497A1.013757C0-- From nobody Wed Dec 19 05:07:47 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C449D126CB6; Wed, 19 Dec 2018 05:07:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <154522486568.14754.12136677357051268505@ietfa.amsl.com> Date: Wed, 19 Dec 2018 05:07:45 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:07:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : YANG Schema Item iDentifier (SID) Authors : Michel Veillette Alexander Pelov Ivaylo Petrov Filename : draft-ietf-core-sid-05.txt Pages : 26 Date : 2018-12-19 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 64-bit unsigned numbers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-sid-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 19 05:42:54 2018 Return-Path: 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 0EDBE1274D0 for ; Wed, 19 Dec 2018 05:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 W4DaB5scqlJ7 for ; Wed, 19 Dec 2018 05:42:49 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C69126CB6 for ; Wed, 19 Dec 2018 05:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBJDgdnU001545 for ; Wed, 19 Dec 2018 14:42:44 +0100 (CET) Received: from [192.168.217.114] (p54A6C3F1.dip0.t-ipconnect.de [84.166.195.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43Kbg30lJ6z1Br6; Wed, 19 Dec 2018 14:42:39 +0100 (CET) Content-Type: multipart/mixed; boundary="Apple-Mail=_DBAD0CA7-9BED-4276-82A6-4F03DF761A76" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <2E82C032-312F-4031-AE45-13D56868D8C3@tzi.org> Date: Wed, 19 Dec 2018 14:42:37 +0100 X-Mao-Original-Outgoing-Id: 566919756.012956-685cd95716582afda359d385efdebd5d Message-Id: <6C69E274-A35B-4447-ABBA-A4C46BA42F5A@tzi.org> References: <2E82C032-312F-4031-AE45-13D56868D8C3@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] 2018-12-20 1600Z -- Re: CoRE Virtual Interims between IETF103 and IETF104 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:42:52 -0000 --Apple-Mail=_DBAD0CA7-9BED-4276-82A6-4F03DF761A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 5, 2018, at 13:17, Carsten Bormann wrote: >=20 > Between IETF102 and IETF103, we had a number of WebEx calls (virtual = interim meetings) of the WG. >=20 > In Bangkok, we said we were going to continue this, again maybe = alternately to the bi-weekly calls that the CBOR WG has. The CBOR WG = has now chosen their dates, which are Wednesday 1800Z to 1900Z, starting = from 2018-12-19. >=20 > So we would be starting on 2018-12-26 (probably not), or then = 2019-01-09: >=20 > Day: every other Wednesday beginning on 9 January > Dates: 9, 23 Jan; 6, 20 Feb; 6, 20 March > Time: 18:00 to 19:00 UTC=20 > (10:00..11:00 PST except for 2019-03-20, 19:00..20:00 CET, =E2=80=A6) It has been pointed out that while 1800Z is a good time for CBOR, the = CoRE WG may not want to follow their lead for the time of day of the = interim meetings (but let=E2=80=99s stick with the Wednesday bi-weekly = cadence). To collect opinions on this, I have set up a quick doodle: https://doodle.com/poll/y6rvm3zu8hhwvbye We will select a time of day in the interim tomorrow. > Since that would leave us without any interim this year, we are = proposing to add >=20 > =E2=9E=94 Thu 2018-12-20, 1600Z..1700Z (08:00 PST, 17:00 CET, =E2=80=A6)= >=20 > as a single-use exception (probably with a focus on the resource = directory). I=E2=80=99m proposing the following rough agenda: * RD Update and discussion (Christian Ams=C3=BCss, 25 min) * Can the RD, as defined now, be used well with CoRAL? (Klaus Hartke, 20 = min) * 2019 Q1 virtual interims (Chairs, 5 min) Please send updates to the chairs or to the list. > All meetings will be on the IETF WebEx, details to be announced. CoRE Virtual Interim Thursday, December 20, 2018 16:00 | Greenwich Time (Reykjavik, GMT) | 1 hr Meeting number (access code): 646 858 447 Meeting password: constrained When it=E2=80=99s time, join the meeting: https://ietf.webex.com/ietf/j.php?MTID=3Dm10a369cffc7dc76ad8b2cd569f6000c3= =20 Join by phone: 1-650-479-3208 Call-in toll number (US/Canada) Add to Calendar:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm5957e2c4318376fe2afa1152377b9535= Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_DBAD0CA7-9BED-4276-82A6-4F03DF761A76 Content-Disposition: attachment; filename=Webex_Meeting.ics Content-Type: text/calendar; x-unix-mode=0644; name="Webex_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Greenwich=20Time=0ABEGIN:STANDARD=0ADTSTART:20160101T000000=0A= TZOFFSETFROM:+0000=0ATZOFFSETTO:+0000=0ATZNAME:Standard=20Time=0A= END:STANDARD=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"CORE=20= Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:core-chairs@ietf.org=0A= ORGANIZER;CN=3D"CORE=20Working=20Group":MAILTO:core-chairs@ietf.org=0A= DTSTART;TZID=3D"Greenwich=20Time":20181220T160000=0A= DTEND;TZID=3D"Greenwich=20Time":20181220T170000=0A= LOCATION:https://ietf.webex.com/ietf=0ATRANSP:OPAQUE=0A= SEQUENCE:1545226408=0AUID:06aa314e-5e98-4ab5-9185-d8f79d837b80=0A= DTSTAMP:20181220T160000Z=0ADESCRIPTION:\n\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm3a1216c81fe5cfaec3c0406= 28a1d2f82\nMeeting=20number=20(access=20code):=20646=20858=20= 447\nMeeting=20password:=20constrained\n\n\n\nJOIN=20BY=20= PHONE\n1-650-479-3208=20Call-in=20toll=20number=20(US/Canada)=20\nTap=20= here=20to=20call=20(mobile=20phones=20only,=20hosts=20not=20supported):=20= tel:%2B1-650-479-3208,,*01*646858447%23%23*01*\n\n\n\nCan't=20join=20the=20= meeting?\nhttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIM= PORTANT=20NOTICE:=20Please=20note=20that=20this=20Webex=20service=20= allows=20audio=20and=20other=20information=20sent=20during=20the=20= session=20to=20be=20recorded,=20which=20may=20be=20discoverable=20in=20a=20= legal=20matter.=20By=20joining=20this=20session,=20you=20automatically=20= consent=20to=20such=20recordings.=20If=20you=20do=20not=20consent=20to=20= being=20recorded,=20discuss=20your=20concerns=20with=20the=20host=20or=20= do=20not=20join=20the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09=  
 
 
=09=09Join=20= Webex=20meeting=09=09=09=09=09=09=09=09=09=09=09=09= =09=09=09=09=09=09=09
=09=09=09=09=09=09Meeting=20number=20(access=20code):=20646=20858=20= 447=09=09=09=09=09
=09=09=09= =09=09=09
Meeting=20password:constrained
=09= =09

 
 
Join=20by=20phone =20
1-650-479-3208 Call-in=20toll=20= number=20(US/Canada) =20


=09 
=09= =09= Can't=20join=20= the=20meeting?=09 
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20= this=20Webex=20service=20allows=20audio=20and=20other=20information=20= sent=20during=20the=20session=20to=20be=20recorded,=20which=20may=20be=20= discoverable=20in=20a=20legal=20matter.=20By=20joining=20this=20session,=20= you=20automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20= not=20consent=20to=20being=20recorded,=20discuss=20your=20concerns=20= with=20the=20host=20or=20do=20not=20join=20the=20session.=0A= SUMMARY:CoRE=20Virtual=20Interim=0APRIORITY:5=0ACLASS:PUBLIC=0A= BEGIN:VALARM=0ATRIGGER:-PT5M=0AACTION:DISPLAY=0ADESCRIPTION:Reminder=0A= END:VALARM=0AEND:VEVENT=0AEND:VCALENDAR=0A= --Apple-Mail=_DBAD0CA7-9BED-4276-82A6-4F03DF761A76 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_DBAD0CA7-9BED-4276-82A6-4F03DF761A76-- From nobody Wed Dec 19 07:25:24 2018 Return-Path: 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 44F2F124D68 for ; Wed, 19 Dec 2018 07:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 SajWlEtXD_iB for ; Wed, 19 Dec 2018 07:25:20 -0800 (PST) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EAF12008F for ; Wed, 19 Dec 2018 07:25:19 -0800 (PST) Received: from si0vm1948.rbesz01.com (unknown [139.15.230.188]) by fe0vms0187.rbdmz01.com (Postfix) with ESMTPS id 43KdxS2bCXz1XLDR3; Wed, 19 Dec 2018 16:25:16 +0100 (CET) Received: from si0vm2083.rbesz01.com (unknown [10.58.172.176]) by si0vm1948.rbesz01.com (Postfix) with ESMTPS id 43KdxS2GYVz1VD; Wed, 19 Dec 2018 16:25:16 +0100 (CET) X-AuditID: 0a3aad17-a49ff700000078f5-26-5c1a62dc4dfe Received: from si0vm1950.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by si0vm2083.rbesz01.com (SMG Outbound) with SMTP id D5.B9.30965.CD26A1C5; Wed, 19 Dec 2018 16:25:16 +0100 (CET) Received: from SI-MBX2032.de.bosch.com (si-mbx2032.de.bosch.com [10.3.230.35]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 43KdxS0Wm7z2M; Wed, 19 Dec 2018 16:25:16 +0100 (CET) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2032.de.bosch.com (10.3.230.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 19 Dec 2018 16:25:15 +0100 Received: from SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c]) by SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c%4]) with mapi id 15.01.1591.008; Wed, 19 Dec 2018 16:25:15 +0100 From: "Kraus Achim (INST/ECS4)" To: "core@ietf.org" Thread-Topic: Groupcomm for CoAP (RFC 7390) implementations Thread-Index: AQHUk5wb1rHWGBZAhU287Ez7+Sa8FaWGNSIQ Date: Wed, 19 Dec 2018 15:25:15 +0000 Message-ID: <0e7ddbeabd4a4ad580b454330d3bb1d2@bosch-si.com> References: <9F1B592D-E78C-4E2F-8402-EF029CAC1421@ericsson.com> In-Reply-To: <9F1B592D-E78C-4E2F-8402-EF029CAC1421@ericsson.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.81.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wTZxjHee9Ke3Q9OVpqH7p1uhvLxmIRS03wxwbxjwX/2dQtWVS2cdiD dvQH9oCIiRnZMgXGwgKDYnXQLcjInAOxLpXp2KoLMjp1Y05GXCZIEK2aGkFZJ+3uuGL7x/77 vt/n+bzf530uR+DKbkJLWOyVrNPOWGmpXCJff0ynv1qiLcp5v0Ge9/2dXjzvRrBFVoAVhucu Swu7uv7BtmA75BtNrNVSzTpXv1wsN1+bPCStCCn2NP61IKtF5xQNKIUAygiNrk5pA5ITSsqF gWfCh4mHUwg+H3wgEw93EfSHIrHKaQQh3yQm8FJqPTR7zsoEnU49CycCQSRonNoE12t/W9Qq vufH4GGp2LMBjnjnY9oAc7dPLLIS6jkY7r20qEm+x9XYjgtaSeWD7/iVxawUqgBcF+eTBY0o HfT1XcTFLA2MT3Vi4nso6Dot+kCp4eb1SLKoV8AHTcJrCL4/C3oHVovoM/DpRxOx2DQYPjgl +QRp3Am3uuOEO4FwJxAeJPkKqTlLTrXNkJOXm+0sYbm9OWuydzls/Uj8WBof+vKPUj+iCEQr yDe2a4uUyUw1V2Pzo7UERqtJ2TreWlbiMNWYGc78jrPKynK0lkRJSUlK1WObqyqxWTjO4rD7 ERA4nU6OGXmONDE1e1mnQ8T86ElCQmvIaL1tp5IqYyrZcpatYJ1L1Q0EQQOZwvBgmpMtY/eU WqyVS2VaJ2YuT6wkxmJEih/lEgo+e7pYyOYqGBtnKYvhGSKuXHLj6M/oNSLiibpw4vdAfTtO DNXPHcaVErvDzmo15CZhHEqgzFX2x9NonyI932FFSnVCIX7jLfQn4vepItUCrOD/j/gcQH7Y NbFTmRYz45DhCM9QM1KI9rQi6Lh/GUH4QI8E/N1XJPBooVsK37ibCOiN1j0Bg4eal0H4YGsq jN0+q4a/A5fU0Hr8QgZ0dBzVQf+91qdhcPr8SohcOEfD/IPPMsHXdvJ5aHdNvQAzswOroD30 7yoYPNmmh8BDrx5m54b00LIQ0kM0HNHD+JmBbBj2hg1wNFiXCzNjnUYYaBoxQtf9U2tv8UvG +CVbvZiw5Eqm8n+WHHPjr9PWovy3Cwt++GkHs3/LgZVXk65xL419vHkks+38mwabLZjR0nyM vjm5PXPre19P20sDr+8O3xsPpt4xObZuHlV53919t/zMjVHVrlfqHVNmDWRlOXSBHkJiWPdo o2Hoi22v5lOlJrMxteyt2eLyqeX78b5ff3HuG60r3jZC29O/fdg22bOPlnBmZs2LuJNj/gNQ HdiBuQQAAA== Archived-At: Subject: Re: [core] Groupcomm for CoAP (RFC 7390) implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 15:25:23 -0000 SGksDQoNCkNhbGlmb3JuaXVtIG9mZmVycyBhICJ2ZXJ5IGVhcmx5IiBzdXBwb3J0IGZvciBtdWx0 aWNhc3Qgc2luY2UgZW5kIG9mIE9jdG9iZXIgMjAxOA0KKGN1cnJlbnRseSBpbiB0aGUgMi4wLngt U05BUFNIT1QpLiANCkJ1dCBJIHdvdWxkIGdvIHRoYXQgZmFyLCB0byBzYXksIHRoaXMgaXMgUkZD NzM5MCBjb21wbGlhbnQgOi0pLiAgICANCg0KTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbiAvIEJl c3QgcmVnYXJkcw0KDQpBY2hpbSBLcmF1cw0KDQooSU5TVC9FQ1M0KSANCkJvc2NowqBTb2Z0d2Fy ZSBJbm5vdmF0aW9uc8KgR21iSCB8IFN0dXR0Z2FydGVyIFN0cmHDn2UgMTMwIHwgNzEzMzIgV2Fp YmxpbmdlbiB8IEdFUk1BTlkgfCB3d3cuYm9zY2gtc2kuY29tDQoNClNpdHo6IEJlcmxpbiwgUmVn aXN0ZXJnZXJpY2h0OiBBbXRzZ2VyaWNodCBDaGFybG90dGVuYnVyZzsgSFJCIDE0ODQxMSBCIA0K QXVmc2ljaHRzcmF0c3ZvcnNpdHplbmRlcjogRHIuLUluZy4gVGhvcnN0ZW4gTMO8Y2tlOyBHZXNj aMOkZnRzZsO8aHJ1bmc6IERyLiBTdGVmYW4gRmVyYmVyLCBNaWNoYWVsIEhhaG4sIERyLiBBbGVr c2FuZGFyIE1pdHJvdmljIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBj b3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHw7ZyYW4gU2VsYW5kZXIN ClNlbnQ6IEZyZWl0YWcsIDE0LiBEZXplbWJlciAyMDE4IDEyOjAwDQpUbzogY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogW2NvcmVdIEdyb3VwY29tbSBmb3IgQ29BUCAoUkZDIDczOTApIGltcGxlbWVu dGF0aW9ucw0KDQpBbGwsDQoNCkRvZXMgYW55b25lIGtub3cgaWYgdGhlcmUgaXMgYSBsaXN0IG9m IENvQVAgaW1wbGVtZW50YXRpb25zIHN1cHBvcnRpbmcgUkZDIDczOTAgKEdyb3VwIENvbW11bmlj YXRpb24gZm9yIENvQVApPyANCg0KaHR0cDovL2NvYXAudGVjaG5vbG9neS8gbWVudGlvbnMgUkZD IDczOTAgdW5kZXIgInNwZWNpZmljYXRpb25zIiBidXQgSSBkaWRuJ3QgZmluZCBhbnl0aGluZyB1 bmRlciAiaW1wbGVtZW50YXRpb25zIi4NCg0KVGhhbmtzDQpHw7ZyYW4NCiANCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0 DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUNCg== From nobody Wed Dec 19 07:54:13 2018 Return-Path: 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 88535130E3C for ; Wed, 19 Dec 2018 07:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 cFiJddIJlFd6 for ; Wed, 19 Dec 2018 07:54:05 -0800 (PST) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA5F130E41 for ; Wed, 19 Dec 2018 07:54:05 -0800 (PST) Received: from si0vm1948.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 43KfZg2wysz1XLG2w; Wed, 19 Dec 2018 16:54:03 +0100 (CET) Received: from fe0vm7918.rbesz01.com (unknown [10.58.172.176]) by si0vm1948.rbesz01.com (Postfix) with ESMTPS id 43KfZg2bX9z1Sq; Wed, 19 Dec 2018 16:54:03 +0100 (CET) X-AuditID: 0a3aad10-37bff70000003834-b6-5c1a699bd0fb Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm7918.rbesz01.com (SMG Outbound) with SMTP id C1.83.14388.B996A1C5; Wed, 19 Dec 2018 16:54:03 +0100 (CET) Received: from SI-MBX2032.de.bosch.com (si-mbx2032.de.bosch.com [10.3.230.35]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 43KfZg0f5Qz1CN; Wed, 19 Dec 2018 16:54:03 +0100 (CET) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2032.de.bosch.com (10.3.230.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 19 Dec 2018 16:54:02 +0100 Received: from SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c]) by SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c%4]) with mapi id 15.01.1591.008; Wed, 19 Dec 2018 16:54:02 +0100 From: "Kraus Achim (INST/ECS4)" To: "core@ietf.org" CC: =?iso-8859-1?Q?Christian_Ams=FCss?= Thread-Topic: [core] My wishlist for corr-clar Thread-Index: AQHUllpq7zX30fbcwkW8IFgQ2KxHDaWGNpQA Date: Wed, 19 Dec 2018 15:54:02 +0000 Message-ID: <464d1690c8c541a0ab6e07499b011301@bosch-si.com> References: <20181217224636.GA20914@hephaistos.amsuess.com> In-Reply-To: <20181217224636.GA20914@hephaistos.amsuess.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.81.84] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wbZRjHee+u7cvBueMY41kdITldgug6wOFgw2k0MRB10WSZumFYkaO9 rL/sFTKWLFk2UdYZ2WBYLJOVpZKNOIvbjEWwuIKakQkmE8aQH9Ph6sYgmcjAzYFXDtb+4T+X 7/t9ns/zPO/z5jDJfYq1WLQ4BLtFb+LVNEVvOpOyrkHUFma838XkBPwfUTmBSR/5PJHvvHBP le/1/kO8Ruyg80oEk1gu2Ndv2UUbD3SusA1k7QmGDlL70bdpThSLgd0AbU3VaieiMce6CLh6 Yhoph28QnP7+kEo5TCG4EphcSutAMBcKasK8mt0ENZ6uRb2SfQzOXZpAYU2yz4FzdoIM60R2 HVz4waVWcnTQXRkgFZ0FM2OXF1mKXQuuvnbZx5hhN0Pv1dSwzcmyM9SvCutYNg/620OLZRCb Aq2tfaTSKhmGxk8QynVY8HYoPrBJcPP6vErRqXCw+q5GydfBYN0xtaKfhOYmZUyGTYCLn4xT R1CyO6qsOwpxRyHuKMSDqBaUVCpklJs35mbm6OzFgrQ3I1P3jtV8FimPxfpRW09pELEY8fHM tre0hZxKXy5VmIMoGxN8EqPJla1Hiq0lFUa9ZCyyl5kEidcyKCYmhkt8aEtlxWZRkkSrJYgA k/xKZnCDzDEl+oq9gt2qYEH0KKb4ZCazQNzJsQa9Q9gtCDbBvhzdjDEPzKxBBhPsgkHYUyqa HMthPkXpuSo6Et2WwLFB9DSOl3sPhUswkk1vlkTDEr5awbllN4L2oAI871lwkfjHQzPHSY6y WC2CNpkxGuUqbDjfWGZ5OId2DeNpJwq5pKhApNYtNIDkTSYqt4iX/4zIBMBUen/bySUsmREo 66TMsPXp0FlLw5e9r0Oj/22Ye+8wgsbpfvkz5CNgeLqDAL9rloCuuVoSOuZbSBi+OEXCvQ9O URBsvkKBv86vgqG/PGqo/7VJDf8+aFaDf7BFA2fvf66BqpMBDSyc+glDp2sQw5+jfbEwcyBA Q+PtMRpqDl+jYfrMJA2+hao4qL95LA5Gey7FwfnKO3Fwv+5c/C15t4S8W9N5Irxbh97xP7td ciNX0+5HuZf7qna/kf17Q3b6vn0j21syqv74ri1r6/q0v1e9LHXzI9uLfn4q78ZIt5i2o+Do M96t18UvXj19d8Xj46s/u/0u9+zoDZvFW9s7nOAbNoSCpcd1R8p3vRSYYD6e+qX1FVv+A4fu 6NfXqp32Jza+aR4Ye/GFO2u2uNcWjRWIX800+Gq2fZjKU5JRn5lO2iX9f7zhw1KwBAAA Archived-At: Subject: Re: [core] My wishlist for corr-clar X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 15:54:11 -0000 Hello Carsten and CoRE, great idea to create a corr-clar! I would like to add also a minor issue from the californium issues list: https://github.com/eclipse/californium/issues/664 "Example of using "ETAG" and "IF-None-MATCH" tags" https://tools.ietf.org/html/rfc7252#section-10.2.2 Conditional GETs: Conditional HTTP GET requests that include an "If- Match" or "If-None-Match" request-header field can be mapped to a corresponding CoAP request. The "If-Modified-Since" and "If- Unmodified-Since" request-header fields are not directly supported by CoAP but are implemented locally by a caching proxy. The californium issue was caused by the confusion,=20 if the http-options are mapped into their corresponding coap-option, or, only the http-request is mapped to a coap-request using potential different= options. I assume the second is true. If so, I would appreciate, if the exact mapping could be added explicitly. Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus Bosch=A0Software Innovations=A0GmbH | Stuttgarter Stra=DFe 130 | 71332 Waib= lingen | GERMANY | www.bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B=20 Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L=FCcke; Gesch=E4ftsf=FChrung:= Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic=20 -----Original Message----- From: core On Behalf Of Christian Ams=FCss Sent: Montag, 17. Dezember 2018 23:47 To: core@ietf.org Subject: [core] My wishlist for corr-clar Hello Carsten and CoRE, while there's no established workflow for adding to core-corr-clar, here ar= e a few items I've collected and think would make good additions to that do= cument: * A name for the path-less URI constructed from doing role reversal. RD would have been easier to write with this, and any role reversal is easier to argue about with it too, for example in OSCORE. * A statement on whether that can always be done even if the resulting URI can not be used by anyone else, or might not even have a proper URI representation (coap+tcp://...:ephemeral-port/ for the former, the address of the browser side of a websocket in for the latter). I've sketched up some strawman text (with potential not only better naming but also completely contrary statements) below. * The text from lwig-coap defining the "block key" * echo-request-tag uses a slightly updated version of this (even though not naming it) that elective NoCacheKey options are not described as part of the "block key" (as they could safely be served by an intermediary if all else matches). (Anyway, the lwig-coap text could be a starting point.) * Observation: Anything can cancel implicitly RFC7641 leaves it open how a new request on an active observation token should be processed if it's neither a registration update (which could only vary th ETag set) nor an explicit deregistration. Practically speaking, the server needs to assume that the client has lost any state it had of the observation (for otherwise it would have followed the protocol) and thus treat the old observation as cancelled and process whatever is in the new observation. corr-clar might be a good place to talk about this and pave the way towards sanctioning it. (In effect, that'd mean that anything in an observation can be changed by an observation update -- the server would treat it as a new registraiton anyway if it so wishes.) Has there been any progress on moving corr-clar towards WG adoption, or on = its procedural side (how section status w/rt WG consensus is managed)? Best regards Christian --- Strawman text for the constructed URI: 2.2 RFC7252-1.2 Terminology: RFC7252 hints at the possibility for role reversal in Section 9.1.1 by suggesting that the DTLS client should also act as the CoAP client, and RFC8323 accordingly distinguishes between a CoAP client and a connection initiator (however often they may coincide) in Section 3.3. They do not contain considerations for the URIs that'd describe resources on the DTLS client or connection initiator side. : Role-Reversal URI The Role-Reversal URI of a request is a URI based on which resources hosted by the endpoint that sent the request are named. Its construction depends on the protocol used. For CoAP over UDP, DTLS, TCP, TLS and WebSockets, the Role-Reversal URI i= s constructed by following RFC7252 Section 6.5 and RFC8323 Section 8.7, but with no CoAP options present, and using the source rather than destination address and port. For CoAP over TCP, TLS and WebSockets, that results in an address that is not generally usable (because opening such a connection would not succeed), but can still be used locally for the duration of the connection. Such URIs should not be used outside the host on which the Role-Reversal URI was generated, or for a longer than the connection persists. For CoAP over DTLS, TLS and secure WebSockets, the credentials presented by the Connection Initiator may be insufficient to justify using that connection as to access resources hosted on it. If applications use Role-Reversal URIs over secure protocols, they need to describe under which circumstances those URIs are usable. When used with IPv6, the source address can be a link-local address that requires a zone identifier to be disambiguated between several interfaces. A zone identifier is expressed following RFC 6874, and like Role-Reversal URIs in connection-based protocols can not be used outside the host which generated it. Note that a client can not express resources under its Role-Reversal URI in request payloads as relative references, as these requests's base URIs are ... [probably anonymous, with the application stepping in? the target URI?]. Resources on Role-Reversal URIs must be announced using relative references that use application-dpendant base URIs, or (preferably) perform resource discovery. {{I-D.core-resource-directory}} uses the Role-Reversal URI as the default value for the "base" registration parameter, and described explicitly there as it predates this definition. -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom From nobody Wed Dec 19 09:02:15 2018 Return-Path: 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 E4674130E66 for ; Wed, 19 Dec 2018 09:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Pbh7KX8B; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=TfV3HHTg 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 18CPZorEri3u for ; Wed, 19 Dec 2018 09:02:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4A3130E54 for ; Wed, 19 Dec 2018 09:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1545238928; x=1547830928; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LaW8aYTawPjgClO2va4ULmDzxY/cbtProD69CUVSMYQ=; b=Pbh7KX8B+zvtq5jmq2bUQy9PosPkKEwpnJQRLpBrSOtFG05KsqPYJLP81r0CdaH+ htj2cYpHrnTyCQW1/MVMCDxNp+6Vuxl4bV9RRNS0Nxq7Jr0SaP3q8OlyOAFka1Wm kl7b20NPbgy+uPvK0IQ/aEQJxpXxULld+LJVWvW4p8A=; X-AuditID: c1b4fb3a-167ff7000000672c-ca-5c1a79906d81 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.6D.26412.0997A1C5; Wed, 19 Dec 2018 18:02:08 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 19 Dec 2018 18:02:08 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 19 Dec 2018 18:02:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kthQwkwwnfsEnKdj0t4CR8dvkBW2IPsvCKlg6kBV6HM=; b=TfV3HHTgb9uFWhm3N581RL++xMQZ+aAC72nZY6A76i7W5DHd6zjzBhW/y9olkU+I0paBJ2Hal4M1yjH2LcgQ+bWUqI9IKgS9UoYX16DnEaS+mKCo3gRstIo7q+Eplb5J2W9zZlZUDMTsdNyUPgNIFo2asULpDWrsmhXwTGHGphw= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3084.eurprd07.prod.outlook.com (10.170.244.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Wed, 19 Dec 2018 17:02:07 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d887:8381:e9ee:6512]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d887:8381:e9ee:6512%3]) with mapi id 15.20.1446.018; Wed, 19 Dec 2018 17:02:07 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Kraus Achim (INST/ECS4)" CC: "core@ietf.org" Thread-Topic: Groupcomm for CoAP (RFC 7390) implementations Thread-Index: AQHUk5wb1rHWGBZAhU287Ez7+Sa8FaWGNSIQgAAcyQA= Date: Wed, 19 Dec 2018 17:02:06 +0000 Message-ID: References: <9F1B592D-E78C-4E2F-8402-EF029CAC1421@ericsson.com> <0e7ddbeabd4a4ad580b454330d3bb1d2@bosch-si.com> In-Reply-To: <0e7ddbeabd4a4ad580b454330d3bb1d2@bosch-si.com> Accept-Language: en-US Content-Language: sv-SE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [90.236.59.168] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3084; 6:8mtprhDnQVJVbWnWhk/Uw9op8IzkMG3e6ihQk0ZDN0fyJSiisVDn9Y9p9nfKpR4wSGEsMAqZmvapemLdnqF6wBJmcVDjIMt00IBdd+/jb2/N0UT3USxM4FZ0smn/7DntmDkvWqBQb6sRimh8hBtoOAj6KvgfoyT1TdzFpPad7Jbv/p0yS5MKsWMUiAwQjdLd2+kF/FmtfWi10MIRQJYTdU970jgSVHmgyzyvNqZ/LcqFpIdrhN3i8avHArmHYAhhmM/eGasT3TzWrh/k6x0E4pT4lrK6JLHUjiEcUY4jtt6ODzIfR2a/2u6GBS/Nfkxk/NVff0BC54ffVxVTyhHdhu9CvITSx7ETG6D8GR3XItA5VJM6bEWdp+R38RNpnPF6G5kFc9xbgHuXuoCs+aeYuooPYU5jxgyLP/rqG3uhIfM4biptyU4cvwspN/jlCbcejI9W8ZKNrXFsX5PipGSgvg==; 5:6xlx26LJY4qPWswe/Yg8icxU6X6u/sPqsdsl78Q5GVqOANa+TsgqXj3PmrVtj2Ym+6qkVJvhZhltXXSdorQwB+K1PWKmidfKL1SuLUdJbMuy6SG7vbwjWUwugfUFsjNXipEFkAAcz6H1s0i9IHNyj/NEX5fZY0tT1rPWJCnIoBI=; 7:bBd4JtJegKMG+JhG8eAYXM0DSbZYu7QfwPH/9DdSb4zVqFcONlnVv84w7CLySefL7CRp68s5YZ7f/YohqBVxCp9osYO0IvNtng+ppsL2/F/djArCE4LY0DoZvuXagZ92Usr/3BLqZCModt/LktBLpQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 43a2c0a3-a71d-414a-fd77-08d665d3b51b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR07MB3084; x-ms-traffictypediagnostic: HE1PR07MB3084: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(4983020)(4982022)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3084; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3084; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(136003)(396003)(199004)(189003)(13464003)(966005)(99936001)(6486002)(82746002)(476003)(6436002)(8936002)(86362001)(53936002)(478600001)(7736002)(305945005)(99286004)(486006)(11346002)(25786009)(446003)(14454004)(105586002)(2616005)(85202003)(66066001)(4326008)(15974865002)(68736007)(106356001)(6246003)(229853002)(53546011)(26005)(81156014)(2906002)(186003)(83716004)(5660300001)(71190400001)(3846002)(36756003)(6116002)(33656002)(81166006)(71200400001)(85182001)(76176011)(14444005)(256004)(6916009)(102836004)(6512007)(6306002)(66574012)(6506007)(8676002)(97736004)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3084; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YVKw9kZM68mNNrTHvAkMpyEboVmrt7ZEOyjAsNliDY5wALqqc0aG4JaFHhNzjyOJn7Gvr1it+PB8xE2fiUy/Ht0SKb8YLOMLLnzwcqXNynTW8aIbcSGyHfm2BpsonYIIqAbPCgSk6xn4ZV1+zg285cOIOVzK4ajImbmaYibm+W3mXn0zalHJ4WInpd+1jvYGPcigc8Cl05zTYJuYiqhyAM2wX9c+pxz9YxGEqbFqUQKQdkYoJr2RQkTsANWc8ZwUcryZLTxD5LaShNYULao8X0fD6wl3xLKLdcGw0DWD8nSQ9bd7+BOe+Pay8Bt9FvYh spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary=Apple-Mail-E9427BDC-E378-4A5D-A79E-6D5D07003625; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 43a2c0a3-a71d-414a-fd77-08d665d3b51b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 17:02:06.8800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3084 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe9733XwdLR+X5mGi6CpBQS1RMLXsCn4J/NCHUqlWvqiom+41 UVEYRhmaIZqImjfQNLMLJlgfnG6poZmaMQ0pcVNR85r3W6ttj4Hffuf8f5znHHhYWtIhkLJx ihROpZAnyIQipvR6a4Z3Qbo06tSvTY/AuldNgkDNwhv6PBXWXGNCYbW121Q4FSEKieYS4lI5 le+526LY0uFFlDQZmtbWeU2Nts7mIlsWsD/slOtsLCzBnQjeZTvlIpGZNxD8mb4vIEUtBdoX M4ylYHABDTk/9PtJEQUN3/poUhgRjC0+FliGCfFlGFcbKQs74EBY61mz9ml8HD6Vf7TyURwE y7tVDHGCoa5lS5iLWDMHwdBCuqXN4JPQur4utLAYh0Lblx2G7JoMWw8HrHvb4hDI6SiwPoXw MdjsbaLIU06wWjFOkTsdwPD1s5CwI8xOmATEvwnZr9X7fXfQPW9GhF1gqCoPWe4CPCwEQ+GD fckblouLacJXYaR9QkCkUQTZhRsCywGAvSC7+wzBePgw4Et0V2jMNzBEX6dhJX+YKUC+ZQd2 LTNnNC5C8ERXQpdZj7aHntJJhkie0J5Xv8/u8DTPYEM4GLafGRHhAJjr+o0OOtWIbUSOPMfz iTF+fj6cKu4uzysVPgoupRmZ/5K2ZTfoPdJOX9AhzCLZYXG/UholEchT+fREHTphnmN8+3IQ SRmFUsHJHMTf/c2xOFqensGplLdU9xI4XoecWUbmJN6T2EdJcIw8hYvnuCRO9T+lWFupGhW1 3Amn6n3ykv2zljwzI10oyUxf1rzGuc/VrmYyf7fGsGiT5tHDHrrSO7U0lZmm6TdFXPSc3tTP 72kUuvkVvyC22+QgbNgeqSx279IvXRr726+sqLxh19IxWn1ENhcZ8BMbnd3cKsZL1auFEDPo kaTHjVH64YBHs9qlEmW0jOFj5ae9aBUv/wfS1KMSUwMAAA== Archived-At: Subject: Re: [core] Groupcomm for CoAP (RFC 7390) implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 17:02:13 -0000 --Apple-Mail-E9427BDC-E378-4A5D-A79E-6D5D07003625 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWNoaW0sIHRoYW5rcyENCg0KSXQgc2VlbXMgdGhlcmUgaXMgbm8gbGlzdCB5ZXQgb2YgaW1wbGVt ZW50YXRpb25zIHN1cHBvcnRpbmcgQ29BUCBvdmVyIG11bHRpY2FzdC4gDQoNCkkgZ290IGFuIGlu ZGljYXRpb24gdGhhdCBNYmVkIE9TIGltcGxlbWVudHMgUkZDIDczOTAuIENvdWxkIHNvbWVvbmUg Y29uZmlybSBvciBkZW55IHRoYXQ/DQoNCk90aGVyIENvQVAgaW1wbGVtZW50YXRpb25zIHdpdGgg c3VwcG9ydCBmb3IgbXVsdGljYXN0Pw0KDQpUaGFua3MNCkfDtnJhbg0KDQoNCg0KPiAxOSBkZWMu IDIwMTgga2wuIDE2OjI1IHNrcmV2IEtyYXVzIEFjaGltIChJTlNUL0VDUzQpIDxBY2hpbS5LcmF1 c0Bib3NjaC1zaS5jb20+Og0KPiANCj4gSGksDQo+IA0KPiBDYWxpZm9ybml1bSBvZmZlcnMgYSAi dmVyeSBlYXJseSIgc3VwcG9ydCBmb3IgbXVsdGljYXN0IHNpbmNlIGVuZCBvZiBPY3RvYmVyIDIw MTgNCj4gKGN1cnJlbnRseSBpbiB0aGUgMi4wLngtU05BUFNIT1QpLiANCj4gQnV0IEkgd291bGQg Z28gdGhhdCBmYXIsIHRvIHNheSwgdGhpcyBpcyBSRkM3MzkwIGNvbXBsaWFudCA6LSkuICAgIA0K PiANCj4gTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbiAvIEJlc3QgcmVnYXJkcw0KPiANCj4gQWNo aW0gS3JhdXMNCj4gDQo+IChJTlNUL0VDUzQpIA0KPiBCb3NjaCBTb2Z0d2FyZSBJbm5vdmF0aW9u cyBHbWJIIHwgU3R1dHRnYXJ0ZXIgU3RyYcOfZSAxMzAgfCA3MTMzMiBXYWlibGluZ2VuIHwgR0VS TUFOWSB8IHd3dy5ib3NjaC1zaS5jb20NCj4gDQo+IFNpdHo6IEJlcmxpbiwgUmVnaXN0ZXJnZXJp Y2h0OiBBbXRzZ2VyaWNodCBDaGFybG90dGVuYnVyZzsgSFJCIDE0ODQxMSBCIA0KPiBBdWZzaWNo dHNyYXRzdm9yc2l0emVuZGVyOiBEci4tSW5nLiBUaG9yc3RlbiBMw7xja2U7IEdlc2Now6RmdHNm w7xocnVuZzogRHIuIFN0ZWZhbiBGZXJiZXIsIE1pY2hhZWwgSGFobiwgRHIuIEFsZWtzYW5kYXIg TWl0cm92aWMgDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog Y29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgR8O2cmFuIFNlbGFuZGVy DQo+IFNlbnQ6IEZyZWl0YWcsIDE0LiBEZXplbWJlciAyMDE4IDEyOjAwDQo+IFRvOiBjb3JlQGll dGYub3JnDQo+IFN1YmplY3Q6IFtjb3JlXSBHcm91cGNvbW0gZm9yIENvQVAgKFJGQyA3MzkwKSBp bXBsZW1lbnRhdGlvbnMNCj4gDQo+IEFsbCwNCj4gDQo+IERvZXMgYW55b25lIGtub3cgaWYgdGhl cmUgaXMgYSBsaXN0IG9mIENvQVAgaW1wbGVtZW50YXRpb25zIHN1cHBvcnRpbmcgUkZDIDczOTAg KEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVApPyANCj4gDQo+IGh0dHA6Ly9jb2FwLnRlY2hu b2xvZ3kvIG1lbnRpb25zIFJGQyA3MzkwIHVuZGVyICJzcGVjaWZpY2F0aW9ucyIgYnV0IEkgZGlk bid0IGZpbmQgYW55dGhpbmcgdW5kZXIgImltcGxlbWVudGF0aW9ucyIuDQo+IA0KPiBUaGFua3MN Cj4gR8O2cmFuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== --Apple-Mail-E9427BDC-E378-4A5D-A79E-6D5D07003625 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMyjCCBgAw ggPooAMCAQICEQDitNpy8aKbKejNtzWscSV0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MzAeFw0xODAyMDExMjQ5MTJaFw0yMTAyMDExMjQ5MTFaMGsxETAPBgNVBAoMCEVyaWNzc29uMRgw FgYDVQQDDA9Hw7ZyYW4gU2VsYW5kZXIxKjAoBgkqhkiG9w0BCQEWG2dvcmFuLnNlbGFuZGVyQGVy aWNzc29uLmNvbTEQMA4GA1UEBRMHZXJhZ29zZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALZyYqhrKqHwiZ9VtUIG2KpEzGfaqDSmGGsPGoLJoRFtqgrASfmHoEs0uYzKIZIrfZbUswG3 g6oHaoCICXtWOS0rxWx3KYiNbf3ekBqejhL/gg/sxG4l0Ko15odauekanpBH+xiojMKkpy61Rs6l ZZomjVazPRa9sFBg8suyoZzMqReTSoalKN9lKSp8tm7Fqa/GXvQGCIRxDv761jishq0J9mU1BOPW CfBhFjpgnldqO6xQ/utmk5VgJZFOzyk51ym+Nn6CO8Q/hMcX6vBCx2Mk4G/iWd7B86qXwv8pppa8 EtJw9s4v8fZ4A5s42G71pjx+bwx9hjvena+2bnPwVScCAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8w PaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 My5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRl bGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2dvcmFuLnNlbGFuZGVyQGVyaWNz c29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFDpeCIPtX5pdpmwWTBhfPzwgqPVOMB8GA1UdIwQYMBaAFBx7 GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAwdPb CdlbVFhVXREJjekBfVFM1NHlY+PN/KA6RHWmIiXqeAXRzS/QpY76mdqv1DXwXyTqrMpxst/Qgddb eKLEedwXlyxRB83vR8wTfFowfNv8jHZMFz6dWW2CJC5dj68b4H3Ur0/HniDvBKc7iUuWL2ehIeC8 rC+q8B1+ydvLcgDUYCbHgERDo/1zbVpb1I8ITnP+tRmpUHAi7eLYrXbOpyzqXt+oymNLzL7Y4hY1 J6bravIEwvCNk/k45ojuxTRjcTV06U2mAHU8KBTq4dgzeLvkIjgJtdLNnBWD/BdZocXhv8Y8ZE/e c5tSeVIwWbL79cMMrbBh+DFJYXYLc/cZKT/fN5Vcjo6cqDYWRdYCJQvZrVD0kZdePO8w2+Wf9dDm z+sAkSrDLl/bMAPF/TUNwxiMaweYM/9SZ91RENS/AOALZ+64krp4NllCl7faitrzfLs7ltT8p2FT lsUQMsSymGyNHCbPJpDonguQj8SjO1dn9SZNcMWPZ5zOrLPqfipxZNsG83tA41kIxW7AZWS0MFGV cj8n76L1j5SO7y4DvfIYEmFT0pCCymHc/MhrKArr07nv1uTTWSltlKCJ3rGxNWFNP9YjkOme8VqG ywnoaB5VDsJrqD9r/Re1bc8Oe9oiShIVCfFX34RkXpBLdf72Jt3XSf3Vc4n6XKPMjzMri5kwggbC MIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0 NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5v u5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ub ppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o 58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57 HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWI XwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw 1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOd gdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1 c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6 Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB /wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0 cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6g PIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYx LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud DgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gT EjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q 1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8O UWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw9 6AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0Ro GzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CC KEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i 7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+R zPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKk veBJzqgb8ToH7WLoOzmPRCmPlpAxggLAMIICvAIBATBcMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIRAOK02nLx opsp6M23NaxxJXQwCQYFKw4DAhoFAKCCATkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTgxMjE5MTcwMjA2WjAjBgkqhkiG9w0BCQQxFgQUX9/loEPDRKugVosKDYDe wZhYxAIwawYJKwYBBAGCNxAEMV4wXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDitNpy8aKbKejNtzWscSV0 MG0GCyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDitNpy8aKbKejNtzWscSV0MA0G CSqGSIb3DQEBAQUABIIBAITQ6IQZccupf/+R9XNwhOuU5enU2qCQq/DeD0fmVaSMIDKuRL5t8xwi KdckUCNzIy2fJPnQjjaNQQgDV1HTdM1s/rhzMC06IRQHs7Q0daBTDs+8MU60aaXmMmr/6w9mvsaq jg3i8e5PS9GDctlFHU2ozSeX/wFC1khumHGqfWNEcO49qv77d4miVuxPl7bUTqbWTZiaMh/iRimy 9dXwVYU7sZ1QUlKzuVMeQ0kwVrjmjO4vjpeWMrwmKJyevH5vM2OOvbnMcQD41WG5sdfbuCv2YFdZ HszlZVNSSQsinWLFF7+KldirMhLG4+2sU+NaeyjRCS35x77IH8KWWyYbpjkAAAAAAAA= --Apple-Mail-E9427BDC-E378-4A5D-A79E-6D5D07003625-- From nobody Wed Dec 19 10:50:16 2018 Return-Path: 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 6F6D0130EBB for ; Wed, 19 Dec 2018 10:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mZP-xrXSlEeD for ; Wed, 19 Dec 2018 10:49:58 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B34130EBD for ; Wed, 19 Dec 2018 10:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBJInlvv025884; Wed, 19 Dec 2018 19:49:52 +0100 (CET) Received: from [192.168.217.102] (p54A6C3F1.dip0.t-ipconnect.de [84.166.195.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43KkTQ5fX8z1Br6; Wed, 19 Dec 2018 19:49:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Dec 2018 19:49:45 +0100 Cc: "Kraus Achim (INST/ECS4)" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 566938184.393572-24520a800baf937257e7839dba39f7f0 Content-Transfer-Encoding: quoted-printable Message-Id: <846CB7BF-0D57-44BC-8F7E-0E8C308973AA@tzi.org> References: <9F1B592D-E78C-4E2F-8402-EF029CAC1421@ericsson.com> <0e7ddbeabd4a4ad580b454330d3bb1d2@bosch-si.com> To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Groupcomm for CoAP (RFC 7390) implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 18:50:03 -0000 On Dec 19, 2018, at 18:02, G=C3=B6ran Selander = wrote: >=20 > It seems there is no list yet of implementations supporting CoAP over = multicast.=20 Just for the record: I would expect any CoAP server implementation to = support CoAP over multicast; otherwise the requirements in section 7 and = 8 about discovery cannot be met. I think we are talking about support beyond that, as in RFC 7390 = support? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Dec 19 12:11:22 2018 Return-Path: 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 D143B130ED8 for ; Wed, 19 Dec 2018 12:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=bD0hdSBW; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=dK2WudC8 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 Af0ySCGS465T for ; Wed, 19 Dec 2018 12:11:18 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C4E130EC9 for ; Wed, 19 Dec 2018 12:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1545250276; x=1547842276; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MK+NYWLXUk9UjGFcnTzyEb2cMrzf/T0Luv2DctxaxEA=; b=bD0hdSBWyURa/Fi67bpQ9cQR3HLzPRwKv5kEZvFDQP6eE1v1v3b7k/iBkI5bEsiN UP32gXYF6G4BrWCSMIx8pQXk9L9WoZop/kvB+F1XznTDRAi2syuuqpv7bJ8DwbKH f12dReH/M4Q0kiXY+paIAE676zHRWVVhdMMPyHZoGGo=; X-AuditID: c1b4fb2d-2198b9e00000062f-39-5c1aa5e34bf4 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E6.E8.01583.3E5AA1C5; Wed, 19 Dec 2018 21:11:16 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 19 Dec 2018 21:10:21 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 19 Dec 2018 21:10:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vt2DMVZP281t3/uv/YG18Lif1cXmIaesk5Y6Tk4/NMk=; b=dK2WudC8tnA4JxfdTj+lMn3qLAdFykXBb7+V/RfpmIIo8WV+yfvNO44JXeA66zxvv1HcAcTOP/ABo4S9wJRN9jzyNqqLp6tKvOq9tHb1pUgT9gDmM+LG4UsfwT6hQCJGrdc5oqgadfs+6HfTm/AdTn4RvZSqwjbYO76bmXxaIhw= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3308.eurprd07.prod.outlook.com (10.170.246.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.15; Wed, 19 Dec 2018 20:10:20 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d887:8381:e9ee:6512]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::d887:8381:e9ee:6512%3]) with mapi id 15.20.1446.018; Wed, 19 Dec 2018 20:10:20 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann CC: "Kraus Achim (INST/ECS4)" , "core@ietf.org" Thread-Topic: [core] Groupcomm for CoAP (RFC 7390) implementations Thread-Index: AQHUk5wb1rHWGBZAhU287Ez7+Sa8FaWGNSIQgAAcyQCAAB4UgIAAFoEA Date: Wed, 19 Dec 2018 20:10:19 +0000 Message-ID: <8F7034D2-B296-4066-92AF-CDF61C3678DF@ericsson.com> References: <9F1B592D-E78C-4E2F-8402-EF029CAC1421@ericsson.com> <0e7ddbeabd4a4ad580b454330d3bb1d2@bosch-si.com> <846CB7BF-0D57-44BC-8F7E-0E8C308973AA@tzi.org> In-Reply-To: <846CB7BF-0D57-44BC-8F7E-0E8C308973AA@tzi.org> Accept-Language: en-US Content-Language: sv-SE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [90.236.59.168] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3308; 6:W27gn5QkZhXtaUapuiTzT0uPlQ+M+6H7PXqFU0cbPKll2Pwcd+39GIsy2IpzPrKtE9QYGVqjpEIg589pMNkwWsHHMuvvTld/snyUB+XCcvSuKT4i6EAjDwBqrprRVLI9u7zl5GKsnK/nDuyMhr2EfUtbvLRDouZVJthmH8ZpEYu/N1s0DRTt68yPqhurt8RvhRJsskVJUvl9vwWLwDbDKvJOaJ0PE1L/47h7u5dRmZIWTyEaGVG1w+8E2J9Rx2/hutqorbiQu7FNA96dQ7LznHTPVWaUSSy16RSr5NwxdOitBN4I9SRWRwzlFHTKPFnBKkpqknYW9LhVXiLk5Q5z3GwKXc8DppN5eC0MIU3genzCa7ma36nTOsQ2jehSVL6wZjve3g9RR7SFuplYcq+C8vYxPed/Gc6/H4WI5E7oDltpxKKvAr/wZZo9F7ujuSTLmv/3iFlPxnrSxe8S8iFfWQ==; 5:tfulKviDhL86PV31pJGgkPYFrBUKEUMVyzFdS5iMmnm8YvGpBYpwVE5JjwAM3fQ8ZHOuPqJPuC/kKUQUuoF3uCQLAp2ahI2jA2j9YTHM9GuB3B7vtBJQJwt4UGhHEZpQx9xN2WYsMuMtW4yLYi9nWXX5APvOpXDr6ZT+i/6mu/o=; 7:q1jDj4hM/xD6ZXR7zazC2ncCfgz/PPg3C1TTdJfOrrcM0mDEIQcAt+xIA5aHbUbDKikMyqgMf4NZtHBenYwgQxfFE2FEIvP+/gRZP8L8KXOjI9t1Ls6DSXORFczMHWqrTI8GZDycrBb5wXdqd5KAXg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fc223d0b-b356-4756-a414-08d665ee0044 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR07MB3308; x-ms-traffictypediagnostic: HE1PR07MB3308: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(102415395)(6040522)(2401047)(8121501046)(5005006)(3231475)(944501520)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3308; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3308; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(366004)(136003)(189003)(199004)(8936002)(105586002)(478600001)(85202003)(106356001)(33656002)(66066001)(316002)(54906003)(5660300001)(93886005)(8676002)(97736004)(256004)(85182001)(486006)(11346002)(2616005)(476003)(3846002)(6116002)(81166006)(81156014)(2906002)(446003)(99936001)(14454004)(36756003)(7736002)(83716004)(229853002)(76176011)(6512007)(26005)(186003)(6486002)(86362001)(6246003)(102836004)(6436002)(6506007)(25786009)(6916009)(53546011)(305945005)(71200400001)(71190400001)(99286004)(53936002)(4326008)(82746002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3308; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cgabaJD/c5MQDj19EKt3NNTLRRg3ejurRFGDzP/JvSJgLBzAsGcKPu38/kuyLJIfkzkjfRfnD+JUFg18EiqPfqgGMMNfHxAo2GAmpPidAeDXTS40GgqIEB9SBEtayjZ/4yseR+lUwZn0uOSqSniBAlZHTNGI0Klg/ZICDKgKfkHT3YvQIauZY17H1p4X85uSnIlTNhlzuUKgsVQLbIbtfrMn8X8hEkKdTJW5Judh6SVE9GqHHzZ81/99QWHM0pZ536SzfSYGZNBQECeWAFAuOKZtgCC45VcGCivZ8iIJWycP+0Jf/rzjTYEAeNVdjeUH spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary=Apple-Mail-143BEB1A-2209-46F5-A8C7-503C1E7B9AD3; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fc223d0b-b356-4756-a414-08d665ee0044 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 20:10:19.9374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3308 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03Se0hTURwHcM7u3XYdDY5z5o9JgSOFjGn5CMEwDTGzNxFJWTr0oqZO2TVT ozQzwqlgpaGryMc08pGysqzh1KV/+Cimouh8TzHDDLPINJPc7gL/+5zz+57z+x04FCHq5kqo eEUqrVTIE6U8AVkW/va6bK5aErG/Zwj5VTfUc/06iye4fvqlRiKQCNVWbKJQjWaNE/qoMv4M cVFwKIZOjE+jlZ4BUYK4x98K+CkFB9MbdYX8bNTuo0IUBdgHWibCVMiOEuFOBLdVIax/IXjf cIu1hgMa3WUVElAkLiLgVWsVaVmIcDEHNsYGeGzKjGCk1stiHg6G6Wwzx2IxloKxv96aIfAl +PnZaN13wEFQM9hhyxyBBb2OZB0C8yoj32ISu0LlsBFZLMSHwWQYJdjGIwhMd0oJS8EO+0Nf hc7aAOGdsNpTz2GbOcGPp9NWAxbDTH8vj7UjfJnd5LL5K5DzMtu27wKGGi1ivQsGnuXbPMyD 3/Ni1jJYLikhWJ+EFx1T1oEAmxAMto3aDrjDeM6szQkw1jVJst4NtYUzJHtgjoAqTTO/CHmq tw2r3qoR+CEC/Ug7V219tj10l82RbGgvtOU/t9kFivNn+Kz9Ye2JGbH2hcWu72h7phxRtciR oRkmKdbL24NWxkczTLLCQ0GnatHWp+p4/UfWguoWgwwIU0i6Q6hQSyJEXHkak5FkQHu27jE3 1RmRhFQkK2ipWLhStFUWxsgzMmllcqTyWiLNGJAzRUqdhBsi+wgRjpWn0gk0nUIr/1c5lJ0k G6kLS7LG19Zlsqudbn1Hc+8JgNQvuz4YI6K+jg+fPi5zM7eWLviKmyYDHFJaCk7NmM7kVQjC Pq3m7RN94E79NZ3LKj9v7A9e2lyPDnDSut29qXv3Jj38xIX83pFGL3L0Rsp9ZW54oMl5qLlk YNoo7s4s8JavREdVNWUKj0XWn/0oJZk4+QF3QsnI/wFnKRcWXAMAAA== Archived-At: Subject: Re: [core] Groupcomm for CoAP (RFC 7390) implementations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 20:11:20 -0000 --Apple-Mail-143BEB1A-2209-46F5-A8C7-503C1E7B9AD3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNCj4gMTkgZGVjLiAyMDE4IGtsLiAxOTo1MCBza3JldiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZz46DQo+IA0KPj4gT24gRGVjIDE5LCAyMDE4LCBhdCAxODowMiwgR8O2cmFuIFNlbGFu ZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gDQo+PiBJdCBzZWVt cyB0aGVyZSBpcyBubyBsaXN0IHlldCBvZiBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydGluZyBDb0FQ IG92ZXIgbXVsdGljYXN0LiANCj4gDQo+IEp1c3QgZm9yIHRoZSByZWNvcmQ6IEkgd291bGQgZXhw ZWN0IGFueSBDb0FQIHNlcnZlciBpbXBsZW1lbnRhdGlvbiB0byBzdXBwb3J0IENvQVAgb3ZlciBt dWx0aWNhc3Q7IG90aGVyd2lzZSB0aGUgcmVxdWlyZW1lbnRzIGluIHNlY3Rpb24gNyBhbmQgOCBh Ym91dCBkaXNjb3ZlcnkgY2Fubm90IGJlIG1ldC4NCj4gDQo+IEkgdGhpbmsgd2UgYXJlIHRhbGtp bmcgYWJvdXQgc3VwcG9ydCBiZXlvbmQgdGhhdCwgYXMgaW4gUkZDIDczOTAgc3VwcG9ydD8NCg0K WWVzLCBSRkMgNzM5MCwgYnV0IG5vdCBuZWNlc3NhcmlseSBjb21wbGV0ZTsgb25lIHJlYXNvbiBm b3IgdGhlIHF1ZXN0aW9uIGlzIHRvIGlkZW50aWZ5IHdoaWNoIGNvbW11bml0aWVzIG1heSBiZSBp bnRlcmVzdGVkIGluIHRoZSB1cGRhdGVkIGRyYWZ0IGFuZCB0aGUgdXBjb21pbmcgaW50ZXJvcCB0 ZXN0LiANCg0KQlINCkfDtnJhbg0KDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo= --Apple-Mail-143BEB1A-2209-46F5-A8C7-503C1E7B9AD3 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMyjCCBgAw ggPooAMCAQICEQDitNpy8aKbKejNtzWscSV0MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MzAeFw0xODAyMDExMjQ5MTJaFw0yMTAyMDExMjQ5MTFaMGsxETAPBgNVBAoMCEVyaWNzc29uMRgw FgYDVQQDDA9Hw7ZyYW4gU2VsYW5kZXIxKjAoBgkqhkiG9w0BCQEWG2dvcmFuLnNlbGFuZGVyQGVy aWNzc29uLmNvbTEQMA4GA1UEBRMHZXJhZ29zZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALZyYqhrKqHwiZ9VtUIG2KpEzGfaqDSmGGsPGoLJoRFtqgrASfmHoEs0uYzKIZIrfZbUswG3 g6oHaoCICXtWOS0rxWx3KYiNbf3ekBqejhL/gg/sxG4l0Ko15odauekanpBH+xiojMKkpy61Rs6l ZZomjVazPRa9sFBg8suyoZzMqReTSoalKN9lKSp8tm7Fqa/GXvQGCIRxDv761jishq0J9mU1BOPW CfBhFjpgnldqO6xQ/utmk5VgJZFOzyk51ym+Nn6CO8Q/hMcX6vBCx2Mk4G/iWd7B86qXwv8pppa8 EtJw9s4v8fZ4A5s42G71pjx+bwx9hjvena+2bnPwVScCAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8w PaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 My5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRl bGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2dvcmFuLnNlbGFuZGVyQGVyaWNz c29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFDpeCIPtX5pdpmwWTBhfPzwgqPVOMB8GA1UdIwQYMBaAFBx7 GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAwdPb CdlbVFhVXREJjekBfVFM1NHlY+PN/KA6RHWmIiXqeAXRzS/QpY76mdqv1DXwXyTqrMpxst/Qgddb eKLEedwXlyxRB83vR8wTfFowfNv8jHZMFz6dWW2CJC5dj68b4H3Ur0/HniDvBKc7iUuWL2ehIeC8 rC+q8B1+ydvLcgDUYCbHgERDo/1zbVpb1I8ITnP+tRmpUHAi7eLYrXbOpyzqXt+oymNLzL7Y4hY1 J6bravIEwvCNk/k45ojuxTRjcTV06U2mAHU8KBTq4dgzeLvkIjgJtdLNnBWD/BdZocXhv8Y8ZE/e c5tSeVIwWbL79cMMrbBh+DFJYXYLc/cZKT/fN5Vcjo6cqDYWRdYCJQvZrVD0kZdePO8w2+Wf9dDm z+sAkSrDLl/bMAPF/TUNwxiMaweYM/9SZ91RENS/AOALZ+64krp4NllCl7faitrzfLs7ltT8p2FT lsUQMsSymGyNHCbPJpDonguQj8SjO1dn9SZNcMWPZ5zOrLPqfipxZNsG83tA41kIxW7AZWS0MFGV cj8n76L1j5SO7y4DvfIYEmFT0pCCymHc/MhrKArr07nv1uTTWSltlKCJ3rGxNWFNP9YjkOme8VqG ywnoaB5VDsJrqD9r/Re1bc8Oe9oiShIVCfFX34RkXpBLdf72Jt3XSf3Vc4n6XKPMjzMri5kwggbC MIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0 NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5v u5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ub ppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o 58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57 HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWI XwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw 1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOd gdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1 c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6 Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB /wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0 cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6g PIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYx LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud DgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gT EjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q 1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8O UWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw9 6AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0Ro GzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CC KEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i 7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+R zPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKk veBJzqgb8ToH7WLoOzmPRCmPlpAxggLAMIICvAIBATBcMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIRAOK02nLx opsp6M23NaxxJXQwCQYFKw4DAhoFAKCCATkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTgxMjE5MjAxMDE5WjAjBgkqhkiG9w0BCQQxFgQUGDl99dzJkfD6P6IxufLs XYi/PIkwawYJKwYBBAGCNxAEMV4wXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDitNpy8aKbKejNtzWscSV0 MG0GCyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDitNpy8aKbKejNtzWscSV0MA0G CSqGSIb3DQEBAQUABIIBAFGgrlqWYufONkT68GswitVjAuhMSmlOPbzKnF/eNGpuJRwpQBmBqz6W QYGAgAZnze2hXwSvCp/AiZjkH33YSch9D+45v6ZB/M7G5+L67HleWRRhQDCUPTaEDyaHlLyf+MjF EpBNi5pirSW9n0Xy+YWGo3dyPxOjdJXoVIf6IM9J1IZ3CYpjjCPfqtulDT6uIh1PGlSmwolPuisG 2jycMTsYzjNaT042+7gC+W/7JlSmfer+6hum3nc/BWu5pR2K2JFqtL8MaG7O3eUbFC6ZTlUdILxq d5r3w9UUaXivoTjiPkaPf+fQ9L9POOfwpBacx6NZ2W3f4wzJ0eXtrEArGWoAAAAAAAA= --Apple-Mail-143BEB1A-2209-46F5-A8C7-503C1E7B9AD3-- From nobody Thu Dec 20 05:22:48 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C44D12426E; Thu, 20 Dec 2018 05:22:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <154531216653.19071.6019607110746941985@ietfa.amsl.com> Date: Thu, 20 Dec 2018 05:22:46 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-18.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 13:22:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-18.txt Pages : 74 Date : 2018-12-20 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-18 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 20 06:40:57 2018 Return-Path: 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 4632A12894E; Thu, 20 Dec 2018 06:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.565 X-Spam-Level: X-Spam-Status: No, score=-14.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 F7QGr9IR3Y1c; Thu, 20 Dec 2018 06:40:53 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6396A1277CC; Thu, 20 Dec 2018 06:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2971; q=dns/txt; s=iport; t=1545316851; x=1546526451; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=F026c1+Se4d/JgUnUreyauqFeX+qopJnKxayOjU1GFI=; b=UAhQQYOHt9rk2hOS6FPZmymal+7WwHBKocr8Aoz8+n0V06/Uug8XVbje zwf1oYQ2AIzy9PXtLCzLn0jNyHrto7zK96QplW7X2Kn0gqBA6f5DKQAb3 hW0E4sXtwTjlbeh3UEt//AVDDs0iIfTM4dZsueonaSaEnHrSSiuOyhdZK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADMqBtc/xbLJq1aChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYJpcBIng32IGV+MfAgll12Bew0YC4R?= =?us-ascii?q?JAoMONAkNAQMBAQIBAQJtHAyFPQEBBAEBIQ8BBTYbCxgCAiYCAicwBwwGAgE?= =?us-ascii?q?Bgx4BggEPp2CBL4QxAg5AP4RpgQuLS4FAP4E4DIJfgx4BAQIBARaBHAWDLoJ?= =?us-ascii?q?XAolHl3YJhxGKTgYYgV9NhFKDC4dUiU2Ee4RHhn6BRjgogS4zGggbFRohgmw?= =?us-ascii?q?Jgh4XiF6FPz8DMIwbgkwBAQ?= X-IronPort-AV: E=Sophos;i="5.56,377,1539648000"; d="scan'208";a="8939900" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 14:40:49 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wBKEenKv020417; Thu, 20 Dec 2018 14:40:50 GMT To: core@ietf.org, draft-ietf-core-sid@ietf.org References: <154522486568.14754.12136677357051268505@ietfa.amsl.com> From: Robert Wilton Message-ID: Date: Thu, 20 Dec 2018 14:40:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <154522486568.14754.12136677357051268505@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-sid-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 14:40:55 -0000 Hi, I've raised this previously, but I'm not sure whether there was any discussion or conclusion, or perhaps I missed it: SIDs are currently defined to be 64 bit unsigned numbers, but I think that it would be better to limit these to the positive part of signed 64 bit integers instead.  This still allows a very large range of SIDs to be allocated but I think will make it easier for normal programming languages to handle: 1) Both Python and JVM based languages don't naturally handle unsigned 64 bit integers.  It is pragmatically likely that those implementations will probably choose to use a signed 64 bit integer instead to represent SIDs, breaking interoperability. 2) The SIDs in the YANG CBOR encoded as deltas to the parent SID.  If the parent has a small SID (e.g . 1), and the child has a large SID (e.g. 2^64-1) then the delta will end up as a large negative number (2^64 - 2) that cannot be represented in C's signed 64 bit integer, making that difficult to handle as well. Hence, given signed integer maths is expected to be performed on SIDs, it would be safer and easier to define them within the range of values that can be represented by a signed 64 integer. Thanks, Rob On 19/12/2018 13:07, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Constrained RESTful Environments WG of the IETF. > > Title : YANG Schema Item iDentifier (SID) > Authors : Michel Veillette > Alexander Pelov > Ivaylo Petrov > Filename : draft-ietf-core-sid-05.txt > Pages : 26 > Date : 2018-12-19 > > Abstract: > YANG Schema Item iDentifiers (SID) are globally unique 64-bit > unsigned numbers used to identify YANG items. This document defines > the semantics, the registration, and assignment processes of SIDs. > To enable the implementation of these processes, this document also > defines a file format used to persist and publish assigned SIDs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-sid-05 > https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > . > From nobody Thu Dec 20 09:10:16 2018 Return-Path: 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 2D6FE13113D for ; Thu, 20 Dec 2018 09:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ccldM3MQ_ZHd for ; Thu, 20 Dec 2018 09:10:11 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B7313113B for ; Thu, 20 Dec 2018 09:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wBKHA37n023624 for ; Thu, 20 Dec 2018 18:10:08 +0100 (CET) Received: from client-0187.vpn.uni-bremen.de (client-0187.vpn.uni-bremen.de [134.102.107.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43LJCv00KHz1Br6; Thu, 20 Dec 2018 18:10:02 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <6C69E274-A35B-4447-ABBA-A4C46BA42F5A@tzi.org> Date: Thu, 20 Dec 2018 18:10:01 +0100 X-Mao-Original-Outgoing-Id: 567018598.844803-30863a9df2901a434a1f3acfd9d913cc Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E82C032-312F-4031-AE45-13D56868D8C3@tzi.org> <6C69E274-A35B-4447-ABBA-A4C46BA42F5A@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] Going for 1600Z -- Re: CoRE Virtual Interims between IETF103 and IETF104 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 17:10:14 -0000 In the virtual interim just a few minutes ago, we decided to go for = 1600Z (with apologies to the US west coast participants; please all buy = them beers in Prague). This makes it: >> Day: every other Wednesday beginning on 9 January >> Dates: 9, 23 Jan; 6, 20 Feb; 6, 20 March >> Time: 16:00 to 17:00 UTC=20 >> (08:00..09:00 PST except for 2019-03-20, 17:00..28:00 CET, =E2=80=A6) Other notes from today=E2=80=99s virtual interim are at: https://etherpad.tools.ietf.org/p/notes-interim-2012-12-20-core (Thanks, Marco, Klaus, and other unnamed note takers. And thanks to Christian and Klaus for preparing the slots! Please send slides to the chairs.) Gr=C3=BC=C3=9Fe, Carsten