From nobody Sun Apr 1 11:37:51 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 6192F120454; Sun, 1 Apr 2018 11:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 K0vb-Nsq7maG; Sun, 1 Apr 2018 11:37:48 -0700 (PDT) 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 7C056126BF0; Sun, 1 Apr 2018 11:37:48 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 1 Apr 2018 11:35:31 -0700 From: Jim Schaad To: CC: 'core' Date: Sun, 1 Apr 2018 11:37:39 -0700 Message-ID: <053601d3c9e8$84da96f0$8e8fc4d0$@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: AdNVlUeSaSytAQ/PQfuysn69+VtrlA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 01 Apr 2018 18:37:50 -0000 Here are some more questions on the document. 1. The registration text in section 5.3 says that the interface is idempotent, however it is not clear to me just how idempotent this is supposed to be. It is obvious that the goal is to make sure that a different resource is not created, however I am not clear what is supposed to happen with some of the parameters such as the 'lt' parameter. One way to implement this is to just make it a POST to the previously existing resource which would inherit old attributes on the endpoint. The other way is to say we are going to create a new resource, it just has the same address. It is not clear which, if any, of these two methods is to be used. Never mind I found the answer to this one. Need to think if I want clearer language. 2. When doing an endpoint lookup, I assume that the 'lt' parameter would be the same as the one registered at creation. Is there/should there be a parameter which is a TTL value? 3. How are href comparisons done. a) compare against what was registered b) Resolve what was registered and the href in the current context and compare c) something I did not think of 4. compare on group for remote endpoint. Should this do the remote lookup or can it just be ignored for attribute comparison 5. Value of lt = should it be the set parameter or the time left - how would time left be represented outherwise - should it be represented. 6. Inferred context based on source IP when an update is done. If no con is provided, is that supposed to be checked again to see if it is "right"? Only if we did the infer to begin with? 7. I don't understand the presence of the content-format for the empty message posted for simple registration. This seems to be odd if the content is empty. 8 Is there supposed to be a way for simple registration to return an error message? As written this is not necessarily done. Specifically, the response to the post can be executed before the query to /.well-known/core is done and the registration is attempted. From nobody Mon Apr 2 13:29:06 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 4E8AE120454; Mon, 2 Apr 2018 13:29:04 -0700 (PDT) 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.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152270094426.28572.17716524654688812656@ietfa.amsl.com> Date: Mon, 02 Apr 2018 13:29:04 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 20:29:04 -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 : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-14.txt Pages : 49 Date : 2018-04-02 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-14 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-14 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 Mon Apr 2 13:36: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 6F6C7126C2F for ; Mon, 2 Apr 2018 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 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 5kwFyUzHHVfl for ; Mon, 2 Apr 2018 13:36:31 -0700 (PDT) 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 E5CBD12D87B for ; Mon, 2 Apr 2018 13:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522701384; 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=pVhFuv6lkPF3KlUoLlRhQgGVvtDhLYGjUCVKE2q7YF0=; b=gl/4RcrDjAXm8o6gL7mktiJzb/FE6nc+ba942CT7MHttrXsOHrPEz0Wqhq+28HOx nVgZ9cm9PcdE04RBDYsTiMPYNsViTkU6vn9o3XrVwZF+6dRrW/Yo5s5kJfb0P9Rv ShrchCOM4FBmxCrEgVPCU0Y/u4IlJfMKQKNOUOJBLjY=; X-AuditID: c1b4fb25-1c7ff7000000522b-70-5ac2944755fc Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2C.81.21035.74492CA5; Mon, 2 Apr 2018 22:36:24 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0382.000; Mon, 2 Apr 2018 22:36:23 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] I-D Action: draft-ietf-core-senml-14.txt Thread-Index: AQHTysFBN0qa8fp5N0+VG4AroneMKqPtzZEA Date: Mon, 2 Apr 2018 20:36:22 +0000 Message-ID: <1EB61F67-6163-4C30-A226-C7F78258EC2A@ericsson.com> References: <152270094426.28572.17716524654688812656@ietfa.amsl.com> In-Reply-To: <152270094426.28572.17716524654688812656@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.95.226.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7iK7HlENRBsef81jse7ue2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGW8frmEuOClY0fbrC3sD42beLkZODgkBE4nV67YydzFycQgJ HGGUeDW3gRXCWcwo8fv9XyaQKjYBe4nJaz4ygtgiAhISnV/3s4PYwgI2Ep03XjNDxG0lel+u ZYGwjSS2Xf3MCmKzCKhIPOm5DDaHF2jOjhMLwWqEBFwkjjy8DzaTU8BV4sG122A1jAJiEt9P rQGzmQXEJW49mc8EcamAxJI955khbFGJl4//sULY8hIzzt6CqteTuDF1ClsXIweQbS2xd1sF RFhbYtlCiDN5BQQlTs58wjKBUXQWkg2zkHTPQuiehaR7FpLuBYysqxhFi1OLk3LTjYz1Uosy k4uL8/P08lJLNjECI+Xglt+qOxgvv3E8xCjAwajEw9tUfihKiDWxrLgy9xCjBAezkgjvikUH o4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzPjTfHCUkkJ5YkpqdmlqQWgSTZeLglGpgFNJtVF6y WnXaWmmPWzzcdUcmr5Gd/OCTk/H5r7ozH8vY/rP8fVaxcuXXxR//p77cbrarZr7S93qXjf+S XJYHW6TKqbzZ9uab3KPHc8P/ppY4lS1asebG8os/O673FewO5aydHMRe3KIiL6utLeguu3xh 9NWeZaUi5fHn77cUP1U5aXbqc1rNWiWW4oxEQy3mouJEAJ1l1seQAgAA Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 02 Apr 2018 20:36:34 -0000 This update clarifies the IANA registrations and also addresses genart and = other comments received since the last version. Cheers, Ari > On 2 Apr 2018, at 23.29, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > Title : Media Types for Sensor Measurement Lists (SenML) > Authors : Cullen Jennings > Zach Shelby > Jari Arkko > Ari Keranen > Carsten Bormann > Filename : draft-ietf-core-senml-14.txt > Pages : 49 > Date : 2018-04-02 >=20 > Abstract: > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Measurement Lists > (SenML). Representations are defined in JavaScript Object Notation > (JSON), Concise Binary Object Representation (CBOR), Extensible > Markup Language (XML), and Efficient XML Interchange (EXI), which > share the common SenML data model. A simple sensor, such as a > temperature sensor, could use one of these media types in protocols > such as HTTP or CoAP to transport the measurements of the sensor or > to be configured. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-senml-14 > https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Apr 2 23:02: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 890F812E035 for ; Mon, 2 Apr 2018 23:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, 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 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 iTz3ZqUM0IYx for ; Mon, 2 Apr 2018 23:02:41 -0700 (PDT) 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 19E9C12E034 for ; Mon, 2 Apr 2018 23:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522735359; 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=M2mae/aAtRIhn0qkWFGRc8/CF1QcPExI5YDPhbWN26E=; b=GlxI/vMBP3Lg98CwaMxpUkZE3whOeIM+MXINmc760Qn7wY4LTysSJhoq2uoMysEn GxR8LMBP90dsv48T6lUhR9ftRuV1vI9ebAal3ThvTA/XBe1NioONYo4o5/cVxVmH Om5z6RpqX34V/VD1REXvXR2QZtDVWWdywi/bzjqaWv8=; X-AuditID: c1b4fb3a-e21ff70000005d56-f4-5ac318feda18 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.22.23894.EF813CA5; Tue, 3 Apr 2018 08:02:39 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.243]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0382.000; Tue, 3 Apr 2018 08:02:38 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: WGA of draft-keranen-core-too-many-reqs Thread-Index: AQHTwFzVYL6ZLE442UO5TfMYfy+HVqPugHkA Date: Tue, 3 Apr 2018 06:02:38 +0000 Message-ID: <631C486B-18A7-43C8-84E4-B2F89731FEE3@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [37.219.185.77] Content-Type: multipart/signed; boundary="Apple-Mail=_5C9D7CD3-A031-45AA-AA0D-5A6451757DA0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7je5/icNRBl1TuC32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD2zrzAVtARUHJn8i7GB8axXFyMnh4SAicT39yeYuhi5OIQE jjBKTP41jwXCWcwo0fRlNzNIFZuAs8SnZ43sILaIgJnEll1fWUFsYaDu48t6WSDiphL/7p2E qjGS2Nq4GqyGRUBF4uvPyUA2BwevgL3EzLNOIGEhILNr9i8mEJtTwEHi//GNYGMYBcQkvp9a AxZnFhCXuPVkPhPEoSISDy+eZoOwRSVePv7HCmErSvzuX8QGcjOzwBRGiS3bW8ASvAKCEidn PmGZwCg8C8msWcjqZiGpgyhKkthw9gYjhK0tsWzha2YIW1Nif/dyFkxxDYnObxNZIWxTiddH P0L1WkvM+HWQDcJWlJjS/ZB9ASP3KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAeDy45bfV DsaDzx0PMQpwMCrx8HqJHY4SYk0sK67MPcSoAjTn0YbVFxilWPLy81KVRHjP7TkUJcSbklhZ lVqUH19UmpNafIhRmoNFSZzXKc0iSkggPbEkNTs1tSC1CCbLxMEp1cA4RXafTlPCa0urnN9b v1lrLZoRwerp/G8Vp6571vW5C9zbtp/vDyljmbNrkuxts5WrFn4rL9e6GcDdMpElQ3jZ74u/ HJ0Oz0/ql1dsaLl7uOFYdvoX7v8JT96pl6eUM0zQsgmq9znFt25ym2jWpK7TN/8ccky50GF5 +ujnZo6C2Rm+YZvPTJyvxFKckWioxVxUnAgAYaCJh88CAAA= Archived-At: Subject: Re: [core] WGA of draft-keranen-core-too-many-reqs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2018 06:02:44 -0000 --Apple-Mail=_5C9D7CD3-A031-45AA-AA0D-5A6451757DA0 Content-Type: multipart/alternative; boundary="Apple-Mail=_8EF57C32-55B4-47A5-A67D-1AF4EBB8E885" --Apple-Mail=_8EF57C32-55B4-47A5-A67D-1AF4EBB8E885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, from the email discussion and the last IETF101 comments it is clear that = there is consensus for adoption. The authors should resubmit a new version under CoRE WG. Ciao! - - Jaime Jim=C3=A9nez > On 20 Mar 2018, at 17.05, Jaime Jim=C3=A9nez = wrote: >=20 > Dear CoRE, >=20 > yesterday we had the presentation of the = https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-00 = draft, = which registers the =E2=80=9C4.29=E2=80=9D error code when =E2=80=9Ctoo = many requests=E2=80=9D are sent. While there was in-room consensus that = this document is needed the chairs would like to take it to the list for = further comments before working group adoption.=20 >=20 > Thanks, > - - Jaime Jim=C3=A9nez >=20 --Apple-Mail=_8EF57C32-55B4-47A5-A67D-1AF4EBB8E885 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all,

from the email = discussion and the last IETF101 comments it is clear that there is = consensus for adoption.
The authors should resubmit = a new version under CoRE WG.

Ciao!
- - Jaime Jim=C3=A9nez

On 20 Mar 2018, at 17.05, Jaime Jim=C3=A9nez <jaime.jimenez@ericsson.com> wrote:

Dear CoRE,

yesterday we had the = presentation of the https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-00= draft, which registers the =E2=80=9C4.29=E2=80=9D error code when = =E2=80=9Ctoo many requests=E2=80=9D are sent. While there was in-room = consensus that this document is needed the chairs would like to take it = to the list for further comments before working group = adoption. 

Thanks,
- - = Jaime Jim=C3=A9nez


= --Apple-Mail=_8EF57C32-55B4-47A5-A67D-1AF4EBB8E885-- --Apple-Mail=_5C9D7CD3-A031-45AA-AA0D-5A6451757DA0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDQwMzA2MDIzN1owIwYJKoZIhvcNAQkEMRYEFFnXEmdQ3Z1qwCJ5Xd38Gvkv8lW3 MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAEqOhFuLnKEgNOF3borxZ/vglLWy+H843Ni1ZYVH9FDAzF8W3sT6bMgcCX2iDSavc fWas4j4awn8vo/oyP5k2flRR9VcCQFsNU4LjbA9GIThNwbKvhl34PrIRDmf9hnuadwqIOvFjEHfG feIVqxPKorb8hdQ6ppIfsjKqyjNmLplQ0AtFhuu4Q/qZo6o7CpQwyj67VunRtgZrHt09BWgDe9v+ XVXvyfQQayN62XNOpPSIffazLowqSEdEDhz4+kl54t2+JT8jNrd+5h3Ur0DkuBTGrw+fKDZzsbO1 gg0b3JMzqh4RPIhDzaaOn6i8Zv8CJJuQxjlRG7KqwAS+2588aAAAAAAAAA== --Apple-Mail=_5C9D7CD3-A031-45AA-AA0D-5A6451757DA0-- From nobody Tue Apr 3 01:07:29 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 76B7E124205 for ; Tue, 3 Apr 2018 01:07:28 -0700 (PDT) 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, 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 cHb9g2XaLhHr for ; Tue, 3 Apr 2018 01:07:26 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.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 CD30B12E057 for ; Tue, 3 Apr 2018 01:07:25 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud7.xs4all.net with ESMTPA id 3GyRfK05P8U073GyRfKcJm; Tue, 03 Apr 2018 10:07:23 +0200 Received: from 2001:983:a264:1:4905:6ba6:772b:783e by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 03 Apr 2018 10:07:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 03 Apr 2018 10:07:23 +0200 From: peter van der Stok To: Esko Dijk Cc: "core (core@ietf.org)" Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <2c9c5e546d18ff61160437e74dc7df43@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfMkgx0GSKGXtk/L1QOHSF55J9gXhep3X3Tx+JEqfboap7nHY0y8hDLKH1lD+R7+6kGY6YKsYDHHvpWSlxCAiEY3cAT2LT9bRI2F4L9dQSfRPZhzozdzX m6sSKY+9URNBhtkrobWdb2vJtBpTOeVQplpeQ5sCqPEM9f43l0cRrp4dFdS++azfyBorODPuDMfx4734PiCwc2j5ocNi1MX8xEAbg5pW74zgyjs8OFLPWrWK Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory-13 review - Sections 1-4 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2018 08:07:28 -0000 Hi Esko, thanks for the comments, below some reactions. Most suggestions are taken over in github (excluding the ones that need some discussion) Esko Dijk schreef op 2018-03-26 14:51: > Dear RD authors, > > Below are my review remarks for a partial review of RD-13: Sections 1 > to 4. I thought it good to submit now already, because any > clarifications of the model (3.2 and 3.3) could help the understanding > in doing further review of the rest of the document. > > Best regards, > > Esko Dijk > > 3.1 > > accessing those resources -> accessing that resource Not sure about that: the multicast cited in the phrase targets resources on multiple hosts. > > act on behalf -> act on behalf of Good catch > > "Changes in the Resource Directory do not propagate automatically back > to its source" could use some clarification. > > -> what is "its source" here exactly? Source of the change, or rather > the web server that a registration entry is about? The web server where the resource is located, as you suggest. will be clarified > > -> in case the source is the registering web server itself, why would > a change need to be propagated back to it at all? The server device is > itself the initiator of the change. It should NOT be propagated; and we want to make sure that THAT is understood. > > -> in case the source is the CT, why would a CT's change to an RD > entry need to be propagated back to the CT? This is not the case. > > 3.2 > > Figure 2 and other places in the document use "Target" as a term; > because not everyone may be familiar with this abbreviation I would > add "Target" in the Section 2 list of terms. Because [RFC 3986][RFC > 6690] also do not define this abbreviation. Good suggestion; > > 3.3 > > The term "host" is now used here for the first time in the document > while previously it was a (constrained) "web server". So in the bullet > "a set of links belonging to the host" we could clarify this by > changing to: > > "a set of links belonging to the host (the web server whose resources > are registered with an RD)" Agree, clarifies things. Suggestion: s/The host/A web server/. > > This links the two terminologies together nicely. "Host" is still a > good term to use in 3.3 since we also introduce the "hosts" relation > here. In my suggestion the earlier equivalence between host noun and host verb is no longer present. > > Last bullet on page 10: adapt formatting to show this bullet is part > of the bullets-list above it. Now it looks as if the link attributes > bullets list that starts on page 9 has only 3 bullets. Right; numbering will solve this, but needs some "markdown" gymnastics > > Figure 4: lifetime 'lt' should be '1' according to the text, not '0-1' thanks, good catch > > > Figure 4: Direction of reading the relations seems not always > consistent. For example, I can read "group is composed of 1 or more > registrations" or I can read "registration is composed of 1 or more > groups". The latter is suggested by the placement of the "+1" in the > figure, but this seems wrong, so best to have the "+1" text moved > close to the "registration" box to make it clear and use the UML > class diagram way of directionality of relations. > > In case the relation goes *both* ways then a solution is to apply the > UML class diagram association notation, which means two numbers are > placed next to a relationship line showing that 1 group can be > associated to 1+ registrations and at the same time one registration > can be associated to 0+ groups. Absolutely agree. An oversight from our side. > > See https://en.wikipedia.org/wiki/Class_diagram#Association [1] for > some info and examples. I feel this UML class diagram is a better > representation used most commonly in today's (IT) industry - and we'd > better use a graphical representation that provides the expresssion of > directionality that we need. thanks for the reference > > "A Group has no or one Multicast address attribute and is composed of > 0 or more endpoints" -> that should be -> "A Group has zero or one > Multicast address attribute and is composed of zero or more > registrations" if I read Figure 4. There is no line going from the > "Group" box to an "Endpoint" box in the figure. Right: caused by registration and endpoint equivalences: will change the text > > 3.6 > > "Resource groups may defined to allow batched reads from multiple > resources" > > -> sentence is unclear whether this is 'an additional RD feature' as > mentioned in the paragraph, or not. "Batch" does not come back in the > RD draft. Also the concept of "resource groups" does not come back in > the RD draft, we only have endpoint groups in Section 6. @Michael may react here as well; my proposal: remove the phrase. or change to: Groups may be defined to support efficient data transport. > > 4 > > (re-e)starting -> (re)starting (re-)starting > > RD directory servers -> resource directory servers -> RD server > > the service with name rd._sub.._coap._udp -> here we specify a new > subtype 'rd' under the service name 'coap'. If I read > https://tools.ietf.org/html/rfc6763#section-16 correctly, then it is > not mandatory to register this at IANA. Still it might be best to > place this definition in a new Section 9.6 under 9 IANA > Considerations, mentioning this subtype is specified here but not > registered in the IANA Services Names registry because that's > optional. What do you think? I looked at the service name and transport protocol port number registry The transport by coap still needs to be defined there and an expert has to be named. @Carsten, I am sure that you have an opinion here. > > Edge Router (6LBR) -> Border Router (6LBR) OK > > 4.1 > > "This information is needed when endpoints cannot discover the > Resource Directory with a link-local multicast address because the > endpoint and the RD are separated by a border Router" > > -> I would suggest > > "This information is needed when endpoints cannot discover the > Resource Directory with a link-local or realm-local scope multicast > address because the endpoint and the RD are separated by a border > router" Good suggestion > > "The lifetime 0x0 means that the RD address is invalid and to be > removed." > > -> this information is already provided in the diagram below, in the > text for the "Valid Lifetime" field. So I suggest removing here to > avoid double definition of the same. OK > > ------------------------- > The information contained in this email may be confidential and/or > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this email is strictly prohibited and may be unlawful. > If you are not the intended recipient, please contact the sender by > return e-mail and destroy all copies of the original email. > > > Links: > ------ > [1] https://en.wikipedia.org/wiki/Class_diagram#Association > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 3 01:21: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 BE47012DB6D; Tue, 3 Apr 2018 01:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, T_RP_MATCHES_RCVD=-0.01, 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 z3oos_vVSG14; Tue, 3 Apr 2018 01:21:28 -0700 (PDT) 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 49E40124205; Tue, 3 Apr 2018 01:21:27 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id EB26F496B7; Tue, 3 Apr 2018 10:21:24 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0FC8859; Tue, 3 Apr 2018 10:21:24 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B198B41; Tue, 3 Apr 2018 10:21:23 +0200 (CEST) Received: (nullmailer pid 5292 invoked by uid 1000); Tue, 03 Apr 2018 08:21:22 -0000 Date: Tue, 3 Apr 2018 10:21:22 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Cc: DNSSD WG mailing list , Ivaylo Petrov , Jim Schaad , Hauke Petersen Message-ID: <20180403082122.GA30478@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20180322144452.GA13008@hephaistos.amsuess.com> <20180322150452.GA17015@hephaistos.amsuess.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2018 08:21:33 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello parties interested in the RD interop, we will have the plug test on April 10th, starting 14:00 UTC; a voice and text chat room is available at IETF Jitsi[1] to coordinate, exchange addresses and test results. I've expressed the participant survey as an online questionnaire at [2]; participants that have not yet answered my plain text version please fill this out before the 7th. Best regards Christian [1]: https://jitsi.tools.ietf.org/rd-plugtest [2]: https://chrysn.limequery.org/999235 --=20 You don't use science to show that you're right, you use science to become right. -- Randall Munroe --KsGdsel6WgEHnImy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrDOX0ACgkQOY0REtOk veFkYBAAgBq73u0rAVvoQZAM3WjfKHKlwBGjfCJqIVBgXJ5cdP8oTI9uqCQCLCRz ehoWLnRpGWfCajuOrvJEb36E0uRR1HFFuF8AD1LDHf9MqBpwRaTJqIm5r747ARCC o/LeGIxtHSGDqC7QsPPThZfuLluYEj9EdLy8KmbHwTvyJ6K05oD5587EnqMC39AX QtSKOpksvmwswT+9+gb634xQO7jYaCRV2J0UZDaVLa0S9xvBnaYrv2/tHIjZSRLI wDTCqHzNmNyXDZCOEB86HitxjDRfCyAEdCH5YceB3kw9NsQT1id5wzTFbq3oIUAr f/FHCdxdvh9wz6bzNkGcISaF+8TNiz1ljp+Dz8W5OGr1usyUDw4T4dffUTugMfil ZJ3ZCu6C4cVEo0YXRrWW/BFAtKbsItfL04UUf2URZs2aGJaXiIcWfhn27pCCIUNG LqlLLpFNCW8NgHNGfBCU6rGGudENAZK+tmPZxW3QGbVfuVwwjppKJZ/wCRv0dyHW ZHN/EKP1TvW9oM07WugganCqbK/YwBGpbTU+EVCizE8wK6Gqlgu6FWDpX+dddYCE vKG1tfVTKpGiJfwqou2eIlunLriteW/woXrn7qKNEl/j7P/3mfLs+yxhfRl5hkRm xJe1Uuvxchy6vwJZxVNcVdXle2eBPVfRWkLvJQXZTesYd/N/R/4= =KOZy -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From nobody Wed Apr 4 02:21:17 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 DF96B1270AE; Wed, 4 Apr 2018 02:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eXRKlyB-oW-m; Wed, 4 Apr 2018 02:21:13 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.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 93B581270A0; Wed, 4 Apr 2018 02:21:12 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud7.xs4all.net with ESMTPA id 3ebNfZONB8U073ebNfPuSq; Wed, 04 Apr 2018 11:21:11 +0200 Received: from 2001:983:a264:1:c19f:d02a:9be0:9afa by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 04 Apr 2018 11:21:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 04 Apr 2018 11:21:09 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-ietf-core-resource-directory@ietf.org, 'core' Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> Message-ID: <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfK+sibWf7x501eDDiyVwfq8OhP8LvEYjPETwXZcBywUdOIOTzpu4AF0UlJl5zdUm0N6BBeVLuhZl1DP/BC356Motd3Nf2SU24kq8qDzaikxneoRxxIxB ZAc98wXXuu2ilU6uYGkEN4cmE2HIhKaNbfzDai6ZUeTMjzvGUKVPsg38iqPGLN8deqQwuoLppAH5K6iPoQlCltYz0pzVUMneMHblggzMTLgPqU4eC1Xv7KxN hbyJkgfac+v16hguyTU2Wg== Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 09:21:16 -0000 Hi Jim, thanks for the questions. Se my answers below. Jim Schaad schreef op 2018-04-01 20:37: > Here are some more questions on the document. > > 1. The registration text in section 5.3 says that the interface is > idempotent, however it is not clear to me just how idempotent this is > supposed to be. It is obvious that the goal is to make sure that a > different resource is not created, however I am not clear what is > supposed > to happen with some of the parameters such as the 'lt' parameter. One > way > to implement this is to just make it a POST to the previously existing > resource which would inherit old attributes on the endpoint. The other > way > is to say we are going to create a new resource, it just has the same > address. It is not clear which, if any, of these two methods is to be > used. > > Never mind I found the answer to this one. Need to think if I want > clearer > language. I hope we find the same answer. The text says "registering with the same endpoint parameters , ep and d, does not create multiple resources. Consequently, registering with existing ep and d removes existing registration and creates new registration with new location. Registering with a different ep and same d, or different d and same ep, creates new registration next to the existing one. The values of the other parameters are irrelevant. is additional text like above needed? > > 2. When doing an endpoint lookup, I assume that the 'lt' parameter > would be > the same as the one registered at creation. Is there/should there be a > parameter which is a TTL value? I don't understand the question. TTL is about the lifetime of a packet in the network (expressed in hops) lt is about the lifetime of the registration expressed in seconds > > 3. How are href comparisons done. > a) compare against what was registered > b) Resolve what was registered and the href in the current context > and compare > c) something I did not think of probably someone else wants to react as well. The model in the RD stores the target as specified in /.well-known/core of the source. At lookup the links are resolved against con. Consequently, the comparison of href is the comparison versus the target as stored in the RD and as copied from /.well-knwon/core. Is that reasonable for you? needs extra text in the RD spec.? > > 4. compare on group for remote endpoint. Should this do the remote > lookup > or can it just be ignored for attribute comparison I am not quite sure what you mean by attribute comparison. When it is about registration attributes, no remote lookup seems necessary to me. > > 5. Value of lt = should it be the set parameter or the time left - how > would time left be represented outherwise - should it be represented. Right on the nail. This is very vaguely specified. The unit is specified as seconds. In my expectation the returned lt value is the time in seconds from lookup till end. Other opinions by my co-authors? If we all agree, we specify it as such in the RD spec. > > 6. Inferred context based on source IP when an update is done. If no > con > is provided, is that supposed to be checked again to see if it is > "right"? > Only if we did the infer to begin with? My interpretation of the current text is: When a registration is done with the same ep and d values, the old registration is removed and a new one with the new parameter values is created at a new location. That means that the value of con is specified in the registration without any memory of earlier values. > > 7. I don't understand the presence of the content-format for the empty > message posted for simple registration. This seems to be odd if the > content > is empty. content-format is specified such that RD knows what content-format to request. > > 8 Is there supposed to be a way for simple registration to return an > error > message? As written this is not necessarily done. Specifically, the > response to the post can be executed before the query to > /.well-known/core > is done and the registration is attempted. I see what you mean: also the return of 2.04 shows in the example but not in the specification. This warrants additional text to specify the simple registration text. > > Many thanks for these questions. Looking forward to your answer, Greetings, peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Apr 4 06:28: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 8757812762F for ; Wed, 4 Apr 2018 06:28:33 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 l55FbBJWoNgq for ; Wed, 4 Apr 2018 06:28:30 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554D612D574 for ; Wed, 4 Apr 2018 06:28:29 -0700 (PDT) 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; bh=bGbm+KeNHByFlU6T6yhN9O5d7UMA5oJY47NUnKIACSU=; b=UwKh2EUjaA3WNQMIfu/uDRBRYoL3sTiQLAYKRpzN4nZ6nXdWklJKUyoZdI5qYSzYSJY4ICOfXCFbGPaGnhBnjR86kZ4XNPVjbS9rpM3JCmCpZNV7RafnHQYlHwqOpW0Jjfdi1whipRwLdeLwzRR7zqx+1vUUAu97qNZopYCZUQg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1438.eurprd08.prod.outlook.com (10.167.210.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 13:28:26 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf%18]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 13:28:26 +0000 From: Hannes Tschofenig To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-resource-directory-13 Thread-Index: AdPMF9lKXAono47RQq6YE2x1uyweaQ== Date: Wed, 4 Apr 2018 13:28:26 +0000 Message-ID: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [194.136.97.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1438; 7:ImFiR1AiUODy+nuNwPkmhaumbnPiwfAjK97hFzsh8az7kqVc/3eDhXKgNFUIfHKK1Xbx9kNyCzJMrheyjqGbv51eULvL0iRHrvGMAXAWVJShWeRHfWBfDeXSA37P+8oAX7nx4m48Nx1BOR109/0uhJ5Jqy56KAm46D9rvw7ROtONsqFpur9SocwQ1B/c173hbzW/dk6Q+YBNhz3ltGESNwgOEt4I57ZDTd8rZfV5e2haLml+ajZk0JAFov1Hr/n2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 299f38fa-27b1-41fc-1420-08d59a2ff282 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1438; x-ms-traffictypediagnostic: VI1PR0801MB1438: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1438; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1438; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39380400002)(39860400002)(366004)(53754006)(199004)(40434004)(189003)(3846002)(6116002)(3660700001)(99286004)(3280700002)(7696005)(2906002)(68736007)(6916009)(14454004)(72206003)(102836004)(186003)(105586002)(478600001)(59450400001)(2900100001)(74316002)(33656002)(8936002)(6506007)(25786009)(5660300001)(106356001)(81166006)(26005)(8676002)(7736002)(66066001)(5250100002)(9686003)(86362001)(55016002)(316002)(53936002)(97736004)(476003)(6436002)(486006)(81156014)(5890100001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1438; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kSvbIoPj/ADojcigjsrIx4uE9/f8VblTHDXrAtQap3T1ogxV9Kqwnb8khDgM0m3rrh5sAgF5wZt1hftSwLEgV6jUU6c4Xz6l4Lf6g6MPXISdZoFqx40k3Jhnf4/aYHQg5WnUxl0OMmviLABDGEVRRKNExSC3f5SzCoOmpxp2Wvhk0XWwU1IfAzmj9BiwhvO28eoOwOE7yAv/bJNg8rivk6TBAoqZkDaOF5mEAT97PzSBP6CRzdkB62IxAa0j8pEPIp8z6V+DMiJuz6lIjw9Z6d9SGfGTo2D/RY9TTC8uTXQBfNiy+O6b+3oo9yAWKnzYHlVVPlgaDYEHUDGa9wwyTP3AvonspKAws7OD/iGVNlWQlw78YfGqmR5H5TBBFiWQ/4KFwmccJwsJEvd3Dix1Yc7p3mrOOdqfBkXzG+Ep2hY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 299f38fa-27b1-41fc-1420-08d59a2ff282 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 13:28:26.3513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1438 Archived-At: Subject: [core] draft-ietf-core-resource-directory-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 13:28:33 -0000 Hi all, I have a remark for the RD draft: Section 5.3 defines the registration proc= edure and indicates that the endpoint name is "mostly mandatory". I would prefer it is defined as "optional". Section 8.1 highlights the secu= rity issues with using this unauthenticated identifier quite nicely. Howeve= r, it comes up with a strange conclusion IMHO. Here is what it says: " Therfore, Endpoints MUST include the Endpoint identifier in the message, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. " I would argue that under normal operation there is no reason to include the= endpoint name since it is not authenticated and there will be a security p= rotocol used (which offers authenticated endpoint identification). For this= reason I would argue that the endpoint name has to be optional and I prefe= r that it is stated that it will be used only for debugging purposes or for= those cases where the identifiers used in the security protocol are insuff= icient for endpoint identification. Ciao Hannes 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. From nobody Wed Apr 4 06:41: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 5F035129C70 for ; Wed, 4 Apr 2018 06:41:33 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 wCitj83aT8gg for ; Wed, 4 Apr 2018 06:41:30 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0066.outbound.protection.outlook.com [104.47.1.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DEE127601 for ; Wed, 4 Apr 2018 06:41:25 -0700 (PDT) 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; bh=EuOAwVWWnuFegiLRXiVO+tg1E5a70xi34r0CjAFkrG0=; b=CtRm/QyQYfnIHFHAmzVt3O2DWoY7Lz/MnOKjfJbprXQEH6VoxpRHqbw9SM/sVK+yXB9t3G+NnmGkgtsLB/Hfy9q8To+65yUeVg3fCfmIXE6hpQdC8hJ5PPcNmosUkgHQcYBtIh+m+hiMBg7xzEtVskA/xgWsa9moJ09EXSr7EfI= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1711.eurprd08.prod.outlook.com (10.168.67.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 13:41:22 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf%18]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 13:41:22 +0000 From: Hannes Tschofenig To: "core@ietf.org WG" Thread-Topic: Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwQ== Date: Wed, 4 Apr 2018 13:41:22 +0000 Message-ID: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [194.136.97.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1711; 7:sWiFk+pRGvrmzyYxc8AA6Gio3TzMVvZU8etZ6eIfV0MspJCoulqJjRRGxtqlGPzWhx6R1d6TG3bcH2ChmS2aeKm8MqKmvwSqrQAl51Siozy0b5+M5V/xntWGRpyTW4a0uOs0e7Ac+StNiW8Knn4Asks+nBfFjjRnajIpUBCPl2CYVzCWP75wWN+jpgHAqEUtqUGmKw3CkQNhTw6Awfy12LNUHMI8cuKD+jS6m7vQCkE38W9DBYjFuSa2gxY2tvKv x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 59e3d20f-878a-4289-7554-08d59a31c0f4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1711; x-ms-traffictypediagnostic: VI1PR0801MB1711: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1711; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1711; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(376002)(396003)(366004)(199004)(189003)(53754006)(40434004)(74316002)(66066001)(97736004)(186003)(25786009)(316002)(68736007)(72206003)(478600001)(486006)(26005)(5660300001)(6436002)(476003)(9686003)(102836004)(54896002)(7736002)(6306002)(55016002)(53936002)(2906002)(8676002)(86362001)(105586002)(8936002)(81166006)(6116002)(790700001)(106356001)(6506007)(6916009)(3660700001)(3846002)(7696005)(3280700002)(2900100001)(99286004)(81156014)(5890100001)(14454004)(59450400001)(5250100002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1711; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kc9fQWR5EhZmClL9EQiYxRVy6WypLHYl3dBZ45moAufUErckDI1kXrARYSrkTSXdbP8r2WIzR4TBsQHuxV9eyjINmRqj1WY1I4psqanhbh//o5S2J1a0Z6VzRxXuIeKIWmF7Z9wuaxu+TNkhrGh6jxCxx2PDIaymzM20BxcAw3YFUxmjKtDWcyRHwx7Kafnr/CyLRoP4XeuINmeC1vn7We1mZPFUp36B+ZXCrpg4sZvfzKV8n0mpJSjk4d6X4134nsRAJLhQW027AZUDdhiDVwatHL63HPz8C77JL+A64J0lhZN7VOs7JX2Td6G/VKtZVS0HyNfkzt80A3T4fDxGZXjuAAQCrYLv6HOpWUjMBWbZzLPg5+OCMtvHIhXKM2f0i7bKKEnIyTiyvHIKVXP8tRkgADOeaaW+1KAeDkSLPbM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112B52094B182F5D44C4F64FAA40VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59e3d20f-878a-4289-7554-08d59a31c0f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 13:41:22.3020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1711 Archived-At: Subject: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 13:41:33 -0000 --_000_VI1PR0801MB2112B52094B182F5D44C4F64FAA40VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I noticed that the term "endpoint name" is used in the IETF RD draft while = the OMA LwM2M spec uses the term "endpoint client name". Endpoint is a conf= using term since it is used differently in the CoAP spec than in the Web en= vironment. For this reason I believe it would be better to use the term "endpoint clie= nt name" also in the RD draft. This would improve alignment between the two= specs. Ciao Hannes 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_VI1PR0801MB2112B52094B182F5D44C4F64FAA40VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I noticed that the term “endpoint name” = is used in the IETF RD draft while the OMA LwM2M spec uses the term “= endpoint client name”. Endpoint is a confusing term since it is used = differently in the CoAP spec than in the Web environment.

 

For this reason I believe it would be better to use = the term “endpoint client name” also in the RD draft. This woul= d improve alignment between the two specs.

 

Ciao

Hannes

 

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_VI1PR0801MB2112B52094B182F5D44C4F64FAA40VI1PR0801MB2112_-- From nobody Wed Apr 4 07:31: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 DEC01126CBF for ; Wed, 4 Apr 2018 07:31:54 -0700 (PDT) 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=ericsson.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 cl0ZGTiTS_GU for ; Wed, 4 Apr 2018 07:31:53 -0700 (PDT) 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 715E212025C for ; Wed, 4 Apr 2018 07:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522852310; 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=7ZdsNtBFuVfrRHrkuhzoHVNMMWYgLGn6OmmsZd9qfMw=; b=XsM1PueMjzwSyrBfWy/gFrZ5lvcnEhcFmu/x0Oc/SD5FAQgvhpPrAyIY3KMZuwT0 snA2VNFbYAfjPNgu1UFF+dbA0C/yyvIwTTcmtd/eP58MM/SOwfT037t13qYAg3ac VcomA2N7SWSlFnxmj565e3ynHLqtYT4yuHT/CKZpArE=; X-AuditID: c1b4fb3a-e21ff70000005d56-03-5ac4e1d69c7d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.C6.23894.6D1E4CA5; Wed, 4 Apr 2018 16:31:50 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.243]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 16:31:50 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Hannes Tschofenig CC: "core@ietf.org WG" , Carsten Bormann Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A Date: Wed, 4 Apr 2018 14:31:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.166.49.243] Content-Type: multipart/signed; boundary="Apple-Mail=_C603B1D8-7CD8-4DF3-B191-45E577CD4306"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsUyM2K7iu61h0eiDGYuVrY4MuUuq8W+t+uZ LW7OOMXkwOyxZt4aRo8lS34yeUxblBnAHMVlk5Kak1mWWqRvl8CVcfPeddaCWRUVs6YuZGlg 3JbbxcjJISFgIjF5ygJmEFtI4AijxKp/pl2MXED2YkaJq4t3soEk2AScJT49a2QHsUUEDCX2 Nh9iBbGZBdwkHn/+D9YsLOAiMWFaNytEjatE97vHjF2MHEC2kcTU59IgYRYBFYlvbw6ygNi8 AvYSPZ2bWSD2Jkis2zgLbAynQKLE9OMnwMYwCohJfD+1hglilbjErSfzmSBuFpF4ePE0G4Qt KvHy8T9WCFtR4uy7h0wg9zMLTGGUaHz/nwlimaDEyZlPWCYwisxCMmsWsrpZSOogipIkrp48 wAhha0ssW/iaGcLWlNjfvZwFU1xDovPbRFYI21Ti9dGPUL3WEjN+HWSDsBUlpnQ/ZF/AyL2K UbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCWD275bbWD8eBzx0OMAhyMSjy87BePRAmxJpYV V+YeYlQBmvNow+oLjFIsefl5qUoivA+OAaV5UxIrq1KL8uOLSnNSiw8xSnOwKInzOqVZRAkJ pCeWpGanphakFsFkmTg4pRoY23aox1r4bniioTKzPfTX9BV1kwSm8ux8qbpp0zUhA12T3YpC c1XbNi11e2DFOvOFhLHhgeMeGbvvm+yV09oq+HP21kNhn5P+rbTwZuBZf2TqO4+TT6Vjrmz6 2WSfo8+3NcOU8/apt4xan5ltl+w9eHHjhNLwm4w6KXsLlh28bdBx8yVbX8Szq0osxRmJhlrM RcWJAIU1Qk3tAgAA Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 14:31:55 -0000 --Apple-Mail=_C603B1D8-7CD8-4DF3-B191-45E577CD4306 Content-Type: multipart/alternative; boundary="Apple-Mail=_591CB04C-3FEA-4BB7-B97A-FEFEC2AAAC4A" --Apple-Mail=_591CB04C-3FEA-4BB7-B97A-FEFEC2AAAC4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Note that endpoint can refer to both source and destination, being and = IP:port in its simplest form:=20 https://tools.ietf.org/html/rfc7252#page-6 = =20 The fact that LWM2M swaps those role names might actually add to the = confusion, probably OMA LWM2M should be the one changing the terminology = as the device is mostly a =E2=80=9Cserver=E2=80=9D hosting resources and = only is a =E2=80=9Cclient=E2=80=9D during bootstrapping and = registration. We could have used terms like =E2=80=9Cservient=E2=80=9D = instead but it might be too late for that. Ciao! - - Jaime Jim=C3=A9nez > On 4 Apr 2018, at 16.41, Hannes Tschofenig = wrote: >=20 > Hi all,=20 > =20 > I noticed that the term =E2=80=9Cendpoint name=E2=80=9D is used in the = IETF RD draft while the OMA LwM2M spec uses the term =E2=80=9Cendpoint = client name=E2=80=9D. Endpoint is a confusing term since it is used = differently in the CoAP spec than in the Web environment. > =20 > For this reason I believe it would be better to use the term = =E2=80=9Cendpoint client name=E2=80=9D also in the RD draft. This would = improve alignment between the two specs. > =20 > Ciao > Hannes > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. = _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_591CB04C-3FEA-4BB7-B97A-FEFEC2AAAC4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Note = that endpoint can refer to both source and destination, being and IP:port in its simplest form: 
https://tools.ietf.org/html/rfc7252#page-6 

The fact that LWM2M = swaps those role names might actually add to the confusion, probably OMA = LWM2M should be the one changing the terminology as the device is mostly = a =E2=80=9Cserver=E2=80=9D hosting resources and only is a =E2=80=9Cclient= =E2=80=9D during bootstrapping and registration. We could have used = terms like =E2=80=9Cservient=E2=80=9D instead but it might be too late = for that.

Ciao!
- - Jaime Jim=C3=A9nez

On 4 Apr 2018, at 16.41, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all, 
 
I noticed = that the term =E2=80=9Cendpoint name=E2=80=9D is used in the IETF RD = draft while the OMA LwM2M spec uses the term =E2=80=9Cendpoint client = name=E2=80=9D. Endpoint is a confusing term since it is used differently = in the CoAP spec than in the Web environment.
 
For this = reason I believe it would be better to use the term =E2=80=9Cendpoint = client name=E2=80=9D also in the RD draft. This would improve alignment = between the two specs.
 
Ciao
Hannes
 
IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be = privileged. If you are not the intended recipient, please 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. _______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_591CB04C-3FEA-4BB7-B97A-FEFEC2AAAC4A-- --Apple-Mail=_C603B1D8-7CD8-4DF3-B191-45E577CD4306 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDQwNDE0MzE0OFowIwYJKoZIhvcNAQkEMRYEFIGjYtHGhPolvA8AjThz7MLQ3NfH MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAHtwxQSZv8KdKBBlXaL0nokQX3WzQHBNZGV+xidr5u16dajyq0mz/14he8n1pTIFi hUcfCZ3o2v8Gy/qEgw/HNMccevGs6vvFaeL9dJmzxH8E3TF4HkSh4FuQD9+Ng+lnpBlrJUN0N+k7 U2keRcA2R8K5JcNFQ1she7XtsYKOIgcFKur4oYPUUyjnkuhgDKORw8X2l5B8FVxz6eHpITOhqpNG cgr05f1djXL442tvm+zFh2G9EBL/KDLVbMEtoIsCF6PBV8KK7GaTR3nUZPqm+RXtdLLrJ43gS2u/ 6trPU7d9Ktb9ArupwZ10vFCTmMV2PnqVCykR002WHFy0U+wsqAAAAAAAAA== --Apple-Mail=_C603B1D8-7CD8-4DF3-B191-45E577CD4306-- From nobody Wed Apr 4 08:57:03 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 4CADD12DA3E; Wed, 4 Apr 2018 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 tWmuP2uUGxMp; Wed, 4 Apr 2018 08:57:00 -0700 (PDT) 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 75F2B1201F8; Wed, 4 Apr 2018 08:56:59 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 4 Apr 2018 08:54:41 -0700 From: Jim Schaad To: CC: , 'core' References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> In-Reply-To: <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> Date: Wed, 4 Apr 2018 08:56:50 -0700 Message-ID: <06f101d3cc2d$8d3287d0$a7979770$@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: AQJlGCTfhwAxJ6Bs/Tz93rcnT3QjuQKDbAikoroJObA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 15:57:02 -0000 > -----Original Message----- > From: peter van der Stok > Sent: Wednesday, April 4, 2018 2:21 AM > To: Jim Schaad > Cc: draft-ietf-core-resource-directory@ietf.org; 'core' > Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 > > Hi Jim, > > thanks for the questions. Se my answers below. > > Jim Schaad schreef op 2018-04-01 20:37: > > Here are some more questions on the document. > > > > 1. The registration text in section 5.3 says that the interface is > > idempotent, however it is not clear to me just how idempotent this is > > supposed to be. It is obvious that the goal is to make sure that a > > different resource is not created, however I am not clear what is > > supposed to happen with some of the parameters such as the 'lt' > > parameter. One way to implement this is to just make it a POST to the > > previously existing resource which would inherit old attributes on the > > endpoint. The other way is to say we are going to create a new > > resource, it just has the same address. It is not clear which, if > > any, of these two methods is to be used. > > > > Never mind I found the answer to this one. Need to think if I want > > clearer language. > > I hope we find the same answer. > The text says "registering with the same endpoint parameters , ep and d, > does not create multiple resources. > Consequently, registering with existing ep and d removes existing > registration and creates new registration with new location. Registering with > a different ep and same d, or different d and same ep, creates new > registration next to the existing one. The values of the other parameters are > irrelevant. I believe that if you register with existing ep and d, it will remove the existing registration and create a new registration with the SAME location. This is part of being idempotent. I agree w/ the endpoint/d mismatch. > > is additional text like above needed? > > > > 2. When doing an endpoint lookup, I assume that the 'lt' parameter > > would be the same as the one registered at creation. Is there/should > > there be a parameter which is a TTL value? > > I don't understand the question. TTL is about the lifetime of a packet in the > network (expressed in hops) lt is about the lifetime of the registration > expressed in seconds In this case, TTL would be the number of seconds until the registration expires. I have seen TTL used in non-packet situations to describe the exact same thing - how long is this going to be alive. I have debated using the smallest TTL value when I return a result as the option Max-Age, but that does not quite mesh with how that option is defined. > > > > 3. How are href comparisons done. > > a) compare against what was registered > > b) Resolve what was registered and the href in the current context > > and compare > > c) something I did not think of > > probably someone else wants to react as well. > The model in the RD stores the target as specified in /.well-known/core of > the source. > At lookup the links are resolved against con. > Consequently, the comparison of href is the comparison versus the target as > stored in the RD and as copied from /.well-knwon/core. > > Is that reasonable for you? needs extra text in the RD spec.? This is how I read the current text, but it was not the only possible answer. If the answer is not b, then I don't think extra text is needed. > > > > > 4. compare on group for remote endpoint. Should this do the remote > > lookup or can it just be ignored for attribute comparison > > I am not quite sure what you mean by attribute comparison. > When it is about registration attributes, no remote lookup seems necessary > to me. If I do the lookup of /rd/gp-lookup?rt=foobar And one of the groups has the following /rd-group/xxx https://otherrd/rd-group/yyy I would follow the local group definition to find out if the resource type is defined on some resource in the group, however the question is do I need to go and query the other group which is not local in order to do the same tree walking when doing attribute comparisons. Not that this applies to remote endpoint registrations in a group as well. > > > > > 5. Value of lt = should it be the set parameter or the time left - > > how would time left be represented outherwise - should it be represented. > > Right on the nail. This is very vaguely specified. The unit is specified as > seconds. > In my expectation the returned lt value is the time in seconds from lookup till > end. > > Other opinions by my co-authors? If we all agree, we specify it as such in the > RD spec. This is a dup of the TTL question above. Sorry that I missed that. > > > > 6. Inferred context based on source IP when an update is done. If no > > con is provided, is that supposed to be checked again to see if it is > > "right"? > > Only if we did the infer to begin with? > > My interpretation of the current text is: > When a registration is done with the same ep and d values, the old > registration is removed and a new one with the new parameter values is > created at a new location. > That means that the value of con > is specified in the registration without any memory of earlier values. This is not the sequence that I was looking for. POST /rd?ep=node1 - payload contains the set of resources the register. - returns a location of /rd/yyyy POST /rd/yyyy?ep=node1 - payload is empty. In the first post, the rd will infer a context based on how the registration is done. The second post just says that the TTL value is to be refreshed back to the life-time value. However, the inferred context could also be changed. > > > > 7. I don't understand the presence of the content-format for the > > empty message posted for simple registration. This seems to be odd if > > the content is empty. > > content-format is specified such that RD knows what content-format to > request. Would accept be a better option to use? This would allow for more than one value to be specified. > > > > 8 Is there supposed to be a way for simple registration to return an > > error message? As written this is not necessarily done. > > Specifically, the response to the post can be executed before the > > query to /.well-known/core is done and the registration is attempted. > > I see what you mean: also the return of 2.04 shows in the example but not in > the specification. > This warrants additional text to specify the simple registration text. > > > > > Many thanks for these questions. > Looking forward to your answer, > > Greetings, > > peter > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Wed Apr 4 10:40:51 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 AFD4F126BF6 for ; Wed, 4 Apr 2018 10:40:49 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 epT6e3H8t1yb for ; Wed, 4 Apr 2018 10:40:46 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0077.outbound.protection.outlook.com [104.47.2.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697AF124C27 for ; Wed, 4 Apr 2018 10:40:45 -0700 (PDT) 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; bh=dmJI79S/qs70nvU1o7ilZxHr9UYeHOCzzCK1ZFxJVoM=; b=EZzfpZlKESyfeZ1zntBgdC6oTFepijploZEzWQWUOzlodgnCrir1lxc3jG6BuD33TI24bRUywlwh4AVBWrBzNovaLLKHkiWtk6jxbDGVxpfVu8kclo/wjIt3GbTtGOb3mKEuQjnGi00qJzbpzI8IYVMZ8KxyKyp+dIwPJkHj0mo= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1694.eurprd08.prod.outlook.com (10.168.67.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Wed, 4 Apr 2018 17:40:41 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf%18]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 17:40:41 +0000 From: Hannes Tschofenig To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= CC: "core@ietf.org WG" , Carsten Bormann Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBA= Date: Wed, 4 Apr 2018 17:40:40 +0000 Message-ID: References: In-Reply-To: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [194.136.97.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1694; 7:/UjOLu4z6isWq71BP1CnDkM0Z/RLnufw9A0TI+Zp80fKlOOYfv8cu174xQerXI0CWVhIszdBOHgm7lftomFC1ChW46mcEGrxEnAcS8ismu8cMl/KNvgh5LaT2S5MHaT5F781sj6dlobqeYusedRU8I8V4xwf3cTsjgFStcRzKGSJQkBwHTDmQpz7IgU4NCpnaHdl2Yl+UbH21ZbEA1huwmoEJSWiOrIe2PtQKK8j8+z3FP38Sywsr6bmbvddsxb0 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 01d0bd44-6ce0-4829-d8f2-08d59a532f92 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1694; x-ms-traffictypediagnostic: VI1PR0801MB1694: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(180628864354917)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1694; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1694; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(366004)(346002)(376002)(39860400002)(40434004)(53754006)(199004)(189003)(8676002)(236005)(6506007)(790700001)(2906002)(7736002)(6246003)(6436002)(966005)(4326008)(14454004)(8936002)(74316002)(68736007)(54896002)(106356001)(446003)(53936002)(3660700001)(6306002)(97736004)(486006)(55016002)(33656002)(105586002)(3846002)(9686003)(6116002)(25786009)(476003)(11346002)(99286004)(316002)(26005)(186003)(5890100001)(81156014)(54906003)(66066001)(5250100002)(9326002)(7696005)(86362001)(5660300001)(6916009)(72206003)(53546011)(102836004)(478600001)(3280700002)(2900100001)(81166006)(229853002)(59450400001)(76176011)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1694; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: EIF7X1caswK6O7naYDGAS+yPKGjJ8Ppne+oONGsjIlO4Ce2cdJ7mfPx3EV/YZaOD49jraA7bs43nu9dbwftoAcw5qgKqXcj5x37TIYrY2V0Z6/y1SR8cYDOo90xzft3BypcYSSARDhsp2Aq9CuQYJdgAe15vETHX3nwYZre7gM4hmfmiHNgz+t+WkytSxKngnwTVu+R/qlzwlyPYS8aiEVV0VGBRfdSBUokDF0HeyM9X7sd/x3PdX8sjVjr0vg+yTV8gZ4DtcvKRzOYpqcKeJhHlkNN1nNOn+KrxpWAQxmn1vj5pjnDNAJB1KOGK27X1+ksl3Bmx9GRMvsKKwoeof2R/b4RGSgLiqeqRizrRKzw8ipDsjipu6BsOSmP0yJ9EV1Dw/675KLtmF8TarFjusiTOHetvg1z3FbQmWkCf/YE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21128EA2B70DEEE7C5775A62FAA40VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01d0bd44-6ce0-4829-d8f2-08d59a532f92 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 17:40:41.2659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1694 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 17:40:50 -0000 --_000_VI1PR0801MB21128EA2B70DEEE7C5775A62FAA40VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFpbWUsDQoNCnVzaW5nIElQIGFkZHJlc3MgYW5kIHBvcnQgZm9yIGFuIGVuZHBvaW50IChj bGllbnQpIG5hbWUgd291bGQgbm90IGJlIGEgZ29vZCBpZGVhLg0KSW4gZ2VuZXJhbCwgaXQgd2Fz IG5vdCBhIGdvb2QgaWRlYSB0byBoYXZlIHRoaXMgcGFyYW1ldGVyIGRlZmluZWQgaW4gdGhlIGZp cnN0IHBsYWNlLiBJdCBtaWdodCBhY3R1YWxseSBiZSBiZXR0ZXIgdG8gcmVtb3ZlIGl0IGFsdG9n ZXRoZXIuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBKYWltZSBKaW3DqW5leiBbbWFpbHRvOmph aW1lLmppbWVuZXpAZXJpY3Nzb24uY29tXQ0KU2VudDogMDQgQXByaWwgMjAxOCAxNzozMg0KVG86 IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogY29yZUBpZXRmLm9yZyBXRzsgQ2Fyc3RlbiBCb3JtYW5u DQpTdWJqZWN0OiBSZTogW2NvcmVdIEVuZHBvaW50IENsaWVudCBOYW1lIC8gRW5kcG9pbnQgTmFt ZSBpbiBSRCBkcmFmdA0KDQpIaSwNCg0KTm90ZSB0aGF0IGVuZHBvaW50IGNhbiByZWZlciB0byBi b3RoIHNvdXJjZSBhbmQgZGVzdGluYXRpb24sIGJlaW5nIGFuZCBJUDpwb3J0IGluIGl0cyBzaW1w bGVzdCBmb3JtOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjcGFnZS02DQoN ClRoZSBmYWN0IHRoYXQgTFdNMk0gc3dhcHMgdGhvc2Ugcm9sZSBuYW1lcyBtaWdodCBhY3R1YWxs eSBhZGQgdG8gdGhlIGNvbmZ1c2lvbiwgcHJvYmFibHkgT01BIExXTTJNIHNob3VsZCBiZSB0aGUg b25lIGNoYW5naW5nIHRoZSB0ZXJtaW5vbG9neSBhcyB0aGUgZGV2aWNlIGlzIG1vc3RseSBhIOKA nHNlcnZlcuKAnSBob3N0aW5nIHJlc291cmNlcyBhbmQgb25seSBpcyBhIOKAnGNsaWVudOKAnSBk dXJpbmcgYm9vdHN0cmFwcGluZyBhbmQgcmVnaXN0cmF0aW9uLiBXZSBjb3VsZCBoYXZlIHVzZWQg dGVybXMgbGlrZSDigJxzZXJ2aWVudOKAnSBpbnN0ZWFkIGJ1dCBpdCBtaWdodCBiZSB0b28gbGF0 ZSBmb3IgdGhhdC4NCg0KQ2lhbyENCi0gLSBKYWltZSBKaW3DqW5leg0KDQoNCk9uIDQgQXByIDIw MTgsIGF0IDE2LjQxLCBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoN Ckkgbm90aWNlZCB0aGF0IHRoZSB0ZXJtIOKAnGVuZHBvaW50IG5hbWXigJ0gaXMgdXNlZCBpbiB0 aGUgSUVURiBSRCBkcmFmdCB3aGlsZSB0aGUgT01BIEx3TTJNIHNwZWMgdXNlcyB0aGUgdGVybSDi gJxlbmRwb2ludCBjbGllbnQgbmFtZeKAnS4gRW5kcG9pbnQgaXMgYSBjb25mdXNpbmcgdGVybSBz aW5jZSBpdCBpcyB1c2VkIGRpZmZlcmVudGx5IGluIHRoZSBDb0FQIHNwZWMgdGhhbiBpbiB0aGUg V2ViIGVudmlyb25tZW50Lg0KDQpGb3IgdGhpcyByZWFzb24gSSBiZWxpZXZlIGl0IHdvdWxkIGJl IGJldHRlciB0byB1c2UgdGhlIHRlcm0g4oCcZW5kcG9pbnQgY2xpZW50IG5hbWXigJ0gYWxzbyBp biB0aGUgUkQgZHJhZnQuIFRoaXMgd291bGQgaW1wcm92ZSBhbGlnbm1lbnQgYmV0d2VlbiB0aGUg dHdvIHNwZWNzLg0KDQpDaWFvDQpIYW5uZXMNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91LiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_VI1PR0801MB21128EA2B70DEEE7C5775A62FAA40VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBKYWltZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dXNpbmcgSVAgYWRkcmVzcyBh bmQgcG9ydCBmb3IgYW4gZW5kcG9pbnQgKGNsaWVudCkgbmFtZSB3b3VsZCBub3QgYmUgYSBnb29k IGlkZWEuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JbiBnZW5lcmFsLCBpdCB3YXMgbm90IGEgZ29vZCBpZGVhIHRvIGhhdmUgdGhpcyBw YXJhbWV0ZXIgZGVmaW5lZCBpbiB0aGUgZmlyc3QgcGxhY2UuIEl0IG1pZ2h0IGFjdHVhbGx5IGJl IGJldHRlciB0byByZW1vdmUgaXQgYWx0b2dldGhlci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNpYW88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGFubmVzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYWltZSBKaW3DqW5leiBbbWFpbHRvOmphaW1lLmppbWVu ZXpAZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA0IEFwcmlsIDIwMTggMTc6MzI8 YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KPGI+Q2M6PC9iPiBjb3JlQGll dGYub3JnIFdHOyBDYXJzdGVuIEJvcm1hbm48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3Jl XSBFbmRwb2ludCBDbGllbnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCBlbmRwb2ludCBjYW4g cmVmZXIgdG8gYm90aCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uLCBiZWluZyBhbmQNCjxpPklQOnBv cnQ8L2k+IGluIGl0cyBzaW1wbGVzdCBmb3JtOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MjUyI3BhZ2UtNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjcGFn ZS02PC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgZmFjdCB0aGF0IExXTTJNIHN3YXBzIHRob3NlIHJvbGUgbmFtZXMgbWln aHQgYWN0dWFsbHkgYWRkIHRvIHRoZSBjb25mdXNpb24sIHByb2JhYmx5IE9NQSBMV00yTSBzaG91 bGQgYmUgdGhlIG9uZSBjaGFuZ2luZyB0aGUgdGVybWlub2xvZ3kgYXMgdGhlIGRldmljZSBpcyBt b3N0bHkgYSDigJxzZXJ2ZXLigJ0gaG9zdGluZyByZXNvdXJjZXMgYW5kIG9ubHkgaXMgYSDigJxj bGllbnTigJ0gZHVyaW5nIGJvb3RzdHJhcHBpbmcNCiBhbmQgcmVnaXN0cmF0aW9uLiBXZSBjb3Vs ZCBoYXZlIHVzZWQgdGVybXMgbGlrZSDigJxzZXJ2aWVudOKAnSBpbnN0ZWFkIGJ1dCBpdCBtaWdo dCBiZSB0b28gbGF0ZSBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbyE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSAt IEphaW1lIEppbcOpbmV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQgQXByIDIwMTgsIGF0IDE2LjQx LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2Zlbmln QGFybS5jb20iPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SGkgYWxsLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBub3RpY2VkIHRoYXQgdGhlIHRlcm0g4oCcZW5kcG9p bnQgbmFtZeKAnSBpcyB1c2VkIGluIHRoZSBJRVRGIFJEIGRyYWZ0IHdoaWxlIHRoZSBPTUEgTHdN Mk0gc3BlYyB1c2VzIHRoZSB0ZXJtIOKAnGVuZHBvaW50IGNsaWVudCBuYW1l4oCdLiBFbmRwb2lu dCBpcyBhIGNvbmZ1c2luZyB0ZXJtIHNpbmNlIGl0DQogaXMgdXNlZCBkaWZmZXJlbnRseSBpbiB0 aGUgQ29BUCBzcGVjIHRoYW4gaW4gdGhlIFdlYiBlbnZpcm9ubWVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9y IHRoaXMgcmVhc29uIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdXNlIHRoZSB0ZXJt IOKAnGVuZHBvaW50IGNsaWVudCBuYW1l4oCdIGFsc28gaW4gdGhlIFJEIGRyYWZ0LiBUaGlzIHdv dWxkIGltcHJvdmUgYWxpZ25tZW50IGJldHdlZW4gdGhlIHR3byBzcGVjcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGFubmVzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQogaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91LiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnB1cnBsZSI+Y29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y bWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB21128EA2B70DEEE7C5775A62FAA40VI1PR0801MB2112_-- From nobody Wed Apr 4 11:05: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 BE9B9126BFD for ; Wed, 4 Apr 2018 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WqdmfGK2fNc8 for ; Wed, 4 Apr 2018 11:05:51 -0700 (PDT) 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 9204712D775 for ; Wed, 4 Apr 2018 11:05:50 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 4 Apr 2018 11:03:32 -0700 From: Jim Schaad To: 'Hannes Tschofenig' , =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= CC: References: In-Reply-To: Date: Wed, 4 Apr 2018 11:05:41 -0700 Message-ID: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0709_01D3CC04.E0FC1A30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGcf25aV3GTfadMlg2+OgOm0/j8CAHJGZYkAVowTP2kRmWywA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 18:05:54 -0000 ------=_NextPart_000_0709_01D3CC04.E0FC1A30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hannes, =20 I am not completely clear. Are you saying that the RD should not have = the endpoint name parameter as a defined property or something else? =20 Jim =20 =20 From: core On Behalf Of Hannes Tschofenig Sent: Wednesday, April 4, 2018 10:41 AM To: Jaime Jim=C3=A9nez Cc: core@ietf.org WG Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hi Jaime,=20 =20 using IP address and port for an endpoint (client) name would not be a = good idea.=20 In general, it was not a good idea to have this parameter defined in the = first place. It might actually be better to remove it altogether.=20 =20 Ciao Hannes =20 From: Jaime Jim=C3=A9nez [mailto:jaime.jimenez@ericsson.com]=20 Sent: 04 April 2018 17:32 To: Hannes Tschofenig Cc: core@ietf.org WG; Carsten Bormann Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hi, =20 Note that endpoint can refer to both source and destination, being and = IP:port in its simplest form:=20 https://tools.ietf.org/html/rfc7252#page-6=20 =20 The fact that LWM2M swaps those role names might actually add to the = confusion, probably OMA LWM2M should be the one changing the terminology = as the device is mostly a =E2=80=9Cserver=E2=80=9D hosting resources and = only is a =E2=80=9Cclient=E2=80=9D during bootstrapping and = registration. We could have used terms like =E2=80=9Cservient=E2=80=9D = instead but it might be too late for that. =20 Ciao! - - Jaime Jim=C3=A9nez =20 On 4 Apr 2018, at 16.41, Hannes Tschofenig > wrote: =20 Hi all,=20 =20 I noticed that the term =E2=80=9Cendpoint name=E2=80=9D is used in the = IETF RD draft while the OMA LwM2M spec uses the term =E2=80=9Cendpoint = client name=E2=80=9D. Endpoint is a confusing term since it is used = differently in the CoAP spec than in the Web environment. =20 For this reason I believe it would be better to use the term = =E2=80=9Cendpoint client name=E2=80=9D also in the RD draft. This would = improve alignment between the two specs. =20 Ciao Hannes =20 IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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. = _______________________________________________ core mailing list core@ietf.org = https://www.ietf.org/mailman/listinfo/core =20 IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please 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.=20 ------=_NextPart_000_0709_01D3CC04.E0FC1A30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hannes,<= /o:p>

 

I am not = completely clear.=C2=A0 Are you saying that the RD should not have the = endpoint name parameter as a defined property or something = else?

 

Jim

 

 

From:<= /b> = core <core-bounces@ietf.org> On Behalf Of Hannes = Tschofenig
Sent: Wednesday, April 4, 2018 10:41 = AM
To: Jaime Jim=C3=A9nez = <jaime.jimenez@ericsson.com>
Cc: core@ietf.org WG = <core@ietf.org>
Subject: Re: [core] Endpoint Client Name = / Endpoint Name in RD draft

 

Hi Jaime,

 

using IP address and port for an endpoint (client) name would not be a = good idea.

In general, it was not a good idea to have this parameter defined in = the first place. It might actually be better to remove it altogether. =

 

Ciao

Hannes

 

From: = Jaime Jim=C3=A9nez [mailto:jaime.jimenez@ericsson.= com]
Sent: 04 April 2018 17:32
To: Hannes = Tschofenig
Cc: core@ietf.org WG; Carsten = Bormann
Subject: Re: [core] Endpoint Client Name / Endpoint = Name in RD draft

 

Hi,

 

Note that endpoint can refer to = both source and destination, being and IP:port in its simplest = form: 

 

The fact that LWM2M swaps those = role names might actually add to the confusion, probably OMA LWM2M = should be the one changing the terminology as the device is mostly a = =E2=80=9Cserver=E2=80=9D hosting resources and only is a = =E2=80=9Cclient=E2=80=9D during bootstrapping and registration. We could = have used terms like =E2=80=9Cservient=E2=80=9D instead but it might be = too late for that.

 

Ciao!

- - Jaime = Jim=C3=A9nez

 

On 4 Apr 2018, at 16.41, Hannes Tschofenig <Hannes.Tschofenig@arm.com&g= t; wrote:

 

Hi all, 

 

I noticed = that the term =E2=80=9Cendpoint name=E2=80=9D is used in the IETF RD = draft while the OMA LwM2M spec uses the term =E2=80=9Cendpoint client = name=E2=80=9D. Endpoint is a confusing term since it is used differently = in the CoAP spec than in the Web = environment.

 

For this = reason I believe it would be better to use the term =E2=80=9Cendpoint = client name=E2=80=9D also in the RD draft. This would improve alignment = between the two specs.

 

Ciao

Hannes

 

IMPORTANT = NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, = please 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. = _______________________________________________
core mailing = list
core@ietf.org
<= span lang=3DEN-GB>https://www.ietf.org/mailman/listinfo/core<= /p>

 

IMPORTANT = NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, = please 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. =

------=_NextPart_000_0709_01D3CC04.E0FC1A30-- From nobody Wed Apr 4 12:02: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 45C0512D952 for ; Wed, 4 Apr 2018 12:02:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 7tO_XfzNA6g2 for ; Wed, 4 Apr 2018 12:02:09 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10079.outbound.protection.outlook.com [40.107.1.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAD412E8F1 for ; Wed, 4 Apr 2018 12:01:39 -0700 (PDT) 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; bh=EAVaG4CfjTUe35lbIeSkHLVKlwPtHlUxRxrMmFro33Q=; b=JGxBPysyjJle1mBX9rTgXpc/X6MgB16QxjEaqmexE5Ub5Mq3K5VO3jILIUe5Pg282nhLgi6J0T3WIjK1PPWnq2sz40syd1SStpM+FwiVr+d0DbJ9Suu7E3+Svnvhzf4mEb1APv6w7YkHpPaBn66syFTFEKY0E0fkxIvpOJVQXhM= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1727.eurprd08.prod.outlook.com (10.168.67.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Wed, 4 Apr 2018 19:01:29 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf%18]) with mapi id 15.20.0631.013; Wed, 4 Apr 2018 19:01:29 +0000 From: Hannes Tschofenig To: Jim Schaad , =?utf-8?B?J0phaW1lIEppbcOpbmV6Jw==?= CC: "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBCAALM9gP//8agg Date: Wed, 4 Apr 2018 19:01:29 +0000 Message-ID: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com> In-Reply-To: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com> 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=Hannes.Tschofenig@arm.com; x-originating-ip: [194.136.97.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1727; 7:dENgOH8OMUraYNg48QUIGRr0ENcag9l4Ey4DSdh6K5OeGaRjdYDy/UOIp2/FyiQ/vH1U29OKvqxHlGKgabJePGZgXPZZH4ZMnDPS+akn3WpRk897qH5KppJITfNPDwd4jWC8c5fjld3fZcVZnrUQ/2qHaChJB3xYtGaQ1sgJVVdoTT7Nlm+foDkDsPmRYT7y5GHNN6ZprUeF+wsHUzQSz+XITEODyZV48w0nHGe9B1ru2xj8crVN8dFHTmorVuzF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 98d9a1b3-e46e-410c-e95d-08d59a5e796d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1727; x-ms-traffictypediagnostic: VI1PR0801MB1727: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(180628864354917)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1727; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1727; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(39380400002)(376002)(346002)(366004)(53754006)(189003)(199004)(40434004)(478600001)(105586002)(72206003)(3846002)(3660700001)(59450400001)(790700001)(66066001)(53546011)(229853002)(6116002)(33656002)(6506007)(966005)(2900100001)(110136005)(476003)(7696005)(606006)(7736002)(486006)(5660300001)(2906002)(97736004)(81156014)(76176011)(25786009)(3280700002)(74316002)(8936002)(5890100001)(86362001)(55016002)(102836004)(5250100002)(106356001)(81166006)(186003)(26005)(9326002)(446003)(99286004)(316002)(93886005)(14454004)(6436002)(4326008)(11346002)(68736007)(54896002)(9686003)(236005)(53936002)(6306002)(6246003)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1727; H:VI1PR0801MB2112.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: FN+Yz2Ia7bwcboQnNHPcTXtnQLDCc34k0RQOlubFjvIrIj193rnPsfXZreXHBbkMGtJC24s3kUn5W8DYsTySHvdlz7yQ1BkjJJKrzMUZmT0Zsh0Vbl5ZMJpdxF/8VPwqwa3v1Z3wXNrkz6aHTAMFc8vY12WdDEbGTI56aAh+mkmEFBEhLHBazVi97tZPQYHOcS7iv0n5pDRrJ2cTu5lettt8zNWH7YRfW6LZXAWyjz3hlMjoFc2Xh1wUSkqghOWXz2L1pAaXKa0/0fhU4HUmk8fv8t2qW0VPyr36kNWth8FW8QJyuWJoGzIuGHu9xIwHzCxieHxYTU2cKDPEuEZyi+4OVMdOKNcb5WK/yr9a+NHw8jBZboXcoErPRTIHxfvoRjv/4MsDE3tuaifnSooJXXSuVSDT8M/sXpDRz7aq1QM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112FB25797DCB8F546C148DFAA40VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98d9a1b3-e46e-410c-e95d-08d59a5e796d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 19:01:29.6549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1727 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2018 19:02:12 -0000 --_000_VI1PR0801MB2112FB25797DCB8F546C148DFAA40VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpJIGhhZCB2YXJpb3VzIGNvbW1lbnRzOg0KDQpGaXJzdCwgSSBhcmd1ZSB0aGF0 IHRoZSBMd00yTSBzcGVjIGFuZCB0aGUgUkQgZHJhZnQgc2hvdWxkIGJlIGluIHN5bmMgcmVnYXJk aW5nIHRoZSBuYW1lIG9mIHRoZSBwYXJhbWV0ZXIuDQoNClNlY29uZCwgSSBiZWxpZXZlIHRoYXQg dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpcyBjb3JyZWN0IGluIHRoZSB0aHJl YXQgZGVzY3JpcHRpb24gYnV0IGNhbWUgdG8gdGhlIHdyb25nIGNvbmNsdXNpb24gcmVnYXJkaW5n IHRoZSB1c2Ugb2YgdGhlIHBhcmFtZXRlci4gSW4gZXNzZW5jZSwgdGhlIHBhcmFtZXRlciBzaG91 bGQgYmUgb3B0aW9uYWwgYW5kIHByb2JhYmx5IG9ubHkgdXNlZCBmb3IgZGVidWdnaW5nLg0KDQpU aGlyZCwgSSB3ZW50IGFzIGZhciBhcyBzYXlpbmcgdGhhdCB0aGUgZW5kcG9pbnQgbmFtZSBwYXJh bWV0ZXIgc2hvdWxkIGFjdHVhbGx5IGJlIHJlbW92ZWQgYWx0b2dldGhlci4gSSBjYW4gYWxyZWFk eSBzZWUgaG93IHRob3NlIGRlcGxveWluZyBpdCB3aWxsIGdldCBpdCB3cm9uZyBhbmQgd2lsbCBp bnRyb2R1Y2Ugc2VjdXJpdHkgcHJvYmxlbXMuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBKaW0g U2NoYWFkIFttYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbV0NClNlbnQ6IDA0IEFwcmlsIDIw MTggMjE6MDYNClRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgJ0phaW1lIEppbcOpbmV6Jw0KQ2M6IGNv cmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29yZV0gRW5kcG9pbnQgQ2xpZW50IE5hbWUgLyBF bmRwb2ludCBOYW1lIGluIFJEIGRyYWZ0DQoNCkhhbm5lcywNCg0KSSBhbSBub3QgY29tcGxldGVs eSBjbGVhci4gIEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIFJEIHNob3VsZCBub3QgaGF2ZSB0aGUg ZW5kcG9pbnQgbmFtZSBwYXJhbWV0ZXIgYXMgYSBkZWZpbmVkIHByb3BlcnR5IG9yIHNvbWV0aGlu ZyBlbHNlPw0KDQpKaW0NCg0KDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5p Zw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA0LCAyMDE4IDEwOjQxIEFNDQpUbzogSmFpbWUgSmlt w6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWltZS5qaW1lbmV6QGVy aWNzc29uLmNvbT4+DQpDYzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4gV0cg PGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtjb3Jl XSBFbmRwb2ludCBDbGllbnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQNCg0KSGkg SmFpbWUsDQoNCnVzaW5nIElQIGFkZHJlc3MgYW5kIHBvcnQgZm9yIGFuIGVuZHBvaW50IChjbGll bnQpIG5hbWUgd291bGQgbm90IGJlIGEgZ29vZCBpZGVhLg0KSW4gZ2VuZXJhbCwgaXQgd2FzIG5v dCBhIGdvb2QgaWRlYSB0byBoYXZlIHRoaXMgcGFyYW1ldGVyIGRlZmluZWQgaW4gdGhlIGZpcnN0 IHBsYWNlLiBJdCBtaWdodCBhY3R1YWxseSBiZSBiZXR0ZXIgdG8gcmVtb3ZlIGl0IGFsdG9nZXRo ZXIuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBKYWltZSBKaW3DqW5leiBbbWFpbHRvOmphaW1l LmppbWVuZXpAZXJpY3Nzb24uY29tXQ0KU2VudDogMDQgQXByaWwgMjAxOCAxNzozMg0KVG86IEhh bm5lcyBUc2Nob2ZlbmlnDQpDYzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4g V0c7IENhcnN0ZW4gQm9ybWFubg0KU3ViamVjdDogUmU6IFtjb3JlXSBFbmRwb2ludCBDbGllbnQg TmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQNCg0KSGksDQoNCk5vdGUgdGhhdCBlbmRw b2ludCBjYW4gcmVmZXIgdG8gYm90aCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uLCBiZWluZyBhbmQg SVA6cG9ydCBpbiBpdHMgc2ltcGxlc3QgZm9ybToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MjUyI3BhZ2UtNg0KDQpUaGUgZmFjdCB0aGF0IExXTTJNIHN3YXBzIHRob3NlIHJvbGUg bmFtZXMgbWlnaHQgYWN0dWFsbHkgYWRkIHRvIHRoZSBjb25mdXNpb24sIHByb2JhYmx5IE9NQSBM V00yTSBzaG91bGQgYmUgdGhlIG9uZSBjaGFuZ2luZyB0aGUgdGVybWlub2xvZ3kgYXMgdGhlIGRl dmljZSBpcyBtb3N0bHkgYSDigJxzZXJ2ZXLigJ0gaG9zdGluZyByZXNvdXJjZXMgYW5kIG9ubHkg aXMgYSDigJxjbGllbnTigJ0gZHVyaW5nIGJvb3RzdHJhcHBpbmcgYW5kIHJlZ2lzdHJhdGlvbi4g V2UgY291bGQgaGF2ZSB1c2VkIHRlcm1zIGxpa2Ug4oCcc2VydmllbnTigJ0gaW5zdGVhZCBidXQg aXQgbWlnaHQgYmUgdG9vIGxhdGUgZm9yIHRoYXQuDQoNCkNpYW8hDQotIC0gSmFpbWUgSmltw6lu ZXoNCg0KT24gNCBBcHIgMjAxOCwgYXQgMTYuNDEsIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3Jv dGU6DQoNCkhpIGFsbCwNCg0KSSBub3RpY2VkIHRoYXQgdGhlIHRlcm0g4oCcZW5kcG9pbnQgbmFt ZeKAnSBpcyB1c2VkIGluIHRoZSBJRVRGIFJEIGRyYWZ0IHdoaWxlIHRoZSBPTUEgTHdNMk0gc3Bl YyB1c2VzIHRoZSB0ZXJtIOKAnGVuZHBvaW50IGNsaWVudCBuYW1l4oCdLiBFbmRwb2ludCBpcyBh IGNvbmZ1c2luZyB0ZXJtIHNpbmNlIGl0IGlzIHVzZWQgZGlmZmVyZW50bHkgaW4gdGhlIENvQVAg c3BlYyB0aGFuIGluIHRoZSBXZWIgZW52aXJvbm1lbnQuDQoNCkZvciB0aGlzIHJlYXNvbiBJIGJl bGlldmUgaXQgd291bGQgYmUgYmV0dGVyIHRvIHVzZSB0aGUgdGVybSDigJxlbmRwb2ludCBjbGll bnQgbmFtZeKAnSBhbHNvIGluIHRoZSBSRCBkcmFmdC4gVGhpcyB3b3VsZCBpbXByb3ZlIGFsaWdu bWVudCBiZXR3ZWVuIHRoZSB0d28gc3BlY3MuDQoNCkNpYW8NCkhhbm5lcw0KDQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxtYWls dG86Y29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29yZQ0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112FB25797DCB8F546C148DFAA40VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFy Z2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjkyMzczMTE1MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6OTc5MTMxNTU4IDEzNDgwNzU2OSAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4 MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIEppbSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYWQgdmFyaW91cyBjb21tZW50 czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Rmlyc3QsIEkgYXJndWUgdGhhdCB0aGUgTHdNMk0gc3BlYyBhbmQgdGhl IFJEIGRyYWZ0IHNob3VsZCBiZSBpbiBzeW5jIHJlZ2FyZGluZyB0aGUgbmFtZSBvZiB0aGUgcGFy YW1ldGVyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5TZWNvbmQsIEkgYmVsaWV2ZSB0aGF0IHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9uIHNlY3Rpb24gaXMgY29ycmVjdCBpbiB0aGUgdGhyZWF0IGRlc2NyaXB0aW9u IGJ1dCBjYW1lIHRvIHRoZSB3cm9uZyBjb25jbHVzaW9uIHJlZ2FyZGluZyB0aGUgdXNlIG9mIHRo ZSBwYXJhbWV0ZXIuDQogSW4gZXNzZW5jZSwgdGhlIHBhcmFtZXRlciBzaG91bGQgYmUgb3B0aW9u YWwgYW5kIHByb2JhYmx5IG9ubHkgdXNlZCBmb3IgZGVidWdnaW5nLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGly ZCwgSSB3ZW50IGFzIGZhciBhcyBzYXlpbmcgdGhhdCB0aGUgZW5kcG9pbnQgbmFtZSBwYXJhbWV0 ZXIgc2hvdWxkIGFjdHVhbGx5IGJlIHJlbW92ZWQgYWx0b2dldGhlci4gSSBjYW4gYWxyZWFkeSBz ZWUgaG93IHRob3NlIGRlcGxveWluZyBpdCB3aWxsIGdldCBpdA0KIHdyb25nIGFuZCB3aWxsIGlu dHJvZHVjZSBzZWN1cml0eSBwcm9ibGVtcy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmltIFNjaGFhZCBbbWFp bHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDQgQXByaWwg MjAxOCAyMTowNjxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc7ICdKYWltZSBKaW3D qW5leic8YnI+DQo8Yj5DYzo8L2I+IGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IFtjb3JlXSBFbmRwb2ludCBDbGllbnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJh ZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IYW5uZXMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBhbSBu b3QgY29tcGxldGVseSBjbGVhci4mbmJzcDsgQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgUkQgc2hv dWxkIG5vdCBoYXZlIHRoZSBlbmRwb2ludCBuYW1lIHBhcmFtZXRlciBhcyBhIGRlZmluZWQgcHJv cGVydHkgb3Igc29tZXRoaW5nIGVsc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmltPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGNvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpj b3JlLWJvdW5jZXNAaWV0Zi5vcmciPmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPkhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXByaWwgNCwgMjAxOCAxMDo0MSBBTTxicj4NCjxiPlRvOjwvYj4gSmFpbWUgSmltw6lu ZXogJmx0OzxhIGhyZWY9Im1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbSI+amFpbWUu amltZW5lekBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+IFdHICZsdDs8YSBocmVmPSJtYWls dG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbY29yZV0gRW5kcG9pbnQgQ2xpZW50IE5hbWUgLyBFbmRwb2ludCBOYW1lIGluIFJE IGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGkgSmFpbWUsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnVzaW5nIElQIGFkZHJlc3MgYW5kIHBvcnQg Zm9yIGFuIGVuZHBvaW50IChjbGllbnQpIG5hbWUgd291bGQgbm90IGJlIGEgZ29vZCBpZGVhLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGdlbmVyYWwsIGl0IHdhcyBub3QgYSBn b29kIGlkZWEgdG8gaGF2ZSB0aGlzIHBhcmFtZXRlciBkZWZpbmVkIGluIHRoZSBmaXJzdCBwbGFj ZS4gSXQgbWlnaHQgYWN0dWFsbHkgYmUgYmV0dGVyIHRvIHJlbW92ZSBpdCBhbHRvZ2V0aGVyLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5DaWFvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhbm5lczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFpbWUgSmltw6luZXog WzxhIGhyZWY9Im1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNzc29uLmNvbSI+bWFpbHRvOmphaW1l LmppbWVuZXpAZXJpY3Nzb24uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNCBBcHJpbCAy MDE4IDE3OjMyPGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+IFdHOyBD YXJzdGVuIEJvcm1hbm48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSBFbmRwb2ludCBD bGllbnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCBlbmRwb2ludCBjYW4gcmVmZXIgdG8gYm90 aCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uLCBiZWluZyBhbmQNCjxpPklQOnBvcnQ8L2k+IGluIGl0 cyBzaW1wbGVzdCBmb3JtOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3Bh Z2UtNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjcGFnZS02PC9hPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgZmFjdCB0aGF0IExXTTJNIHN3YXBzIHRob3NlIHJvbGUgbmFtZXMgbWlnaHQgYWN0dWFsbHkg YWRkIHRvIHRoZSBjb25mdXNpb24sIHByb2JhYmx5IE9NQSBMV00yTSBzaG91bGQgYmUgdGhlIG9u ZSBjaGFuZ2luZyB0aGUgdGVybWlub2xvZ3kgYXMgdGhlIGRldmljZSBpcyBtb3N0bHkgYSDigJxz ZXJ2ZXLigJ0gaG9zdGluZyByZXNvdXJjZXMgYW5kIG9ubHkgaXMgYSDigJxjbGllbnTigJ0gZHVy aW5nIGJvb3RzdHJhcHBpbmcNCiBhbmQgcmVnaXN0cmF0aW9uLiBXZSBjb3VsZCBoYXZlIHVzZWQg dGVybXMgbGlrZSDigJxzZXJ2aWVudOKAnSBpbnN0ZWFkIGJ1dCBpdCBtaWdodCBiZSB0b28gbGF0 ZSBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2lhbyE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSAtIEphaW1lIEppbcOp bmV6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNCBBcHIgMjAx OCwgYXQgMTYuNDEsIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVz LlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBhbGwsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIG5vdGljZWQgdGhhdCB0aGUgdGVy bSDigJxlbmRwb2ludCBuYW1l4oCdIGlzIHVzZWQgaW4gdGhlIElFVEYgUkQgZHJhZnQgd2hpbGUg dGhlIE9NQSBMd00yTSBzcGVjIHVzZXMgdGhlIHRlcm0g4oCcZW5kcG9pbnQgY2xpZW50IG5hbWXi gJ0uIEVuZHBvaW50IGlzIGEgY29uZnVzaW5nIHRlcm0gc2luY2UgaXQNCiBpcyB1c2VkIGRpZmZl cmVudGx5IGluIHRoZSBDb0FQIHNwZWMgdGhhbiBpbiB0aGUgV2ViIGVudmlyb25tZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gb3IgdGhpcyByZWFzb24gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGJldHRlciB0byB1 c2UgdGhlIHRlcm0g4oCcZW5kcG9pbnQgY2xpZW50IG5hbWXigJ0gYWxzbyBpbiB0aGUgUkQgZHJh ZnQuIFRoaXMgd291bGQgaW1wcm92ZSBhbGlnbm1lbnQgYmV0d2VlbiB0aGUgdHdvIHNwZWNzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5DaWFvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IYW5uZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXINCiBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5nIGxpc3Q8 YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxlIj5jb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQogaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB2112FB25797DCB8F546C148DFAA40VI1PR0801MB2112_-- From nobody Wed Apr 4 22:52:23 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 C601A124234 for ; Wed, 4 Apr 2018 22:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, 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 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 V8D_nEXbp_dy for ; Wed, 4 Apr 2018 22:52:19 -0700 (PDT) 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 B90E0124207 for ; Wed, 4 Apr 2018 22:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522907536; 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=IYqunMxTsQ7fVgu0yNFsUCMCBpqB1x0VqJvAPT6CfDk=; b=AIWLPnElVMri9R49vpFc4DS9PlyJWTcdWIUelHGjJzAOvrlRvWxzppYzsKPwvg1D Q/uz2dpahsOlfDY2rn91dcd8LIlP+hPvm4IvgNcKDQDkPWZOKkAd2LZrgFo7tM9X t1quYBKsbj99eeVYDBe9nEQf5atA3dRc80Mz4fx+z7Y=; X-AuditID: c1b4fb3a-1ff859c000005d56-78-5ac5b99084c8 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.28.23894.099B5CA5; Thu, 5 Apr 2018 07:52:16 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.243]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 07:52:15 +0200 From: =?Windows-1252?Q?Jaime_Jim=E9nez?= To: Hannes Tschofenig CC: Jim Schaad , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBCAAJG2gIAAD5eAgADXWe4= Date: Thu, 5 Apr 2018 05:52:14 +0000 Message-ID: <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7BA9B091F4894ED4B6EC5AD7D971D6F7ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7n+6EnUejDM6v07HY93Y9s8XNGaeY LFZP/87mwOyxZt4aRo+Nc6azeSxZ8pMpgDmKyyYlNSezLLVI3y6BK+P7ApWC/m2MFXMmrWBu YDy2gLGLkZNDQsBE4sue78wgtpDAEUaJFcdjuxi5gOzFjBLXH85nA0mwCbhKdCy9yApiiwgY SuxtPgRmMwt4SPQ1fwKzhQVcJCZM64aqcZXofveYEcL2k9iz/SeYzSKgItH+5RnYTF4Be4nb rV8YIRb/YJI4+MgCxOYUSJS4N/UrWJxRQEzi+6k1TBC7xCXuTelhhThaQGLJnvPMELaoxMvH /6DuSZZ413OcEWK+oMTJmU9YJjAKz0LSPgtJ2SwkZRBxA4n35+YzQ9jaEssWvoay9SU2fjnL iCy+gJF9FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgVB3c8ttqB+PB546HGAU4GJV4eJ2m HY0SYk0sK67MPcQowcGsJMLL2gwU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuUZhElJJCeWJKa nZpakFoEk2Xi4JRqYGR5Oj0i+cezpa1J3Cmfvv0XZq27Xl6z+0M0h+19rakPits9t/7avOm1 2lmdR73X3zSslRVa9Uql6Me2u6c9bzJP330nw6d/mplIn87bHq8Arh1KDEq3VWc/n/4nrESj pSa7ymaipoVVQfymy7/YWBymn9qiyLlreZOwWu2d9U12ZYwWhmHB/5VYijMSDbWYi4oTAZJS rF6mAgAA Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 05:52:22 -0000 --_000_7BA9B091F4894ED4B6EC5AD7D971D6F7ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, You mean we should remove the =93endpoint name=94 altogether, so not using = URNs to identify CoAP endpoints for example? The rationale for using endpoint name was at least discussed in 2014, back = then it seemed useful in the context of LWM2M. http://ietf.org/mail-archive/web/core/current/msg05645.html Ciao! El 4 abr 2018, a las 22:01, Hannes Tschofenig > escribi=F3: Hi Jim, I had various comments: First, I argue that the LwM2M spec and the RD draft should be in sync regar= ding the name of the parameter. Second, I believe that the security consideration section is correct in the= threat description but came to the wrong conclusion regarding the use of t= he parameter. In essence, the parameter should be optional and probably onl= y used for debugging. Third, I went as far as saying that the endpoint name parameter should actu= ally be removed altogether. I can already see how those deploying it will g= et it wrong and will introduce security problems. Ciao Hannes From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 04 April 2018 21:06 To: Hannes Tschofenig; 'Jaime Jim=E9nez' Cc: core@ietf.org Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft Hannes, I am not completely clear. Are you saying that the RD should not have the = endpoint name parameter as a defined property or something else? Jim From: core > On Behalf = Of Hannes Tschofenig Sent: Wednesday, April 4, 2018 10:41 AM To: Jaime Jim=E9nez > Cc: core@ietf.org WG > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft Hi Jaime, using IP address and port for an endpoint (client) name would not be a good= idea. In general, it was not a good idea to have this parameter defined in the fi= rst place. It might actually be better to remove it altogether. Ciao Hannes From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com] Sent: 04 April 2018 17:32 To: Hannes Tschofenig Cc: core@ietf.org WG; Carsten Bormann Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft Hi, Note that endpoint can refer to both source and destination, being and IP:p= ort in its simplest form: https://tools.ietf.org/html/rfc7252#page-6 The fact that LWM2M swaps those role names might actually add to the confus= ion, probably OMA LWM2M should be the one changing the terminology as the d= evice is mostly a =93server=94 hosting resources and only is a =93client=94= during bootstrapping and registration. We could have used terms like =93se= rvient=94 instead but it might be too late for that. Ciao! - - Jaime Jim=E9nez On 4 Apr 2018, at 16.41, Hannes Tschofenig > wrote: Hi all, I noticed that the term =93endpoint name=94 is used in the IETF RD draft wh= ile the OMA LwM2M spec uses the term =93endpoint client name=94. Endpoint i= s a confusing term since it is used differently in the CoAP spec than in th= e Web environment. For this reason I believe it would be better to use the term =93endpoint cl= ient name=94 also in the RD draft. This would improve alignment between the= two specs. Ciao Hannes 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core 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. 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_7BA9B091F4894ED4B6EC5AD7D971D6F7ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

You mean we should remove the =93endpoint name=94 altogether, so not u= sing URNs to identify CoAP endpoints for example? 

The rationale for using endpoint name was at least discussed in 2014, = back then it seemed useful in the context of LWM2M.


Ciao!

El 4 abr 2018, a las 22:01, Hannes Tschofenig <Hannes.Tschofenig@arm.com> escribi=F3:

Hi Jim,

 <= /p>

I had various comments:

 <= /p>

First, I argue that the L= wM2M spec and the RD draft should be in sync regarding the name of the para= meter.

 <= /p>

Second, I believe that th= e security consideration section is correct in the threat description but c= ame to the wrong conclusion regarding the use of the parameter. In essence, the parameter should be optional and probably only used for de= bugging.

 <= /p>

Third, I went as far as s= aying that the endpoint name parameter should actually be removed altogethe= r. I can already see how those deploying it will get it wrong and will introduce security problems.

 <= /p>

Ciao

Hannes<= /p>

 

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: 04 April 2018 21:06
To: Hannes Tschofenig; 'Jaime Jim=E9nez'
Cc: core@ietf.org
Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hannes,

 =

I am not completely clea= r.  Are you saying that the RD should not have the endpoint name param= eter as a defined property or something else?

 =

Jim

 =

 =

From: core <c= ore-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 4, 2018 10:41 AM
To: Jaime Jim=E9nez <jaime.jimenez@ericsson.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hi Jaime,

 <= /p>

using IP address and port= for an endpoint (client) name would not be a good idea.

In general, it was not a = good idea to have this parameter defined in the first place. It might actua= lly be better to remove it altogether.

 <= /p>

Ciao

Hannes<= /p>

 <= /p>

From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com]
Sent: 04 April 2018 17:32
To: Hannes Tschofenig
Cc: core@ietf.org WG; Carsten B= ormann
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hi,

 

Note that endpoint can refer to both source and dest= ination, being and IP:port in its simplest form: 

 

The fact that LWM2M swaps those role names might act= ually add to the confusion, probably OMA LWM2M should be the one changing t= he terminology as the device is mostly a =93server=94 hosting resources and= only is a =93client=94 during bootstrapping and registration. We could have used terms like =93servient=94 instead but= it might be too late for that.

 

Ciao!

- - Jaime Jim=E9nez=

 

On 4 Apr 2018, at 16.41, Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

 

Hi all, 

 

I noticed that the term =93endpoint nam= e=94 is used in the IETF RD draft while the OMA LwM2M spec uses the term = =93endpoint client name=94. Endpoint is a confusing term since it is used differently in the CoAP spec than in the Web environment.

 

For this reason I believe it would be b= etter to use the term =93endpoint client name=94 also in the RD draft. This= would improve alignment between the two specs.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this= email and any attachments are confidential and may also be privileged. If = you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it f= or any purpose, or store or copy the information in any medium. Thank you. = _______________________________________________
core mailing list
core@iet= f.org
https://www.ietf.org/mailman/listinfo/core<= /o:p>

 

IMPORTANT NOTICE: The contents of this = email and any attachments are confidential and may also be privileged. If y= ou are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it f= or any purpose, or store or copy the information in any medium. Thank you.

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_7BA9B091F4894ED4B6EC5AD7D971D6F7ericssoncom_-- From nobody Thu Apr 5 00:51:33 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 DF545120725; Thu, 5 Apr 2018 00:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 m6AmOqkg1AEN; Thu, 5 Apr 2018 00:51:29 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 BAF1B1200F1; Thu, 5 Apr 2018 00:51:28 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud7.xs4all.net with ESMTPA id 3zg5fmOCI8U073zg5fU2QV; Thu, 05 Apr 2018 09:51:25 +0200 Received: from 2001:983:a264:1:600b:380:6597:a9e6 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 05 Apr 2018 09:51:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Apr 2018 09:51:25 +0200 From: peter van der Stok To: Jim Schaad Cc: consultancy@vanderstok.org, draft-ietf-core-resource-directory@ietf.org, 'core' Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> Message-ID: <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfGGZhXjyV4wg51Su+4Bf80NdQF3SNCuNKFLg0zbIc041DTbH3NWbjfVkEhaeBMQvljqLJzu6kRgk0d2ifL6RhutVDotSIUOP9uwKP/UeyibP7TmZzPKt nklZWtFHOk2Ex5hNo9pGL+T96UtGH8VYkm+FqAKinnAgZuJ19PCtFJQeR569yTchJVOoxu+29MtLvCQe9kkclCtVK8hXYC0Wkj4v9T3fuoZu1QD4xCyupEAl KwSwaY14Xe93J7XZOLOvDJViQKn+5oVCqlsfONYU3fs= Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 07:51:32 -0000 Hi Jim, some additional questions and remark, >> > 1. The registration text in section 5.3 says that the interface is >> > idempotent, however it is not clear to me just how idempotent this is >> > supposed to be. It is obvious that the goal is to make sure that a >> > different resource is not created, however I am not clear what is >> > supposed to happen with some of the parameters such as the 'lt' >> > parameter. One way to implement this is to just make it a POST to the >> > previously existing resource which would inherit old attributes on the >> > endpoint. The other way is to say we are going to create a new >> > resource, it just has the same address. It is not clear which, if >> > any, of these two methods is to be used. >> > >> > Never mind I found the answer to this one. Need to think if I want >> > clearer language. >> >> I hope we find the same answer. >> The text says "registering with the same endpoint parameters , ep and >> d, >> does not create multiple resources. >> Consequently, registering with existing ep and d removes existing >> registration and creates new registration with new location. >> Registering > with >> a different ep and same d, or different d and same ep, creates new >> registration next to the existing one. The values of the other >> parameters > are >> irrelevant. > > I believe that if you register with existing ep and d, it will remove > the > existing registration and create a new registration with the SAME > location. > This is part of being idempotent. > > I agree w/ the endpoint/d mismatch. Idempotency says that applying the same operation multiple times should lead to the same result independent of the number of times. The problem is: what is the same operation; If only ep and d are relevant then applying multiple times an operation (registration) with the same ep and d values indeed leads to the same result ignoring all other attribute values (including location) If one says that the same operation implies that all other specification parameters are unchanged, then indeed location should not be changed in that case. What view do you adhere to? And do you suggest we should insert clarifying text? >> > >> > 4. compare on group for remote endpoint. Should this do the remote >> > lookup or can it just be ignored for attribute comparison >> >> I am not quite sure what you mean by attribute comparison. >> When it is about registration attributes, no remote lookup seems >> necessary >> to me. > > If I do the lookup of > /rd/gp-lookup?rt=foobar > > And one of the groups has the following > > /rd-group/xxx > https://otherrd/rd-group/yyy > > I would follow the local group definition to find out if the resource > type > is defined on some resource in the group, however the question is do I > need > to go and query the other group which is not local in order to do the > same > tree walking when doing attribute comparisons. Not that this applies > to > remote endpoint registrations in a group as well. Thanks for the example. Indeed following the latest text, the comparison should include the remote registration. The text could include words like tree walking is done locally only; personally I would not be too happy about that. Apparently the text should say something about remote groups and tree walking. I will add the issue to github. > >> >> > >> > 5. Value of lt = should it be the set parameter or the time left - >> > how would time left be represented outherwise - should it be > represented. >> >> Right on the nail. This is very vaguely specified. The unit is >> specified > as >> seconds. >> In my expectation the returned lt value is the time in seconds from >> lookup > till >> end. >> >> Other opinions by my co-authors? If we all agree, we specify it as >> such > in the >> RD spec. > Also an issue for github to get more reactions > >> > >> > 6. Inferred context based on source IP when an update is done. If no >> > con is provided, is that supposed to be checked again to see if it is >> > "right"? >> > Only if we did the infer to begin with? >> >> My interpretation of the current text is: >> When a registration is done with the same ep and d values, the old >> registration is removed and a new one with the new parameter values is >> created at a new location. >> That means that the value of con >> is specified in the registration without any memory of earlier values. > > This is not the sequence that I was looking for. > > POST /rd?ep=node1 > - payload contains the set of resources the register. > - returns a location of /rd/yyyy > > POST /rd/yyyy?ep=node1 > - payload is empty. > > In the first post, the rd will infer a context based on how the > registration > is done. The second post just says that the TTL value is to be > refreshed > back to the life-time value. However, the inferred context could also > be > changed. Thanks for the example; it would take me long to figure this out otherwise. Reading the update specification, the ep=node1 is illegal in the update. Specifying ep means creating a new registration. sending the update POST /rd/yyy will update the lt value. It is allowed to change the value of con in the update POST specification. The question is: When an updating ep, different from the registering one, sends the update of lt, does the context change to the hosts relation value of the updating ep. My gut reaction is no. it does not change the context value in the RD because that needs an explicit ?con= in the update specification. A warning in the RD text to this effect looks reasonable. > > >> > >> > 7. I don't understand the presence of the content-format for the >> > empty message posted for simple registration. This seems to be odd if >> > the content is empty. >> >> content-format is specified such that RD knows what content-format to >> request. > > Would accept be a better option to use? This would allow for more than > one > value to be specified. Agree. > >> > >> > 8 Is there supposed to be a way for simple registration to return an >> > error message? As written this is not necessarily done. >> > Specifically, the response to the post can be executed before the >> > query to /.well-known/core is done and the registration is attempted. >> >> I see what you mean: also the return of 2.04 shows in the example but >> not > in >> the specification. >> This warrants additional text to specify the simple registration text. >> > >> > will add the simple registration template to the text. many thanks for your additional explanations. One issue of idempotency is left. Peter From nobody Thu Apr 5 03:02: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 A5CC1126C25 for ; Thu, 5 Apr 2018 03:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I_YcgjMCPdxd for ; Thu, 5 Apr 2018 03:02:48 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE20124205 for ; Thu, 5 Apr 2018 03:02:47 -0700 (PDT) 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; bh=kN0T7R3L30PB4C0TLHIHz3+lJEVeEZzyHckoXh6cUag=; b=YH4n/MWHXSZ2f9mVq+29nAv3DZ9O1b00CIf0w3vPJW5TKeKzg3hUwpdcRQVwwN9gTtWgWnlzXwOaMvQ2qVMXBSyTbfcM4kenlTphzfNTd6uqpJ1F+5uSYN/51SVcAklDgDSCrIn3yEF6+CGVCvd8zsMG4b6PdBK+/iQ7mTejOQo= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1757.eurprd08.prod.outlook.com (10.168.67.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 5 Apr 2018 10:02:44 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::64d4:b973:bf81:cfbf%18]) with mapi id 15.20.0631.013; Thu, 5 Apr 2018 10:02:44 +0000 From: Hannes Tschofenig To: =?iso-8859-1?Q?Jaime_Jim=E9nez?= CC: Jim Schaad , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBCAALM9gP//8agggADTwQD//7rfYA== Date: Thu, 5 Apr 2018 10:02:44 +0000 Message-ID: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> In-Reply-To: <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> 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=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1757; 7:Hz3VG6yiAlgN2QK4YSmSHFaddNDzpYSMS9piSZZC4pMHUbOVzLqaoy2qxsW1wnGnd63FQP0LBrlt6T3peUnC2keOqdQa/d6IBS3oCcnTIU5s4W4iZu70xdgCwUvySpKuaTUu/c8Mulq7k3QvL0euSs8uOYIEY19T4yjxNktOa5CA6R14P1OGs24FyM3YItAYg0lda5KQaIgfyt2Lfapc/DwHCxyi9q9xPyCXPqci99obOpN5TA5m/XLO3LkI8kpe x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9beb88b8-2443-4c7e-bdf4-08d59adc60b4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1757; x-ms-traffictypediagnostic: VI1PR0801MB1757: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(180628864354917)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1757; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1757; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39380400002)(376002)(396003)(39860400002)(53754006)(189003)(199004)(40434004)(51914003)(3280700002)(6306002)(3846002)(54896002)(6116002)(236005)(790700001)(72206003)(68736007)(53936002)(33656002)(316002)(25786009)(55016002)(6436002)(14454004)(5250100002)(81166006)(97736004)(81156014)(74316002)(8676002)(446003)(11346002)(9326002)(5890100001)(6916009)(486006)(7736002)(53376002)(9686003)(6246003)(66066001)(7696005)(76176011)(53546011)(186003)(93886005)(59450400001)(86362001)(6506007)(8936002)(4326008)(99286004)(106356001)(229853002)(2906002)(966005)(606006)(3660700001)(102836004)(2900100001)(105586002)(54906003)(26005)(5660300001)(476003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1757; H:VI1PR0801MB2112.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: yzBnZj8sFTN00O54ze9mvl2R0BjT5m5eI4ZAvm9nY82IgjSoR6N8DSLI99jnXm2HsTFIXhk9pWPMbVBFyDU3qipdANF2ICC7dTEd+MHYio4/yFrVCekPZDW3QfX5jNZw9NDNDnvFFG/6cb74NLPfZrTrlmloviBDWTj8C2lPOSKVmwusZ19DdrV+kdnmZjomRQB2kghNF3UgiRzpT0LJLEghMMW/a6uBjCmWJ1IC7rlZRJYZwr8kcMzkaAjA1JgkYYQq+eezMKp0GfD1myiyTinGrreP9SHhtRAHyFR/28ZH5/iQW/QJ6IWcw9K3hZze/VSljWnkhy/tW6SvUySADW/iEAntCwGNX0FEzz0XyFR27TTt6jRRsspbEKoySgUJteskdosCH6UD+cKilUMIKkBFTWHYrof9RMmiL4VDWO4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112A692CB307D213A89DFC8FABB0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9beb88b8-2443-4c7e-bdf4-08d59adc60b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 10:02:44.7327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1757 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 05 Apr 2018 10:02:52 -0000 --_000_VI1PR0801MB2112A692CB307D213A89DFC8FABB0VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jaime, Thanks for the pointer to earlier discussions on this topic. Looking at the discussions from 2014 it appears that there is some misunder= standing of how this endpoint name interacts with the security protocol and= what vulnerabilities are created by relying on an identifier that is unaut= henticated. I am curious what we lose if we remove this identifier altogether. The only= thing that comes to my mind is a debugging capability where you might want= to test your system without any security protocol. In any practical deploy= ment I would not recommend to use RD without security. Ciao Hannes From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com] Sent: 05 April 2018 07:52 To: Hannes Tschofenig Cc: Jim Schaad; core@ietf.org Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft Hi, You mean we should remove the "endpoint name" altogether, so not using URNs= to identify CoAP endpoints for example? The rationale for using endpoint name was at least discussed in 2014, back = then it seemed useful in the context of LWM2M. http://ietf.org/mail-archive/web/core/current/msg05645.html Ciao! El 4 abr 2018, a las 22:01, Hannes Tschofenig > escribi=F3: Hi Jim, I had various comments: First, I argue that the LwM2M spec and the RD draft should be in sync regar= ding the name of the parameter. Second, I believe that the security consideration section is correct in the= threat description but came to the wrong conclusion regarding the use of t= he parameter. In essence, the parameter should be optional and probably onl= y used for debugging. Third, I went as far as saying that the endpoint name parameter should actu= ally be removed altogether. I can already see how those deploying it will g= et it wrong and will introduce security problems. Ciao Hannes From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: 04 April 2018 21:06 To: Hannes Tschofenig; 'Jaime Jim=E9nez' Cc: core@ietf.org Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft Hannes, I am not completely clear. Are you saying that the RD should not have the = endpoint name parameter as a defined property or something else? Jim From: core > On Behalf = Of Hannes Tschofenig Sent: Wednesday, April 4, 2018 10:41 AM To: Jaime Jim=E9nez > Cc: core@ietf.org WG > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft Hi Jaime, using IP address and port for an endpoint (client) name would not be a good= idea. In general, it was not a good idea to have this parameter defined in the fi= rst place. It might actually be better to remove it altogether. Ciao Hannes From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com] Sent: 04 April 2018 17:32 To: Hannes Tschofenig Cc: core@ietf.org WG; Carsten Bormann Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft Hi, Note that endpoint can refer to both source and destination, being and IP:p= ort in its simplest form: https://tools.ietf.org/html/rfc7252#page-6 The fact that LWM2M swaps those role names might actually add to the confus= ion, probably OMA LWM2M should be the one changing the terminology as the d= evice is mostly a "server" hosting resources and only is a "client" during = bootstrapping and registration. We could have used terms like "servient" in= stead but it might be too late for that. Ciao! - - Jaime Jim=E9nez On 4 Apr 2018, at 16.41, Hannes Tschofenig > wrote: Hi all, I noticed that the term "endpoint name" is used in the IETF RD draft while = the OMA LwM2M spec uses the term "endpoint client name". Endpoint is a conf= using term since it is used differently in the CoAP spec than in the Web en= vironment. For this reason I believe it would be better to use the term "endpoint clie= nt name" also in the RD draft. This would improve alignment between the two= specs. Ciao Hannes 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core 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. 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. 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_VI1PR0801MB2112A692CB307D213A89DFC8FABB0VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jaime,

 <= /p>

Thanks for the pointer to= earlier discussions on this topic.

 <= /p>

Looking at the discussion= s from 2014 it appears that there is some misunderstanding of how this endp= oint name interacts with the security protocol and what vulnerabilities are created by relying on an identifier that is unauthenti= cated.

 <= /p>

I am curious what we lose= if we remove this identifier altogether. The only thing that comes to my m= ind is a debugging capability where you might want to test your system without any security protocol. In any practical deployment I w= ould not recommend to use RD without security.

 <= /p>

Ciao

Hannes<= /p>

 

From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com]
Sent: 05 April 2018 07:52
To: Hannes Tschofenig
Cc: Jim Schaad; core@ietf.org
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hi,

 

You mean we should remove the “endpoint name&#= 8221; altogether, so not using URNs to identify CoAP endpoints for example?=  

 

The rationale for using endpoint name was at least d= iscussed in 2014, back then it seemed useful in the context of LWM2M.<= /o:p>

 

 

Ciao!


El 4 abr 2018, a las 22:01, Hannes Tschofenig <Hannes.Tschofenig@arm.com> escribi=F3:

Hi Jim,

 <= /p>

I had various comments:

 <= /p>

First, I argue that the L= wM2M spec and the RD draft should be in sync regarding the name of the para= meter.

 <= /p>

Second, I believe that th= e security consideration section is correct in the threat description but c= ame to the wrong conclusion regarding the use of the parameter. In essence, the parameter should be optional and probably only used for de= bugging.

 <= /p>

Third, I went as far as s= aying that the endpoint name parameter should actually be removed altogethe= r. I can already see how those deploying it will get it wrong and will introduce security problems.

 <= /p>

Ciao

Hannes<= /p>

 <= /p>

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: 04 April 2018 21:06
To: Hannes Tschofenig; 'Jaime Jim=E9nez'
Cc: core@ietf.org
Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hannes,

 =

I am not completely clea= r.  Are you saying that the RD should not have the endpoint name param= eter as a defined property or something else?

 =

Jim

 =

 =

From: core <c= ore-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 4, 2018 10:41 AM
To: Jaime Jim=E9nez <jaime.jimenez@ericsson.com>
Cc: core@ietf.org WG <core@ietf.org>
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hi Jaime,

 <= /p>

using IP address and port= for an endpoint (client) name would not be a good idea.

In general, it was not a = good idea to have this parameter defined in the first place. It might actua= lly be better to remove it altogether.

 <= /p>

Ciao

Hannes<= /p>

 <= /p>

From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com]
Sent: 04 April 2018 17:32
To: Hannes Tschofenig
Cc: core@ietf.org WG; Carsten B= ormann
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft=

 

Hi,

 

Note that endpoint can refer to both source and dest= ination, being and IP:port in its simplest form: 

 

The fact that LWM2M swaps those role names might act= ually add to the confusion, probably OMA LWM2M should be the one changing t= he terminology as the device is mostly a “server” hosting resou= rces and only is a “client” during bootstrapping and registration. We could have used terms like “servient” ins= tead but it might be too late for that.

 

Ciao!

- - Jaime Jim=E9nez

 

On 4 Apr 2018, at 16.41, Hannes Tschofenig <Hannes.Tschofenig@arm.com> w= rote:

 

Hi all, 

 

I noticed that the term “endpoint= name” is used in the IETF RD draft while the OMA LwM2M spec uses the= term “endpoint client name”. Endpoint is a confusing term sinc= e it is used differently in the CoAP spec than in the Web environment.

 

For this reason I believe it would be b= etter to use the term “endpoint client name” also in the RD dra= ft. This would improve alignment between the two specs.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this= email and any attachments are confidential and may also be privileged. If = you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it f= or any purpose, or store or copy the information in any medium. Thank you. = _______________________________________________
core mailing list
core@iet= f.org
https://www.ietf.org/mailman/listinfo/core<= /o:p>

 

IMPORTANT NOTICE: The contents of this = email and any attachments are confidential and may also be privileged. If y= ou are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it f= or any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

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_VI1PR0801MB2112A692CB307D213A89DFC8FABB0VI1PR0801MB2112_-- From nobody Fri Apr 6 00:33:50 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 3C18712DA3F; Fri, 6 Apr 2018 00:33:48 -0700 (PDT) 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.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152300002819.3723.3466756468518932844@ietfa.amsl.com> Date: Fri, 06 Apr 2018 00:33:48 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-too-many-reqs-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 07:33:48 -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 : Too Many Requests Response Code for the Constrained Application Protocol Author : Ari Keranen Filename : draft-ietf-core-too-many-reqs-00.txt Pages : 4 Date : 2018-04-03 Abstract: A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-00 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 Fri Apr 6 22:08:42 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 6FBBA12420B for ; Fri, 6 Apr 2018 22:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 kXxjKWhhlaH9 for ; Fri, 6 Apr 2018 22:08:37 -0700 (PDT) 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 D79F7124319 for ; Fri, 6 Apr 2018 22:08:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 22:06:18 -0700 From: Jim Schaad To: 'Hannes Tschofenig' CC: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> In-Reply-To: Date: Fri, 6 Apr 2018 22:08:27 -0700 Message-ID: <003501d3ce2e$782cb650$688622f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01D3CDF3.CBD0C480" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGcf25aV3GTfadMlg2+OgOm0/j8CAHJGZYkAVowTP0C25wp5gGJaVBZApB/NY4CPYyHEaQAmi2g X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 07 Apr 2018 05:08:40 -0000 ------=_NextPart_000_0036_01D3CDF3.CBD0C480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hannes, =20 I have been thinking about this both from what you said, but also from = the point of view that I have been trying to figure out how to get security implemented for a resource directory and how to specify the what the set = of legal security options would be for a registration. =20 I agree that it makes no sense for an endpoint registering itself to = provide an endpoint name, this should be inferred from the security context. However, the parameter is needed for third party registrations. If you = have somebody registering a set of end points, the security context might say that you can register any endpoint matching floor3-*=20 =20 My initial idea was to just use the path + queries to control access so =20 /rd/ep-register?ep=3Ddevice1 =20 However, I am now trying to deal with the difference between, if present = it must be this vs if present it must be this, if not present then default = to this. =20 Jim =20 =20 From: Hannes Tschofenig =20 Sent: Thursday, April 5, 2018 3:03 AM To: Jaime Jim=E9nez Cc: Jim Schaad ; core@ietf.org Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hi Jaime,=20 =20 Thanks for the pointer to earlier discussions on this topic.=20 =20 Looking at the discussions from 2014 it appears that there is some misunderstanding of how this endpoint name interacts with the security protocol and what vulnerabilities are created by relying on an = identifier that is unauthenticated.=20 =20 I am curious what we lose if we remove this identifier altogether. The = only thing that comes to my mind is a debugging capability where you might = want to test your system without any security protocol. In any practical deployment I would not recommend to use RD without security. =20 Ciao Hannes =20 From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com]=20 Sent: 05 April 2018 07:52 To: Hannes Tschofenig Cc: Jim Schaad; core@ietf.org =20 Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hi, =20 You mean we should remove the =93endpoint name=94 altogether, so not = using URNs to identify CoAP endpoints for example?=20 =20 The rationale for using endpoint name was at least discussed in 2014, = back then it seemed useful in the context of LWM2M. =20 http://ietf.org/mail-archive/web/core/current/msg05645.html =20 Ciao! El 4 abr 2018, a las 22:01, Hannes Tschofenig > escribi=F3: Hi Jim,=20 =20 I had various comments:=20 =20 First, I argue that the LwM2M spec and the RD draft should be in sync regarding the name of the parameter.=20 =20 Second, I believe that the security consideration section is correct in = the threat description but came to the wrong conclusion regarding the use of = the parameter. In essence, the parameter should be optional and probably = only used for debugging.=20 =20 Third, I went as far as saying that the endpoint name parameter should actually be removed altogether. I can already see how those deploying it will get it wrong and will introduce security problems.=20 =20 Ciao Hannes =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: 04 April 2018 21:06 To: Hannes Tschofenig; 'Jaime Jim=E9nez' Cc: core@ietf.org =20 Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hannes, =20 I am not completely clear. Are you saying that the RD should not have = the endpoint name parameter as a defined property or something else? =20 Jim =20 =20 From: core > On = Behalf Of Hannes Tschofenig Sent: Wednesday, April 4, 2018 10:41 AM To: Jaime Jim=E9nez > Cc: core@ietf.org WG > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hi Jaime,=20 =20 using IP address and port for an endpoint (client) name would not be a = good idea.=20 In general, it was not a good idea to have this parameter defined in the first place. It might actually be better to remove it altogether.=20 =20 Ciao Hannes =20 From: Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.com]=20 Sent: 04 April 2018 17:32 To: Hannes Tschofenig Cc: core@ietf.org WG; Carsten Bormann Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft =20 Hi, =20 Note that endpoint can refer to both source and destination, being and IP:port in its simplest form:=20 https://tools.ietf.org/html/rfc7252#page-6=20 =20 The fact that LWM2M swaps those role names might actually add to the confusion, probably OMA LWM2M should be the one changing the terminology = as the device is mostly a =93server=94 hosting resources and only is a = =93client=94 during bootstrapping and registration. We could have used terms like =93servient=94 instead but it might be too late for that. =20 Ciao! - - Jaime Jim=E9nez =20 On 4 Apr 2018, at 16.41, Hannes Tschofenig > wrote: =20 Hi all,=20 =20 I noticed that the term =93endpoint name=94 is used in the IETF RD draft = while the OMA LwM2M spec uses the term =93endpoint client name=94. Endpoint is = a confusing term since it is used differently in the CoAP spec than in the = Web environment. =20 For this reason I believe it would be better to use the term =93endpoint client name=94 also in the RD draft. This would improve alignment = between the two specs. =20 Ciao Hannes =20 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.=20 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.=20 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.=20 ------=_NextPart_000_0036_01D3CDF3.CBD0C480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hannes,<= /o:p>

 

I have been = thinking about this both from what you said, but also from the point of = view that I have been trying to figure out how to get security = implemented for a resource directory and how to specify the what the set = of legal security options would be for a = registration.

 

I agree that = it makes no sense for an endpoint registering itself to provide an = endpoint name, this should be inferred from the security context.=A0 = However, the parameter is needed for third party registrations.=A0 If = you have somebody registering a set of end points, the security context = might say that you can register any endpoint matching floor3-* =

 

My initial = idea was to just use the path + queries to control access = so

 

/rd/ep-regist= er?ep=3Ddevice1

 

However, I = am now trying to deal with the difference between, if present it must be = this vs if present it must be this, if not present then default to = this.

 

Jim

 

 

From:<= /b> = Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Sent: = Thursday, April 5, 2018 3:03 AM
To: Jaime Jim=E9nez = <jaime.jimenez@ericsson.com>
Cc: Jim Schaad = <ietf@augustcellars.com>; core@ietf.org
Subject: RE: = [core] Endpoint Client Name / Endpoint Name in RD = draft

 

Hi Jaime,

 

Thanks for the pointer to earlier discussions on this topic. =

 

Looking at the discussions from 2014 it appears that there is some = misunderstanding of how this endpoint name interacts with the security = protocol and what vulnerabilities are created by relying on an = identifier that is unauthenticated.

 

I am curious what we lose if we remove this identifier altogether. The = only thing that comes to my mind is a debugging capability where you = might want to test your system without any security protocol. In any = practical deployment I would not recommend to use RD without = security.

 

Ciao

Hannes

 

From: = Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.= com]
Sent: 05 April 2018 07:52
To: Hannes = Tschofenig
Cc: Jim Schaad; core@ietf.org
Subject: Re: = [core] Endpoint Client Name / Endpoint Name in RD draft

 

Hi,

 

You mean we should remove the = “endpoint name” altogether, so not using URNs to identify = CoAP endpoints for example? 

 

The rationale for using endpoint = name was at least discussed in 2014, back then it seemed useful in the = context of LWM2M.

 

 

Ciao!


El 4 abr 2018, a = las 22:01, Hannes Tschofenig <Hannes.Tschofenig@arm.com&g= t; escribi=F3:

Hi Jim,

 

I had various comments:

 

First, I argue that the LwM2M spec and the RD draft should be in sync = regarding the name of the parameter.

 

Second, I believe that the security consideration section is correct in = the threat description but came to the wrong conclusion regarding the = use of the parameter. In essence, the parameter should be optional and = probably only used for debugging.

 

Third, I went as far as saying that the endpoint name parameter should = actually be removed altogether. I can already see how those deploying it = will get it wrong and will introduce security problems.

 

Ciao

Hannes

 

From: Jim = Schaad [mailto:ietf@augustcellars.com]=
Sent: 04 April 2018 21:06
To: Hannes Tschofenig; = 'Jaime Jim=E9nez'
Cc: core@ietf.org
Subject: RE: = [core] Endpoint Client Name / Endpoint Name in RD draft

 

Hannes,

 =

I am not = completely clear.  Are you saying that the RD should not have the = endpoint name parameter as a defined property or something = else?

 =

Jim

 =

 =

From:<= /b> = core <core-bounces@ietf.org> = On Behalf Of Hannes Tschofenig
Sent: Wednesday, April = 4, 2018 10:41 AM
To: Jaime Jim=E9nez <jaime.jimenez@ericsson.com= >
Cc: core@ietf.org WG = <core@ietf.org>
Subject: = Re: [core] Endpoint Client Name / Endpoint Name in RD draft

 

Hi Jaime,

 

using IP address and port for an endpoint (client) name would not be a = good idea.

In general, it was not a good idea to have this parameter defined in = the first place. It might actually be better to remove it altogether. =

 

Ciao

Hannes

 

From: = Jaime Jim=E9nez [mailto:jaime.jimenez@ericsson.= com]
Sent: 04 April 2018 17:32
To: Hannes = Tschofenig
Cc: core@ietf.org WG; Carsten = Bormann
Subject: Re: [core] Endpoint Client Name / Endpoint = Name in RD draft

 

Hi,

 

Note that endpoint can refer to = both source and destination, being and IP:port in its simplest = form: 

 

The fact that LWM2M swaps those = role names might actually add to the confusion, probably OMA LWM2M = should be the one changing the terminology as the device is mostly a = “server” hosting resources and only is a = “client” during bootstrapping and registration. We could = have used terms like “servient” instead but it might be too = late for that.

 

Ciao!

- - Jaime = Jim=E9nez

 

On 4 Apr 2018, at 16.41, Hannes Tschofenig <Hannes.Tschofenig@arm.com&g= t; wrote:

 

Hi all, 

 =

I noticed = that the term “endpoint name” is used in the IETF RD draft = while the OMA LwM2M spec uses the term “endpoint client = name”. Endpoint is a confusing term since it is used differently = in the CoAP spec than in the Web environment.

 =

For this = reason I believe it would be better to use the term “endpoint = client name” also in the RD draft. This would improve alignment = between the two specs.

 =

Ciao

Hannes=

 =

IMPORTANT = NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, = please 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. = _______________________________________________
core mailing = list
core@ietf.org
<= span lang=3DEN-GB>https://www.ietf.org/mailman/listinfo/core<= /p>

 

IMPORTANT = NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, = please 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.

IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please 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. =

IMPORTANT = NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, = please 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. =

------=_NextPart_000_0036_01D3CDF3.CBD0C480-- From nobody Sun Apr 8 00:13:25 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 168981275AB; Sun, 8 Apr 2018 00:13:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: ietf@ietf.org, core@ietf.org, draft-ietf-core-senml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152317159890.1454.8031914033984911996@ietfa.amsl.com> Date: Sun, 08 Apr 2018 00:13:19 -0700 Archived-At: Subject: [core] Genart telechat review of draft-ietf-core-senml-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 07:13:19 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-core-senml-?? Reviewer: Roni Even Review Date: 2018-04-08 IETF LC End Date: 2018-03-30 IESG Telechat date: 2018-04-19 Summary: The document is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: From nobody Mon Apr 9 01:04:21 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 2C3E41242F7 for ; Mon, 9 Apr 2018 01:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 e61MSvwwiraf for ; Mon, 9 Apr 2018 01:04:18 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 825D012D96B for ; Mon, 9 Apr 2018 01:04:09 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:212]) by smtp-cloud8.xs4all.net with ESMTPA id 5RmZf3M2P4EsM5RmZfp9es; Mon, 09 Apr 2018 10:04:07 +0200 Received: from 2001:983:a264:1:c122:b170:5d1e:271e by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 09 Apr 2018 10:04:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Apr 2018 10:04:07 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfMOVFFuEjmfdGsi6Ac7r3ZdkZ1zv7ZuALllg14vc/7gBME9fIWCWYLDh9Av8ktH53DdUDN7h4kGdeurXIEuElHSofqY9x/eGU+PEt5lW1IwmvI4yXLwK LUJwcGglP9ApNzgJFjye9XAqQCd3vcwgN6YEnFgqo0gGJvxkvynN4iVn5D0cqsUDaGPzSs5m2I6DwQ+cwmd91JmRLbJJUYwTkU5XkmvhSp0VrggIe3pyScef ZwATvtboGrjWEvjhYQJiZg== Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 08:04:20 -0000 > > I am curious what we lose if we remove this identifier altogether. The > only thing that comes to my mind is a debugging capability where you > might want to test your system without any security protocol. Hi Hannes, Probably, I completely misunderstand your suggestion. Registrations in the RD need identification so that they can be changed, removed , updated, etc... Registrations are identified by the (ep, d) pair, unique within a given RD. Removing ep identifier will force you to find another identifier for a registration......... and you are back to square 1 it seems. Peter From nobody Mon Apr 9 01:15:06 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 4E6041200C5 for ; Mon, 9 Apr 2018 01:15:03 -0700 (PDT) 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 8jJDaECAV363 for ; Mon, 9 Apr 2018 01:15:00 -0700 (PDT) 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 A458612420B for ; Mon, 9 Apr 2018 01:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w398EttT028379; Mon, 9 Apr 2018 10:14:55 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40KNQ72KBQzDg31; Mon, 9 Apr 2018 10:14:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Mon, 9 Apr 2018 10:14:54 +0200 Cc: Hannes Tschofenig , core@ietf.org X-Mao-Original-Outgoing-Id: 544954493.176299-008c74f805fb43d103d028f68a52dc75 Content-Transfer-Encoding: quoted-printable Message-Id: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com> <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> To: peter van der Stok X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 08:15:03 -0000 On Apr 9, 2018, at 10:04, peter van der Stok wrote: >=20 > Removing ep identifier will force you to find another identifier for a = registration......... I read Hannes=E2=80=99 proposal as =E2=80=9Cserver [RD] always selects = the endpoint name=E2=80=9D (as opposed to what is in section 5.3, where = the client provides an endpoint name). The argument seems to be that if a client holds an authorization to = register at an RD, that authorization may imply a specific endpoint = name. (I=E2=80=99m not sure that is always true, as the authorization = may be based on a claim that does not happen to provide an obvious = candidate for that.) To discuss this further, we=E2=80=99ll need to discuss authorization = models for RD access. Maybe high time in any case=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 9 08:37:21 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 2C0E41270A3 for ; Mon, 9 Apr 2018 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ubloxcom.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 Oud9EN5aapvS for ; Mon, 9 Apr 2018 08:37:18 -0700 (PDT) Received: from buffalo.u-blox.com (buffalo.u-blox.com [195.34.89.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5BC124BE8 for ; Mon, 9 Apr 2018 08:37:17 -0700 (PDT) Received: from mail_filter (localhost [127.0.0.1]) by buffalo.u-blox.com (PF_LO_10026) with ESMTP id 1660539E51 for ; Mon, 9 Apr 2018 17:37:14 +0200 (CEST) Received: from ASSP.nospam (localhost [127.0.0.1]) by buffalo.u-blox.com (Postfix) with ESMTP id D656439E31; Mon, 9 Apr 2018 17:37:13 +0200 (CEST) Received: from unknown ([127.0.0.1] helo=anyhost.local) by ASSP.nospam with SMTP (2.4.7); 9 Apr 2018 17:37:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ubloxcom.onmicrosoft.com; s=selector1-ublox-com0c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8duTqIHQl+UHoQaeUEEsL5p8/LibX9lsgU7m4sup0iE=; b=j2FR6A+BALSNYQgc7aQt5d5VG15O0nb8Oww72c2zRVrGf/J/N3qn8ujUYQDisfSfbBJ2LGINv9xNEydYVGWXDkvSQmKl8pyDT0LLIu9MQXthVfEy20DOUMVFrpp3OfClPxC+o+A1HLL3ellYmnSl+jZyzHxIXXtcsT0UUDIxIvk= From: Mojan Mohajer To: "core@ietf.org" CC: "bilhanan.silverajan@tut.fi" , "michael.koster@smartthings.com" Thread-Topic: [core] Questions and comments on draft-ietf-core-dynlink-05 Thread-Index: AdPQFGdEbuEZvhPPRhWOwr69wAGFiA== Date: Mon, 9 Apr 2018 15:37:12 +0000 Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mojan.Mohajer@u-blox.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P12301MB1521; 7:V4y57TtCPtbyotI/5l981Az6EGazokVR+HLFI0WIdbJya1Z+CkfFzg8ytF4wI2/tqEk/VDMejD/CtC/AHNx7Cv5nca8eQsU/APQ51UBIaN0YbkoqShaKsMHwyZvtom8uPKdJ9+FtRMP2siX8Nbp8tQoon3ylrWIl17rP2obQobgC9YBz6Vu1qoF1JOq6zqFTB/Lv+qrIG5qL7S63TJWIEXoEKB/aRYyYCbpE35OJ1T8zOydXbQME8wvkF2rx+Kjd x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 4b759c3e-23e6-4e45-b247-08d59e2fc383 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603328)(7153060)(7193020); SRVR:LO1P12301MB1521; x-ms-traffictypediagnostic: LO1P12301MB1521: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(3002001)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:LO1P12301MB1521; BCL:0; PCL:0; RULEID:; SRVR:LO1P12301MB1521; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39850400004)(376002)(396003)(39380400002)(346002)(25584004)(199004)(189003)(53754006)(4326008)(8676002)(5640700003)(2900100001)(55016002)(53936002)(9686003)(33656002)(2351001)(6436002)(74316002)(305945005)(6916009)(105586002)(68736007)(81166006)(81156014)(476003)(97736004)(5660300001)(106356001)(2906002)(99286004)(3280700002)(72206003)(5250100002)(5890100001)(2501003)(7696005)(1857600001)(478600001)(3660700001)(14454004)(186003)(26005)(486006)(8936002)(59450400001)(1730700003)(86362001)(6506007)(316002)(102836004)(25786009)(54906003)(4743002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P12301MB1521; H:LO1P12301MB1587.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: u-blox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Y6d1GJUbdfkYm6VCyXzydD5NSjalfCNynp9aTb8tbF8dSoaOQ76W08VZoaKa7h66RmU/XL30P+6JRTVX2/JAXipNV6AwP6ssMpcj+7AlvpeKS9wdR8IGoCRgkjgjOw0cI7rPXMGyIczRLtKK293Yc5ZbrG4sgo4vhodoPxIvV9dtwjTC3ObZoMjIk+Cv45u3ZOXJmU06kb48D7+OHlyOv4nBNJLKdCno/0jzSRx8gIzPAJbwBXvvKT4DsEFww9glUyOLLEzr2HP9CqCmM+s5nLIYqISMbReRUbEuU3OIWs5mRiML9LTblb5HhZlA70+sucPDk7mZifnS/98Lxrw/5mbeV2xKRuLPN0kVOVaQvkpNoDhItbpIkdn6WDjTsuNELck/kiWdykgrt9lb5+Qh3TPteDn/qPlH89r7UO2Itkc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4b759c3e-23e6-4e45-b247-08d59e2fc383 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 15:37:12.3007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 80c4ffa6-7511-4bba-9f03-e5872a660c9b X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P12301MB1521 X-OriginatorOrg: u-blox.com X-Assp-Version: 2.4.7(16004) on ASSP.nospam X-Assp-ID: ASSP.nospam 88233-26884 X-Assp-Session: 14591F0 (mail 1) X-Assp-Original-Subject: [core] Questions and comments on draft-ietf-core-dynlink-05 X-Assp-Client-TLS: yes X-Virus-Scanned: clamav-milter 0.99.4 at buffalo X-Virus-Status: Clean Archived-At: Subject: [core] Questions and comments on draft-ietf-core-dynlink-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 09 Apr 2018 15:37:20 -0000 Hi all, Having read through dynlink draft, have few questions and comments that are= listed below: 1) As per section 3, binding entry is unidirectional and only present on on= e end point. So, the question arises as to what does a binding entry consis= t of and whether it also includes binding attributes? If that is the case, = not sure how this applies when the binding method is Observe? For Observe t= he binding method will be at destination as per Table 1, while the binding = attributes should also be know at the source end. 2) Initial synchronisation with poll and observe methods are under control = of destination which can decide when it is ready to start the synchronisati= on process. However, with the push method this seems to be left entirely to= source as to when the synchronisation starts. If the binding table is pre = provisioned through a commissioning tool as suggested in section3, then how= can the source determine when to start synchronisation process? 3) As currently stated when pmin and/or pmax are not present the elapsed ti= me between two state synchronisations are left to the synchronisation initi= ator. For interoperability purposes it may be worth being more prescriptive= as is the case in LwM2M. For example in LwM2M when pmax is not present it'= s taken to have infinite value and when pmin is absent it's taken to be 0, = i.e. there is no time restriction between two consecutive synchronisations = if other conditions are met. 4) As per 3.3.8 if "st" is included with "gt" or "lt" attributes the AND op= erator is used when evaluating synchronisation condition, e.g. "st" AND "gt= ", "st" AND "lt", etc. Unfortunately LwM2M uses OR operation in such evalua= tion. There are valid use cases for both approaches. But it would be nice t= o settle on a common one or maybe consider having yet another attribute to = specify the operation. Admittedly this last suggestion could be a step too = far. 5) The note in section 3.3.8 quite reasonably suggests the use of notificat= ion band min or max for synchronisation on a resource value change. This a= gain is somewhat different to LwM2M where an observe on a resource without = specifying any of the attributes such as gt, lt, pmin, pmax, etc. is used t= o achieve the same result. If acceptable it may be worth extending the note= listing LwM2M approach as another option?=20 6) Introduction section indicates Observe Attributes can either be used wit= h Link Bindings or standalone Observe as in RFC7641. However, section 4.2 i= ndicates that the query string parameters or observe attributes defined in = this draft have to be set up through a PUT method beforehand. At the same t= ime examples in Appendix A reinforce the statement in the introduction whil= e example in 4.1 sets up these attributes when creating a binding through P= OST. LwM2M uses PUT to set up these attributes which effectively attach the= attributes to the resource. But it seems these attributes should logically= belong to a particular binding rather than an individual resource on its o= wn. That is if a resource appears in more than one binding to other resourc= es it could have different set of attributes in each binding entry? At the = same time an Observe with uri-query options specifying these attributes as = per Appendix A could be considered as implicit an binding that is still con= forming to the rule of attributes being attached to a binding as opposed to= an individual resource.=20 Best Regards, Mojan From nobody Thu Apr 12 04:05:19 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 0B8FF1200FC for ; Thu, 12 Apr 2018 04:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-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 4omO5kMFWnGu for ; Thu, 12 Apr 2018 04:05:10 -0700 (PDT) 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 B53A6126C19 for ; Thu, 12 Apr 2018 04:05:09 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 204F64977A for ; Thu, 12 Apr 2018 13:05:05 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3370117C for ; Thu, 12 Apr 2018 13:05:03 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E2D1B31 for ; Thu, 12 Apr 2018 13:05:02 +0200 (CEST) Received: (nullmailer pid 22909 invoked by uid 1000); Thu, 12 Apr 2018 11:04:56 -0000 Date: Thu, 12 Apr 2018 13:04:56 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Message-ID: <20180412110455.GA20765@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [core] Wild suggestion for observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2018 11:05:18 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE WG, observation is being discussed in the context of OSCORE[1], and without overloading that thread, I'd like to run a suggestion by you: Can we generalize Observe a bit to cover non-safe cases? To summarize, observe was originally specified for GET in RFC7641 and then later allowed for FETCH in RFC8132 without really saying much, especially about Block1 that came with that. There have been cases where it would be neat to observe outputs of POSTs too (AFAIR Peter had one, OSCORE would be simpler too, and there was some other in London I don't remember). Proposal: * Observe can be used with all currently specified methods. * For re-registration of interest in the restul of a non-safe operation, the Observe value of the request is 2 ("reregister"). Servers process a reregister just as regular registration, but can only respond if they recognize it as a reregistration, and MUST NOT act on it again. If they don't recognize it, they respond with 4.xx What Are You Talking About. (There's no way to recover from that on the protocol level; that's left to the application). * This is well compatible with existing intermediaries, they'll just go 4.02 Bad Option when they see a client trying to observe a POST, just as they would if they didn't do observation at all. * Applications can use reregister on safe operations too, but really why should they, it only trips off older proxies. (One could consider adding an Observe:3 "deregister-nodo" here that allows a client to stop a registration w/o risking that the operation might be done again when sending Observe:1; frankly, I don't think I'll ever send Observe:1 as GET / No-Response:at-all with the same token is just as good.) That's not really something I want to put on my agenda, but as it popped up a few times in London and now again: Here's how I'd go about it. Best regards Christian --- Bonus content: GoldenEye's traceroute scene as expressed with this extension: POST /traceroute Payload: Find the GoldenEye control center! Observe:0 2.05 Content, Observe:10, Payload: He's not in Russia... 2.05 Content, Observe:20, Payload: He's not in Germany... (Simonova gets impatient:) POST /traceroute Payload: Find the GoldenEye control center! Observe: 2 2.05 Content, Observe:21, Payload: He's still not in Germany... 2.05 Content, Observe: 30, Payload: He's not in New York, Toronto, Chicago, San Francisco 2.05 Content, Observe: 40, Max-Age: large, Payload: He's in Cuba. [1]: https://github.com/core-wg/oscoap/issues/223 --=20 Ceterum censeo RFC6690 esse revidendam. --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrPPVMACgkQOY0REtOk veGnHRAAmI545ssNqO/Cq1zYs3yq18++ypNBtYCqmPP4rLtV1xjDNFgScbHrlnp+ p4aGUzlXuta4WFGQnyt1BJqfrIzZLTenCcAA/WuybLBn7p7cqEvicIjnZP7S0t5R kx1GctEJ9C/GV/uRBPcb/pFO+JLBWnVBXbZL6Pz0wrTDVDq8upFpiLYAY6HnmOC1 Y/x9A85k06mswBTJ2Hc41umj+EEQRYRWOyy3Al2v58MrKnOzu823pqAwNLMkA4DI GEeGticgUKJPW0x6+w1TjqOq8UbQBE8W1K9I+xrfSC4YRjpKG7g438qAKqJCZ/qL W5t9Fbed6yhc8+vyPgoOJYEj9M65xDxJT/ymncgofnkbFjdG3NmAcAV1fjoB8/Q2 AHbD3tNtuOXLVR79VGuRZVdm1jvBTcpBZqn+ZJB1k+FtF0aQoYGriyqcC6jErDN5 YUKzeXa2oaiDL3pcZJROGO6YdZiRql6s1xbGIbhX4Q663zw5lJlUJOiKz0yaWIB6 KzelXx5SNdmvTFU41X0z68qxzQxWHUGrr0xoqm+ibA8W4LPG8Br+OcgFIyvVRFQo FlXkHVERxNg/FL1uKf/NFpozwMyZDM69QXS4RL/zEhPpDxz8Ele2ln8k5V4nrOBg b0gHqD/k7IeBzUKOP0m6dD//m7lSI0kEqMLhU6AbZVhg4lo+54I= =142W -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From nobody Thu Apr 12 04:31: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 B5F1B12025C for ; Thu, 12 Apr 2018 04:31:55 -0700 (PDT) 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 k26mW8aijV_X for ; Thu, 12 Apr 2018 04:31:53 -0700 (PDT) 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 6F78B1200F1 for ; Thu, 12 Apr 2018 04:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3CBVnJ2010823; Thu, 12 Apr 2018 13:31:49 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40MJdx3byVzDX2S; Thu, 12 Apr 2018 13:31:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180412110455.GA20765@hephaistos.amsuess.com> Date: Thu, 12 Apr 2018 13:31:48 +0200 Cc: Core WG mailing list X-Mao-Original-Outgoing-Id: 545225507.452818-0f3e0c6fc298f5c15bda5cd7c83ebd5e Content-Transfer-Encoding: quoted-printable Message-Id: <914708A1-8C9F-4201-9579-18AE2A6C6BF7@tzi.org> References: <20180412110455.GA20765@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Wild suggestion for observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2018 11:31:56 -0000 Hmm. We normally observe resources, with the server sending a fresh = representation when that has changed. What you are proposing means observing the change of a result of a = non-idempotent action that was done once if it were done again but = isn=E2=80=99t (!?). Not sure I=E2=80=99m completely following. The REST way of doing that would be to create a resource on the POST for = the result, and then observe that in a separate request. If that is too heavy, maybe it would be a better way to streamline that = a bit? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 12 05:55:03 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 B0506126579 for ; Thu, 12 Apr 2018 05:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SBqnJ3O08gsE for ; Thu, 12 Apr 2018 05:54:59 -0700 (PDT) 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 1507E124207 for ; Thu, 12 Apr 2018 05:54:58 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B47BE4977A; Thu, 12 Apr 2018 14:54:56 +0200 (CEST) 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 EF5CE17C; Thu, 12 Apr 2018 14:54:54 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9FF1C31; Thu, 12 Apr 2018 14:54:54 +0200 (CEST) Received: (nullmailer pid 27849 invoked by uid 1000); Thu, 12 Apr 2018 12:54:49 -0000 Date: Thu, 12 Apr 2018 14:54:49 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: Core WG mailing list Message-ID: <20180412125448.GG18144@hephaistos.amsuess.com> References: <20180412110455.GA20765@hephaistos.amsuess.com> <914708A1-8C9F-4201-9579-18AE2A6C6BF7@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zrag5V6pnZGjLKiw" Content-Disposition: inline In-Reply-To: <914708A1-8C9F-4201-9579-18AE2A6C6BF7@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Wild suggestion for observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2018 12:55:02 -0000 --Zrag5V6pnZGjLKiw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2018 at 01:31:48PM +0200, Carsten Bormann wrote: > Hmm. We normally observe resources, with the server sending a fresh > representation when that has changed. Yes, and from that PoV, what I'm suggesting is undue. That boundary has IMO been crossed already with FETCH being observable (several observations can run on the same resource and give different results), so this would be the continuation of that line of thought. > What you are proposing means observing the change of a result of a > non-idempotent action that was done once if it were done again but > isn=E2=80=99t (!?). Not sure I=E2=80=99m completely following. Not "if it was done again". As I understand resources and representations, the response body of a POST is not a representation of the resource POSTed to, but a representation of an anonymous, short-lived resource(-ish thing?) that has no address and a short lifetime but might have a representation. An observation on that would give the client various representations of that thing as it evolves during its short lifetime. > The REST way of doing that would be to create a resource on the POST > for the result, and then observe that in a separate request. If that > is too heavy, maybe it would be a better way to streamline that a bit? I do agree that this is what should happen in many cases; and if the outcome of this thread is that all cases where an observable POST would be needed are better covered with POST->Location & observe that, it's perfectly fine with me. (Bonus points if we can streamline that). I don't remember why in Peter's (or was it Jim? that would have been the thread at [1], then) case that was not a viable option. In OSCORE, we're transporting an observation but hiding the method, so everything becomes a meaningless POST; going via a Location would take much of the streamlining out of it. That it's allowed for FETCH just provided an easy way out there, so we're now sending every observation in a FETCH (even though the OSCORE request is not fully side-effect free, and we have to make amends due to that, but it seems to work). But yes: Saying "If you want to Observe POST (or anything else but GET), rather POST with a Location, GET that and DELETE it when it looks done" can be a valid answer too (just one that won't make it into OSCORE). Thanks for your input Christian [1]: https://mailarchive.ietf.org/arch/msg/core/40WH27Y0-QgbjJ5GWxjios3Xkj8 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Zrag5V6pnZGjLKiw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrPVxUACgkQOY0REtOk veEhMw//QBBiuTd0yazDho/DCpZdBGwWu+Nk83FZGxPa6AQlUiRaV1ycNlk/vU/C 28fvJILaqtsIbWXV61gJd0m8b4f6R+NXYgL1zjtkg9sJLG5BmIEi4oQt5oJHYk7c dagQMCfdTPS6XH7QY1vBmR6/+9W5G+CkQfW2XOd0YkcYfTjBsvQMgVsHFVkN4QVW vMzdp7bX09VhIEHAuBGxFE17oPcpaSgO2Ft+v2R2Fg+k/ZXYIhdw92ehZhzmfVlR QFL96ygYc4qY2i7qhjCZA17fCjEiAIeBFxQMiYT6XiulUGdE9JGy57hNaMO3bDWx bHdYJhjYWWLwiOXp00/TXc7b0LvGH8ebstqyshzXEW3rMYUrxv2kxPeToWZ7DfYm L1YBPlAWLSDZtxM4whmtie6OI95qWSVpFf4fKoQIm1eNdxQ8MDIlCffkJ/5Nt+4n k2d6f26Bc2rDBml6eJro3tGS+9YWIzMSo2OywvZGA1tigmVGdwY4kE87JJe8nKc8 2T7/yHiU20wSLNi/N/vLiAd/muVj/FM60ZNwZO8GteJLHpUjr4go/Q7cAaTSq7gb aczWr+yidVvTwFhbza0rxgYi/jq3hFaPTDzNv40KEK5nsVMXVLsORbqgiVIgbuLg DdtDCrf3vmvOxFVAeaZ3d1qNOlJMsGhHRWLRrNqfMl9rwlX7VsM= =WskP -----END PGP SIGNATURE----- --Zrag5V6pnZGjLKiw-- From nobody Thu Apr 12 14:12:09 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 EA4C412DA12; Thu, 12 Apr 2018 14:12:07 -0700 (PDT) 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 gbqi4L0wuega; Thu, 12 Apr 2018 14:12:05 -0700 (PDT) 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 4EC5212D941; Thu, 12 Apr 2018 14:12:04 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D357F49784; Thu, 12 Apr 2018 23:12:02 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id CC62B17C; Thu, 12 Apr 2018 23:12:01 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8B73641; Thu, 12 Apr 2018 23:12:01 +0200 (CEST) Received: (nullmailer pid 5265 invoked by uid 1000); Thu, 12 Apr 2018 21:12:00 -0000 Date: Thu, 12 Apr 2018 23:12:00 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core WG mailing list Cc: DNSSD WG mailing list , Ivaylo Petrov , Jim Schaad , Hauke Petersen Message-ID: <20180412211159.GB20765@hephaistos.amsuess.com> References: <20180322144452.GA13008@hephaistos.amsuess.com> <20180322150452.GA17015@hephaistos.amsuess.com> <20180403082122.GA30478@hephaistos.amsuess.com> <20180411103951.GC14388@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <20180411103951.GC14388@hephaistos.amsuess.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2018 21:12:08 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, we have had a successful plug test in two sessions on Tuesday with a total of 4 implementors[1], 3 resource directories and 7 endpoints (counting full and simple endpoints independently), thereof 2 (one full endpoint, one simple endpoint) on embedded (class C2) systems. Most endpoints could register right away once configured properly, and be looked up by other parties. Issues we encountered were: * Problems from lower layers[2] * Various implementation bugs (programming errors, non-intuitive configuration) Most of these could be fixed ad-hoc by the participants. * Incomplete implementations of RD functionality * Lookup: One server has not yet implemented support for arbitrary registration attributes at the lookup side, and only supports querying for known parameters without wildcards; this was a known limitation of this work-in-progress implementation. * Lookup: The requirements of -13 to have absolute references in both the href and anchor of resource lookup has only been implemented on one server. This was probably due to authors having carried over the behavior from earlier draft versions. * Discovery: The embedded endpoint implementation did not implement the discovery step but needed to be configured with a full registration URI. * Only little unclear parts in the current RD draft * May a con=3D argument be present in a simple registration? (Probably not, though this precludes simple registration over TCP). * Can there be a Location-Query option in a registration response? (Probably not, we just didn't say that.) * Can a con=3D have query parameters? (Certainly not intended, it just didn't even occur to anyone before.) Those parts are being fed into the process of refinding the resource-directory document, in parallel to the other input we've been receiving. All tested endpoints could register on the servers they were tested against[3]. Endpoints for full registration did registration, updates and removal of registrations (where supported; some endpoints (esp. the embedded one) chose not to implement updates or removal). We found the resources advertised by the endpoints in the resource looup interfaces using the supported media types (application/link-format for all involved, +cbor and +json where supported). One of the registering endpoints has not seen any updates since at least -11; that did not impede its ability to register. All things considered, we regard these first tests as successful. Topics we would like to explore in a future second round of this plug test: * see whether all participants can implent their missing features (esp., see how well full URI discovery works from embedded systems) * extensions to the RD (RD-DNS-SD, distributed RDs) * groups (those are only supported by one implementation so far) * actually accessing the advertised resources Best regards Christian --=20 Ceterum censeo RFC6690 esse revidendam. [1]: Test participants were Jim Schaad, Ivaylo Petrov (with ackl.io's resource directory), Hauke Petersen (with endpoints implemented on RIOT) and Christian Ams=FCss (with aiocoap) [2]: In detail, those were: * Production and parsing of invalid RFC6690 (which link attributes need to be quoted, trailing commas, parsers expecting a '=3D' after 'obs') * Errors on CoAP level (NON vs. ACK, Accept ignored) * URIs needing explicit port values * Incompatible TLS implementations (two participants have basic support for CoAP over TLS, but with disjoint authentication options) * Routing / name resolution problems Those problems were understood (with the help of the respective specifications, where needed), and are worked on by the authors. I've seen a similar class of issues during the OSCORE plug tests. We might consider collaborating on building a test suite for some of those so that future implementors can self-test their ground work during development. [3]: Not all were tested against all due to a timezone mismatch that caused the test to be split in two sessions. --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrPy5cACgkQOY0REtOk veFP5w//b9h8l1jHh3y5gv+OTjf1aAG8Dsdd7sKKpwdPlexKmoTa1L53OcOCDvjB F8EtchN7hifkN207RxcIJpK1IxhrKpNShQY0OfwPgcNkNxLPASILngaOyGn9aLWH RaiYVz3thtki7xFUNj1fep2134V5h6kwz+KhyGZObp7y/oa3aiSTOXxSz6/RR5ue 50hIfRyGro/Oy46d2Es4o1fIGKHGVtnHbg6Zl9/w9+xga1ilDOBqw3QfihZRVFkX DtasA8rlL53R5UWVaofEqKmd0Q5w/ceW+6sYRsXzkgf+jf7eaeguXlREEkopyWU9 TkCRpfT7KUrmCR3iNEUkvWdpTe9MEpllKBK+XO6cjYM0ulfWeonAJOTUeBPfiMDr 63Mam3Z88a0/k3VLMmDDfM28O0MBVWKb6OihFoTDoKEeXJS+BmeQxFI/ZDvyJSeC 0aal0iD/bOss3gRagwGIKznk33bWfUZKNjTatzBseEAUSKLplbm/3gU5WXoPTgtb z6QzNhovSPqWjTd1J3EFzdZj5UZdb4bAzWPnqAZwat1sfjDMAO+iAFxw6m6fJram 6Hv+v85ydoWmjp1w+KAHgBmkTbNKQE3jiIBT1PFFL9Yf/dffsyvElvXVW67nmNVC bRtZ9uFZCK76vGNI3qDDzuEKvc5VOoyiFF0ZPnyFisCkfp1iugw= =3xV2 -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- From nobody Fri Apr 13 00:04:42 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 2636F127058; Fri, 13 Apr 2018 00:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 iDvaHbrHHhMd; Fri, 13 Apr 2018 00:04:36 -0700 (PDT) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 27BAA126D45; Fri, 13 Apr 2018 00:04:36 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud9.xs4all.net with ESMTPA id 6sl7f2MyELWCh6sl7fuH8v; Fri, 13 Apr 2018 09:04:34 +0200 Received: from 2001:983:a264:1:5054:a506:ff38:f4d9 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 13 Apr 2018 09:04:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 13 Apr 2018 09:04:33 +0200 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Core WG mailing list , DNSSD WG mailing list Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20180412211159.GB20765@hephaistos.amsuess.com> References: <20180322144452.GA13008@hephaistos.amsuess.com> <20180322150452.GA17015@hephaistos.amsuess.com> <20180403082122.GA30478@hephaistos.amsuess.com> <20180411103951.GC14388@hephaistos.amsuess.com> <20180412211159.GB20765@hephaistos.amsuess.com> Message-ID: <04f1581cff70df7435428bffc5ef0755@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfII8k773Ntga9b+7HCfDvobgG9z7v0QYmKQuuDxkomcAucNa2juGJRolelgWgb9x6/+w4dQPakNHC0LAxrvhsQWbZsl2+qaoVI6o5uTsYw+DVMAVOvzE HOgO2MQ6bMA4XvyheSC0LvAD+6IqCoPMPLShNzIwa8f2gz9XEGvGEsPYqhDxwoq/uF27cXYAadlxRxfxXXr12v3EBx+B7I0Q0N73LXuwmqoyuswg30wWn82V W1dvfsCwYw+40YU+mb+nBQ== Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 07:04:40 -0000 Hi Christian, thanks for this very useful work Some questions/ remarks below. > * Only little unclear parts in the current RD draft > > * May a con= argument be present in a simple registration? (Probably > not, though this precludes simple registration over TCP). certainly not; it beats the purpose. We may add text in RD to address the TCP part. > > * Can there be a Location-Query option in a registration response? > (Probably not, we just didn't say that.) to what purpose? > > * Can a con= have query parameters? (Certainly not intended, it just > didn't even occur to anyone before.) It states explicitly that it is a scheme//authority string, no query parameters possible; The simplicity helps to specify an already complex subject > > Those parts are being fed into the process of refining the > resource-directory document, in parallel to the other input we've > been > receiving. to be filled into the github, I hope. > From nobody Fri Apr 13 00:14: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 85BD7127337 for ; Fri, 13 Apr 2018 00:14:35 -0700 (PDT) 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 GmlCgLnKCEPu for ; Fri, 13 Apr 2018 00:14:32 -0700 (PDT) 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 12EC212711A for ; Fri, 13 Apr 2018 00:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3D7ESvv008505; Fri, 13 Apr 2018 09:14:28 +0200 (CEST) Received: from [192.168.217.102] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40MptX3n9mzDXCs; Fri, 13 Apr 2018 09:14:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180412211159.GB20765@hephaistos.amsuess.com> Date: Fri, 13 Apr 2018 09:14:27 +0200 Cc: Core WG mailing list X-Mao-Original-Outgoing-Id: 545296465.678485-ac7f197246017cc4be57bb369d0c4de1 Content-Transfer-Encoding: quoted-printable Message-Id: <9D3CBCEA-C563-4B55-B018-C134B3F023B4@tzi.org> References: <20180322144452.GA13008@hephaistos.amsuess.com> <20180322150452.GA17015@hephaistos.amsuess.com> <20180403082122.GA30478@hephaistos.amsuess.com> <20180411103951.GC14388@hephaistos.amsuess.com> <20180412211159.GB20765@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 07:14:36 -0000 Hi Christian, this is great input. Let me pick out two items here: > * Can there be a Location-Query option in a registration response? > (Probably not, we just didn=E2=80=99t say that.) Why not? (Sorry, I missed out on responding to Jim=E2=80=99s earlier message on = this. I=E2=80=99m trying to find out why we need to restrict the server=E2=80=99= s flexibility in choosing the URI here. Maybe there is a good reason, I=E2=80=99d just like it to be more = explicitly stated.) > Ceterum censeo RFC6690 esse revidendam. Well, the general feeling was that instead of going for a 6690bis, we = maybe want to let the link-format just fade out (In favor of = links-json/-cbor). > * Production and parsing of invalid RFC6690 (which link attributes > need to be quoted,=20 Right. I think we really should be following RFC 8288 here and asking = implementations to be robust to the misguided =E2=80=9Cthis attribute = needs to be quoted=E2=80=9D decisions we made in RFC 6690. Maybe we can put a few updates to 6690 in links-json? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 13 04:03:21 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 E8EB2126B6D for ; Fri, 13 Apr 2018 04:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 5u-Ppb_Oo8Ob for ; Fri, 13 Apr 2018 04:03:16 -0700 (PDT) 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 8DFAE1252BA for ; Fri, 13 Apr 2018 04:03:16 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5158F49784; Fri, 13 Apr 2018 13:03:14 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 151C674; Fri, 13 Apr 2018 13:03:04 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 337B031; Fri, 13 Apr 2018 13:03:04 +0200 (CEST) Received: (nullmailer pid 19929 invoked by uid 1000); Fri, 13 Apr 2018 11:03:02 -0000 Date: Fri, 13 Apr 2018 13:03:02 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: consultancy@vanderstok.org, Carsten Bormann , Jim Schaad Cc: Core WG mailing list Message-ID: <20180413110301.GL18144@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cy9Nn4fUvYST66Pl" Content-Disposition: inline In-Reply-To: <9D3CBCEA-C563-4B55-B018-C134B3F023B4@tzi.org> <04f1581cff70df7435428bffc5ef0755@xs4all.nl> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 11:03:19 -0000 --cy9Nn4fUvYST66Pl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Peter, Carsten, hello Jim (responding cross-thread to the Location-Query point), (removing DNS-SD from the thread because I do not expect those topics to be particularly interesting there) On Fri, Apr 13, 2018 at 09:04:33AM +0200, peter van der Stok wrote: > to be filled into the github, I hope. yes, as I am finally going thorough the existing issues and changes. On Fri, Apr 13, 2018 at 09:14:27AM +0200, Carsten Bormann wrote: > > * Can there be a Location-Query option in a registration response? > > (Probably not, we just didn=E2=80=99t say that.) >=20 > Why not? > (Sorry, I missed out on responding to Jim=E2=80=99s earlier message on th= is. > I=E2=80=99m trying to find out why we need to restrict the server=E2=80= =99s flexibility in choosing the URI here. > Maybe there is a good reason, I=E2=80=99d just like it to be more explici= tly stated.) The good reason is that we are using URI templates in the registration update operation: {+location}{?lt,con,extra-attrs*} While it should be intuitively obvious that for location=3D"x://y/z?a=3Db" and lt=3D"42", the produced URI is "x://y/z?a=3Db<=3D42", RFC6570 Section 3.2.8 does not describe peeking back at what has been expanded to the left side, but prescribes a "?" to be used before the first value, so the produced URI would be "x://y/z?a=3Db?lt=3D42" (or possibly ?a=3Db%3Flt= =3D42 but not ?a=3Db<=3D42). If I'm reading RFC6570 wrong here, Location-Path can be allowed and I'd be happy. Otherwise, we have to choose between using formal URI templates here (vs. saying that some query parameters can be appended) and allowing Location-Query. (Requiring anyone to understand ?foo=3Dbar?baz=3Dqux as two keyswould be madness so it's not an option.) > > Ceterum censeo RFC6690 esse revidendam. >=20 > Well, the general feeling was that instead of going for a 6690bis, we > maybe want to let the link-format just fade out (In favor of > links-json/-cbor). link-json/-cbor is not helping with the issue of [1]. Whoever receives a link-format+json document and wants to follow a link given there needs to take the href and the anchor, and look up in RFC6690 Section 2.1, which is the very root of my misgivings about the situation. [1]: https://mailarchive.ietf.org/arch/msg/core/LS0ccxtH8nEVuy73iZoRkkfBpmw > > * Production and parsing of invalid RFC6690 (which link attributes > > need to be quoted,=20 >=20 > Right. I think we really should be following RFC 8288 here and asking > implementations to be robust to the misguided =E2=80=9Cthis attribute nee= ds to > be quoted=E2=80=9D decisions we made in RFC 6690. >=20 > Maybe we can put a few updates to 6690 in links-json? I don't know from a procedural PoV -- can we? And how far can that go? Best regards Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --cy9Nn4fUvYST66Pl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrQjmIACgkQOY0REtOk veGc6g//Qt/np5ZW6NdRwslLKTbAr0ly+gX1dC8zlU/5hnL55YRXgmZtgCt2RwpN Q9EENxYVaTchKPFguf8fd+/w3QqXe0TbVabm8BcLNr2ld2kIRlGoYOH9kPJoASeA V7kvC3zJb1vQLFuV4qkcYYmUTcvfY6+XddMGTUnzdrAo4HpYkB51oy/Rl1DosIhS iurYUhbu/jZCtRN1mpL+Zu0O+GzzIsypEvgl6y9P8wW4R2SYunL0kEEAwe7WB2/R Z07NAKPMTKwlaRb/+UCWEPhzBYLIvas1wQCK1Yw6DJR+HPdX2+k6ls8uUHiUCkRj AAmz6vGygJM1nZM3JE8iyv+uNOwaI7/Mm5ZYyNy7wICUidG3DU5ZeMTqYVL472yF z37g44jkf/hl520Xqu8qnpEYpfsXibXAEP+IxoFchMHZjcxChggXwdizXIzWNUGp HII6YSPWCjWq4ilN1b835SXa+Lxf35cgt1kY5b/udlX2A9wDXYTXGSVbpeZuG3hV Opt7x7Hjos5/XqoWp6T5KwZ6KnDBjmSB/2dnR1N7JsqdDFjnwHZ+Creycm0/Kuml 17mGwZYQQoMAbKWBU3YRji3+bDSpSmrDVYldZaImhCPX1+SEz2P3iUjMiAFqnqYS xtcMNUsXeI5/KW9a3rpw12j7dMhix1sTUn5LquV+2CRtVn6VWqY= =BuIj -----END PGP SIGNATURE----- --cy9Nn4fUvYST66Pl-- From nobody Fri Apr 13 06:01:56 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 D102E120454 for ; Fri, 13 Apr 2018 06:01:55 -0700 (PDT) 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 EIRGCe9zxlro for ; Fri, 13 Apr 2018 06:01:48 -0700 (PDT) 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 1EB531200C1 for ; Fri, 13 Apr 2018 06:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3DD16Gl022463; Fri, 13 Apr 2018 15:01:06 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40MyZV2hkrzDXJM; Fri, 13 Apr 2018 15:01:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180413110301.GL18144@hephaistos.amsuess.com> Date: Fri, 13 Apr 2018 15:01:05 +0200 Cc: peter van der Stok , Jim Schaad , Core WG mailing list X-Mao-Original-Outgoing-Id: 545317263.971565-b48949272d5ca51101d1a649abf93fc9 Content-Transfer-Encoding: quoted-printable Message-Id: <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> References: <20180413110301.GL18144@hephaistos.amsuess.com> To: =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 13:01:56 -0000 On Apr 13, 2018, at 13:03, Christian M. Ams=C3=BCss = wrote: >=20 > Hello Peter, Carsten, > hello Jim (responding cross-thread to the Location-Query point), >=20 > (removing DNS-SD from the thread because I do not expect those topics = to > be particularly interesting there) >=20 > On Fri, Apr 13, 2018 at 09:04:33AM +0200, peter van der Stok wrote: >> to be filled into the github, I hope. >=20 > yes, as I am finally going thorough the existing issues and changes. >=20 > On Fri, Apr 13, 2018 at 09:14:27AM +0200, Carsten Bormann wrote: >>> * Can there be a Location-Query option in a registration response? >>> (Probably not, we just didn=E2=80=99t say that.) >>=20 >> Why not? >> (Sorry, I missed out on responding to Jim=E2=80=99s earlier message = on this. >> I=E2=80=99m trying to find out why we need to restrict the server=E2=80= =99s flexibility in choosing the URI here. >> Maybe there is a good reason, I=E2=80=99d just like it to be more = explicitly stated.) >=20 > The good reason is that we are using URI templates in the registration > update operation: {+location}{?lt,con,extra-attrs*} >=20 > While it should be intuitively obvious that for location=3D"x://y/z?a=3D= b" > and lt=3D"42", the produced URI is "x://y/z?a=3Db<=3D42", RFC6570 = Section > 3.2.8 does not describe peeking back at what has been expanded to the > left side, but prescribes a "?" to be used before the first value, so > the produced URI would be "x://y/z?a=3Db?lt=3D42" (or possibly = ?a=3Db%3Flt=3D42 > but not ?a=3Db<=3D42). >=20 > If I'm reading RFC6570 wrong here, Location-Path can be allowed and = I'd > be happy. >=20 > Otherwise, we have to choose between using formal URI templates here > (vs. saying that some query parameters can be appended) and allowing > Location-Query. (Requiring anyone to understand ?foo=3Dbar?baz=3Dqux = as two > keyswould be madness so it=E2=80=99s not an option.) I must admit that I read o append "?" to the result string if this is the first defined value or append =E2=80=9C&=E2=80=9D thereafter; as doing the right thing, but then maybe I don=E2=80=99t understand = =E2=80=9Cthe first defined value=E2=80=9D (of what?). We could also use formal URI templates and just say that they are to be = interpreted in the sensible way described above. (I=E2=80=99m not a fan of RFC 6570 URI templates at all, because the = approach is full of brokenness of the kind you describe(*); but it was = available at the time=E2=80=A6) >=20 >>> Ceterum censeo RFC6690 esse revidendam. >>=20 >> Well, the general feeling was that instead of going for a 6690bis, we >> maybe want to let the link-format just fade out (In favor of >> links-json/-cbor). >=20 > link-json/-cbor is not helping with the issue of [1]. No; the intention would be to develop links-json/-cbor in such a way = that itself doesn=E2=80=99t have the issue. (I.e., decouple it a bit from the idiosyncrasies of RFC 6690.) > Whoever receives a link-format+json document and wants to follow a = link > given there needs to take the href and the anchor, and look up in > RFC6690 Section 2.1, which is the very root of my misgivings about the > situation. Not if we don=E2=80=99t define it that way. Generally, the idea is that an RD consumer is not affected by this (we = always use absolute URIs), and an RD submitter would be affected only = if it uses legacy link-format. > [1]: = https://mailarchive.ietf.org/arch/msg/core/LS0ccxtH8nEVuy73iZoRkkfBpmw >=20 >>> * Production and parsing of invalid RFC6690 (which link attributes >>> need to be quoted,=20 >>=20 >> Right. I think we really should be following RFC 8288 here and = asking >> implementations to be robust to the misguided =E2=80=9Cthis attribute = needs to >> be quoted=E2=80=9D decisions we made in RFC 6690. >>=20 >> Maybe we can put a few updates to 6690 in links-json? >=20 > I don't know from a procedural PoV -- can we? And how far can that go? In updating a document, we can go as far as we want. But of course we want to be reasonable and make sure we don=E2=80=99t = invalidate existing implementations of link-format. Instead of doing a link-format v2, the idea is live with v1 and move = over to JSON/CBOR. Gr=C3=BC=C3=9Fe, Carsten (*) the usual mistake of trying to describe operations on the data model = level in terms of operations on the serialization level. That got fixed = in RFC 8288, but not in RFC 6570 templates. In the end, I believe = we=E2=80=99ll be much better off with a CORAL-like representations of = URIs=E2=80=A6 From nobody Fri Apr 13 08:11:40 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 D2DD4126CF6 for ; Fri, 13 Apr 2018 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 Rye9ilZGEwku for ; Fri, 13 Apr 2018 08:11:35 -0700 (PDT) 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 39A96124BE8 for ; Fri, 13 Apr 2018 08:11:34 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 37EA349789; Fri, 13 Apr 2018 17:11:32 +0200 (CEST) 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 DC8DA74; Fri, 13 Apr 2018 17:11:30 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C62A531; Fri, 13 Apr 2018 17:11:28 +0200 (CEST) Received: (nullmailer pid 27932 invoked by uid 1000); Fri, 13 Apr 2018 15:11:23 -0000 Date: Fri, 13 Apr 2018 17:11:23 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org, Carsten Bormann Cc: Hannes Tschofenig , core@ietf.org Message-ID: <20180413151121.GC20765@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S1BNGpv0yoYahz37" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 15:11:38 -0000 --S1BNGpv0yoYahz37 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2018 at 10:04:07AM +0200, peter van der Stok wrote: > > I am curious what we lose if we remove this identifier altogether. The > > only thing that comes to my mind is a debugging capability where you > > might want to test your system without any security protocol. >=20 > Probably, I completely misunderstand your suggestion. > Registrations in the RD need identification so that they can be changed, > removed , updated, etc... Well, the manipulation (change, removal, update) already happens independently of the endpoint name or domain; that is just bound to the registration resource. In the current text, we allow that the endpoint name is not given at registration time if it is explicitly configured and the RD can recognize the endpoint by its security context. > Registrations are identified by the (ep, d) pair, unique within a given R= D. > Removing ep identifier will force you to find another identifier for a > registration......... > and you are back to square 1 it seems. In any authenticated context, that can identifier can be the security context. How that can be expressed at lookup is an open question. An endpoint name string can be what glues those together. On Mon, Apr 09, 2018 at 10:14:54AM +0200, Carsten Bormann wrote: > The argument seems to be that if a client holds an authorization to > register at an RD, that authorization may imply a specific endpoint > name. (I=E2=80=99m not sure that is always true, as the authorization ma= y be > based on a claim that does not happen to provide an obvious candidate > for that.) >=20 > To discuss this further, we=E2=80=99ll need to discuss authorization mode= ls > for RD access. Maybe high time in any case=E2=80=A6 Could everybody maybe sketch how they'd express the permissions they would like to set on their RDs? I'll start with some arbitrary ones that might be useful (at least with some help from Cunningham's Law): TrustTheWebCAs: "This RD accepts any registration, provided who registers can present a X509 certificate chain to my system certificates that carries a Common Name or Subject Alternative Name that matches the host name they give in their con". RequireEKU: "Like TrustTheWebCAs, and if it wants to set an endpoint type (et=3D), that must be justified by an Extended Key Usage in the certificate." EPFromACE: "This RD uses /reg/${domain}/${endpoint} as registration URIs. An endpoint can only register if it holds an ACE-AIF token to POST to that resource issued by my Authorization Server (AS)." PNFromACE: "This RD allows registration of arbitrary endpoints, but advertising an at=3D... (registration) or ol=3D... (link) attribute (see core-protocol-negotiation) requires that that value is contained in an ACE token from my AS." Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --S1BNGpv0yoYahz37 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrQyJYACgkQOY0REtOk veEQwg/+NUff/6zGQesYH4Pq9nexkApscBXhBkmlDY+8LwjL7CHkTKenUMzXEBF6 NLQVYpawDnFoTrJLZe8skEJrKxmp8Oc9OCRD4RzFPHpHQs4clknCBlqEDP+Nm5XV r1H+gvgMxKUdIgzi+IR2XdemQ3vKHl0LhlL4EKsKeOnhcUYlcIhrIM0lXj3zxM2D aC1R4S/l9KlL3XPcvmPq5P7EzAMhCMIgDOySB0hDbSd3bj46FqyrkDUa/sVyIWdK Ww/MjQNxxjIPPtuAqZRxUbARxueUZBgKarxZmWI5H6tVVTPuR8JY6KIpWcjBZLYY jExpFB4TVFPOuZTfnPAXkw/h4bKJkBx15SNR0mhgMkEGxAoSC6voLE6YGVwHR7u4 0jB+cQEozUZzFKAiI0znWc+UhDmG419TjDYvPQhb6eydDs9G+Cpm466dH7YTA6fA rn4bVUGYCE0zw+EKbVrUw4VvM+3S/Wv2r5gi53f8EmsxKkugUYc3C4NcN3WXFcQy IfpTtWc8mm0HhUxQl6+ONV0RDbRDZeYbxWPD71ASTCnAhLf2c97V6t/s8uV4H0fZ I65wCddzUnK5ATzp/TjBKPhu82OZ60vN2CX+DlYrX7FeKy7GmHwFoE5fDAJaqGHB TY8IFO1KqMHKXYmE99mLaB7x0VlU1B6rHjN7aXL+4nYWThQz+eI= =wfsW -----END PGP SIGNATURE----- --S1BNGpv0yoYahz37-- From nobody Fri Apr 13 08:26: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 2282012426E for ; Fri, 13 Apr 2018 08:26:10 -0700 (PDT) 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 er8SrhbjTd-a for ; Fri, 13 Apr 2018 08:26:08 -0700 (PDT) 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 584561241F5 for ; Fri, 13 Apr 2018 08:26:08 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 76DBA49789; Fri, 13 Apr 2018 17:26:06 +0200 (CEST) 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 6EBB674; Fri, 13 Apr 2018 17:26:04 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 11F7431; Fri, 13 Apr 2018 17:26:04 +0200 (CEST) Received: (nullmailer pid 28213 invoked by uid 1000); Fri, 13 Apr 2018 15:26:03 -0000 Date: Fri, 13 Apr 2018 17:26:03 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Hannes Tschofenig Cc: "core@ietf.org WG" Message-ID: <20180413152603.GD18031@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gE7i1rD7pdK0Ng3j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 15:26:10 -0000 --gE7i1rD7pdK0Ng3j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 04, 2018 at 01:28:26PM +0000, Hannes Tschofenig wrote: > I have a remark for the RD draft: Section 5.3 defines the registration > procedure and indicates that the endpoint name is "mostly mandatory". >=20 > I would prefer it is defined as "optional". I agree; this is being discussed in the other thread[1]. > I would argue that under normal operation there is no reason to > include the endpoint name since it is not authenticated and there will > be a security protocol used (which offers authenticated endpoint > identification). Yes, I forgot to update the security considerations when intoducing the "mostly" to mandatory. Taken to our issue tracker[2], fix postponed pending the outcome of the other thread. Thanks Christian [1]: https://mailarchive.ietf.org/arch/msg/core/kNGJgkIQF7ZqXLYJFNq4LGXuBs0 [2]: https://github.com/core-wg/resource-directory/issues/119 --=20 There's always a bigger fish. -- Qui-Gon Jinn --gE7i1rD7pdK0Ng3j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrQzAcACgkQOY0REtOk veEwahAAwXcAtkLIV2xA4oDy4/u/muaQfPx9yH9Pt5i2tLu3kJLh+hdZOUFJeWXm 3hcoQEe/28E9FnyZnXfIhtxZ493pvZJGJGQtYBls6TMooYNB0Y3r2iut8FFF+sVB Wkv1nIhDRtZXlAVN1Xudf99PGW/ZTyp2eJmd0uc5UfgdMvttj9Mg1QbB0OHC4CXE fDMwy52S4IheTYz9icELnc4pYsxH2bdy4BfTeJ6VHITFbdhYodMaYH2zHI0irCpP dmDf6FL+tTJC0KgAw333VhP0YWrDy9+hWtLPOma5EvKICWC5klUwUaSlsHiZ7XeP Cb5A9VTwSrcotLcb9SI37rNIA1v3zWPmlGfedC/PtO2Lw6BlqtJhTq+2vZyaAXmx 38GlHptwSnD7Z+Vntni2qfQAVj2FEJhA16UwCwJZDWq7MIBgQDEnCjRKPPLPRchQ y9KdEfurKqaWXVR8V21jLtbxV3XvJYxab8DiHqKekHgH1Pdutp4dqj3zMqKQXgtM ljLH76RvLisPwi+fUEnffH9eIT03lHXYb3WpKwfJrIIwLM+3Wtb3FsA3uf/z7f2d al5T411IsSHJYUNpKP0JqCP5mLoxFmQWj2cIQ7MAbaVaPgWhqL088TAbFkcNomTB adq88O3O4K3u4XJwj8fOFLu2z5Y4Vw6i1n1w9/RTRBZVcbtpGHg= =AzYU -----END PGP SIGNATURE----- --gE7i1rD7pdK0Ng3j-- From nobody Fri Apr 13 11:29: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 1EF9F127522; Fri, 13 Apr 2018 11:29:57 -0700 (PDT) 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 3aqJ-NhJRI6w; Fri, 13 Apr 2018 11:29:53 -0700 (PDT) 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 351A4124E15; Fri, 13 Apr 2018 11:29:52 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5FF854978E; Fri, 13 Apr 2018 20:29:50 +0200 (CEST) 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 1D42F74; Fri, 13 Apr 2018 20:29:49 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B95E031; Fri, 13 Apr 2018 20:29:48 +0200 (CEST) Received: (nullmailer pid 339 invoked by uid 1000); Fri, 13 Apr 2018 18:29:47 -0000 Date: Fri, 13 Apr 2018 20:29:47 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Cc: Jim Schaad , draft-ietf-core-resource-directory@ietf.org, 'core' Message-ID: <20180413182947.GE18031@hephaistos.amsuess.com> References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PPYy/fEw/8QCHSq3" Content-Disposition: inline In-Reply-To: <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Apr 2018 18:29:57 -0000 --PPYy/fEw/8QCHSq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, Peter, On Thu, Apr 05, 2018 at 09:51:25AM +0200, peter van der Stok wrote: > Idempotency says that applying the same operation multiple times should l= ead > to the same result independent of the number of times. > The problem is: what is the same operation; If only ep and d are relevant > then applying multiple times an operation (registration) with the same ep > and d values indeed leads to the same result ignoring all other attribute > values (including location) >=20 > If one says that the same operation implies that all other specification > parameters are unchanged, then indeed location should not be changed in t= hat > case. >=20 > What view do you adhere to? >=20 > And do you suggest we should insert clarifying text? We should look at why we are requiring idempotency here. =46rom what I can tell, this is because CoAP servers and clients are easier to implement if they can rely on the operation to be idempotent, but they are looking at the very same request being sent again in a relatively short time frame. An additional use case here is stability in presence of "semi-simple" clients that POST their .well-known/core to the directory resource every few hours and never try to parse the Location returned. If those change the registration resource address every time, an observation on the endpoint lookup becomes needlessly noisy. As long as those are the cases we consider, I think that it is sufficient to specify that the registration operation must return the same response to a CoAP request with the same requester / security context, code, options and payload within EXCHANGE_LIFETIME. The concern for observation stability is more a matter of implementation quality, where me can recommend but need not specify. > > 3. How are href comparisons done. > > a) compare against what was registered > > b) Resolve what was registered and the href in the current context > > and compare > > c) something I did not think of >=20 > probably someone else wants to react as well. > The model in the RD stores the target as specified in /.well-known/core of > the source. > At lookup the links are resolved against con. > Consequently, the comparison of href is the comparison versus the target = as > stored in the RD and as copied from /.well-knwon/core. I think the more convenient thing to do is to say that resources are compared against the full path, and registrations and group resources (they can be matched too) are matched against whatever is returned in endpoint lookup. That would be more intuitive to the user of the lookup (matching against what is returned). > > If I do the lookup of > > /rd/gp-lookup?rt=3Dfoobar > >=20 > > And one of the groups has the following > >=20 > > /rd-group/xxx > > https://otherrd/rd-group/yyy > >=20 > > I would follow the local group definition to find out if the > > resource type is defined on some resource in the group, however the > > question is do I need to go and query the other group which is not > > local in order to do the same tree walking when doing attribute > > comparisons. Not that this applies to remote endpoint registrations > > in a group as well. >=20 > Thanks for the example. > Indeed following the latest text, the comparison should include the remote > registration. >=20 > The text could include words like tree walking is done locally only; > personally I would not be too happy about that. > Apparently the text should say something about remote groups and tree > walking. I will add the issue to github. I think that this is out of scope for RD itself. What I'd like to have in RD is the text that ensures that clients will not get upset when they see absolute URIs in group or endpoint lookups. We are not actually describing a distributed RD here, this is only to keep the door open for such extensions. Would it help if we changed the example to say GET coap://rd.example.com/ep?gp=3Dlights1 Res: 2.05 Content ;con=3D"coap://[2001:db8:3::123]:61616"; ep=3D"node1";et=3D"oic.d.sensor";ct=3D"40";lt=3D"600", ;con=3D"coap://[2001:db8:3::124]:61616"; ep=3D"node2";et=3D"oic.d.sensor";ct=3D"40";lt=3D"600" ? It would just indicate that the registration resource is hosted by the same RD but on another protocol (presumably because the endpoint registered using coap+tcp, and that Location can't just jump protocols). > > 5. Value of lt =3D should it be the set parameter or the time left - > > how would time left be represented outherwise - should it be represente= d. >=20 > Right on the nail. This is very vaguely specified. The unit is > specified as seconds. > In my expectation the returned lt value is the time in seconds > from lookup till end. >=20 > Other opinions by my co-authors? If we all agree, we specify it as > such in the RD spec. My expectation is that lt=3D is the registered value and never decreases. (For an additional value that indicates where the registration is in its lifetime, I've suggested lt-age in draft-amsuess-core-rd-replication-01 -- but only because there's an application for it there). Having lt decrease is problematic with caching (admittedly, so is lt-age). What use cases do we have for exposing a lifetime in the endpoint lookup at all? (If we have none, an RD might just as well not display a lifetime). > > POST /rd?ep=3Dnode1 > > - payload contains the set of resources the register. > > - returns a location of /rd/yyyy > >=20 > > POST /rd/yyyy?ep=3Dnode1 > > - payload is empty. > >=20 > > In the first post, the rd will infer a context based on how the > > registration is done. The second post just says that the TTL value > > is to be refreshed back to the life-time value. However, the > > inferred context could also be changed. >=20 > Thanks for the example; it would take me long to figure this out otherwis= e. >=20 > Reading the update specification, the ep=3Dnode1 is illegal in the update. > Specifying ep means creating a new registration. ep=3Dnode1 would be ...well not technically illegal (the template would put the ep in extra-attrs, and the server hopefully not store it there); it is an attribute that is not changing and therefore SHOULD NOT be included in the update by the client. A changed ep would not create a new registration (we're at a registration resource already), but simply be refused. > sending the update > POST /rd/yyy will update the lt value. > It is allowed to change the value of con in the update POST specification. > The question is: > When an updating ep, different from the registering one, sends the update= of > lt, does the context change to the hosts relation value of the updating e= p. >=20 > My gut reaction is no. it does not change the context value in the RD > because that needs an explicit ?con=3D in the update specification. >=20 > A warning in the RD text to this effect looks reasonable. The text is already pretty explicit: "If the parameter is set in an update, it is stored by the RD as the new Base URI under which to interpret the links of the registration, following the same restrictions as in the registration. If the parameter is not set and was set explicitly before, the previous context value is kept unmodified. If the parameter is not set and was not set explicitly before either, the source address and source port of the update request are stored as the context." This allows for clients that do not keep a good eye on their addresses but have their OS pick the latest one. Note that nobody other than the endpoint (or CT if created by one) may manipulate a registration resource. (If we wanted to allow other hosts to manipulate a different endpoint's registration, we'd need something like a ?ct=3Dkeep or change in semantics to allow that -- but I'd like to have a good reason to do that in the first place). > > 7. I don't understand the presence of the content-format for the > > empty message posted for simple registration. This seems to be odd if > > the content is empty. > > [...] > > Would accept be a better option to use? This would allow for more than > one value to be specified. It should be neither; that request is empty and so is the response. The RD will need to probe for the content format of its own (possibly trying its preferred content format first, falling back to an empty accept or 40). The best equivalent of "and look there expecting this content format" would be HTTP's link header (a la 'POST /.w-k/c?ep=3Dnode1, Link: ;ct=3D"40 64 504"'), and we can't do that in CoAP, at the very least not in a simple registration. > > > 8 Is there supposed to be a way for simple registration to return an > > > error message? As written this is not necessarily done. > > > Specifically, the response to the post can be executed before the > > > query to /.well-known/core is done and the registration is attempted. > >=20 > > I see what you mean: also the return of 2.04 shows in the example > > but not in the specification. > > This warrants additional text to specify the simple registration text. >=20 > will add the simple registration template to the text. I think that the more important question behind is of whether the RD should (or may) wait with a response until it has fetched the .w-k/c of the endpoint. The example shows "respond first, then ask details", which we might consider prescribing given that highly constrained clients might not manage to multi-task the request and the response. (Dealing 5.03 Sorry I'm Busy until their pending request is answered or expired). Best regards Christian (updating the issue tracker in parallel) --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --PPYy/fEw/8QCHSq3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrQ9xgACgkQOY0REtOk veHN9BAAlTejKLPhrfXSY1KQEI5aMhSFT0D6N+xlHCSLvkA6aVxhgPw8PB810ss/ emdwRqYAPdmsSvfwQE+6PHnPhOBlxf+oqPcZbtD4K51kEOQJlOjHqTLUcQiAd8/L vfkYPHXLcRL4wUcRctdTBcTMXlgK+/TmbgGmyBlnDIkV7iSk45/9rxR9ZcS4fH+u DNg8O3RPylVVVTBu9arwMDLHR6B5AXqHk6cVB9I4nnZV0RIc491xnb0OOgT4IzeY jnTInmJ6nyt64+I3heFpQCsxDqEz8IXn5HcUCoCMpnPRovEeqP49R6HwQ50Wmut8 Q9Ok3ogoD575X68dpxQZX8LUA1AOZTqYDVeQ+0vDKKvwkFv0E8XuXgRa32UlnaBg IgqsYD34pJ6CFxDS3ImoXWDUROg3KVYjEWWuNheqX0JvRPBPob4gOEBUTPrl+E6u 3eHfOyJWIEGVZSoOwXFiLdJLEayTJaVbaJ0t4InEqKk5DbjmR9ByusWY5LaGE19l 8lQOJVnqJNOJ52nptnxnMTOU7w4JWZSa4NTbqYddPtkEfFDyfl8zcDWgpfC+5h3e ZncKgKAnrNTRg8c7D4anX8e+CJnSd9Q7+Jyo9q1LfSmHJ7E1KSPWUDmD9RRwt+Dg l2feHLxcB8tldKkmMyWdNjU0NpbYw8bPdr/ZSg+LlfjNbUj+IMs= =Q6QM -----END PGP SIGNATURE----- --PPYy/fEw/8QCHSq3-- From nobody Sun Apr 15 11:20: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 0DAEA120725 for ; Sun, 15 Apr 2018 11:20:01 -0700 (PDT) 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, 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 JS-gJDfKTRs0 for ; Sun, 15 Apr 2018 11:19:58 -0700 (PDT) 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 7E8E91201FA for ; Sun, 15 Apr 2018 11:19:58 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Apr 2018 11:17:32 -0700 From: Jim Schaad To: =?utf-8?Q?'Christian_Ams=C3=BCss'?= , 'Carsten Bormann' CC: 'Core WG mailing list' References: <20180412110455.GA20765@hephaistos.amsuess.com> <914708A1-8C9F-4201-9579-18AE2A6C6BF7@tzi.org> <20180412125448.GG18144@hephaistos.amsuess.com> In-Reply-To: <20180412125448.GG18144@hephaistos.amsuess.com> Date: Sun, 15 Apr 2018 11:19:51 -0700 Message-ID: <011101d3d4e6$5a11a9f0$0e34fdd0$@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: AQK8yPI49fbTFbVH+z1LQEyWkSlINQHKKYDoAXR3AtWiFkTMUA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Wild suggestion for observation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 18:20:01 -0000 > -----Original Message----- > From: core On Behalf Of Christian Ams=C3=BCss > Sent: Thursday, April 12, 2018 5:55 AM > To: Carsten Bormann > Cc: Core WG mailing list > Subject: Re: [core] Wild suggestion for observation >=20 > On Thu, Apr 12, 2018 at 01:31:48PM +0200, Carsten Bormann wrote: > > Hmm. We normally observe resources, with the server sending a fresh > > representation when that has changed. >=20 > Yes, and from that PoV, what I'm suggesting is undue. >=20 > That boundary has IMO been crossed already with FETCH being observable > (several observations can run on the same resource and give different > results), so this would be the continuation of that line of thought. >=20 > > What you are proposing means observing the change of a result of a > > non-idempotent action that was done once if it were done again but > > isn=E2=80=99t (!?). Not sure I=E2=80=99m completely following. >=20 > Not "if it was done again". As I understand resources and = representations, > the response body of a POST is not a representation of the resource = POSTed > to, but a representation of an anonymous, short-lived resource(-ish = thing?) > that has no address and a short lifetime but might have a = representation. >=20 > An observation on that would give the client various representations = of that > thing as it evolves during its short lifetime. >=20 >=20 > > The REST way of doing that would be to create a resource on the POST > > for the result, and then observe that in a separate request. If = that > > is too heavy, maybe it would be a better way to streamline that a = bit? >=20 > I do agree that this is what should happen in many cases; and if the = outcome > of this thread is that all cases where an observable POST would be = needed > are better covered with POST->Location & observe that, it's perfectly = fine > with me. (Bonus points if we can streamline that). >=20 > I don't remember why in Peter's (or was it Jim? that would have been = the > thread at [1], then) case that was not a viable option. This was the way that I finally designed my problem to work. It is a = bit interesting from the view of: I observe the resource and then I = post to the resource. It is very likely that I would get back the same = content representation twice once in the observe and once from the post. = This is the same type of thing that happens in the OSCORE world where = one needs to carefully think about what it means to observe a resource = on the encrypted side and when and where things come back from the FETCH = vs POST operation. Jim >=20 > In OSCORE, we're transporting an observation but hiding the method, so > everything becomes a meaningless POST; going via a Location would take > much of the streamlining out of it. That it's allowed for FETCH just = provided > an easy way out there, so we're now sending every observation in a = FETCH > (even though the OSCORE request is not fully side-effect free, and we = have > to make amends due to that, but it seems to work). >=20 > But yes: Saying "If you want to Observe POST (or anything else but = GET), > rather POST with a Location, GET that and DELETE it when it looks = done" > can be a valid answer too (just one that won't make it into OSCORE). >=20 > Thanks for your input > Christian >=20 > [1]: https://mailarchive.ietf.org/arch/msg/core/40WH27Y0- > QgbjJ5GWxjios3Xkj8 >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom From nobody Sun Apr 15 11:47:44 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 BEFFD126FB3 for ; Sun, 15 Apr 2018 11:47:41 -0700 (PDT) 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, 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 N2GhqgmTM8cn for ; Sun, 15 Apr 2018 11:47:39 -0700 (PDT) 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 25F50126DD9 for ; Sun, 15 Apr 2018 11:47:39 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Apr 2018 11:45:13 -0700 From: Jim Schaad To: 'Carsten Bormann' , =?utf-8?Q?'=22Christian_M._Ams=C3=BCss=22'?= CC: 'peter van der Stok' , 'Core WG mailing list' References: <20180413110301.GL18144@hephaistos.amsuess.com> <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> In-Reply-To: <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> Date: Sun, 15 Apr 2018 11:47:32 -0700 Message-ID: <011501d3d4ea$384220d0$a8c66270$@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: AQHjWhje2sbDIUe1Lp3N6W6ZOySHQAKC/HHEo88GZ+A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 18:47:42 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Friday, April 13, 2018 6:01 AM > To: "Christian M. Ams=C3=BCss" > Cc: peter van der Stok ; Jim Schaad > ; Core WG mailing list > Subject: Re: [core] Report on first Resource Directory plugtest >=20 > On Apr 13, 2018, at 13:03, Christian M. Ams=C3=BCss = > wrote: > > > > Hello Peter, Carsten, > > hello Jim (responding cross-thread to the Location-Query point), > > > > (removing DNS-SD from the thread because I do not expect those = topics > > to be particularly interesting there) > > > > On Fri, Apr 13, 2018 at 09:04:33AM +0200, peter van der Stok wrote: > >> to be filled into the github, I hope. > > > > yes, as I am finally going thorough the existing issues and changes. > > > > On Fri, Apr 13, 2018 at 09:14:27AM +0200, Carsten Bormann wrote: > >>> * Can there be a Location-Query option in a registration response? > >>> (Probably not, we just didn=E2=80=99t say that.) > >> > >> Why not? > >> (Sorry, I missed out on responding to Jim=E2=80=99s earlier message = on this. > >> I=E2=80=99m trying to find out why we need to restrict the = server=E2=80=99s flexibility in > choosing the URI here. > >> Maybe there is a good reason, I=E2=80=99d just like it to be more = explicitly > >> stated.) > > > > The good reason is that we are using URI templates in the = registration > > update operation: {+location}{?lt,con,extra-attrs*} > > > > While it should be intuitively obvious that for = location=3D"x://y/z?a=3Db" > > and lt=3D"42", the produced URI is "x://y/z?a=3Db<=3D42", RFC6570 = Section > > 3.2.8 does not describe peeking back at what has been expanded to = the > > left side, but prescribes a "?" to be used before the first value, = so > > the produced URI would be "x://y/z?a=3Db?lt=3D42" (or possibly > > ?a=3Db%3Flt=3D42 but not ?a=3Db<=3D42). > > > > If I'm reading RFC6570 wrong here, Location-Path can be allowed and > > I'd be happy. > > > > Otherwise, we have to choose between using formal URI templates here > > (vs. saying that some query parameters can be appended) and allowing > > Location-Query. (Requiring anyone to understand ?foo=3Dbar?baz=3Dqux = as > > two keyswould be madness so it=E2=80=99s not an option.) >=20 > I must admit that I read >=20 >=20 > o append "?" to the result string if this is the first defined = value > or append =E2=80=9C&=E2=80=9D thereafter; >=20 > as doing the right thing, but then maybe I don=E2=80=99t understand = =E2=80=9Cthe first defined > value=E2=80=9D (of what?). >=20 > We could also use formal URI templates and just say that they are to = be > interpreted in the sensible way described above. >=20 > (I=E2=80=99m not a fan of RFC 6570 URI templates at all, because the = approach is full of > brokenness of the kind you describe(*); but it was available at the = time=E2=80=A6) I would agree that I would not have read this as needing to have two "?" = characters in the query parameters. My issue is that I worry about the = case that an RD decides to use foo=3DXXX as the location query and then = some application decides to use foo as a query parameter in the extra = parameters or in a link description. This works fine on RD = implementation #1 because it is just using a location path to point to = the end point, but when it hits RD implementation #2 which is using the = location query as well it starts failing. =20 It is also slightly a pain because it is harder to combine query = parameters than it is to just use a path, but that can easily be dealt = with. Jim >=20 > > > >>> Ceterum censeo RFC6690 esse revidendam. > >> > >> Well, the general feeling was that instead of going for a 6690bis, = we > >> maybe want to let the link-format just fade out (In favor of > >> links-json/-cbor). > > > > link-json/-cbor is not helping with the issue of [1]. >=20 > No; the intention would be to develop links-json/-cbor in such a way = that > itself doesn=E2=80=99t have the issue. > (I.e., decouple it a bit from the idiosyncrasies of RFC 6690.) >=20 > > Whoever receives a link-format+json document and wants to follow a > > link given there needs to take the href and the anchor, and look up = in > > RFC6690 Section 2.1, which is the very root of my misgivings about = the > > situation. >=20 > Not if we don=E2=80=99t define it that way. >=20 > Generally, the idea is that an RD consumer is not affected by this (we = always > use absolute URIs), and an RD submitter would be affected only if it = uses > legacy link-format. >=20 > > [1]: > > > https://mailarchive.ietf.org/arch/msg/core/LS0ccxtH8nEVuy73iZoRkkfBpmw > > > >>> * Production and parsing of invalid RFC6690 (which link attributes > >>> need to be quoted, > >> > >> Right. I think we really should be following RFC 8288 here and > >> asking implementations to be robust to the misguided =E2=80=9Cthis = attribute > >> needs to be quoted=E2=80=9D decisions we made in RFC 6690. > >> > >> Maybe we can put a few updates to 6690 in links-json? > > > > I don't know from a procedural PoV -- can we? And how far can that = go? >=20 > In updating a document, we can go as far as we want. > But of course we want to be reasonable and make sure we don=E2=80=99t = invalidate > existing implementations of link-format. > Instead of doing a link-format v2, the idea is live with v1 and move = over to > JSON/CBOR. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) the usual mistake of trying to describe operations on the data = model level > in terms of operations on the serialization level. That got fixed in = RFC 8288, > but not in RFC 6570 templates. In the end, I believe we=E2=80=99ll be = much better off > with a CORAL-like representations of URIs=E2=80=A6 From nobody Sun Apr 15 11:53:38 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 7A342126DD9 for ; Sun, 15 Apr 2018 11:53:36 -0700 (PDT) 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, 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 FRImhjxLZQYi for ; Sun, 15 Apr 2018 11:53:34 -0700 (PDT) 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 89A4C126CE8 for ; Sun, 15 Apr 2018 11:53:33 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Apr 2018 11:51:06 -0700 From: Jim Schaad To: 'Carsten Bormann' , =?utf-8?Q?'=22Christian_M._Ams=C3=BCss=22'?= CC: 'peter van der Stok' , 'Core WG mailing list' References: <20180413110301.GL18144@hephaistos.amsuess.com> <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> In-Reply-To: <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> Date: Sun, 15 Apr 2018 11:53:25 -0700 Message-ID: <011601d3d4eb$0abcba20$20362e60$@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: AQHjWhje2sbDIUe1Lp3N6W6ZOySHQAKC/HHEo88IatA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 18:53:36 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Friday, April 13, 2018 6:01 AM > To: "Christian M. Ams=C3=BCss" > Cc: peter van der Stok ; Jim Schaad > ; Core WG mailing list > Subject: Re: [core] Report on first Resource Directory plugtest >=20 > On Apr 13, 2018, at 13:03, Christian M. Ams=C3=BCss = > wrote: > > > > Hello Peter, Carsten, > > hello Jim (responding cross-thread to the Location-Query point), > > > >>> Ceterum censeo RFC6690 esse revidendam. > >> > >> Well, the general feeling was that instead of going for a 6690bis, = we > >> maybe want to let the link-format just fade out (In favor of > >> links-json/-cbor). > > > > link-json/-cbor is not helping with the issue of [1]. >=20 > No; the intention would be to develop links-json/-cbor in such a way = that > itself doesn=E2=80=99t have the issue. > (I.e., decouple it a bit from the idiosyncrasies of RFC 6690.) >=20 > > Whoever receives a link-format+json document and wants to follow a > > link given there needs to take the href and the anchor, and look up = in > > RFC6690 Section 2.1, which is the very root of my misgivings about = the > > situation. >=20 > Not if we don=E2=80=99t define it that way. >=20 > Generally, the idea is that an RD consumer is not affected by this (we = always > use absolute URIs), and an RD submitter would be affected only if it = uses > legacy link-format. >=20 > > [1]: > > > https://mailarchive.ietf.org/arch/msg/core/LS0ccxtH8nEVuy73iZoRkkfBpmw > > > >>> * Production and parsing of invalid RFC6690 (which link attributes > >>> need to be quoted, > >> > >> Right. I think we really should be following RFC 8288 here and > >> asking implementations to be robust to the misguided =E2=80=9Cthis = attribute > >> needs to be quoted=E2=80=9D decisions we made in RFC 6690. > >> > >> Maybe we can put a few updates to 6690 in links-json? > > > > I don't know from a procedural PoV -- can we? And how far can that = go? >=20 > In updating a document, we can go as far as we want. > But of course we want to be reasonable and make sure we don=E2=80=99t = invalidate > existing implementations of link-format. > Instead of doing a link-format v2, the idea is live with v1 and move = over to > JSON/CBOR. Doing this is going to make my life as an implementor really a mess. I = will no longer be able to simply have a single representation of the = internal data structure and do the parsing as serialization to a common = format. I am now going to need to remember what the original = representation was and do the serializations differently based on that = value. In addition to this, all of my internal calls to setup the link = format to begin with need to have this distinction so that things get = serialized correctly. What would this mean for serializing out = /.well-known/core - are the meanings different if one serializes to cbor = as opposed to link-format? I think this would make more problems that = it would solve. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) the usual mistake of trying to describe operations on the data = model level > in terms of operations on the serialization level. That got fixed in = RFC 8288, > but not in RFC 6570 templates. In the end, I believe we=E2=80=99ll be = much better off > with a CORAL-like representations of URIs=E2=80=A6 From nobody Sun Apr 15 12:31:04 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 A8E6C1270A0 for ; Sun, 15 Apr 2018 12:31:02 -0700 (PDT) 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, 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 wGd9xzjK1W26 for ; Sun, 15 Apr 2018 12:31:00 -0700 (PDT) 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 3658D12708C for ; Sun, 15 Apr 2018 12:31:00 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Apr 2018 12:28:33 -0700 From: Jim Schaad To: =?utf-8?Q?'Christian_Ams=C3=BCss'?= , , 'Carsten Bormann' CC: 'Hannes Tschofenig' , References: <20180413151121.GC20765@hephaistos.amsuess.com> In-Reply-To: <20180413151121.GC20765@hephaistos.amsuess.com> Date: Sun, 15 Apr 2018 12:30:52 -0700 Message-ID: <011701d3d4f0$46255e50$d2701af0$@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: AQGfMgGYuZnAjgmyOi0d4VE9O1YZbqRrcsRg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 19:31:03 -0000 > -----Original Message----- > From: core On Behalf Of Christian Ams=C3=BCss > Sent: Friday, April 13, 2018 8:11 AM > To: consultancy@vanderstok.org; Carsten Bormann > Cc: Hannes Tschofenig ; core@ietf.org > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft >=20 > On Mon, Apr 09, 2018 at 10:04:07AM +0200, peter van der Stok wrote: > > > I am curious what we lose if we remove this identifier altogether. > > > The only thing that comes to my mind is a debugging capability = where > > > you might want to test your system without any security protocol. > > > > Probably, I completely misunderstand your suggestion. > > Registrations in the RD need identification so that they can be > > changed, removed , updated, etc... >=20 > Well, the manipulation (change, removal, update) already happens > independently of the endpoint name or domain; that is just bound to = the > registration resource. >=20 > In the current text, we allow that the endpoint name is not given at > registration time if it is explicitly configured and the RD can = recognize the > endpoint by its security context. >=20 > > Registrations are identified by the (ep, d) pair, unique within a = given RD. > > Removing ep identifier will force you to find another identifier for = a > > registration......... > > and you are back to square 1 it seems. >=20 > In any authenticated context, that can identifier can be the security = context. > How that can be expressed at lookup is an open question. > An endpoint name string can be what glues those together. >=20 > On Mon, Apr 09, 2018 at 10:14:54AM +0200, Carsten Bormann wrote: > > The argument seems to be that if a client holds an authorization to > > register at an RD, that authorization may imply a specific endpoint > > name. (I=E2=80=99m not sure that is always true, as the = authorization may be > > based on a claim that does not happen to provide an obvious = candidate > > for that.) > > > > To discuss this further, we=E2=80=99ll need to discuss authorization = models > > for RD access. Maybe high time in any case=E2=80=A6 >=20 >=20 > Could everybody maybe sketch how they'd express the permissions they > would like to set on their RDs? >=20 >=20 > I'll start with some arbitrary ones that might be useful (at least = with some > help from Cunningham's Law): >=20 > TrustTheWebCAs: "This RD accepts any registration, provided who = registers > can present a X509 certificate chain to my system certificates that = carries a > Common Name or Subject Alternative Name that matches the host name > they give in their con". TrustTheWebCAs + GodBit: This RD accepts any registration, provided who = registers can present an X509 certificate chain to my system = certificates that carries a common or alternative name (or maybe an EKU) = that matches to the God criteria. >=20 > RequireEKU: "Like TrustTheWebCAs, and if it wants to set an endpoint = type > (et=3D), that must be justified by an Extended Key Usage in the = certificate." I would probably generalize this rule to - The RD may extract additional = information from the certificate beyond the naming to either enforce or = supplement attributes set such as endpoint types or domains. >=20 > EPFromACE: "This RD uses /reg/${domain}/${endpoint} as registration = URIs. > An endpoint can only register if it holds an ACE-AIF token to POST to = that > resource issued by my Authorization Server (AS)." EPFromACE2: This RD uses /reg?ep=3D${endpoint}&d=3D${domain} as = registration URIs. An endpoint can only register if it holds an ACE-AIF = token to POST to that resource issued by my Authorization Server (AS). = The token may contain values for fields in the URI-queries which are to = be either enforced, or set if not present in the registration request. = Examples are ep, d, et. >=20 > PNFromACE: "This RD allows registration of arbitrary endpoints, but > advertising an at=3D... (registration) or ol=3D... (link) attribute = (see > core-protocol-negotiation) requires that that value is contained in an = ACE > token from my AS." RSFromACE: This RD allows registration of endpoints, but restricts the = resources that can be registered. All resources registered must be = filtered by matching one of a number of patterns potentially with values = that can be defaulted in. Jim >=20 >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom From nobody Sun Apr 15 13:49:51 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 50E7D129502; Sun, 15 Apr 2018 13:49:50 -0700 (PDT) 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, 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 ISMCIPCnC5Yx; Sun, 15 Apr 2018 13:49:47 -0700 (PDT) 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 C4033128C0A; Sun, 15 Apr 2018 13:49:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Apr 2018 13:47:19 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , CC: , 'core' References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> <20180413182947.GE18031@hephaistos.amsuess.com> In-Reply-To: <20180413182947.GE18031@hephaistos.amsuess.com> Date: Sun, 15 Apr 2018 13:49:38 -0700 Message-ID: <011f01d3d4fb$46f2bf70$d4d83e50$@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: AQJlGCTfhwAxJ6Bs/Tz93rcnT3QjuQKDbAikAicKlhEBvLCqIgKF3LRkophREmA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Apr 2018 20:49:50 -0000 > -----Original Message----- > From: Christian Ams=FCss > Sent: Friday, April 13, 2018 11:30 AM > To: consultancy@vanderstok.org > Cc: Jim Schaad ; draft-ietf-core-resource- > directory@ietf.org; 'core' > Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 >=20 > Hello Jim, Peter, >=20 > On Thu, Apr 05, 2018 at 09:51:25AM +0200, peter van der Stok wrote: > > Idempotency says that applying the same operation multiple times > > should lead to the same result independent of the number of times. > > The problem is: what is the same operation; If only ep and d are > > relevant then applying multiple times an operation (registration) = with > > the same ep and d values indeed leads to the same result ignoring = all > > other attribute values (including location) > > > > If one says that the same operation implies that all other > > specification parameters are unchanged, then indeed location should > > not be changed in that case. > > > > What view do you adhere to? > > > > And do you suggest we should insert clarifying text? >=20 > We should look at why we are requiring idempotency here. >=20 > From what I can tell, this is because CoAP servers and clients are = easier to > implement if they can rely on the operation to be idempotent, but they = are > looking at the very same request being sent again in a relatively = short time > frame. >=20 > An additional use case here is stability in presence of "semi-simple" > clients that POST their .well-known/core to the directory resource = every few > hours and never try to parse the Location returned. If those change = the > registration resource address every time, an observation on the = endpoint > lookup becomes needlessly noisy. >=20 > As long as those are the cases we consider, I think that it is = sufficient to > specify that the registration operation must return the same response = to a > CoAP request with the same requester / security context, code, options = and > payload within EXCHANGE_LIFETIME. >=20 > The concern for observation stability is more a matter of = implementation > quality, where me can recommend but need not specify. I am less worried about the observation jitter problems than I am about = the turnover on groups. Given that groups are defined in terms of the href returned from an endpoint registration this means that groups are going = to be updated every time. I really think that the location needs to not = change for the lifetime of the registration not just the EXCHANGE_LIFETIME. I = am not sure that idempotent means anything useful when looking at doing registrations because I don't really know what it would mean to say something is idempotent here. Does it mean that if nothing changes = then nothing happens or just that if you register the same thing then the = same set of events should happen w/ the same outcomes. >=20 > > > 3. How are href comparisons done. > > > a) compare against what was registered > > > b) Resolve what was registered and the href in the current = context > > > and compare > > > c) something I did not think of > > > > probably someone else wants to react as well. > > The model in the RD stores the target as specified in > > /.well-known/core of the source. > > At lookup the links are resolved against con. > > Consequently, the comparison of href is the comparison versus the > > target as stored in the RD and as copied from /.well-knwon/core. I am not sure what you are saying. I do comparison followed by serialization at the moment. I do the resolution during serialization = and not during comparison. This is the reason that I was asking the = question. >=20 > I think the more convenient thing to do is to say that resources are compared > against the full path, and registrations and group resources (they can = be > matched too) are matched against whatever is returned in endpoint = lookup. >=20 > That would be more intuitive to the user of the lookup (matching = against > what is returned). This is understandable and reasonable. And would mean that I need to = change my code. >=20 > > > If I do the lookup of > > > /rd/gp-lookup?rt=3Dfoobar > > > > > > And one of the groups has the following > > > > > > /rd-group/xxx > > > https://otherrd/rd-group/yyy > > > > > > I would follow the local group definition to find out if the > > > resource type is defined on some resource in the group, however = the > > > question is do I need to go and query the other group which is not > > > local in order to do the same tree walking when doing attribute > > > comparisons. Not that this applies to remote endpoint = registrations > > > in a group as well. > > > > Thanks for the example. > > Indeed following the latest text, the comparison should include the > > remote registration. > > > > The text could include words like tree walking is done locally only; > > personally I would not be too happy about that. > > Apparently the text should say something about remote groups and = tree > > walking. I will add the issue to github. >=20 > I think that this is out of scope for RD itself. What I'd like to have = in RD is the > text that ensures that clients will not get upset when they see = absolute URIs > in group or endpoint lookups. >=20 > We are not actually describing a distributed RD here, this is only to = keep the > door open for such extensions. >=20 > Would it help if we changed the example to say >=20 > GET coap://rd.example.com/ep?gp=3Dlights1 > Res: 2.05 Content > = ;con=3D"coap://[2001:db8:3::123]:6161 > 6"; > ep=3D"node1";et=3D"oic.d.sensor";ct=3D"40";lt=3D"600", > ;con=3D"coap://[2001:db8:3::124]:61616"; > ep=3D"node2";et=3D"oic.d.sensor";ct=3D"40";lt=3D"600" >=20 > ? It would just indicate that the registration resource is hosted by = the same > RD but on another protocol (presumably because the endpoint registered > using coap+tcp, and that Location can't just jump protocols). Yeah, that whole question jumps back to the question - if it is on a different schema is it the same resource or a different resource. I = think that the example with the explanation would be better. >=20 >=20 > > > 5. Value of lt =3D should it be the set parameter or the time = left - > > > how would time left be represented outherwise - should it be > represented. > > > > Right on the nail. This is very vaguely specified. The unit is > > specified as seconds. > > In my expectation the returned lt value is the time in seconds from > > lookup till end. > > > > Other opinions by my co-authors? If we all agree, we specify it as > > such in the RD spec. >=20 > My expectation is that lt=3D is the registered value and never = decreases. > (For an additional value that indicates where the registration is in = its lifetime, > I've suggested lt-age in draft-amsuess-core-rd-replication-01 > -- but only because there's an application for it there). Having lt decrease is > problematic with caching (admittedly, so is lt-age). >=20 > What use cases do we have for exposing a lifetime in the endpoint = lookup at > all? >=20 > (If we have none, an RD might just as well not display a lifetime). All of the cases that I can think of can be done with observe. I think = that this probably does not need to be discussed except to say that max-age should not be set to this value. >=20 > > > POST /rd?ep=3Dnode1 > > > - payload contains the set of resources the register. > > > - returns a location of /rd/yyyy > > > > > > POST /rd/yyyy?ep=3Dnode1 > > > - payload is empty. > > > > > > In the first post, the rd will infer a context based on how the > > > registration is done. The second post just says that the TTL = value > > > is to be refreshed back to the life-time value. However, the > > > inferred context could also be changed. > > > > Thanks for the example; it would take me long to figure this out otherwise. > > > > Reading the update specification, the ep=3Dnode1 is illegal in the = update. > > Specifying ep means creating a new registration. >=20 > ep=3Dnode1 would be ...well not technically illegal (the template = would put the > ep in extra-attrs, and the server hopefully not store it there); it is = an attribute > that is not changing and therefore SHOULD NOT be included in the = update by > the client. >=20 > A changed ep would not create a new registration (we're at a = registration > resource already), but simply be refused. >=20 > > sending the update > > POST /rd/yyy will update the lt value. > > It is allowed to change the value of con in the update POST specification. > > The question is: > > When an updating ep, different from the registering one, sends the > > update of lt, does the context change to the hosts relation value of = the > updating ep. > > > > My gut reaction is no. it does not change the context value in the = RD > > because that needs an explicit ?con=3D in the update specification. > > > > A warning in the RD text to this effect looks reasonable. >=20 > The text is already pretty explicit: >=20 > "If the parameter is set in an update, it is stored by the RD as = the > new Base URI under which to interpret the links of the = registration, > following the same restrictions as in the registration. If the > parameter is not set and was set explicitly before, the previous > context value is kept unmodified. If the parameter is not set and > was not set explicitly before either, the source address and = source > port of the update request are stored as the context." >=20 > This allows for clients that do not keep a good eye on their addresses = but > have their OS pick the latest one. >=20 > Note that nobody other than the endpoint (or CT if created by one) may > manipulate a registration resource. >=20 > (If we wanted to allow other hosts to manipulate a different = endpoint's > registration, we'd need something like a ?ct=3Dkeep or change in = semantics to > allow that -- but I'd like to have a good reason to do that in the = first place). I missed this text. It answers the question that I had. >=20 >=20 > > > 7. I don't understand the presence of the content-format for the > > > empty message posted for simple registration. This seems to be = odd > > > if the content is empty. > > > > [...] > > > > Would accept be a better option to use? This would allow for more > > than one value to be specified. >=20 > It should be neither; that request is empty and so is the response. >=20 > The RD will need to probe for the content format of its own (possibly trying > its preferred content format first, falling back to an empty accept or 40). >=20 > The best equivalent of "and look there expecting this content format" > would be HTTP's link header (a la 'POST /.w-k/c?ep=3Dnode1, Link: > ;ct=3D"40 64 504"'), and we can't do = that in > CoAP, at the very least not in a simple registration. >=20 >=20 > > > > 8 Is there supposed to be a way for simple registration to = return > > > > an error message? As written this is not necessarily done. > > > > Specifically, the response to the post can be executed before = the > > > > query to /.well-known/core is done and the registration is attempted. > > > > > > I see what you mean: also the return of 2.04 shows in the example > > > but not in the specification. > > > This warrants additional text to specify the simple registration = text. > > > > will add the simple registration template to the text. >=20 > I think that the more important question behind is of whether the RD should > (or may) wait with a response until it has fetched the .w-k/c of the endpoint. > The example shows "respond first, then ask details", which we might > consider prescribing given that highly constrained clients might not manage > to multi-task the request and the response. (Dealing > 5.03 Sorry I'm Busy until their pending request is answered or = expired). I would have done an ACK (to stop resends) followed by a response when = the resources had been queried rather than returning two different responses that are different and would need to have a pending. If the client = cannot wait for the response, it knows that the message is being processed. However it would know not to shutdown until it has gotten a final = answer. I don't see any need to return some type of busy. The constrained client should be able to respond to questions while it is in the middle of = asking one. Jim >=20 >=20 > Best regards > Christian >=20 > (updating the issue tracker in parallel) >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Sun Apr 15 18:14:59 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 CC99A12D872; Sun, 15 Apr 2018 18:14:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152384129782.20960.16349162045599799033.idtracker@ietfa.amsl.com> Date: Sun, 15 Apr 2018 18:14:57 -0700 Archived-At: Subject: [core] Spencer Dawkins' Yes on draft-ietf-core-senml-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 01:14:58 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-senml-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for doing this work. It's impressive. From nobody Sun Apr 15 22:13:49 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 244C312D893; Sun, 15 Apr 2018 22:13:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152385562714.20981.11979029181023832211.idtracker@ietfa.amsl.com> Date: Sun, 15 Apr 2018 22:13:47 -0700 Archived-At: Subject: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 05:13:47 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-senml-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hopefully this is easy to address: §4.7 talks about how SenML can also be used to configure parameters and controlling actuators. That capability has some rather significant security implications, but I failed to find mention of it in the security considerations. That needs to be explicitly discussed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: §4.4: "If this value is a version number larger than the version which the system understands, the system SHOULD NOT use this object." Why not MUST NOT? Are there situations where an implementation might reasonably use an object with a higher version number than the implementation understands? Editorial/Nits: The title is misleading. It makes it sound like the document is just registering media types; in fact it defines SenML. §1, first paragraph: "This format was defined...": The antecedent of "this" is unclear, since the fact the document defines SenML has not yet been mentioned. §4.3, table 1: What do the asterisks mean? §5.1.2, paragraph starting with "Note that...": I'm surprised to find normative requirements buried in a note in an example. §10, first paragraph: " the an integrated sum...": competing articles. §14: "Sensor data can range from information with almost no security considerations..." s/security/privacy From nobody Sun Apr 15 22:15:20 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 25E1C12D893; Sun, 15 Apr 2018 22:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> Date: Sun, 15 Apr 2018 22:15:13 -0700 Archived-At: Subject: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 05:15:13 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-senml-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hopefully this is easy to address: §4.7 talks about how SenML can also be used to configure parameters and controlling actuators. That capability has some rather significant security implications, but I failed to find mention of it in the security considerations. That needs to be explicitly discussed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: §4.4: "If this value is a version number larger than the version which the system understands, the system SHOULD NOT use this object." Why not MUST NOT? Are there situations where an implementation might reasonably use an object with a higher version number than the implementation understands? Editorial/Nits: The title is misleading. It makes it sound like the document is just registering media types; in fact it defines SenML. §1, first paragraph: "This format was defined...": The antecedent of "this" is unclear, since the fact the document defines SenML has not yet been mentioned. §4.3, table 1: What do the asterisks mean? §5.1.2, paragraph starting with "Note that...": I'm surprised to find normative requirements buried in a note in an example. §10, first paragraph: " the an integrated sum...": competing articles. §14: "Sensor data can range from information with almost no security considerations..." s/security/privacy From nobody Mon Apr 16 00:46: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 7545512D886; Mon, 16 Apr 2018 00:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 k3y77LMtKm0q; Mon, 16 Apr 2018 00:46:37 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.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 F2132126BF0; Mon, 16 Apr 2018 00:46:30 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:211]) by smtp-cloud7.xs4all.net with ESMTPA id 7yqJfEbfL8U077yqJfCvcx; Mon, 16 Apr 2018 09:46:29 +0200 Received: from 2001:983:a264:1:a97d:6638:fb5:6cad by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 16 Apr 2018 09:46:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 16 Apr 2018 09:46:27 +0200 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: consultancy@vanderstok.org, Jim Schaad , draft-ietf-core-resource-directory@ietf.org, 'core' Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20180413182947.GE18031@hephaistos.amsuess.com> References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> <20180413182947.GE18031@hephaistos.amsuess.com> Message-ID: <7b887b22f034883c48b8a46c9c199ea3@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKcU1dwrc9HQWW36F1lGZxK7xtar7rzbj/97PEN+ZJDfIJaZbEUSot7S7L9PglKrE2VezRFBsQcIO2h1EGJilQ7kevjBfRWV9e+vXGHB6XvxFdoMbx0f Y4bxMVGTwfQEkaQ4kzAcsTRczUgiS3fCL/mFK7YBZkJEArCA3kI6k+TN/bRY7GLrbJlcqLHMCSv//cMQri5Fl59ssDK3rMlDGVImsBQCfFuvxJBRuXafq+gL mvtJO7xVXBRdaUvUrDCKOVlHg5ZJYgprntPYMhnzhK9O25WWG/stjtl3X7KAnMtI Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 16 Apr 2018 07:46:44 -0000 > >> > POST /rd?ep=node1 >> > - payload contains the set of resources the register. >> > - returns a location of /rd/yyyy >> > >> > POST /rd/yyyy?ep=node1 >> > - payload is empty. >> > >> > In the first post, the rd will infer a context based on how the >> > registration is done. The second post just says that the TTL value >> > is to be refreshed back to the life-time value. However, the >> > inferred context could also be changed. >> >> Thanks for the example; it would take me long to figure this out >> otherwise. >> >> Reading the update specification, the ep=node1 is illegal in the >> update. >> Specifying ep means creating a new registration. > > ep=node1 would be ...well not technically illegal (the template would > put the ep in extra-attrs, and the server hopefully not store it > there); > it is an attribute that is not changing and therefore SHOULD NOT be > included in the update by the client. I do not follow. Registration template: EP->RD POST URI template {+rd}{?ep,d,lt,con,extra-attrs*} Update template EP->RD POST URI template {+rd}{?lt,con,extra-attrs*} What distinguishes Update from registration? => the presence of ?ep,d saying that extra-attrs* can include ep makes life really difficult IMO. sending a POST to /rd/123 can create a new registration at /rd/123/567, according to me, we did not distinguish resources as registration resource or general rd resource. Am I missing something? > > A changed ep would not create a new registration (we're at a > registration resource already), but simply be refused. > >> sending the update >> POST /rd/yyy will update the lt value. >> It is allowed to change the value of con in the update POST >> specification. >> The question is: >> When an updating ep, different from the registering one, sends the >> update of >> lt, does the context change to the hosts relation value of the >> updating ep. >> >> My gut reaction is no. it does not change the context value in the RD >> because that needs an explicit ?con= in the update specification. >> >> A warning in the RD text to this effect looks reasonable. > > The text is already pretty explicit: > > "If the parameter is set in an update, it is stored by the RD as > the > new Base URI under which to interpret the links of the > registration, > following the same restrictions as in the registration. If the > parameter is not set and was set explicitly before, the previous > context value is kept unmodified. If the parameter is not set and > was not set explicitly before either, the source address and source > port of the update request are stored as the context." Do we understand that the hosts relation does not set the parameter? > > This allows for clients that do not keep a good eye on their addresses > but have their OS pick the latest one. > > Note that nobody other than the endpoint (or CT if created by one) may > manipulate a registration resource. but difficult to check or enforce. the registration has no memory of the registering ep. > > (If we wanted to allow other hosts to manipulate a different endpoint's > registration, we'd need something like a ?ct=keep or change in > semantics > to allow that -- but I'd like to have a good reason to do that in the > first place). > > From nobody Mon Apr 16 01:26:21 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 4CFAC127077 for ; Mon, 16 Apr 2018 01:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 t5b4ghOVHh4n for ; Mon, 16 Apr 2018 01:26:18 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.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 8998E126BF0 for ; Mon, 16 Apr 2018 01:26:18 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud7.xs4all.net with ESMTPA id 7zSqfF9ZQ8U077zSqfDBsu; Mon, 16 Apr 2018 10:26:16 +0200 Received: from 2001:983:a264:1:a97d:6638:fb5:6cad by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 16 Apr 2018 10:26:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 16 Apr 2018 10:26:16 +0200 From: peter van der Stok To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: consultancy@vanderstok.org, Carsten Bormann , Jim Schaad , Core WG mailing list Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20180413110301.GL18144@hephaistos.amsuess.com> References: <20180413110301.GL18144@hephaistos.amsuess.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfNqn5uXLycSZmLIvkwYzrLZtLlk5dJv0Mmj+XrJ//4FiF4LVJPbEFlAGWtdSaOy9LbZFLV0fspVohophkTXjXJPk96KSbwQNsoQ0cGsPvL85Fz0vc83x 7kGPzKEzSZPPP0UnQ+U2Yndk4p4cU13SsL1DOKsI16xx2aBxIl03YR3YrgCRj7JehfU4OESjU/WDk0mbJJtBFaa2jchDxQJxAiqcHRYftu1LIWykZ7ZOaKhv wQMGbGUE/gjrcMzm5n2O94T6mUtH7NHBy0l4BTPpmnPjY3y4rT3PTA2X/jWupxO1 Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 16 Apr 2018 08:26:20 -0000 Hi all, The extra-attrs* in the template has more consequence than I originally thought. Apparently, it allows any query-parameter used in a given link to be used in the RD and given a value. The consequence is that we do not have a resource directory but something more fine-grained: a query directory. A user can specify a large number of queries with different values in a link specification. The RD can then be queried for links with for example: nm="petervanderstok". Don't we want to contain the possible query parameters that we allow in extra-attrs*. An alternative is that exra-attrs* provides a list of the query parameters that are available for the link. Peter > > The good reason is that we are using URI templates in the registration > update operation: {+location}{?lt,con,extra-attrs*} > > While it should be intuitively obvious that for location="x://y/z?a=b" > and lt="42", the produced URI is "x://y/z?a=b<=42", RFC6570 Section > 3.2.8 does not describe peeking back at what has been expanded to the > left side, but prescribes a "?" to be used before the first value, so > the produced URI would be "x://y/z?a=b?lt=42" (or possibly ?a=b%3Flt=42 > but not ?a=b<=42). > > If I'm reading RFC6570 wrong here, Location-Path can be allowed and I'd > be happy. > > Otherwise, we have to choose between using formal URI templates here > (vs. saying that some query parameters can be appended) and allowing > Location-Query. (Requiring anyone to understand ?foo=bar?baz=qux as two > keyswould be madness so it's not an option.) > From nobody Mon Apr 16 07:24: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 A97A612DA11 for ; Mon, 16 Apr 2018 07:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 keNdUtktyX-M for ; Mon, 16 Apr 2018 07:24:39 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 D090712DA14 for ; Mon, 16 Apr 2018 07:24:36 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id y128so18235023iod.4 for ; Mon, 16 Apr 2018 07:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=j22+OleBAOZvmFfkq8Gef3+fScPkfL/HnyodPlsMaK8=; b=MsHNBqIEDzNPbh8qAy5Ib1L9Yc6KE5ed7s0MwaJtAs6Oz0m1VIcVr3woQVvmEKO6XM p0V8t1VMLRCyoeOHzdpuCTgiHqdMzK1gvxu8i7dGFykahbLQOywIuXZRHSsBFuLjYxit ikaqlRDkx0VAYMXey16DqvykK9PG7l5O2dZuo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=j22+OleBAOZvmFfkq8Gef3+fScPkfL/HnyodPlsMaK8=; b=d1V9ZLLvGmoefZq8C+ECffeqpGbjL7EForGv9rgnbnJzAcdxWBibLWJIEJVj+XtdLb B8MimdnhY+R5/56/O/exmjILBYUJ0Llf72AhPKqXEUOKXjmjinBZcXbmihXwkm8K0RwW 0mgIghDMqkegTXMu2pnUH9EA8lpb7vYKefsiwHt7VqsKKinMJRjkY/qXC0mBvsWIIZ+Z Jsk+PxIkaVTtqf2ipBFQUwLAjbJ+ysUuDEyLmjIUnEukjYJWETe+BA+Q6P8rv0aYaDGt 612fzkkKnHoopTq/zVaedYTRQRHRfN361AVzlZ4K6nRv7Rs4vhHtZX1Th/7KWTQYaGw7 uDdQ== X-Gm-Message-State: ALQs6tCcSBYXOz7FbEPaF7xSOraDGWSgWK5jABBtUa56e5GyT7mZB1KX ++NhXSTenX2Zxhip8Vm9TLMmGQ== X-Google-Smtp-Source: AIpwx48LTfcGrFpgRx/ZKdakrKMMO9QBl94nOvN3TtMc2WEu/5y5eO1yyr77Kc/I7Vs+T9TNO6MehA== X-Received: by 10.107.137.224 with SMTP id t93mr4935274ioi.230.1523888675990; Mon, 16 Apr 2018 07:24:35 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id d14sm6014454ioe.24.2018.04.16.07.24.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 07:24:35 -0700 (PDT) To: Ben Campbell , The IESG Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml@ietf.org References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <4d7372a5-357b-a9f2-efd8-0ecdc3c76bf2@mozilla.com> Date: Mon, 16 Apr 2018 08:24:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AKFjvmISVYaoq2PxmaSwMgBQzPvjopiMN" Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 16 Apr 2018 14:24:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AKFjvmISVYaoq2PxmaSwMgBQzPvjopiMN Content-Type: multipart/mixed; boundary="pFfxrFLYVU5jOCizrfbnRvU5MWeF8otDk"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell , The IESG Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml@ietf.org Message-ID: <4d7372a5-357b-a9f2-efd8-0ecdc3c76bf2@mozilla.com> Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> In-Reply-To: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> --pFfxrFLYVU5jOCizrfbnRvU5MWeF8otDk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/15/18 11:15 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-core-senml-14: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-senml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hopefully this is easy to address: >=20 > =C2=A74.7 talks about how SenML can also be used to configure paramete= rs and > controlling actuators. That capability has some rather significant secu= rity > implications, but I failed to find mention of it in the security > considerations. That needs to be explicitly discussed. The actuation and configuration functionality has always been underspecified; I raised an issue about it last year: https://www.ietf.org/mail-archive/web/core/current/msg08871.html Although that concern was minimally addressed, more could be said to lock this down. Peter --pFfxrFLYVU5jOCizrfbnRvU5MWeF8otDk-- --AKFjvmISVYaoq2PxmaSwMgBQzPvjopiMN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrUsiEACgkQZWGMGH9o FKnz8hAA5dP5FHFLwzh6lDKgCJeQhkSyex05Jbb26Xu5+EFDtve5pQWbzVCDOJwG +NNRBvT/nWO20RRcNyUrUq11HIHP09eINexbAVpMhmG80C6Bq7fuNh0wsiUYNPsR uz9R20hcdjYanwpIbV9lPqtDLEUfnqqOhb1hel5qFr+wkmeEuW/6II6XKkIDhxGQ DYMgR/Rt7qERpMZ0nbWmT6OMRYfD2diSVBBtHYMfq+7hoaGDdNOp73cUP7TRZGHb x/t9X5PSx5G/a+fmRVhXkjCxbt7C6T6MMpAqHX42oJmjz2hBXf4M0ocBRTH3SxPW Xv/YKo7OIR/I2JjZPbhFz0mRDTUevoUUA92CXTXjA9D6Jfr93Yatm4ZW0Q71Jv9B qDWpnpt5e8UsEV+I34PCZ94c5MZ5BVgkAv6ujrL9LE9ryf/uOSetMx0M/dEtuC7P QOh0PUKnk3MNwvfTNEGgQ7nvcJfVxfKV8u0Hra4Uy6jTH2EqXNZfFMBdSIsmaWMa xsmJorkVi0upBUf+FRKe/f//b7zOFktVDbDrv+90Fu4xO/+I8O+N1Zms9UCODyby etnumk8V2LOwDlh4IRwpPz7y1rsoLGHsiq0pzJ717YipaLd9tAdcev/NFpY/AmBV JAMN2TUiMp/3982TezxLRQLRCVtx8SDSoFqtFirYvqn9a8xvCtU= =W4WN -----END PGP SIGNATURE----- --AKFjvmISVYaoq2PxmaSwMgBQzPvjopiMN-- From nobody Mon Apr 16 12:56:05 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 6F2021241F3; Mon, 16 Apr 2018 12:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152390856344.19573.405946028706072168.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2018 12:56:03 -0700 Archived-At: Subject: [core] Eric Rescorla's No Objection on draft-ietf-core-senml-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 19:56:03 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-core-senml-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4594 COMMENTS > > Abstract > > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Measurement Lists > (SenML). Representations are defined in JavaScript Object Notation You're kind of burying the lede here. This document defines SenML, it doesn't just define media type. > measurement every second, batch up 60 of them, and then send the > batch to a server. It would include the relative time each > measurement was made compared to the time the batch was sent in each > SenML Record. The server might have accurate NTP time and use the > time it received the data, and the relative offset, to replace the > times in the SenML with absolute times before saving the SenML Pack You use "Pack" here before you define it in S 3. > kinds of fields: base and regular. The base fields can be included > in any SenML Record and they apply to the entries in the Record. > Each base field also applies to all Records after it up to, but not > including, the next Record that has that same base field. All base > fields are optional. Regular fields can be included in any SenML > Record and apply only to that Record. It looks like it's permissible to intermix Base and Regular fields in the same record. Assuming that's so, it would be helpful to say so. > ("vs" for "String Value") and binary data ("vd" for "Data Value"). > Exactly one value field MUST appear unless there is Sum field in > which case it is allowed to have no Value field. > > Sum: Integrated sum of the values over time. Optional. This field > is in the unit specified in the Unit value multiplied by seconds. This text is hard to read, but the dimensional analysis seems potentially wrong, for at least some measurements. I assume you're thinking of something like watts and watt-hours. but if the value is for instance bits, then "bit-seconds" is not a meaningful unit, and yet you might want to sum these. > > The SenML format can be extended with further custom fields. Both > new base and regular fields are allowed. See Section 12.2 for > details. Implementations MUST ignore fields they don't recognize > unless that field has a label name that ends with the '_' character > in which case an error MUST be generated. How does this map to CBOR? I see you explain this later, but here would be helpful > concatenated name MUST consist only of characters out of the set "A" > to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_"; > furthermore, it MUST start with a character out of the set "A" to > "Z", "a" to "z", or "0" to "9". This restricted character set was > chosen so that concatenated names can be used directly within various > URI schemes (including segments of an HTTP path with no special Assuming I am understanding this correctly, then "/" is a problem inside a path component. > specified above puts strict limits on the URI schemes and URN > namespaces that can be used. As a result, implementers need to take > care in choosing the naming scheme for concatenated names, because > such names both need to be unique and need to conform to the > restricted character set. One approach is to include a bit string > that has guaranteed uniqueness (such as a 1-wire address). Some of citation for 1-wire please. > | Encoding | Size | Compressed Size | > +----------+------+-----------------+ > | JSON | 573 | 206 | > | XML | 649 | 235 | > | CBOR | 254 | 196 | > | EXI | 161 | 184 | Compression not working out so well for EXI > > To select a single SenML Record, the "rec" scheme followed by a > single number is used. For the purpose of numbering records, the > first record is at position 1. A range of records can be selected by > giving the first and the last record number separated by a '-' > character. Instead of the second number, the '*' character can be This is an odd notation as * usually means "all". Why not just omit the terminal #? > > New entries can be added to the registration by Expert Review as > defined in [RFC8126]. Experts should exercise their own good > judgment but need to consider that shorter labels should have more > strict review. New entries should not be made that counteract the > advice at the end of Section 4.4. Note that you say earlier that you don't expect to define new CBOR integers. That should probably be repeated here. > Sensor data can range from information with almost no security > considerations, such as the current temperature in a given city, to > highly sensitive medical or location data. This specification > provides no security protection for the data but is meant to be used > inside another container or transport protocol such as S/MIME > [RFC5751] or HTTP with TLS [RFC5246] that can provide integrity, This is the wrong citation for HTTP over TLS. That's RFC 2818. > We would like to thank Alexander Pelov, Alexey Melnikov, Andrew > McClure, Andrew McGregor, Bjoern Hoehrmann, Christian Amsuess, > Christian Groves, Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe > Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa > Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, Peter > Saint-Andre, Roni Even, and Stephen Farrell, for their review Nit: no comma after Farrell From nobody Tue Apr 17 00:23:31 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 335BF12EB12; Tue, 17 Apr 2018 00:23:30 -0700 (PDT) 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 vQp4Klhoo1ST; Tue, 17 Apr 2018 00:23:27 -0700 (PDT) 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 A502D12EB11; Tue, 17 Apr 2018 00:23:26 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id CEC5A497A7; Tue, 17 Apr 2018 09:23:23 +0200 (CEST) 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 E61016F; Tue, 17 Apr 2018 09:23:22 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 859F941; Tue, 17 Apr 2018 09:23:22 +0200 (CEST) Received: (nullmailer pid 27428 invoked by uid 1000); Tue, 17 Apr 2018 07:23:21 -0000 Date: Tue, 17 Apr 2018 09:23:21 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Cc: Jim Schaad , draft-ietf-core-resource-directory@ietf.org, 'core' Message-ID: <20180417072320.GB28669@hephaistos.amsuess.com> References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> <20180413182947.GE18031@hephaistos.amsuess.com> <7b887b22f034883c48b8a46c9c199ea3@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: <7b887b22f034883c48b8a46c9c199ea3@xs4all.nl> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2018 07:23:30 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Peter, On Mon, Apr 16, 2018 at 09:46:27AM +0200, peter van der Stok wrote: > > ep=3Dnode1 would be ...well not technically illegal (the template would > > put the ep in extra-attrs, and the server hopefully not store it there); > > it is an attribute that is not changing and therefore SHOULD NOT be > > included in the update by the client. >=20 > I do not follow. > Registration template: > EP->RD > POST > URI template {+rd}{?ep,d,lt,con,extra-attrs*} >=20 > Update template > EP->RD > POST > URI template {+rd}{?lt,con,extra-attrs*} >=20 > What distinguishes Update from registration? =3D> the presence of ?ep,d > saying that extra-attrs* can include ep makes life really difficult IMO. What distinguishes them is the first part of the template: The registration goes to /rd. The update goes to /reg/1234 (and should be {+location}). (Example paths used without loss of generality.) > sending a POST to /rd/123 can create a new registration at /rd/123/567, > according to me, we did not distinguish resources as registration resource > or general rd resource. I do not think so. It is nowhere that we indicate that the Registration Update operation on the location (POST /reg/1234) creates anything or returns a Location. (General note on POST: POST doesn't necessarily mean "create this as a new resource under", its general meaning is "Enact whatever your thing is with this data". That can often be "store in a new resource" as it is with the /rd directory resource.) > > The text is already pretty explicit: > >=20 > > "If the parameter is set in an update, it is stored by the RD as the > > new Base URI under which to interpret the links of the registration, > > following the same restrictions as in the registration. If the > > parameter is not set and was set explicitly before, the previous > > context value is kept unmodified. If the parameter is not set and > > was not set explicitly before either, the source address and source > > port of the update request are stored as the context." >=20 > Do we understand that the hosts relation does not set the parameter? Where does rel=3D"hosts" come into play here? > > This allows for clients that do not keep a good eye on their addresses > > but have their OS pick the latest one. > >=20 > > Note that nobody other than the endpoint (or CT if created by one) may > > manipulate a registration resource. >=20 > but difficult to check or enforce. the registration has no memory of the > registering ep. It doesn't need to be enforced, only to be trusted. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrVoN8ACgkQOY0REtOk veGRUw/+PGcdiVmSDzvQhjU/9ns8XyYaPEo/n6rPPQw+eX4hRTXmjwneYKHqvGxH P+3Q662ilgiNLjqGT8tZEwzokD3fZK+qj47hDtcUgxLpPzVO25ziUX9kuGXmyMUr 36jU4HfQjN9Ibcw7LXB2d2moAl6outf4jB6fPp+3KhvQOratvV/+FXKHJrNRB8AA Q9KjuceVVvnxN2YRrvlKK7C6OEvGpxTfj22h3xJYFgyTffiBuHt0QUY+cDY4viPp VEQo9deURpfgQ0F32v6L/yxY6Bk/dHC8149YTQMJDfVeI2rjn2CeJ1ZkAsMu0KJj RZR+85TtGKbXquve8aVIAq4QjH7UZTBW6l604K+LNtgmsVNv3vjlJukvPnL1sN4b St8GDMavUU020WKn9l0riIjxTs/Bv+XHF4wupbwFR6gYEDsUNnnVksl8/sRpnd/x vIrEpAXasP+hsAYzC1I8v//7UywRyAUnWDXg3bT9DAtQKTcbTbpXDOr+a/rK2Ohq VA5/5DKmbBqje7ykrqdEtELk+0WV56AoQorek9I8OLGlJ5Gqcxige49ZVfW05X0o chXRIzxz0/h8xRieo/o8NMpi+dVABYR26naAC6bRlifDRyWgbVnQxOlf3nt9ikwT 9t8+0SgwV6rv6bjfFXdGwUMM+lDGMz7zOK/K7l2MPH0gWysAw0g= =oAe0 -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From nobody Tue Apr 17 06:18:19 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 7F6F312EB3F; Tue, 17 Apr 2018 06:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OA0md0m2UQkI; Tue, 17 Apr 2018 06:18:13 -0700 (PDT) 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 53ECD12EB35; Tue, 17 Apr 2018 06:18:13 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9587C497AD; Tue, 17 Apr 2018 15:18:10 +0200 (CEST) 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 B669E1B2; Tue, 17 Apr 2018 15:18:06 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1AD5D35F; Tue, 17 Apr 2018 15:18:06 +0200 (CEST) Received: (nullmailer pid 15925 invoked by uid 1000); Tue, 17 Apr 2018 13:18:04 -0000 Date: Tue, 17 Apr 2018 15:18:04 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: consultancy@vanderstok.org, draft-ietf-core-resource-directory@ietf.org, 'core' Message-ID: <20180417131803.GA3716@hephaistos.amsuess.com> References: <053601d3c9e8$84da96f0$8e8fc4d0$@augustcellars.com> <7be5aeccaf53c373bcc999136dfec5cb@xs4all.nl> <06f101d3cc2d$8d3287d0$a7979770$@augustcellars.com> <0ef32a74d6b492e4e8e8fd4c917467c5@xs4all.nl> <20180413182947.GE18031@hephaistos.amsuess.com> <011f01d3d4fb$46f2bf70$d4d83e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <011f01d3d4fb$46f2bf70$d4d83e50$@augustcellars.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Questions on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2018 13:18:16 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, hello RD authors, On Sun, Apr 15, 2018 at 01:49:38PM -0700, Jim Schaad wrote: > I am less worried about the observation jitter problems than I am about t= he > turnover on groups. Given that groups are defined in terms of the href > returned from an endpoint registration this means that groups are going to > be updated every time. I really think that the location needs to not cha= nge > for the lifetime of the registration not just the EXCHANGE_LIFETIME. I am > not sure that idempotent means anything useful when looking at doing > registrations because I don't really know what it would mean to say > something is idempotent here. Does it mean that if nothing changes then > nothing happens or just that if you register the same thing then the same > set of events should happen w/ the same outcomes. But the location does not change over the lifetime of the registration (see also my parallel response to Peter at [1]) unless I got something very wrong. Only if an endpoint re-registers (ie. sends the same POST to /rd), long-term idempotency does become the matter. But I'd argue that this is close enough to situations of "the EP did not update its registration in time and already got kicked out" than to regular updates. Not that we'd already have an answer to how group management interacts with temporarily timed-out clients; maybe we should solve that first and then come back to the topic of idempotency. [1]: https://mailarchive.ietf.org/arch/msg/core/IYkEs59MMdPWPH5nOjiYyO6juFY > > > > 3. How are href comparisons done. > [...] >=20 > I am not sure what you are saying. I do comparison followed by > serialization at the moment. I do the resolution during serialization and > not during comparison. This is the reason that I was asking the question. I'd say "compare the resolved absolute references", in other words "resolve, then compare, then serialize". That's more work for the RD (and for you as an implementor), but matches more closely the expectations of the client, and should be better suited for later steps with protocol-negotiation. > > We are not actually describing a distributed RD here, this is only > > to keep the door open for such extensions. > >=20 > > Would it help if we changed the example to say > >=20 > > GET coap://rd.example.com/ep?gp=3Dlights1 > > Res: 2.05 Content > > ;con=3D"coap://[2001:db8:3::123]:616= 16"; > > ep=3D"node1";et=3D"oic.d.sensor";ct=3D"40";lt=3D"600", > > ;con=3D"coap://[2001:db8:3::124]:61616"; > > ep=3D"node2";et=3D"oic.d.sensor";ct=3D"40";lt=3D"600" > >=20 > > ? It would just indicate that the registration resource is hosted by > > the same RD but on another protocol (presumably because the endpoint > > registered using coap+tcp, and that Location can't just jump > > protocols). >=20 > Yeah, that whole question jumps back to the question - if it is on a > different schema is it the same resource or a different resource. I thi= nk > that the example with the explanation would be better. Unless something explicitly says that it is the same, it is not. Text proposal at [2] for review by the other authors. [2]: https://github.com/core-wg/resource-directory/pull/129 > > What use cases do we have for exposing a lifetime in the endpoint > > lookup at all? > >=20 > > (If we have none, an RD might just as well not display a lifetime). >=20 > All of the cases that I can think of can be done with observe. I think t= hat > this probably does not need to be discussed except to say that max-age > should not be set to this value. There is always a Max-Age, it has a default value of 60 (seconds). > > I think that the more important question behind is of whether the RD > > should (or may) wait with a response until it has fetched the .w-k/c > > of the endpoint. The example shows "respond first, then ask > > details", which we might consider prescribing given that highly > > constrained clients might not manage to multi-task the request and > > the response. (Dealing 5.03 Sorry I'm Busy until their pending > > request is answered or expired). >=20 > I would have done an ACK (to stop resends) followed by a response when the > resources had been queried rather than returning two different responses > that are different and would need to have a pending. If the client cannot > wait for the response, it knows that the message is being processed. > However it would know not to shutdown until it has gotten a final answer.= I > don't see any need to return some type of busy. The constrained client > should be able to respond to questions while it is in the middle of asking > one. I was not so much thinking about returning "busy" than about returning "Success" in the sense of "I've got your request; whatever happens further is out of your control". Given that two RDs are behaving observably different here, I'm opening this as an issue (basically "should we manadate your behavior or is either fine, and if the latter do we need to warn simple client implementors?") at [3]. [3]: https://github.com/core-wg/resource-directory/issues/130 Thanks for your input Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrV9AcACgkQOY0REtOk veGmyw/9FzzGGkHUU0qhS0vf+MkRLUZIp9J2tshinKXwY2U5nKeDBjzh/Wdvit4Z Da7tBybpIRnpyOzJX9RhuxytbgJqewyO9ZRdbf9abg20gGIGdMO+oFjyQEZt0Jv1 p//2i9XV3IbqCJkPu8qUn5qCcs+eFwvbfGKa9V/ayI6rrcjXm7mYxBssBxo4ji5q b8yMENkbuQuJsLLATeh/SpzKAGBIqVhIHuXxuPiCT9wTWw5rceuF/qsUzi5q/yLt wzfyXJa9JRxq6KHhxN3CsVvtM0lAu33sY8ZlIB8I88YrLaB3JUu1nsT//my5myaf 5pYHQaGDm/VshlcU75vAO+ZxkOgE+ori5+WV+1xljd4FnxBZmZWpX8gXNyQYk+yw MOXVRE715klK+ddk5meDEYsfKfdfKK4i9pP+WvvqTb0KGwdEk3iVRj9a1s2AgJfg MBkeTmNd5ZHFInJ19hJZqArd0Vhs9uJIg0iXmU9iHG51pT63dqkCwH7htvqAwP2t uwjGlmGj/LcFWz+2Z1RPX3PzoQ+W/qt2gbF0GpZvOUj7mZZU90INnogBABJukgWA 2U1Q+gmLfsnJ11znbBpi9JetiilxOnmocSWzDXkK1INRnMNngTjVQy5FP4XyDspn JTZh4WiV9IV6mQenOMgo4OCdv0vgZH5TuzL4zXg1HfNPXNJa2FE= =TQOK -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From nobody Tue Apr 17 08:26: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 6D41C12D955 for ; Tue, 17 Apr 2018 08:26:08 -0700 (PDT) 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 Fqu3A_Dh3c6q for ; Tue, 17 Apr 2018 08:26:05 -0700 (PDT) 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 655F112D953 for ; Tue, 17 Apr 2018 08:26:05 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7CACC497AB; Tue, 17 Apr 2018 17:26:02 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5E7566F; Tue, 17 Apr 2018 17:26:01 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 13F1831; Tue, 17 Apr 2018 17:26:01 +0200 (CEST) Received: (nullmailer pid 22057 invoked by uid 1000); Tue, 17 Apr 2018 15:25:59 -0000 Date: Tue, 17 Apr 2018 17:25:59 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Jim Schaad Cc: 'Carsten Bormann' , 'peter van der Stok' , 'Core WG mailing list' Message-ID: <20180417152558.GA18144@hephaistos.amsuess.com> References: <20180413110301.GL18144@hephaistos.amsuess.com> <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> <011501d3d4ea$384220d0$a8c66270$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Z83JOb+Pp/DrQW9p" Content-Disposition: inline In-Reply-To: <011501d3d4ea$384220d0$a8c66270$@augustcellars.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2018 15:26:08 -0000 --Z83JOb+Pp/DrQW9p Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2018 at 11:47:32AM -0700, Jim Schaad wrote: > Carsten Bormann wrote: > > We could also use formal URI templates and just say that they are to be > > interpreted in the sensible way described above. > >=20 > > (I=E2=80=99m not a fan of RFC 6570 URI templates at all, because the ap= proach is full of > > brokenness of the kind you describe(*); but it was available at the tim= e=E2=80=A6) >=20 > I would agree that I would not have read this as needing to have two > "?" characters in the query parameters. My issue is that I worry > about the case that an RD decides to use foo=3DXXX as the location query > and then some application decides to use foo as a query parameter in > the extra parameters or in a link description. This works fine on RD > implementation #1 because it is just using a location path to point to > the end point, but when it hits RD implementation #2 which is using > the location query as well it starts failing. =20 There would not be a conflict with use in links descriptions, but still would be with extra parameters in a registration update. On those grounds I'll propose a text to rule out query parameters. Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Z83JOb+Pp/DrQW9p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrWEfwACgkQOY0REtOk veHjMg/9HUqoum3e7axIHzfs/F8DgzoUx/fNPzFdAgY/KkJKyKV6BEB5Q1ESA9YW GZliSYHUZIUT17YhUjyuJHa1D9RVWpvXgsVdGBwEyxPsPu9ghvi22xJBLbcZJN8g FaB27GQ7ouZbZhSvWKb6QR1aPxrO+3jEEVgekxzBBJSZqSmIc++Q5FTMSfddHx+U F/WHY/5ll+sqtzuyfOO0xsuwHwrwNBB+/uWVVOSYt2vjCStt/DTRSuDfG8z6Whfe nnJSSdAwOozzx7y6TveLZZ4EShvElVLbLWpM1j/RnXI05R7ewaT3uETvCfMh5+EH 1+OdMIj1ObmQ5H80kzxgYHv+7tzHIG9c5i2ak/KZpwDdIUp1YuJyBBuoVvHxvXhC yhovdlk2xgz5etV1JPt5112fRJa20pGUfBbC8DcTTGrLfXT12DOcRa8Lei536PKw 6SkY/zzWOjBXhHsnmXjn6u0MLCveRULW2nXm4HTu2r5QO8kullFNNRetX36TEuj8 Jc+LfwxZNaITyGmAI/SvaIHctIWaJ0zURj4eNp/pB1uAV42WUFqAf9t29AoPJICH 49TjEiMkHaeGt9tgI3OImD75D+lTTsRCBGzqbBniuCUGA0t389Z49MCFrCC3zn5R m/1mzzwxU36fbyxCE13uA9eGDrL2yjmwOa4XqlyAhHbNe6u+Fco= =0iwI -----END PGP SIGNATURE----- --Z83JOb+Pp/DrQW9p-- From nobody Tue Apr 17 08:50: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 56D6C124319 for ; Tue, 17 Apr 2018 08:50:46 -0700 (PDT) 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 Yp-uoXQ9NP7Q for ; Tue, 17 Apr 2018 08:50:43 -0700 (PDT) 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 C7AF21200FC for ; Tue, 17 Apr 2018 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3HFo3mt009182; Tue, 17 Apr 2018 17:50:03 +0200 (CEST) Received: from client-0049.vpn.uni-bremen.de (client-0049.vpn.uni-bremen.de [134.102.107.49]) (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 40QV7b1ChhzDWcF; Tue, 17 Apr 2018 17:50:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <011601d3d4eb$0abcba20$20362e60$@augustcellars.com> Date: Tue, 17 Apr 2018 17:50:02 +0200 Cc: =?utf-8?Q?=22Christian_M=2E_Ams=C3=BCss=22?= , peter van der Stok , Core WG mailing list X-Mao-Original-Outgoing-Id: 545673000.7351021-371eb1b2ab0bbb689e5ac4891d4097bc Content-Transfer-Encoding: quoted-printable Message-Id: <896368D2-5353-437F-A87C-51C76D7AA797@tzi.org> References: <20180413110301.GL18144@hephaistos.amsuess.com> <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> <011601d3d4eb$0abcba20$20362e60$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2018 15:50:46 -0000 Hi Jim, >> In updating a document, we can go as far as we want. >> But of course we want to be reasonable and make sure we don=E2=80=99t = invalidate >> existing implementations of link-format. >> Instead of doing a link-format v2, the idea is live with v1 and move = over to >> JSON/CBOR. >=20 > Doing this is going to make my life as an implementor really a mess. = I will no longer be able to simply have a single representation of the = internal data structure and do the parsing as serialization to a common = format. I am now going to need to remember what the original = representation was and do the serializations differently based on that = value. In addition to this, all of my internal calls to setup the link = format to begin with need to have this distinction so that things get = serialized correctly. =20 That would indeed be a disaster, and I thought we can avoid all of this. = =20 My assumption was that we can move forward the data model while staying = compatible with the older serialization. > What would this mean for serializing out /.well-known/core - are the = meanings different if one serializes to cbor as opposed to link-format? =20= If we don=E2=80=99t want to carry forward the idiosyncrasies of = link-format to JSON/CBOR, that is the inevitable result. =20 But this should be doable with a small piece of code in the serializer, = not by having two different data models. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 17 09:40: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 AA9F9126B72 for ; Tue, 17 Apr 2018 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 yYftnhFlm3k7 for ; Tue, 17 Apr 2018 09:40:21 -0700 (PDT) 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 6172F124B18 for ; Tue, 17 Apr 2018 09:40:21 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5825B497AB; Tue, 17 Apr 2018 18:40:19 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 817336F; Tue, 17 Apr 2018 18:40:18 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3D93B31; Tue, 17 Apr 2018 18:40:18 +0200 (CEST) Received: (nullmailer pid 23853 invoked by uid 1000); Tue, 17 Apr 2018 16:40:17 -0000 Date: Tue, 17 Apr 2018 18:40:17 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann , Jim Schaad Cc: Core WG mailing list Message-ID: <20180417164016.GC28669@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline In-Reply-To: <011601d3d4eb$0abcba20$20362e60$@augustcellars.com> <29B20CA2-4179-4BBA-A0A7-5365C5A2BE85@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Report on first Resource Directory plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2018 16:40:25 -0000 --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, hello Jim, On Fri, Apr 13, 2018 at 03:01:05PM +0200, Carsten Bormann wrote: > >> Well, the general feeling was that instead of going for a 6690bis, we > >> maybe want to let the link-format just fade out (In favor of > >> links-json/-cbor). > >=20 > > link-json/-cbor is not helping with the issue of [1]. >=20 > No; the intention would be to develop links-json/-cbor in such a way that= itself doesn=E2=80=99t have the issue. > (I.e., decouple it a bit from the idiosyncrasies of RFC 6690.) That means that a simple encoder like Appendix A becomes quite a bit more complex (it needs to learn URI parsing), as do implementations like Jim's. ("Doing this is going to make my life as an implementor really a mess. [...] I think this would make more problems that it would solve.") I'm not saying it should not be done, just pointing out that it's a big step for a document at that stage. To address the rest of Jim's text on that topic: > What would this mean for serializing out /.well-known/core - are the > meanings different if one serializes to cbor as opposed to > link-format? =20 I can't tell for links-json+cbor, but in general yes. For example, what is serialized in link-format as ;if=3D"core.s";rel=3D"x";anchor=3D"coap://1.2.3.4/bar", ;rel=3D"baz";if=3D"core.a";rel=3D"x";anchor=3D"coap://1= =2E2.3.4/bar", could be serialized equivalently in CoRAL(ish) as [ [2, // link ignore, // relation [ // target [1, 'coap'], // Scheme [3, h'01020304'], // IP literal, [6, "bar"], // path "bar" ], [ [2, // link rel:hosts, [[5, 0], [6, "foo"]], // absolute path with one component "foo" [ [2, attr:if, "core.s"], ], ], [2, rel:baz, [[5, 3]], // relative path "baz" constructed from name of the rel [[2, attr:if, "core.a"]], ]]]] which is not at all alike the link-format serialization in that it even constructs relative references in a completely different way. As long as an RD only supports link-format and possibly strictly link-format-compatible CBOR/JSON versions are around, the data model can be an ordered string-valued multi-dictionary with special meaning but only string handling for href and anchor. With other serializations, those need to become URIs. The stable data model is annotated web links between URIs; I hope that RDF is a suitable data model too (HSML and CoRAL seem to indicate that). The href-and-anchor-as-strings model is a simplification that can be suitable for link-format, but not the general case. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlrWI2oACgkQOY0REtOk veGgng//dmfUQfqS2xOTmsGrQbA+LewbuizpPkREJglTqruTm7nArDmVqm3NQUnn VbHinCStPk8UKlfYAvLEUBkUXRvN4pozKTm3TsEdvPs2b787DTJwiF+qWJnjKkVn G6/K+ZuLmfuEUhka5IpVdlsCF06gF0OT1HWE/XIuUCcZgpqSTOuWLQLvPy2vBlWp FjLAi1DPMU+9T7rDOKVR1vq/IkqLAPOk8rF9RP/YQhsYmjgOw455suFL9iBpG0MA 9XMrfJ0AUu9trGZ7siAgJ/W22Zikc3DepWJWy7SKpuiy/pL7RNYm/u7g+1LaEKWg +WeaCIL+HyPMuFvtoL6Lm828GpL2+gfODFt8CPKw198X2ZXMGLQgdX88zNVNAIUb jibomVc60JG/2SYm/n11D+Wg8X46aUFlMTYTtNnSasRsc0mZHzO69gJxjnq4AbbJ SI+E+CxaOyntBqJchiYhFmgqfjCJy3aSFC4saYRqQzvDJNPgy2mu9OuDjwWZcXJg Lhx2zQI76ma5PnOu6eBkysldhjUhKTMtZVgiz6dD1SasoPbaDcNxQJt1t+0Q9002 G9acLN0B8msY0eOX5ejKK+K7mdaRongVe0ZxX5mEwqC1buE+XQ6tKULVnCscLkxu yQu9dlaMu1DRk8lUqaHcO91jWUpkbxOvRhVG+trUY9J4COe6lG0= =It6k -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C-- From nobody Wed Apr 18 18:45: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 E778F12D877; Wed, 18 Apr 2018 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=H3H86Q2I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MF77tJL6 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 84_ncaTvHvye; Wed, 18 Apr 2018 18:45:34 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1942127871; Wed, 18 Apr 2018 18:45:33 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 44BE021990; Wed, 18 Apr 2018 21:45:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 18 Apr 2018 21:45:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=P7Iipe5SytsJbNVGdKcn8zEqhMjD/ isVxMq8Kqx4g8o=; b=H3H86Q2IUfWU2FPYUvIlxHP0AOlxv5TGui+DIcTRdIaMM XlC7eaUkM/axe3uq92Yr1R8Qz9UHaINMLOJEOdu+nkL7Wqrh7lY+o2ipAC0Fh0R6 cRGoVqw7UWHyfe0SbvNwHeJEYsZ3tc8itn4SgZjrxFdODOyP1mHTOV2HyLf8GoxW UHkYFvApUlC9l0WsIFSxNBMaKnGEpsYg7mfPoADByHImC7c7JO/1ldeU1UR9kjNA iaFroS2m71knyY9v24Pz2YwQ0PXtQUI7qyFKwmmOSRHZEuz2ql7SJGRwFfI45ams bl6+My33OquNbSl4Hu98eQjTHQnAhB0f0nkgQ7N1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=P7Iipe 5SytsJbNVGdKcn8zEqhMjD/isVxMq8Kqx4g8o=; b=MF77tJL6UBwunA97dtXYPM CzEXkqiuh0/sEN7lRaiPmRjYqdbTGQqX5kalhsft6vcnPhOzLiGi90QjtIw+hdf9 cVubfHCQJO9SNfjoLrfOKrOAxVRpVQtKfA60JmTIUJF3TD6MM4R1HjZ4/90dMk/z /XmFRHhso09YIo+0wNAIpx438uxjRQoVCrN1WUDh019oj5bVu/ZPBgTikWHorHPp 6whvc+NrNQtF/PInrE7nKeQTvFIrukxawqq2/Jb3E/132vHwuenk95lyoU3kunvm l8PXFioo8juSvdRAgsus+fVNP4CG7slvGa2M0l0bXaoKflFfZNEevnrR3CecVsfw == X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id CDB0FE4350; Wed, 18 Apr 2018 21:45:32 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <16FAE862-3F10-4325-AB87-5DF31FBADF09@ericsson.com> Date: Wed, 18 Apr 2018 21:45:32 -0400 Cc: Roni Even , "gen-art@ietf.org" , "core@ietf.org" , "draft-ietf-core-senml.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <152221578820.29905.10455247933119493699@ietfa.amsl.com> <16FAE862-3F10-4325-AB87-5DF31FBADF09@ericsson.com> To: =?utf-8?Q?Ari_Ker=C3=A4nen?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-senml-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2018 01:45:36 -0000 Roni, thanks for your reviews. Ari, thanks for making the fixes. I have = entered a Yes ballot. Alissa > On Mar 30, 2018, at 7:03 AM, Ari Ker=C3=A4nen = wrote: >=20 > Thank you for the review Roni! Good catches.=20 >=20 > Seems we forgot to update the EXI example offsets when regenerated the = examples. I made a PR to include these fixes in the next revision: = https://github.com/core-wg/senml-spec/pull/102/files >=20 >=20 > Cheers, > Ari >=20 >> On 28 Mar 2018, at 8.43, Roni Even wrote: >>=20 >> Reviewer: Roni Even >> Review result: Ready with Nits >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-core-senml-?? >> Reviewer: Roni Even >> Review Date: 2018-03-27 >> IETF LC End Date: 2018-03-30 >> IESG Telechat date: 2018-04-19 >>=20 >> Summary: >> The document is ready for publication as a standard track RFC with = nits >>=20 >> Major issues: >>=20 >> Minor issues: >>=20 >> Nits/editorial comments: >>=20 >> 1. in section 5.1.6 "another devices" should be "other devices" or = "another >> device" 2. in section 8 "It can simply hard code the output = replacing the >> 1-wire device ID starting at byte 0x20 and going to byte 0x2F with = it's device >> ID". I think that the offset ix 0x10 to 0x1f >>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Apr 18 19:33:17 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 17C2012025C; Wed, 18 Apr 2018 19:33:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2018 19:33:15 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 02:33:15 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-senml-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I agree with Ben's DISCUSS. Additionally, I have serious reservations about introducing the concept of "base fields" that apply to subsequent array elemnets unless overridden. It seems to violate an abstraction barrier for at least some of the serialization formats, and prevents snippets from being composable and commutable absent the resolution/normalization process. It does not seem like the markup language and the document contain suffient safeguards against misuse to prevent security holes (both sensor data and commands could be misinterpreted). It seems that some substantially expanded text should be added on the hazards of the non-resolved format and giving guidance on when resolution/normalization must be performed in order to avoid correctness and security issues. There also seem to be sizeable risks associated with the semantics for time values. In particular, both with the use of an implicit-"now-ish", and with positive and negative values being interpreted with respect to a different absolute time base. (The involvement of base time is a further complication -- I do not remember any discussion of the interaction of a (positive) base time and a negative regular time, for example. I also do not remember any discussion of how the "now-ish" semantics make it actively harmful to do things like store-and-forward or archive SenML data (again, absent normalization), or what sort of granularity the "now-ish" semantics are expected to adhere to. (Is "yesterday" still considered "roughly now"?) I understand the desire for this sort of semantics, but the current specification seems to leave many potential problems exposed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4.4 Just "Considerations" is an unusual subject title. Having no Unit and no Base Unit is allowed, but you don't say what the semantics are in that case (presumably just a dimensionless counter for integers, with units not really being applicable to non-numeric types). Interestingly, Section 5.1.7 deems it fit to use "/" for the unit for a boolean value, even though "/" is supposed to be a (continuous/floating-point) ratio. Section 4.5 Just to double-check: you really do want to privilege this specification's version for eternity, for the purpose of being omitted from resolved records? Section 12.1 is there not some other units registry we can use? I fear begetting https://xkcd.com/927/ . Also, how is/should the table be sorted? Also in Section 12.1, number 9, is the need for case sensitivity in Units (or otherwise?) normatively covered anywhere? If not, should it? Section 12 Are Base fields supposed to get negative CBOR labels (and not other fields)? Is this mentioned explicitly somewhere? (Yes, I know that the intent is for no more CBOR lablels to be allocated, but that is only a SHOULD-level requirement.) In Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character. should that say something about "mandatory to understand but not defined in this document"? (Also in 12.3.1 et seq?) Section 13 Why are we talking about "executable content" at all? It seems quite unrelated to the rest of the document. From nobody Thu Apr 19 00:14:14 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 5136412D77C; Thu, 19 Apr 2018 00:14:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2018 00:14:13 -0700 Archived-At: Subject: [core] Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 07:14:13 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-senml-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who contributed to this document. --------------------------------------------------------------------------- §9 defines a URI fragment identification scheme that is intended to apply to senml+xml / sensml+xml. Since this uses the "+xml" structured syntax suffix, it has to comply with the fragment identifier considerations associated with that suffix. See: https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml In particular, +xml has requirements around citing section 5 of RFC 7303 (which this document doesn't), as well as requiring support for element() fragments; e.g.: coap://example.com/temp#element(/1/3) must be allowed as an alias for coap://example.com/temp#rec=3 If you want to restrict other aspects of XPointerFramework fragment identifiers, I believe you'll have to say so explicitly. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Benjamin's concerns about the ambiguity of time handling, and Ben's concerns about the security implications of writing to devices. I also have concerns about the notion of "now" and relative times with the streaming formats: is it relative to the time the stream was opened? Or relative to the time the record was received? Given that the document highlights time precisions down to the sub-microsecond level, and given that the record sizes are likely to be much smaller than the TCP maximum segment size, this presumably needs to take into consideration possible buffering effects due to Nagle's algorithm. --------------------------------------------------------------------------- §4.3: > | Data Value | vd | 8 | String (*) | string (*) | I find nowhere in the document that explains what these "(*)" notations mean. --------------------------------------------------------------------------- §8: > 8. EXI Representation (application/senml-exi) All the other MIME types here use the structured syntax format, which makes this one stick out as unnecessarily different. Given that the barrier for registering +exi as a suffix is "expert review," and the only real requirement that expert is going to check is a reference suitable for normatively citing (which EXI is by virtue of its appearance in the "Normative References" section of this document), it seems that the correct (and easy) thing to do here is simply go ahead and register "+exi". As an example: we just did this for +gzip; see the RFC Editor Note at https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/writeup/ From nobody Thu Apr 19 05:29: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 8DC7512D95C; Thu, 19 Apr 2018 05:29:56 -0700 (PDT) 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 UmV7EF504QSI; Thu, 19 Apr 2018 05:29:55 -0700 (PDT) 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 D1A071271FD; Thu, 19 Apr 2018 05:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3JCTogv028817; Thu, 19 Apr 2018 14:29:50 +0200 (CEST) Received: from client-0044.vpn.uni-bremen.de (client-0044.vpn.uni-bremen.de [134.102.107.44]) (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 40Rdbf1fQZzDX21; Thu, 19 Apr 2018 14:29:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2018 14:29:49 +0200 Cc: The IESG , draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 545833783.9225889-766ade997f1c709df086f16802abf5c5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2018 12:29:56 -0000 Here is my knee-jerk reaction to the other Ben=E2=80=99s review. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hopefully this is easy to address: >=20 > =C2=A74.7 talks about how SenML can also be used to configure = parameters and > controlling actuators. That capability has some rather significant = security > implications, but I failed to find mention of it in the security > considerations. That needs to be explicitly discussed. Indeed. TBD. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive: >=20 > =C2=A74.4: "If this value is a version number larger than the version = which the > system understands, the system SHOULD NOT use this object." >=20 > Why not MUST NOT? Are there situations where an implementation might = reasonably > use an object with a higher version number than the implementation = understands? Not really. Fair point. > Editorial/Nits: >=20 > The title is misleading. It makes it sound like the document is just > registering media types; in fact it defines SenML. Right, it is defining the media types. (Hmm, if =E2=80=9Cmedia types=E2=80=9D means =E2=80=9Cmedia type names = and their registrations=E2=80=9D, maybe we do need to change the title.) > =C2=A71, first paragraph: "This format was defined...": The antecedent = of "this" is > unclear, since the fact the document defines SenML has not yet been = mentioned. s/This format/The format established by these media types/ > =C2=A74.3, table 1: What do the asterisks mean? (See my knee-jerk comments on Adam=E2=80=99s COMMENTS.) > =C2=A75.1.2, paragraph starting with "Note that...": I'm surprised to = find normative > requirements buried in a note in an example. We should decide the whole stream pile before fixing this (which is just = a symptom of the less-than-well-definedness of streams). > =C2=A710, first paragraph: =E2=80=9C the an integrated sum...": = competing articles. s/the an/an/ > =C2=A714: =E2=80=9CSensor data can range from information with almost = no security > considerations..." > s/security/privacy Yep. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 19 05:32: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 4B2A912D95B; Thu, 19 Apr 2018 05:32:38 -0700 (PDT) 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 8Xq1oXGX4vvu; Thu, 19 Apr 2018 05:32:36 -0700 (PDT) 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 8155B1271FD; Thu, 19 Apr 2018 05:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3JCWWDC002751; Thu, 19 Apr 2018 14:32:32 +0200 (CEST) Received: from client-0044.vpn.uni-bremen.de (client-0044.vpn.uni-bremen.de [134.102.107.44]) (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 40Rdfm0TyYzDX24; Thu, 19 Apr 2018 14:32:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2018 14:32:31 +0200 Cc: The IESG , draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 545833945.573668-4e62fc8860b112665e4b3071e014379c Content-Transfer-Encoding: quoted-printable Message-Id: References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2018 12:32:38 -0000 Sorry about not properly trimming the To: list =E2=80=94 this was meant = to be internal between the authors. A consolidated response will be forthcoming, please disregard this = internal message=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On Apr 16, 2018, at 07:15, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-core-senml-14: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-senml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hopefully this is easy to address: >=20 > =C2=A74.7 talks about how SenML can also be used to configure = parameters and > controlling actuators. That capability has some rather significant = security > implications, but I failed to find mention of it in the security > considerations. That needs to be explicitly discussed. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive: >=20 > =C2=A74.4: "If this value is a version number larger than the version = which the > system understands, the system SHOULD NOT use this object." >=20 > Why not MUST NOT? Are there situations where an implementation might = reasonably > use an object with a higher version number than the implementation = understands? >=20 > Editorial/Nits: >=20 > The title is misleading. It makes it sound like the document is just > registering media types; in fact it defines SenML. >=20 > =C2=A71, first paragraph: "This format was defined...": The antecedent = of "this" is > unclear, since the fact the document defines SenML has not yet been = mentioned. >=20 > =C2=A74.3, table 1: What do the asterisks mean? >=20 > =C2=A75.1.2, paragraph starting with "Note that...": I'm surprised to = find normative > requirements buried in a note in an example. >=20 > =C2=A710, first paragraph: " the an integrated sum...": competing = articles. >=20 > =C2=A714: "Sensor data can range from information with almost no = security > considerations..." > s/security/privacy >=20 >=20 >=20 From nobody Thu Apr 19 05:43:19 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 EC34C12D956; Thu, 19 Apr 2018 05:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.fm header.b=HaRC7sff; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iyceHaBU 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 C8987S8OuipC; Thu, 19 Apr 2018 05:43:08 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249631271FD; Thu, 19 Apr 2018 05:43:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 362D821D41; Thu, 19 Apr 2018 08:43:07 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 19 Apr 2018 08:43:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=SlVGzTkmCr5py0TDFWwHZQBaem2hP FnWGxl4qO8qvFY=; b=HaRC7sffUcJOWfYLMG++zNeH5nfQ8AsihlM2lfFh2c9am cmUoZB21C8n0wR2qknsg4gymdrKrRuaZ8gFFW9rYRjhGHfUGpfVZW8wOoORHUih6 NlNP5YeJHp2uGQ/FImBZT7fatKSUEdjM8qvqV59hA7cZYoBJuDzbd6iMmLiVtJfV SbWF9WU92CnntEYDpbf5pDmr5+OoAvqcFvBpHW2rwIqNGNt1knee9JsVE59Rj9n3 bHPA/Dw99sKetwXdfImiHH052UiKepBJklu5qsNBHNGl8GKfClT8KqkFEvuezNYy w+H3Xohi5Ysin86xLCNH2mCRXRA2ggxXu0xF8dBEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SlVGzT kmCr5py0TDFWwHZQBaem2hPFnWGxl4qO8qvFY=; b=iyceHaBUMqz1NvNxXzHAOq 6YGnA+C0PWwJwwHclgD1Esy5wq82YYholxoHgHaeCYVPbymdE9+bMxhGUUR+LTQO fz/GntSit1An2s4fe73iT4GdX5vbvIF0eXOUzbfuIcxR3g90/wFqibI3pms7Srsg j60gBWpvQ0XG8ibBhREYR9mrhVLXNahOy7I/NWvbUOcoQlSCbGkw49coatXaLcEL JvZUFjEHm1CkkDVV2HFabmiW6J+gAYDtfOZwKxtBbXryZFXrwpLEWTq1rKAoBquk KsLzhJgT+ylS7o+q28i5kpqMkOdWBQ1wQ/nw15u7o7m0UVzDYuueGpQDqRO/Z53w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 154DC9E0B1; Thu, 19 Apr 2018 08:43:07 -0400 (EDT) Message-Id: <1524141787.503698.1343585024.0D5D9338@webmail.messagingengine.com> From: Alexey Melnikov To: Adam Roach , The IESG Cc: jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f3006b89 Date: Thu, 19 Apr 2018 13:43:07 +0100 In-Reply-To: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> References: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2018 12:43:10 -0000 Hi Adam, Reply to your DISCUSS point only: On Thu, Apr 19, 2018, at 8:14 AM, Adam Roach wrote: > =C2=A79 defines a URI fragment identification scheme that is intended to = apply to > senml+xml / sensml+xml. Since this uses the "+xml" structured syntax suff= ix, it > has to comply with the fragment identifier considerations associated with= that > suffix. See: >=20 > https://www.iana.org/assignments/media-type-structured-suffix/media-type-= structured-suffix.xhtml Hmm, I forgot about that! > In particular, +xml has requirements around citing section 5 of RFC 7303 > (which this document doesn't), as well as requiring support for element() > fragments; e.g.: >=20 > coap://example.com/temp#element(/1/3) >=20 > must be allowed as an alias for >=20 > coap://example.com/temp#rec=3D3 >=20 > If you want to restrict other aspects of XPointerFramework fragment ident= ifiers, > I believe you'll have to say so explicitly. I don't think there is a need to deviate from generic +xml fragment handlin= g. I suggest that the Section 9 of this draft: 9. Fragment Identification Methods is updated to reference Section 5 of [RFC7303], plus your example is added.= Then the media type registrations don't need to be updated, as they alread= y reference the fragment handling in Section 9. Does this work for you? Best Regards, Alexey From nobody Thu Apr 19 06:02:33 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 57DAD12D95D; Thu, 19 Apr 2018 06:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 wq_4uHB7xJa7; Thu, 19 Apr 2018 06:02:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 88DC2127978; Thu, 19 Apr 2018 06:02:30 -0700 (PDT) Received: from [172.18.0.15] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3JD2Lrp053081 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Apr 2018 08:02:22 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.18.0.15] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (15D60) In-Reply-To: <1524141787.503698.1343585024.0D5D9338@webmail.messagingengine.com> Date: Thu, 19 Apr 2018 08:02:15 -0500 Cc: The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> <1524141787.503698.1343585024.0D5D9338@webmail.messagingengine.com> To: Alexey Melnikov Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2018 13:02:32 -0000 This works for me as well, as long as the WG doesn=E2=80=99t object.=20 /a > On Apr 19, 2018, at 07:43, Alexey Melnikov wrote:= >=20 > Hi Adam, > Reply to your DISCUSS point only: >=20 >> On Thu, Apr 19, 2018, at 8:14 AM, Adam Roach wrote: >>=20 >> =C2=A79 defines a URI fragment identification scheme that is intended to a= pply to >> senml+xml / sensml+xml. Since this uses the "+xml" structured syntax suff= ix, it >> has to comply with the fragment identifier considerations associated with= that >> suffix. See: >>=20 >> https://www.iana.org/assignments/media-type-structured-suffix/media-type-= structured-suffix.xhtml >=20 > Hmm, I forgot about that! >=20 >> In particular, +xml has requirements around citing section 5 of RFC 7303 >> (which this document doesn't), as well as requiring support for element()= >> fragments; e.g.: >>=20 >> coap://example.com/temp#element(/1/3) >>=20 >> must be allowed as an alias for >>=20 >> coap://example.com/temp#rec=3D3 >>=20 >> If you want to restrict other aspects of XPointerFramework fragment ident= ifiers, >> I believe you'll have to say so explicitly. >=20 > I don't think there is a need to deviate from generic +xml fragment handli= ng. >=20 > I suggest that the Section 9 of this draft: >=20 > 9. Fragment Identification Methods >=20 > is updated to reference Section 5 of [RFC7303], plus your example is added= . Then the media type registrations don't need to be updated, as they alread= y reference the fragment handling in Section 9. Does this work for you? >=20 > Best Regards, > Alexey >=20 From nobody Thu Apr 19 07:57: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 4690F12741D; Thu, 19 Apr 2018 07:56:55 -0700 (PDT) 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 Uil_-ENXoIzI; Thu, 19 Apr 2018 07:56:53 -0700 (PDT) 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 2F624126DFF; Thu, 19 Apr 2018 07:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3JEujUD024657; Thu, 19 Apr 2018 16:56:45 +0200 (CEST) Received: from [10.40.8.7] (unknown [195.77.206.218]) (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 40Rhs83rw2zDX3d; Thu, 19 Apr 2018 16:56:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <1524141787.503698.1343585024.0D5D9338@webmail.messagingengine.com> Date: Thu, 19 Apr 2018 16:56:42 +0200 Cc: Adam Roach , The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml@ietf.org X-Mao-Original-Outgoing-Id: 545842600.819518-51c78cf3e1ac8315d6b6177bd9d201f5 Content-Transfer-Encoding: quoted-printable Message-Id: <0ADB7619-C79E-499E-851A-AD222D9E07D2@tzi.org> References: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> <1524141787.503698.1343585024.0D5D9338@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Apr 2018 14:56:55 -0000 Hi Alexey, > On Apr 19, 2018, at 14:43, Alexey Melnikov = wrote: >=20 > Hi Adam, > Reply to your DISCUSS point only: >=20 > On Thu, Apr 19, 2018, at 8:14 AM, Adam Roach wrote: >=20 >> =C2=A79 defines a URI fragment identification scheme that is intended = to apply to >> senml+xml / sensml+xml. Since this uses the "+xml" structured syntax = suffix, it >> has to comply with the fragment identifier considerations associated = with that >> suffix. See: >>=20 >> = https://www.iana.org/assignments/media-type-structured-suffix/media-type-s= tructured-suffix.xhtml >=20 > Hmm, I forgot about that! >=20 >> In particular, +xml has requirements around citing section 5 of RFC = 7303 >> (which this document doesn't), as well as requiring support for = element() >> fragments; e.g.: >>=20 >> coap://example.com/temp#element(/1/3) >>=20 >> must be allowed as an alias for >>=20 >> coap://example.com/temp#rec=3D3 >>=20 >> If you want to restrict other aspects of XPointerFramework fragment = identifiers, >> I believe you'll have to say so explicitly. >=20 > I don=E2=80=99t think there is a need to deviate from generic +xml = fragment handling. Klaus pointed out that this is counterproductive in a = content-negotiation setting. If I have >> coap://example.com/temp#rec=3D3 or >> coap://example.com/temp#element(/1/3) The server is not going to see the fragment identifier, so it doesn=E2=80=99= t know that, in the first case, all SenML variants could be handled by = the client, and in the second case, only XML should be sent. So we really want the fragment identifiers for all SenML variants to be = the same. RFC 7303 says: If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, it SHOULD NOT follow the naming convention =E2=80=98+xml=E2=80=99. Maybe choosing =E2=80=9C-xml=E2=80=9D is actually the (radical) answer = (which also would reestablish symmetry between -xml and -exi). (We are still discussing whether this observation is also disqualifying = +json and +cbor.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 20 08:47:04 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 C297B12D868 for ; Fri, 20 Apr 2018 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 3dqdv6GX6_8H for ; Fri, 20 Apr 2018 08:47:00 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 6E39B124D68 for ; Fri, 20 Apr 2018 08:47:00 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w3KFkM2d009238 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Apr 2018 17:46:23 +0200 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w3KFkMlO012931 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Apr 2018 17:46:22 +0200 Received: from DENBGAT9ER6MSX.ww902.siemens.net (139.22.70.92) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.389.1; Fri, 20 Apr 2018 17:46:22 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.136]) by DENBGAT9ER6MSX.ww902.siemens.net ([139.22.70.92]) with mapi id 14.03.0389.001; Fri, 20 Apr 2018 17:46:21 +0200 From: "Kovatsch, Matthias" To: Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "consultancy@vanderstok.org" , "'Carsten Bormann'" CC: "'Hannes Tschofenig'" , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0znBtoTmC857b0Co5UImt06WfqQCGI0AgAe4tOA= Date: Fri, 20 Apr 2018 15:46:20 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> In-Reply-To: <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.30] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2018 15:47:03 -0000 RGVhciBsaXN0DQoNCg0KImVwIiBpcyBhbiBhcHBsaWNhdGlvbi1kZWZpbmVkIGlkZW50aWZpZXIg Zm9yIHRoZSByZWdpc3RlcmVkIGVuZHBvaW50LiBJdCBpcyBhIHBhcmFtZXRlciBmb3IgcmVnaXN0 cmF0aW9uLCBidXQgYWxzbyBhIHRhcmdldCBhdHRyaWJ1dGUgdGhhdCB3aWxsIGhhdmUgdGhlIHNh bWUgdmFsdWUuIFRoZSBSRCBtdXN0IHN0b3JlIHRoZSAiZXAiIHBhcmFtZXRlciBmb3IgZWFjaCBy ZWdpc3RlcmVkIGVuZHBvaW50IGFuZCBhdHRhY2ggaXQgYXMgdGFyZ2V0IGF0dHJpYnV0ZSB0byBh bGwgdGhlIGNvcnJlc3BvbmRpbmcgbGlua3MgaXQgcmV0dXJucy4gQXMgUGV0ZXIgc3RhdGVkLCB3 aGVuICJlcCIgaXMgbm90IHVuaXF1ZSwgdGhlIGNsaWVudCBtdXN0IGFsc28gcHJvdmlkZSAiZCIs IHdoaWNoIG11c3QgYmUgcHJvY2Vzc2VkIHNpbWlsYXJseSBieSB0aGUgUkQuDQoNCkFzIHRhcmdl dCBwYXJhbWV0ZXIsIGl0IGlzIHVzZWQgZHVyaW5nIGxvb2t1cC4gQXBwbGljYXRpb25zIHdpbGwg dXNlIHRoZSBhcHBsaWNhdGlvbi1kZWZpbmVkIGlkZW50aWZpZXIsIG5vdCBhIGhhbmRsZSBnZW5l cmF0ZWQgYnkgdGhlIFJELCBub3QgdGhlIHNlY3VyaXR5IGNvbnRleHQuIFdoZW4gYSBjb21taXNz aW9uaW5nIHRvb2wgaXMgcmVnaXN0ZXJpbmcgYW4gZW5kcG9pbnQsIHRoZSBzZWN1cml0eSBjb250 ZXh0IGlzIGFsc28gZGlmZmVyZW50IGZyb20gdGhlIGVuZHBvaW50J3Mgc2VjdXJpdHkgY29udGV4 dCwgYW5kIGhlbmNlIGl0IGNhbm5vdCBiZSB1c2VkIGFzIGVuZHBvaW50IGlkZW50aWZpZXIuDQoN CkFzIGEgcmVzdWx0LCAiZXAiIG11c3Qgbm90IGJlIHJlbW92ZWQuDQoNCkkgdGhpbmsgImVwIiwg anVzdCBsaWtlIHRoZSBvdGhlciByZWdpc3RyYXRpb24gcGFyYW1ldGVycyB0aGF0IGFyZSBhbHNv IHRhcmdldCBhdHRyaWJ1dGVzLCBzaG91bGQgcmVjZWl2ZSBpdHMgb3duIHN1Yi1zZWN0aW9uIHdp dGggYSBwcm9wZXIgZGVmaW5pdGlvbiBhbmQgZXhwbGFuYXRpb24uDQoNCg0KUmVsYXRlZCB0byB0 aGlzIGlzIHRoZSBwcm9wZXIgZGVmaW5pdGlvbiBvZiAiaW5zIiwgd2hpY2ggdW5mb3J0dW5hdGVs eSB3YXMgbW92ZWQgb3ZlciB0byB0aGUgY29yZS1yZC1kbnMtc2QgZHJhZnQuICJpbnMiIGlzIHVz ZWQgdG8gZGlzdGluZ3Vpc2ggcmVzb3VyY2VzIHdpdGggdGhlIHNhbWUgInJ0Ii4gT3JpZ2luYWxs eSwgaXQgd2FzIHVzZWQgZm9yIHJlc291cmNlIHdpdGhpbiB0aGUgc2FtZSBkZXZpY2UgKGUuZy4s IDwvdDE+O3J0PXRlbXBlcmF0dXJlO2lucz1pbmRvb3IsPC90Mj47cnQ9dGVtcGVyYXR1cmU7aW5z PW91dGRvb3IpLiBCeSBub3csIGl0IG9mdGVuIGlzIGFzc3VtZWQgdG8gcmVxdWlyZSBnbG9iYWwg dW5pcXVlbmVzcy4gSSBjbGFpbSB0aGF0IHRoaXMgaXMgbm90IHJlcXVpcmVkIHdoZW4gImVwIiBp cyB1c2VkIGNvcnJlY3RseS4gVXNpbmcgYSBoaWVyYXJjaHkgb2YgImQiIC0+ICJlcCIgLT4gImlu cyIgcHJvdmlkZXMgbW9yZSBmbGV4aWJpbGl0eSB0aGFuIG1ha2luZyAiaW5zIiBnbG9iYWxseSB1 bmlxdWUuICJpbnMiIGNhbiBzdGlsbCBoYXZlIGEgZ2xvYmFsIG1lYW5pbmcgKGNmLiBpbmRvb3Ig dnMgb3V0ZG9vciksIGJ1dCBpdCBzaG91bGQgYmUgcmUtdXNhYmxlIGZvciBhbGwgcmVzb3VyY2Vz IHdpdGggc2ltaWxhciBpbnN0YW5jZSBzZW1hbnRpY3MuIFVuaXF1ZW5lc3MgaXMgYWNoaWV2ZWQg dGhyb3VnaCAiZCIgYW5kICJlcCIuDQoNCkkgdGhpbmsgImlucyIgc2hvdWxkIGJlY29tZSBwYXJ0 IG9mIHRoZSBSRCBkcmFmdCBhZ2FpbiB0byBiZSBkZWZpbmVkIHRvZ2V0aGVyIHdpdGggImQiIGFu ZCAiZXAiLCBhcyB0aGV5IGFyZSBwYXJ0IG9mIGEgbGFyZ2VyIGRpc2NvdmVyeSBmcmFtZXdvcmsu DQoNCg0KQmVzdCB3aXNoZXMsDQpNYXR0aGlhcw0KDQoNCg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hl IE5hY2hyaWNodC0tLS0tDQo+IFZvbjogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y Z10gSW0gQXVmdHJhZyB2b24gSmltIFNjaGFhZA0KPiBHZXNlbmRldDogU29ubnRhZywgMTUuIEFw cmlsIDIwMTggMjE6MzENCj4gQW46ICdDaHJpc3RpYW4gQW1zw7xzcyc7IGNvbnN1bHRhbmN5QHZh bmRlcnN0b2sub3JnOyAnQ2Fyc3RlbiBCb3JtYW5uJw0KPiBDYzogJ0hhbm5lcyBUc2Nob2Zlbmln JzsgY29yZUBpZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogW2NvcmVdIEVuZHBvaW50IENsaWVudCBO YW1lIC8gRW5kcG9pbnQgTmFtZSBpbiBSRCBkcmFmdA0KPiANCj4gDQo+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEFtc8O8c3MNCj4gPiBTZW50OiBGcmlkYXksIEFwcmls IDEzLCAyMDE4IDg6MTEgQU0NCj4gPiBUbzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7IENh cnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KPiA+IENjOiBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47IGNvcmVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW2NvcmVdIEVuZHBvaW50IENsaWVudCBOYW1lIC8gRW5kcG9pbnQgTmFtZSBpbiBSRCBkcmFm dA0KPiA+DQo+ID4gT24gTW9uLCBBcHIgMDksIDIwMTggYXQgMTA6MDQ6MDdBTSArMDIwMCwgcGV0 ZXIgdmFuIGRlciBTdG9rIHdyb3RlOg0KPiA+ID4gPiBJIGFtIGN1cmlvdXMgd2hhdCB3ZSBsb3Nl IGlmIHdlIHJlbW92ZSB0aGlzIGlkZW50aWZpZXIgYWx0b2dldGhlci4NCj4gPiA+ID4gVGhlIG9u bHkgdGhpbmcgdGhhdCBjb21lcyB0byBteSBtaW5kIGlzIGEgZGVidWdnaW5nIGNhcGFiaWxpdHkN Cj4gPiA+ID4gd2hlcmUgeW91IG1pZ2h0IHdhbnQgdG8gdGVzdCB5b3VyIHN5c3RlbSB3aXRob3V0 IGFueSBzZWN1cml0eSBwcm90b2NvbC4NCj4gPiA+DQo+ID4gPiBQcm9iYWJseSwgSSBjb21wbGV0 ZWx5IG1pc3VuZGVyc3RhbmQgeW91ciBzdWdnZXN0aW9uLg0KPiA+ID4gUmVnaXN0cmF0aW9ucyBp biB0aGUgUkQgbmVlZCBpZGVudGlmaWNhdGlvbiBzbyB0aGF0IHRoZXkgY2FuIGJlDQo+ID4gPiBj aGFuZ2VkLCByZW1vdmVkICwgdXBkYXRlZCwgZXRjLi4uDQo+ID4NCj4gPiBXZWxsLCB0aGUgbWFu aXB1bGF0aW9uIChjaGFuZ2UsIHJlbW92YWwsIHVwZGF0ZSkgYWxyZWFkeSBoYXBwZW5zDQo+ID4g aW5kZXBlbmRlbnRseSBvZiB0aGUgZW5kcG9pbnQgbmFtZSBvciBkb21haW47IHRoYXQgaXMganVz dCBib3VuZCB0bw0KPiA+IHRoZSByZWdpc3RyYXRpb24gcmVzb3VyY2UuDQo+ID4NCj4gPiBJbiB0 aGUgY3VycmVudCB0ZXh0LCB3ZSBhbGxvdyB0aGF0IHRoZSBlbmRwb2ludCBuYW1lIGlzIG5vdCBn aXZlbiBhdA0KPiA+IHJlZ2lzdHJhdGlvbiB0aW1lIGlmIGl0IGlzIGV4cGxpY2l0bHkgY29uZmln dXJlZCBhbmQgdGhlIFJEIGNhbg0KPiA+IHJlY29nbml6ZSB0aGUgZW5kcG9pbnQgYnkgaXRzIHNl Y3VyaXR5IGNvbnRleHQuDQo+ID4NCj4gPiA+IFJlZ2lzdHJhdGlvbnMgYXJlIGlkZW50aWZpZWQg YnkgdGhlIChlcCwgZCkgcGFpciwgdW5pcXVlIHdpdGhpbiBhIGdpdmVuIFJELg0KPiA+ID4gUmVt b3ZpbmcgZXAgaWRlbnRpZmllciB3aWxsIGZvcmNlIHlvdSB0byBmaW5kIGFub3RoZXIgaWRlbnRp ZmllciBmb3INCj4gPiA+IGEgcmVnaXN0cmF0aW9uLi4uLi4uLi4uDQo+ID4gPiBhbmQgeW91IGFy ZSBiYWNrIHRvIHNxdWFyZSAxIGl0IHNlZW1zLg0KPiA+DQo+ID4gSW4gYW55IGF1dGhlbnRpY2F0 ZWQgY29udGV4dCwgdGhhdCBjYW4gaWRlbnRpZmllciBjYW4gYmUgdGhlIHNlY3VyaXR5IGNvbnRl eHQuDQo+ID4gSG93IHRoYXQgY2FuIGJlIGV4cHJlc3NlZCBhdCBsb29rdXAgaXMgYW4gb3BlbiBx dWVzdGlvbi4NCj4gPiBBbiBlbmRwb2ludCBuYW1lIHN0cmluZyBjYW4gYmUgd2hhdCBnbHVlcyB0 aG9zZSB0b2dldGhlci4NCj4gPg0KPiA+IE9uIE1vbiwgQXByIDA5LCAyMDE4IGF0IDEwOjE0OjU0 QU0gKzAyMDAsIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCj4gPiA+IFRoZSBhcmd1bWVudCBzZWVt cyB0byBiZSB0aGF0IGlmIGEgY2xpZW50IGhvbGRzIGFuIGF1dGhvcml6YXRpb24gdG8NCj4gPiA+ IHJlZ2lzdGVyIGF0IGFuIFJELCB0aGF0IGF1dGhvcml6YXRpb24gbWF5IGltcGx5IGEgc3BlY2lm aWMgZW5kcG9pbnQNCj4gPiA+IG5hbWUuICAoSeKAmW0gbm90IHN1cmUgdGhhdCBpcyBhbHdheXMg dHJ1ZSwgYXMgdGhlIGF1dGhvcml6YXRpb24gbWF5DQo+ID4gPiBiZSBiYXNlZCBvbiBhIGNsYWlt IHRoYXQgZG9lcyBub3QgaGFwcGVuIHRvIHByb3ZpZGUgYW4gb2J2aW91cw0KPiA+ID4gY2FuZGlk YXRlIGZvciB0aGF0LikNCj4gPiA+DQo+ID4gPiBUbyBkaXNjdXNzIHRoaXMgZnVydGhlciwgd2Xi gJlsbCBuZWVkIHRvIGRpc2N1c3MgYXV0aG9yaXphdGlvbiBtb2RlbHMNCj4gPiA+IGZvciBSRCBh Y2Nlc3MuICBNYXliZSBoaWdoIHRpbWUgaW4gYW55IGNhc2XigKYNCj4gPg0KPiA+DQo+ID4gQ291 bGQgZXZlcnlib2R5IG1heWJlIHNrZXRjaCBob3cgdGhleSdkIGV4cHJlc3MgdGhlIHBlcm1pc3Np b25zIHRoZXkNCj4gPiB3b3VsZCBsaWtlIHRvIHNldCBvbiB0aGVpciBSRHM/DQo+ID4NCj4gPg0K PiA+IEknbGwgc3RhcnQgd2l0aCBzb21lIGFyYml0cmFyeSBvbmVzIHRoYXQgbWlnaHQgYmUgdXNl ZnVsIChhdCBsZWFzdA0KPiA+IHdpdGggc29tZSBoZWxwIGZyb20gQ3VubmluZ2hhbSdzIExhdyk6 DQo+ID4NCj4gPiBUcnVzdFRoZVdlYkNBczogIlRoaXMgUkQgYWNjZXB0cyBhbnkgcmVnaXN0cmF0 aW9uLCBwcm92aWRlZCB3aG8NCj4gPiByZWdpc3RlcnMgY2FuIHByZXNlbnQgYSBYNTA5IGNlcnRp ZmljYXRlIGNoYWluIHRvIG15IHN5c3RlbQ0KPiA+IGNlcnRpZmljYXRlcyB0aGF0IGNhcnJpZXMg YSBDb21tb24gTmFtZSBvciBTdWJqZWN0IEFsdGVybmF0aXZlIE5hbWUNCj4gPiB0aGF0IG1hdGNo ZXMgdGhlIGhvc3QgbmFtZSB0aGV5IGdpdmUgaW4gdGhlaXIgY29uIi4NCj4gDQo+IFRydXN0VGhl V2ViQ0FzICsgR29kQml0OiBUaGlzIFJEIGFjY2VwdHMgYW55IHJlZ2lzdHJhdGlvbiwgcHJvdmlk ZWQgd2hvIHJlZ2lzdGVycyBjYW4gcHJlc2VudCBhbiBYNTA5IGNlcnRpZmljYXRlIGNoYWluIHRv IG15DQo+IHN5c3RlbSBjZXJ0aWZpY2F0ZXMgdGhhdCBjYXJyaWVzIGEgY29tbW9uIG9yIGFsdGVy bmF0aXZlIG5hbWUgKG9yIG1heWJlIGFuIEVLVSkgdGhhdCBtYXRjaGVzIHRvIHRoZSBHb2QgY3Jp dGVyaWEuDQo+IA0KPiA+DQo+ID4gUmVxdWlyZUVLVTogIkxpa2UgVHJ1c3RUaGVXZWJDQXMsIGFu ZCBpZiBpdCB3YW50cyB0byBzZXQgYW4gZW5kcG9pbnQNCj4gPiB0eXBlIChldD0pLCB0aGF0IG11 c3QgYmUganVzdGlmaWVkIGJ5IGFuIEV4dGVuZGVkIEtleSBVc2FnZSBpbiB0aGUgY2VydGlmaWNh dGUuIg0KPiANCj4gSSB3b3VsZCBwcm9iYWJseSBnZW5lcmFsaXplIHRoaXMgcnVsZSB0byAtIFRo ZSBSRCBtYXkgZXh0cmFjdCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGZyb20gdGhlIGNlcnRpZmlj YXRlIGJleW9uZCB0aGUgbmFtaW5nIHRvIGVpdGhlcg0KPiBlbmZvcmNlIG9yIHN1cHBsZW1lbnQg YXR0cmlidXRlcyBzZXQgc3VjaCBhcyBlbmRwb2ludCB0eXBlcyBvciBkb21haW5zLg0KPiANCj4g Pg0KPiA+IEVQRnJvbUFDRTogIlRoaXMgUkQgdXNlcyAvcmVnLyR7ZG9tYWlufS8ke2VuZHBvaW50 fSBhcyByZWdpc3RyYXRpb24gVVJJcy4NCj4gPiBBbiBlbmRwb2ludCBjYW4gb25seSByZWdpc3Rl ciBpZiBpdCBob2xkcyBhbiBBQ0UtQUlGIHRva2VuIHRvIFBPU1QgdG8NCj4gPiB0aGF0IHJlc291 cmNlIGlzc3VlZCBieSBteSBBdXRob3JpemF0aW9uIFNlcnZlciAoQVMpLiINCj4gDQo+IEVQRnJv bUFDRTI6ICBUaGlzIFJEIHVzZXMgL3JlZz9lcD0ke2VuZHBvaW50fSZkPSR7ZG9tYWlufSBhcyBy ZWdpc3RyYXRpb24gVVJJcy4gIEFuIGVuZHBvaW50IGNhbiBvbmx5IHJlZ2lzdGVyIGlmIGl0IGhv bGRzIGFuIEFDRS0NCj4gQUlGIHRva2VuIHRvIFBPU1QgdG8gdGhhdCByZXNvdXJjZSBpc3N1ZWQg YnkgbXkgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKS4gIFRoZSB0b2tlbiBtYXkgY29udGFpbiB2 YWx1ZXMgZm9yIGZpZWxkcyBpbiB0aGUgVVJJLXF1ZXJpZXMNCj4gd2hpY2ggYXJlIHRvIGJlIGVp dGhlciBlbmZvcmNlZCwgb3Igc2V0IGlmIG5vdCBwcmVzZW50IGluIHRoZSByZWdpc3RyYXRpb24g cmVxdWVzdC4gIEV4YW1wbGVzIGFyZSBlcCwgZCwgZXQuDQo+IA0KPiA+DQo+ID4gUE5Gcm9tQUNF OiAiVGhpcyBSRCBhbGxvd3MgcmVnaXN0cmF0aW9uIG9mIGFyYml0cmFyeSBlbmRwb2ludHMsIGJ1 dA0KPiA+IGFkdmVydGlzaW5nIGFuIGF0PS4uLiAocmVnaXN0cmF0aW9uKSBvciBvbD0uLi4gKGxp bmspIGF0dHJpYnV0ZSAoc2VlDQo+ID4gY29yZS1wcm90b2NvbC1uZWdvdGlhdGlvbikgcmVxdWly ZXMgdGhhdCB0aGF0IHZhbHVlIGlzIGNvbnRhaW5lZCBpbiBhbg0KPiA+IEFDRSB0b2tlbiBmcm9t IG15IEFTLiINCj4gDQo+IFJTRnJvbUFDRTogVGhpcyBSRCBhbGxvd3MgcmVnaXN0cmF0aW9uIG9m IGVuZHBvaW50cywgYnV0IHJlc3RyaWN0cyB0aGUgcmVzb3VyY2VzIHRoYXQgY2FuIGJlIHJlZ2lz dGVyZWQuICBBbGwgcmVzb3VyY2VzIHJlZ2lzdGVyZWQgbXVzdA0KPiBiZSBmaWx0ZXJlZCBieSBt YXRjaGluZyBvbmUgb2YgYSBudW1iZXIgb2YgcGF0dGVybnMgcG90ZW50aWFsbHkgd2l0aCB2YWx1 ZXMgdGhhdCBjYW4gYmUgZGVmYXVsdGVkIGluLg0KPiANCj4gSmltDQo+IA0KPiA+DQo+ID4NCj4g PiBCZXN0IHJlZ2FyZHMNCj4gPiBDaHJpc3RpYW4NCj4gPg0KPiA+IC0tDQo+ID4gVG8gdXNlIHJh dyBwb3dlciBpcyB0byBtYWtlIHlvdXJzZWxmIGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVh dGVyIHBvd2Vycy4NCj4gPiAgIC0tIEJlbmUgR2Vzc2VyaXQgYXhpb20NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBs aXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQo= From nobody Fri Apr 20 09:00:52 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 D6ADF12D86D for ; Fri, 20 Apr 2018 09:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 WaTI6Ko9yvj8 for ; Fri, 20 Apr 2018 09:00:48 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 7DAB212D86B for ; Fri, 20 Apr 2018 09:00:48 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id w3KG0jMW023523 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Apr 2018 18:00:45 +0200 Received: from DEFTHW99ERKMSX.ww902.siemens.net (defthw99erkmsx.ww902.siemens.net [139.22.70.147]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w3KG0jPY022392 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Apr 2018 18:00:45 +0200 Received: from DEFTHW99EROMSX.ww902.siemens.net (139.22.70.201) by DEFTHW99ERKMSX.ww902.siemens.net (139.22.70.147) with Microsoft SMTP Server (TLS) id 14.3.389.1; Fri, 20 Apr 2018 18:00:44 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.136]) by DEFTHW99EROMSX.ww902.siemens.net ([139.22.70.201]) with mapi id 14.03.0389.001; Fri, 20 Apr 2018 18:00:44 +0200 From: "Kovatsch, Matthias" To: "core@ietf.org" CC: =?iso-8859-1?Q?=27Christian_Ams=FCss=27?= , "Michael Koster (michaeljohnkoster@gmail.com)" , "Vicari, Norbert" Thread-Topic: Resouce Directory - generic base URIs (con / anchor) Thread-Index: AdPYvrfECZuTGRASR2+jYj6wC+OEZQ== Date: Fri, 20 Apr 2018 16:00:43 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2C@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.30] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2CDEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Subject: [core] Resouce Directory - generic base URIs (con / anchor) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2018 16:00:51 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2CDEFTHW99EL4MSXw_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear list RD allows the "con" parameter to provide a base URI for relative resource U= RIs, when the registration is done from a different source address then the= registered endpoint itself. "con" is restricted to the scheme and authorit= y part of a URI, that is, no path segments are allowed. This came from the = assumption that all CoRE devices will naturally correlate with socket-addre= ss endpoints. However, a registered device(=3Dendpoint, "ep") might not be a natural endp= oint. When using gateways or device proxies, the base URI will have path se= gments and multiple logically different endpoints will share the same socke= t-address (e.g., coaps://gw.example.com/dev/d1, coaps://gw.example.com/dev/= d2, coaps://gw.example.com/dev/d3). This makes it expensive to move such logical endpoints, as updating "con" w= ill not help. All links have to be removed, changed to the new prefix, and = registered anew. This is a problem for some applications (including a bigger alliance using = CoAP), in particular because the patch mechanism is still to be defined - y= et rewriting URI prefixes still will not be really efficient even when havi= ng patch registration updates. I thus propose to generalize "con" to be any base URI that will be applied = to all relative links an endpoint registered. If there is a conflict with a deployed mechanism, we could look into adopti= ng "anchor" and let RD use it similarly to "con", but allowing full base UR= Is (including paths). Or we align with RFC 8288 altogether and replace "con" with "anchor": https= ://tools.ietf.org/html/rfc8288#section-3.2 Ciao, Matthias --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2CDEFTHW99EL4MSXw_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear list

 

RD allows the “con” parameter to provide= a base URI for relative resource URIs, when the registration is done from = a different source address then the registered endpoint itself. “con&= #8221; is restricted to the scheme and authority part of a URI, that is, no path segments are allowed. This came from the assumption = that all CoRE devices will naturally correlate with socket-address endpoint= s.

 

However, a registered device(=3Dendpoint, “ep&= #8221;) might not be a natural endpoint. When using gateways or device prox= ies, the base URI will have path segments and multiple logically different = endpoints will share the same socket-address (e.g., coaps://gw.example.com/dev/d1, coaps://gw.example.com/dev/d2, coaps://gw.e= xample.com/dev/d3).

 

This makes it expensive to move such logical endpoin= ts, as updating “con” will not help. All links have to be remov= ed, changed to the new prefix, and registered anew.

 

This is a problem for some applications (including a= bigger alliance using CoAP), in particular because the patch mechanism is = still to be defined – yet rewriting URI prefixes still will not be re= ally efficient even when having patch registration updates.

 

I thus propose to generalize “con” to be= any base URI that will be applied to all relative links an endpoint regist= ered.

If there is a conflict with a deployed mechanism, we= could look into adopting “anchor” and let RD use it similarly = to “con”, but allowing full base URIs (including paths).

Or we align with RFC 8288 altogether and replace = 220;con” with “anchor”: https://tools.i= etf.org/html/rfc8288#section-3.2

 

Ciao,

Matthias

 

--_000_4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2CDEFTHW99EL4MSXw_-- From nobody Fri Apr 20 13:50: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 7E9C812783A for ; Fri, 20 Apr 2018 13:50:05 -0700 (PDT) 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 sZy6leJOb_iB for ; Fri, 20 Apr 2018 13:50:03 -0700 (PDT) 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 EF47A1200FC for ; Fri, 20 Apr 2018 13:50:02 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B4D53499CF; Fri, 20 Apr 2018 22:49:59 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5035B6F; Fri, 20 Apr 2018 22:49:58 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0B1B931; Fri, 20 Apr 2018 22:49:58 +0200 (CEST) Received: (nullmailer pid 25303 invoked by uid 1000); Fri, 20 Apr 2018 20:49:57 -0000 Date: Fri, 20 Apr 2018 22:49:57 +0200 From: 'Christian =?iso-8859-1?Q?Ams=FCss'?= To: "Kovatsch, Matthias" Cc: "core@ietf.org" , peter van der Stok , "Michael Koster (michaeljohnkoster@gmail.com)" , "Vicari, Norbert" Message-ID: <20180420204957.GA6125@hephaistos.amsuess.com> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2C@DEFTHW99EL4MSX.ww902.siemens.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2C@DEFTHW99EL4MSX.ww902.siemens.net> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Resouce Directory - generic base URIs (con / anchor) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2018 20:50:05 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Matthias, thanks for bringing this to the list. On Fri, Apr 20, 2018 at 04:00:43PM +0000, Kovatsch, Matthias wrote: > I thus propose to generalize "con" to be any base URI that will be > applied to all relative links an endpoint registered. If there is a > conflict with a deployed mechanism, we could look into adopting > "anchor" and let RD use it similarly to "con", but allowing full base > URIs (including paths). We had considered that briefly but found it'd be too difficult for implementors for too little use cases; as you do describe use cases, we might reconsider it. The ugly thing about is: Registrations that are sent in application/link-format can not make use of a path component in the Base URI (which the con is), because RFC6690's resolution rules strip away the Base URI's path component by using Origin terminology. That means that registrations that would use such a con would in practice need to use a content format that does not use RFC6690 resolution rules, and right now it is still under discussion whether links-json will be safe from that. The references in the registration body would all need to be in path-noscheme or path-empty form. (And given that link rewriting in proxies is a fragile thing in general, devices using that should not use path-absolut form anywhere). Would that still work for you? > If there is a conflict with a deployed mechanism, we could look into > adopting "anchor" and let RD use it similarly to "con", but allowing > full base URIs (including paths). > > Or we align with RFC 8288 altogether and replace "con" with "anchor": > https://tools.ietf.org/html/rfc8288#section-3.2 We do use anchor for what RFC8288 intends it for: the Link Context (where the link points from), which is faithfully expressed from what is submitted in the registration. con does something different in that it provides a Base URI to the representation transported in the registering POST. RFC6690 has an unfortunate convolution of those things, but RFC8288 keeps them neatly separate. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlraUm8ACgkQOY0REtOk veE3ehAAuhZ/GVIyITMlGy3UTLooxjR4tkEhw7vKm2451aKPlHtaGlC+OnmOTBfs V2GCeOCr5RUL4cPSCJ5O5+KJr6d8FBAraMatbz8Q7pG2RJgYH0U95c2oFow/pTqN F5vmd7hR2zLJ0+r2/e5aQnG/KwhoMT0HPjruoJqLEItwbmgeb0kETRwPBUlyCxMB T3G0Px7I3tAEdzfT08GYqNhZZBdjwQYZ4bVzvojieN+hBsnPmKtgIGf58xIv/L7L KY9YWrtP2pIU7gIkamzGj1Zl46U2l8pNjO8uP3gErsE1CvPknMUTwguKj73JmJqn AkjYLVBrnEqEYC+X6AFrLXwyq69JW5JrQrXNkcjVLY3zo39NjEBDcxlyaajC1UoS DPf2s7gzM1HRaC3jUe1qKOAnOX3hb4k4SkR4UNv5K970FMqEmhSLPpo0nYVGb1q/ JNH/H5Rk2+BtNthiTWsBjwLfD9MLHf1UDDPm4A2eYp3mPOhlyfN+/PjUEe8Rb1V+ Y6eVEDPtLpuN1lvRCS0XppYYR8oD4UR2R3M9vo7dJ8VzVkz2EYtOVcyfALRjlTBy YtxdHc3+tx6EPJJ+e8SUMxMjVN0QZcWaAgjkf2d5VkohLZLELfIKmJ7IgNx1FYmC T/knIzxJ0I7mDHpmjD9VCt5sxp010/zfFdmqRvUuniqb10waTGo= =fa9M -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From nobody Fri Apr 20 16:38: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 8D4E812D950 for ; Fri, 20 Apr 2018 16:38:11 -0700 (PDT) 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, 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 T1oCoRB_HHqm for ; Fri, 20 Apr 2018 16:38:08 -0700 (PDT) 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 E655112D94F for ; Fri, 20 Apr 2018 16:38:07 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 20 Apr 2018 16:35:35 -0700 From: Jim Schaad To: "'Kovatsch, Matthias'" , =?UTF-8?Q?'Christian_Ams=C3=BCss'?= , CC: References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> Date: Fri, 20 Apr 2018 16:37:55 -0700 Message-ID: <001a01d3d900$9d919eb0$d8b4dc10$@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: AQGj/JiRAqK9XDLfxtiMvvF/yumPWgJTFtjfAZ8yAZgDEqV66wHvlhSppCJjYbA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Apr 2018 23:38:11 -0000 > -----Original Message----- > From: Kovatsch, Matthias > Sent: Friday, April 20, 2018 8:46 AM > To: Jim Schaad ; 'Christian Ams=C3=BCss' > ; consultancy@vanderstok.org; 'Carsten Bormann' > > Cc: 'Hannes Tschofenig' ; core@ietf.org > Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft >=20 > Dear list >=20 >=20 > "ep" is an application-defined identifier for the registered endpoint. = It is a > parameter for registration, but also a target attribute that will have = the same > value. The RD must store the "ep" parameter for each registered = endpoint > and attach it as target attribute to all the corresponding links it = returns. As > Peter stated, when "ep" is not unique, the client must also provide = "d", > which must be processed similarly by the RD. >=20 > As target parameter, it is used during lookup. Applications will use = the > application-defined identifier, not a handle generated by the RD, not = the > security context. When a commissioning tool is registering an = endpoint, the > security context is also different from the endpoint's security = context, and > hence it cannot be used as endpoint identifier. >=20 > As a result, "ep" must not be removed. >=20 > I think "ep", just like the other registration parameters that are = also target > attributes, should receive its own sub-section with a proper = definition and > explanation. >=20 >=20 > Related to this is the proper definition of "ins", which unfortunately = was > moved over to the core-rd-dns-sd draft. "ins" is used to distinguish = resources > with the same "rt". Originally, it was used for resource within the = same > device (e.g., > = ;rt=3Dtemperature;ins=3Dindoor,;rt=3Dtemperature;ins=3Doutdoor)= . By > now, it often is assumed to require global uniqueness. I claim that = this is not > required when "ep" is used correctly. Using a hierarchy of "d" -> "ep" = -> "ins" > provides more flexibility than making "ins" globally unique. "ins" can = still have > a global meaning (cf. indoor vs outdoor), but it should be re-usable = for all > resources with similar instance semantics. Uniqueness is achieved = through > "d" and "ep". >=20 > I think "ins" should become part of the RD draft again to be defined = together > with "d" and "ep", as they are part of a larger discovery framework. If "ins" does not need to be handled in a special manner by the RD, then = I would see no reason for it to be part of the RD draft. Both "ep" and = "d" are treated in a special manner as the pair is required to be = globally unique in the RD. This is not a true statement for the "ins" = attribute even in the core-rd-dns-sd draft. Jim >=20 >=20 > Best wishes, > Matthias >=20 >=20 >=20 > > -----Urspr=C3=BCngliche Nachricht----- > > Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Jim Schaad > > Gesendet: Sonntag, 15. April 2018 21:31 > > An: 'Christian Ams=C3=BCss'; consultancy@vanderstok.org; 'Carsten = Bormann' > > Cc: 'Hannes Tschofenig'; core@ietf.org > > Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft > > > > > > > > > -----Original Message----- > > > From: core On Behalf Of Christian = Ams=C3=BCss > > > Sent: Friday, April 13, 2018 8:11 AM > > > To: consultancy@vanderstok.org; Carsten Bormann > > > Cc: Hannes Tschofenig ; core@ietf.org > > > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD = draft > > > > > > On Mon, Apr 09, 2018 at 10:04:07AM +0200, peter van der Stok = wrote: > > > > > I am curious what we lose if we remove this identifier = altogether. > > > > > The only thing that comes to my mind is a debugging capability > > > > > where you might want to test your system without any security > protocol. > > > > > > > > Probably, I completely misunderstand your suggestion. > > > > Registrations in the RD need identification so that they can be > > > > changed, removed , updated, etc... > > > > > > Well, the manipulation (change, removal, update) already happens > > > independently of the endpoint name or domain; that is just bound = to > > > the registration resource. > > > > > > In the current text, we allow that the endpoint name is not given = at > > > registration time if it is explicitly configured and the RD can > > > recognize the endpoint by its security context. > > > > > > > Registrations are identified by the (ep, d) pair, unique within = a given RD. > > > > Removing ep identifier will force you to find another identifier > > > > for a registration......... > > > > and you are back to square 1 it seems. > > > > > > In any authenticated context, that can identifier can be the = security > context. > > > How that can be expressed at lookup is an open question. > > > An endpoint name string can be what glues those together. > > > > > > On Mon, Apr 09, 2018 at 10:14:54AM +0200, Carsten Bormann wrote: > > > > The argument seems to be that if a client holds an authorization > > > > to register at an RD, that authorization may imply a specific > > > > endpoint name. (I=E2=80=99m not sure that is always true, as = the > > > > authorization may be based on a claim that does not happen to > > > > provide an obvious candidate for that.) > > > > > > > > To discuss this further, we=E2=80=99ll need to discuss = authorization > > > > models for RD access. Maybe high time in any case=E2=80=A6 > > > > > > > > > Could everybody maybe sketch how they'd express the permissions = they > > > would like to set on their RDs? > > > > > > > > > I'll start with some arbitrary ones that might be useful (at least > > > with some help from Cunningham's Law): > > > > > > TrustTheWebCAs: "This RD accepts any registration, provided who > > > registers can present a X509 certificate chain to my system > > > certificates that carries a Common Name or Subject Alternative = Name > > > that matches the host name they give in their con". > > > > TrustTheWebCAs + GodBit: This RD accepts any registration, provided > > who registers can present an X509 certificate chain to my system > certificates that carries a common or alternative name (or maybe an = EKU) > that matches to the God criteria. > > > > > > > > RequireEKU: "Like TrustTheWebCAs, and if it wants to set an = endpoint > > > type (et=3D), that must be justified by an Extended Key Usage in = the > certificate." > > > > I would probably generalize this rule to - The RD may extract > > additional information from the certificate beyond the naming to = either > enforce or supplement attributes set such as endpoint types or = domains. > > > > > > > > EPFromACE: "This RD uses /reg/${domain}/${endpoint} as = registration > URIs. > > > An endpoint can only register if it holds an ACE-AIF token to POST > > > to that resource issued by my Authorization Server (AS)." > > > > EPFromACE2: This RD uses /reg?ep=3D${endpoint}&d=3D${domain} as > > registration URIs. An endpoint can only register if it holds an = ACE- > > AIF token to POST to that resource issued by my Authorization Server = (AS). > The token may contain values for fields in the URI-queries which are = to be > either enforced, or set if not present in the registration request. = Examples > are ep, d, et. > > > > > > > > PNFromACE: "This RD allows registration of arbitrary endpoints, = but > > > advertising an at=3D... (registration) or ol=3D... (link) = attribute (see > > > core-protocol-negotiation) requires that that value is contained = in > > > an ACE token from my AS." > > > > RSFromACE: This RD allows registration of endpoints, but restricts = the > > resources that can be registered. All resources registered must be = filtered > by matching one of a number of patterns potentially with values that = can be > defaulted in. > > > > Jim > > > > > > > > > > > Best regards > > > Christian > > > > > > -- > > > To use raw power is to make yourself infinitely vulnerable to = greater > powers. > > > -- Bene Gesserit axiom > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Fri Apr 20 20:21:29 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 4406E12D7F7; Fri, 20 Apr 2018 20:21:27 -0700 (PDT) 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, 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 esrk3ekpyxrU; Fri, 20 Apr 2018 20:21:25 -0700 (PDT) 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 18A121270A0; Fri, 20 Apr 2018 20:21:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 20 Apr 2018 20:18:53 -0700 From: Jim Schaad To: CC: Date: Fri, 20 Apr 2018 20:21:13 -0700 Message-ID: <002c01d3d91f$ceccd3e0$6c667ba0$@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: AdPZBWVH+JfjjCn/SQuSD23mn0RJBQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] comments on draft-silverajan-core-coap-protocol-negotiation -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2018 03:21:27 -0000 I did a fast scan over this document today and have the following questions. 1. What is the difference between doing a resource lookup via at=coap+tcp:* as oppose to tt=tcp ? Should they return the same result? 2. Is the RD supposed to reject registrations with tt= in them (as any of a group, endpoint or link attribute)? 3. Can I have an at on a group? Is there more than one type of multicast protocol that is, in theory, usable? If yes, then would it ever be used for resolution or just returned? 4. It does not say it, but I assume that ol and at are orthogonal. Thus a query on example 6.2 GET: /rd/lookup?tt=tcp Response: ;ct=41;rt="temperature-f";if="se nsor";anchor="coap+tcp://server.example.com", ;ct=41;rt="door";if="sensor";anc hor="coap+tcp://server.example.com", ;if="sensor"; ol="http://[FDFD::123]:61616"; ol="coap://server2.example.com";anchor="coap+tcp://server.example.com" Jim From nobody Sat Apr 21 13:15:20 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 0ABCA127444; Sat, 21 Apr 2018 13:15:19 -0700 (PDT) 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, 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 GVvBiLOm4t8s; Sat, 21 Apr 2018 13:15:17 -0700 (PDT) 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 CD36C126C2F; Sat, 21 Apr 2018 13:15:16 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 21 Apr 2018 13:12:47 -0700 From: Jim Schaad To: CC: References: <002c01d3d91f$ceccd3e0$6c667ba0$@augustcellars.com> In-Reply-To: <002c01d3d91f$ceccd3e0$6c667ba0$@augustcellars.com> Date: Sat, 21 Apr 2018 13:15:07 -0700 Message-ID: <009401d3d9ad$73019710$5904c530$@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: AQJybaUo5sDEgAmfA8mqbHChX2pz5qLOf0+A Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] comments on draft-silverajan-core-coap-protocol-negotiation -08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Apr 2018 20:15:19 -0000 One more question to go with this. You current are giving the examples of tt=tcp. However, this seems to be a problem as one can have both coap+tcp and coaps+tcp as alternate transports. This means that specifying tt=tcp would be ambigious. Jim > -----Original Message----- > From: core On Behalf Of Jim Schaad > Sent: Friday, April 20, 2018 8:21 PM > To: draft-silverajan-core-coap-protocol-negotiation@ietf.org > Cc: core@ietf.org > Subject: [core] comments on draft-silverajan-core-coap-protocol-negotiation > -08 > > I did a fast scan over this document today and have the following questions. > > 1. What is the difference between doing a resource lookup via > at=coap+tcp:* as oppose to tt=tcp ? Should they return the same result? > > 2. Is the RD supposed to reject registrations with tt= in them (as any of a > group, endpoint or link attribute)? > > 3. Can I have an at on a group? Is there more than one type of multicast > protocol that is, in theory, usable? If yes, then would it ever be used for > resolution or just returned? > > 4. It does not say it, but I assume that ol and at are orthogonal. Thus a query > on example 6.2 > > GET: /rd/lookup?tt=tcp > > Response: > ;ct=41;rt="temperature- > f";if="se > nsor";anchor="coap+tcp://server.example.com", > ;ct=41;rt="door";if="sensor > ";anc > hor="coap+tcp://server.example.com", > ;if="sensor"; > ol="http://[FDFD::123]:61616"; > ol="coap://server2.example.com";anchor="coap+tcp://server.example.com > " > > > > Jim > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Apr 22 20:08: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 3FE8B1243FE for ; Sun, 22 Apr 2018 20:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 lJ05XRgJN47N for ; Sun, 22 Apr 2018 20:08:34 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40048.outbound.protection.outlook.com [40.107.4.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E32D124B0A for ; Sun, 22 Apr 2018 20:08:34 -0700 (PDT) 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; bh=QZwlOftAR8NApjppApTzQ4AJWbCi4MVW7hfR1Q/szTs=; b=onXwo+ktwlIkgT8jGc2P11v7ja1xSSN5RqdjSiLUk4OYUMAvWEF9EtYyUknvEBEFufZ7NgqlAC+M3Av+Jw4xs6RNY+IrZWoMy+XuWI+/5yIUn8uGxTWroWgrEmZO3vhkaYZ809hQwc6h8BfKOyQy1X0kpSzZYZtbxXpuYEqCpDE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1341.eurprd08.prod.outlook.com (10.167.197.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Mon, 23 Apr 2018 03:08:30 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Mon, 23 Apr 2018 03:08:30 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" CC: =?iso-8859-1?Q?Jaime_Jim=E9nez?= , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBCAALM9gP//8agggADTwQD//7rfYADWabOA/+pTH0A= Date: Mon, 23 Apr 2018 03:08:30 +0000 Message-ID: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [103.40.135.62] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1341; 7:qdf9D2jGmT8ys2VVnQBREwy3cYfvBy2AMPa9HByINGIFP7x2rQ9bHLOGG3DQsY+ro/qohQNoC7LRLxhNu98SiOJrwQh9b9BBADAh4krcowMmJpDMEwdyG3yrts9JeJs6P5lcpoZT+R9hg985Y/5tWfv+yTZTLTjiqPnfb/+Xll3JUQIqQFDFtcvIyvJ6OfAZRO1+dBEmdRaEf2n2WWqmsH7fd7dJ9Qh5vHq8zY+nB671v5DcozwDLnZvrcgtUDjW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1341; x-ms-traffictypediagnostic: VI1PR0801MB1341: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231232)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1341; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1341; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39380400002)(346002)(39850400004)(396003)(13464003)(316002)(9686003)(5890100001)(55016002)(26005)(5640700003)(5250100002)(2501003)(54906003)(33656002)(8936002)(1730700003)(59450400001)(76176011)(93886005)(7696005)(2351001)(5660300001)(8676002)(102836004)(81166006)(6436002)(66066001)(3846002)(7736002)(6506007)(53546011)(6116002)(229853002)(6916009)(74316002)(3660700001)(2900100001)(53936002)(6246003)(3280700002)(305945005)(186003)(72206003)(4326008)(446003)(86362001)(11346002)(478600001)(2906002)(25786009)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1341; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: Sls8NXROOsjO5fEydv8Zqv4HbbQrPPilmGCBbLCQ+U7dMJ2wprBWDUSGIU/9aeuPo2Zsk2XGyqZ3sCBvr+XkdQjcaOuLaqtVKdMbU340wQXQWRS62oYqPQ4S7V9qXe+tBJk8kzv+ZO96eg92Itl37kvMrGPdupBQyNOePe03026udQ4U82xxYPNo6A3/FDU/ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2aabca4e-f17b-42bd-2f4f-08d5a8c77d99 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2aabca4e-f17b-42bd-2f4f-08d5a8c77d99 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 03:08:30.1005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1341 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2018 03:08:37 -0000 Hi Peter, The mailing list discussion reconfirms my worry that people will get this w= rong and will introduce security vulnerabilities. I am saying that the security protocol used to protect the communication wi= ll have an authenticated identifier and this identifier then has to be used= for identification of the IoT device. This identifier will then also be us= ed for lookups . I am furthermore arguing that the multiple IoT device cannot share the same= identifier. I agree with Jim that for third party registrations we cannot = completely get rid of the endpoint client name/endpoint name functionality = but for the third party registration you are most likely using a different = approach anyway. I am not sure anyone using the RD specification for commis= sioning tool functionality today since the main purpose of the RD document = is for something entirely different. Ciao Hannes -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: 09 April 2018 15:04 To: Hannes Tschofenig Cc: Jaime Jim=E9nez; core@ietf.org Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft > > I am curious what we lose if we remove this identifier altogether. The > only thing that comes to my mind is a debugging capability where you > might want to test your system without any security protocol. Hi Hannes, Probably, I completely misunderstand your suggestion. Registrations in the RD need identification so that they can be changed, re= moved , updated, etc... Registrations are identified by the (ep, d) pair, unique within a given RD. Removing ep identifier will force you to find another identifier for a regi= stration......... and you are back to square 1 it seems. Peter 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. From nobody Sun Apr 22 20:11: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 057B7124B0A for ; Sun, 22 Apr 2018 20:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 NTFADb2fkXzo for ; Sun, 22 Apr 2018 20:11:53 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0083.outbound.protection.outlook.com [104.47.2.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E431243FE for ; Sun, 22 Apr 2018 20:11:53 -0700 (PDT) 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; bh=o0ZNlYSjLrtibqni0+I3G0ANmWJuq5WoZKsmw5X6OvM=; b=dW1nnAesMcu3I8QqGhNThmszfI0x4w+7XJDRatYS5sAMnz5Pj2CBG7iU/i640dtjPm3/7yNxt6fTvi1zo5+f/Gdfbxdpir+zVPOPXG9aPjJMSrydAP5JWJ/4YK7nFDaFemnGQ1m+6olpNKJFXoAtEotDgV7QStoSjg2HV1ns0wg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1341.eurprd08.prod.outlook.com (10.167.197.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Mon, 23 Apr 2018 03:11:50 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Mon, 23 Apr 2018 03:11:50 +0000 From: Hannes Tschofenig To: "Kovatsch, Matthias" , Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "consultancy@vanderstok.org" , 'Carsten Bormann' CC: "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0zm23rcsFhLKykKKsIPwEtlWPKQCOhQAgAec7ACAA+NkwA== Date: Mon, 23 Apr 2018 03:11:49 +0000 Message-ID: References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: siemens.com; dkim=none (message not signed) header.d=none;siemens.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [103.40.135.62] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1341; 7:fF9YZc8SlOioVBEr9U9pzID7sVH8ELuNMdqB/AZIWaW3xU5pnOt0xs4Qc/iY5hVJNDoBXfQSJZkswslukYMRtPw9YUW2s6yrIytkCw1KgTYLV6KsEZ0TTEbFqI+V+sIGuooF1LKrxDOZyaMysPIxJMjM2IR5pp6cOOapKeADh9rCBBO+Yqc7XFHEFIeUCzQ830xm1wdER/I5tqWIDtzpDV+Frit30ZAMsRJlScetYjg/6xSvMKBjvGFZg3Gh2PV2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1341; x-ms-traffictypediagnostic: VI1PR0801MB1341: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(180628864354917)(278428928389397)(192374486261705)(126837547833334); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231232)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1341; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1341; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39380400002)(346002)(39850400004)(396003)(13464003)(316002)(6306002)(9686003)(5890100001)(55016002)(26005)(110136005)(5250100002)(2501003)(33656002)(8936002)(59450400001)(76176011)(93886005)(7696005)(5660300001)(8676002)(102836004)(81166006)(6436002)(66066001)(3846002)(7736002)(6506007)(53546011)(6116002)(229853002)(74316002)(3660700001)(2900100001)(966005)(53936002)(6246003)(3280700002)(305945005)(186003)(72206003)(4326008)(446003)(86362001)(11346002)(478600001)(2906002)(25786009)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1341; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: KyvZYHpOLzQe+Sb4Hrjx5flpbBOjD5hkgN2dmj9rs0zdMVtsS5wEB+qFEUTJ5Kepcr4xyRBW/6+rKnBiFJfHIkQlt+UPAuts/ZgU5NcJfv+s9vxlqhzyr4cAMWf2USSCZgqbCDr28kJykJQMAmJOP5jDhHZhtYRjmUKR8rivtds9EDUHjn0oEENyqlIKgNZk spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f5163659-e586-4423-12dd-08d5a8c7f4be X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5163659-e586-4423-12dd-08d5a8c7f4be X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 03:11:49.9911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1341 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2018 03:11:57 -0000 SGkgTWF0dGhpYXMsDQoNCkkgYW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB0aGUgZW5kcG9pbnQgY2xp ZW50IG5hbWUvZW5kcG9pbnQgbmFtZSBpcyBnZW5lcmF0ZWQgYnkgdGhlIFJELiBJbiBmYWN0LCBJ IGJlbGlldmUgdGhlIGlkZW50aWZpZXIgdXNlZCBmb3IgaWRlbnRpZnlpbmcgdGhlIElvVCBkZXZp Y2Ugd2lsbCBiZSBzZWxlY3RlZCBvdXRzaWRlIHRoZSBSRCBwcm90b2NvbC4NCg0KPiBBcHBsaWNh dGlvbnMgd2lsbCB1c2UgdGhlIGFwcGxpY2F0aW9uLWRlZmluZWQgaWRlbnRpZmllciwgbm90IGEg aGFuZGxlIGdlbmVyYXRlZCBieSB0aGUgUkQsIG5vdCB0aGUgc2VjdXJpdHkgY29udGV4dC4NCg0K V2hvIHNheXMgdGhhdD8gSWYgYXBwbGljYXRpb25zIG1ha2Ugc2VjdXJpdHkgZGVjaXNpb25zIGJh c2VkIG9uIHVuYXV0aGVudGljYXRlZCBwYXJhbWV0ZXJzIHRoZW4gdGhleSB3aWxsIGJlIHRvYXN0 Lg0KDQpDaWFvDQpIYW5uZXMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog S292YXRzY2gsIE1hdHRoaWFzIFttYWlsdG86bWF0dGhpYXMua292YXRzY2hAc2llbWVucy5jb21d DQpTZW50OiAyMCBBcHJpbCAyMDE4IDIyOjQ2DQpUbzogSmltIFNjaGFhZDsgJ0NocmlzdGlhbiBB bXPDvHNzJzsgY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc7ICdDYXJzdGVuIEJvcm1hbm4nDQpD YzogSGFubmVzIFRzY2hvZmVuaWc7IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IEFXOiBbY29yZV0g RW5kcG9pbnQgQ2xpZW50IE5hbWUgLyBFbmRwb2ludCBOYW1lIGluIFJEIGRyYWZ0DQoNCkRlYXIg bGlzdA0KDQoNCiJlcCIgaXMgYW4gYXBwbGljYXRpb24tZGVmaW5lZCBpZGVudGlmaWVyIGZvciB0 aGUgcmVnaXN0ZXJlZCBlbmRwb2ludC4gSXQgaXMgYSBwYXJhbWV0ZXIgZm9yIHJlZ2lzdHJhdGlv biwgYnV0IGFsc28gYSB0YXJnZXQgYXR0cmlidXRlIHRoYXQgd2lsbCBoYXZlIHRoZSBzYW1lIHZh bHVlLiBUaGUgUkQgbXVzdCBzdG9yZSB0aGUgImVwIiBwYXJhbWV0ZXIgZm9yIGVhY2ggcmVnaXN0 ZXJlZCBlbmRwb2ludCBhbmQgYXR0YWNoIGl0IGFzIHRhcmdldCBhdHRyaWJ1dGUgdG8gYWxsIHRo ZSBjb3JyZXNwb25kaW5nIGxpbmtzIGl0IHJldHVybnMuIEFzIFBldGVyIHN0YXRlZCwgd2hlbiAi ZXAiIGlzIG5vdCB1bmlxdWUsIHRoZSBjbGllbnQgbXVzdCBhbHNvIHByb3ZpZGUgImQiLCB3aGlj aCBtdXN0IGJlIHByb2Nlc3NlZCBzaW1pbGFybHkgYnkgdGhlIFJELg0KDQpBcyB0YXJnZXQgcGFy YW1ldGVyLCBpdCBpcyB1c2VkIGR1cmluZyBsb29rdXAuIEFwcGxpY2F0aW9ucyB3aWxsIHVzZSB0 aGUgYXBwbGljYXRpb24tZGVmaW5lZCBpZGVudGlmaWVyLCBub3QgYSBoYW5kbGUgZ2VuZXJhdGVk IGJ5IHRoZSBSRCwgbm90IHRoZSBzZWN1cml0eSBjb250ZXh0LiBXaGVuIGEgY29tbWlzc2lvbmlu ZyB0b29sIGlzIHJlZ2lzdGVyaW5nIGFuIGVuZHBvaW50LCB0aGUgc2VjdXJpdHkgY29udGV4dCBp cyBhbHNvIGRpZmZlcmVudCBmcm9tIHRoZSBlbmRwb2ludCdzIHNlY3VyaXR5IGNvbnRleHQsIGFu ZCBoZW5jZSBpdCBjYW5ub3QgYmUgdXNlZCBhcyBlbmRwb2ludCBpZGVudGlmaWVyLg0KDQpBcyBh IHJlc3VsdCwgImVwIiBtdXN0IG5vdCBiZSByZW1vdmVkLg0KDQpJIHRoaW5rICJlcCIsIGp1c3Qg bGlrZSB0aGUgb3RoZXIgcmVnaXN0cmF0aW9uIHBhcmFtZXRlcnMgdGhhdCBhcmUgYWxzbyB0YXJn ZXQgYXR0cmlidXRlcywgc2hvdWxkIHJlY2VpdmUgaXRzIG93biBzdWItc2VjdGlvbiB3aXRoIGEg cHJvcGVyIGRlZmluaXRpb24gYW5kIGV4cGxhbmF0aW9uLg0KDQoNClJlbGF0ZWQgdG8gdGhpcyBp cyB0aGUgcHJvcGVyIGRlZmluaXRpb24gb2YgImlucyIsIHdoaWNoIHVuZm9ydHVuYXRlbHkgd2Fz IG1vdmVkIG92ZXIgdG8gdGhlIGNvcmUtcmQtZG5zLXNkIGRyYWZ0LiAiaW5zIiBpcyB1c2VkIHRv IGRpc3Rpbmd1aXNoIHJlc291cmNlcyB3aXRoIHRoZSBzYW1lICJydCIuIE9yaWdpbmFsbHksIGl0 IHdhcyB1c2VkIGZvciByZXNvdXJjZSB3aXRoaW4gdGhlIHNhbWUgZGV2aWNlIChlLmcuLCA8L3Qx PjtydD10ZW1wZXJhdHVyZTtpbnM9aW5kb29yLDwvdDI+O3J0PXRlbXBlcmF0dXJlO2lucz1vdXRk b29yKS4gQnkgbm93LCBpdCBvZnRlbiBpcyBhc3N1bWVkIHRvIHJlcXVpcmUgZ2xvYmFsIHVuaXF1 ZW5lc3MuIEkgY2xhaW0gdGhhdCB0aGlzIGlzIG5vdCByZXF1aXJlZCB3aGVuICJlcCIgaXMgdXNl ZCBjb3JyZWN0bHkuIFVzaW5nIGEgaGllcmFyY2h5IG9mICJkIiAtPiAiZXAiIC0+ICJpbnMiIHBy b3ZpZGVzIG1vcmUgZmxleGliaWxpdHkgdGhhbiBtYWtpbmcgImlucyIgZ2xvYmFsbHkgdW5pcXVl LiAiaW5zIiBjYW4gc3RpbGwgaGF2ZSBhIGdsb2JhbCBtZWFuaW5nIChjZi4gaW5kb29yIHZzIG91 dGRvb3IpLCBidXQgaXQgc2hvdWxkIGJlIHJlLXVzYWJsZSBmb3IgYWxsIHJlc291cmNlcyB3aXRo IHNpbWlsYXIgaW5zdGFuY2Ugc2VtYW50aWNzLiBVbmlxdWVuZXNzIGlzIGFjaGlldmVkIHRocm91 Z2ggImQiIGFuZCAiZXAiLg0KDQpJIHRoaW5rICJpbnMiIHNob3VsZCBiZWNvbWUgcGFydCBvZiB0 aGUgUkQgZHJhZnQgYWdhaW4gdG8gYmUgZGVmaW5lZCB0b2dldGhlciB3aXRoICJkIiBhbmQgImVw IiwgYXMgdGhleSBhcmUgcGFydCBvZiBhIGxhcmdlciBkaXNjb3ZlcnkgZnJhbWV3b3JrLg0KDQoN CkJlc3Qgd2lzaGVzLA0KTWF0dGhpYXMNCg0KDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNo cmljaHQtLS0tLQ0KPiBWb246IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIElt IEF1ZnRyYWcgdm9uIEppbSBTY2hhYWQNCj4gR2VzZW5kZXQ6IFNvbm50YWcsIDE1LiBBcHJpbCAy MDE4IDIxOjMxDQo+IEFuOiAnQ2hyaXN0aWFuIEFtc8O8c3MnOyBjb25zdWx0YW5jeUB2YW5kZXJz dG9rLm9yZzsgJ0NhcnN0ZW4gQm9ybWFubicNCj4gQ2M6ICdIYW5uZXMgVHNjaG9mZW5pZyc7IGNv cmVAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IFtjb3JlXSBFbmRwb2ludCBDbGllbnQgTmFtZSAv IEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQNCj4NCj4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIENocmlzdGlhbiBBbXPDvHNzDQo+ID4gU2VudDogRnJpZGF5LCBBcHJpbCAxMywgMjAx OCA4OjExIEFNDQo+ID4gVG86IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBDYXJzdGVuIEJv cm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gPiBDYzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb20+OyBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtjb3Jl XSBFbmRwb2ludCBDbGllbnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQNCj4gPg0K PiA+IE9uIE1vbiwgQXByIDA5LCAyMDE4IGF0IDEwOjA0OjA3QU0gKzAyMDAsIHBldGVyIHZhbiBk ZXIgU3RvayB3cm90ZToNCj4gPiA+ID4gSSBhbSBjdXJpb3VzIHdoYXQgd2UgbG9zZSBpZiB3ZSBy ZW1vdmUgdGhpcyBpZGVudGlmaWVyIGFsdG9nZXRoZXIuDQo+ID4gPiA+IFRoZSBvbmx5IHRoaW5n IHRoYXQgY29tZXMgdG8gbXkgbWluZCBpcyBhIGRlYnVnZ2luZyBjYXBhYmlsaXR5DQo+ID4gPiA+ IHdoZXJlIHlvdSBtaWdodCB3YW50IHRvIHRlc3QgeW91ciBzeXN0ZW0gd2l0aG91dCBhbnkgc2Vj dXJpdHkgcHJvdG9jb2wuDQo+ID4gPg0KPiA+ID4gUHJvYmFibHksIEkgY29tcGxldGVseSBtaXN1 bmRlcnN0YW5kIHlvdXIgc3VnZ2VzdGlvbi4NCj4gPiA+IFJlZ2lzdHJhdGlvbnMgaW4gdGhlIFJE IG5lZWQgaWRlbnRpZmljYXRpb24gc28gdGhhdCB0aGV5IGNhbiBiZQ0KPiA+ID4gY2hhbmdlZCwg cmVtb3ZlZCAsIHVwZGF0ZWQsIGV0Yy4uLg0KPiA+DQo+ID4gV2VsbCwgdGhlIG1hbmlwdWxhdGlv biAoY2hhbmdlLCByZW1vdmFsLCB1cGRhdGUpIGFscmVhZHkgaGFwcGVucw0KPiA+IGluZGVwZW5k ZW50bHkgb2YgdGhlIGVuZHBvaW50IG5hbWUgb3IgZG9tYWluOyB0aGF0IGlzIGp1c3QgYm91bmQg dG8NCj4gPiB0aGUgcmVnaXN0cmF0aW9uIHJlc291cmNlLg0KPiA+DQo+ID4gSW4gdGhlIGN1cnJl bnQgdGV4dCwgd2UgYWxsb3cgdGhhdCB0aGUgZW5kcG9pbnQgbmFtZSBpcyBub3QgZ2l2ZW4gYXQN Cj4gPiByZWdpc3RyYXRpb24gdGltZSBpZiBpdCBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgYW5k IHRoZSBSRCBjYW4NCj4gPiByZWNvZ25pemUgdGhlIGVuZHBvaW50IGJ5IGl0cyBzZWN1cml0eSBj b250ZXh0Lg0KPiA+DQo+ID4gPiBSZWdpc3RyYXRpb25zIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSAo ZXAsIGQpIHBhaXIsIHVuaXF1ZSB3aXRoaW4gYSBnaXZlbiBSRC4NCj4gPiA+IFJlbW92aW5nIGVw IGlkZW50aWZpZXIgd2lsbCBmb3JjZSB5b3UgdG8gZmluZCBhbm90aGVyIGlkZW50aWZpZXINCj4g PiA+IGZvciBhIHJlZ2lzdHJhdGlvbi4uLi4uLi4uLg0KPiA+ID4gYW5kIHlvdSBhcmUgYmFjayB0 byBzcXVhcmUgMSBpdCBzZWVtcy4NCj4gPg0KPiA+IEluIGFueSBhdXRoZW50aWNhdGVkIGNvbnRl eHQsIHRoYXQgY2FuIGlkZW50aWZpZXIgY2FuIGJlIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KPiA+ IEhvdyB0aGF0IGNhbiBiZSBleHByZXNzZWQgYXQgbG9va3VwIGlzIGFuIG9wZW4gcXVlc3Rpb24u DQo+ID4gQW4gZW5kcG9pbnQgbmFtZSBzdHJpbmcgY2FuIGJlIHdoYXQgZ2x1ZXMgdGhvc2UgdG9n ZXRoZXIuDQo+ID4NCj4gPiBPbiBNb24sIEFwciAwOSwgMjAxOCBhdCAxMDoxNDo1NEFNICswMjAw LCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQo+ID4gPiBUaGUgYXJndW1lbnQgc2VlbXMgdG8gYmUg dGhhdCBpZiBhIGNsaWVudCBob2xkcyBhbiBhdXRob3JpemF0aW9uDQo+ID4gPiB0byByZWdpc3Rl ciBhdCBhbiBSRCwgdGhhdCBhdXRob3JpemF0aW9uIG1heSBpbXBseSBhIHNwZWNpZmljDQo+ID4g PiBlbmRwb2ludCBuYW1lLiAgKEnigJltIG5vdCBzdXJlIHRoYXQgaXMgYWx3YXlzIHRydWUsIGFz IHRoZQ0KPiA+ID4gYXV0aG9yaXphdGlvbiBtYXkgYmUgYmFzZWQgb24gYSBjbGFpbSB0aGF0IGRv ZXMgbm90IGhhcHBlbiB0bw0KPiA+ID4gcHJvdmlkZSBhbiBvYnZpb3VzIGNhbmRpZGF0ZSBmb3Ig dGhhdC4pDQo+ID4gPg0KPiA+ID4gVG8gZGlzY3VzcyB0aGlzIGZ1cnRoZXIsIHdl4oCZbGwgbmVl ZCB0byBkaXNjdXNzIGF1dGhvcml6YXRpb24NCj4gPiA+IG1vZGVscyBmb3IgUkQgYWNjZXNzLiAg TWF5YmUgaGlnaCB0aW1lIGluIGFueSBjYXNl4oCmDQo+ID4NCj4gPg0KPiA+IENvdWxkIGV2ZXJ5 Ym9keSBtYXliZSBza2V0Y2ggaG93IHRoZXknZCBleHByZXNzIHRoZSBwZXJtaXNzaW9ucyB0aGV5 DQo+ID4gd291bGQgbGlrZSB0byBzZXQgb24gdGhlaXIgUkRzPw0KPiA+DQo+ID4NCj4gPiBJJ2xs IHN0YXJ0IHdpdGggc29tZSBhcmJpdHJhcnkgb25lcyB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCAoYXQg bGVhc3QNCj4gPiB3aXRoIHNvbWUgaGVscCBmcm9tIEN1bm5pbmdoYW0ncyBMYXcpOg0KPiA+DQo+ ID4gVHJ1c3RUaGVXZWJDQXM6ICJUaGlzIFJEIGFjY2VwdHMgYW55IHJlZ2lzdHJhdGlvbiwgcHJv dmlkZWQgd2hvDQo+ID4gcmVnaXN0ZXJzIGNhbiBwcmVzZW50IGEgWDUwOSBjZXJ0aWZpY2F0ZSBj aGFpbiB0byBteSBzeXN0ZW0NCj4gPiBjZXJ0aWZpY2F0ZXMgdGhhdCBjYXJyaWVzIGEgQ29tbW9u IE5hbWUgb3IgU3ViamVjdCBBbHRlcm5hdGl2ZSBOYW1lDQo+ID4gdGhhdCBtYXRjaGVzIHRoZSBo b3N0IG5hbWUgdGhleSBnaXZlIGluIHRoZWlyIGNvbiIuDQo+DQo+IFRydXN0VGhlV2ViQ0FzICsg R29kQml0OiBUaGlzIFJEIGFjY2VwdHMgYW55IHJlZ2lzdHJhdGlvbiwgcHJvdmlkZWQNCj4gd2hv IHJlZ2lzdGVycyBjYW4gcHJlc2VudCBhbiBYNTA5IGNlcnRpZmljYXRlIGNoYWluIHRvIG15IHN5 c3RlbSBjZXJ0aWZpY2F0ZXMgdGhhdCBjYXJyaWVzIGEgY29tbW9uIG9yIGFsdGVybmF0aXZlIG5h bWUgKG9yIG1heWJlIGFuIEVLVSkgdGhhdCBtYXRjaGVzIHRvIHRoZSBHb2QgY3JpdGVyaWEuDQo+ DQo+ID4NCj4gPiBSZXF1aXJlRUtVOiAiTGlrZSBUcnVzdFRoZVdlYkNBcywgYW5kIGlmIGl0IHdh bnRzIHRvIHNldCBhbiBlbmRwb2ludA0KPiA+IHR5cGUgKGV0PSksIHRoYXQgbXVzdCBiZSBqdXN0 aWZpZWQgYnkgYW4gRXh0ZW5kZWQgS2V5IFVzYWdlIGluIHRoZSBjZXJ0aWZpY2F0ZS4iDQo+DQo+ IEkgd291bGQgcHJvYmFibHkgZ2VuZXJhbGl6ZSB0aGlzIHJ1bGUgdG8gLSBUaGUgUkQgbWF5IGV4 dHJhY3QNCj4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBjZXJ0aWZpY2F0ZSBiZXlv bmQgdGhlIG5hbWluZyB0byBlaXRoZXIgZW5mb3JjZSBvciBzdXBwbGVtZW50IGF0dHJpYnV0ZXMg c2V0IHN1Y2ggYXMgZW5kcG9pbnQgdHlwZXMgb3IgZG9tYWlucy4NCj4NCj4gPg0KPiA+IEVQRnJv bUFDRTogIlRoaXMgUkQgdXNlcyAvcmVnLyR7ZG9tYWlufS8ke2VuZHBvaW50fSBhcyByZWdpc3Ry YXRpb24gVVJJcy4NCj4gPiBBbiBlbmRwb2ludCBjYW4gb25seSByZWdpc3RlciBpZiBpdCBob2xk cyBhbiBBQ0UtQUlGIHRva2VuIHRvIFBPU1QNCj4gPiB0byB0aGF0IHJlc291cmNlIGlzc3VlZCBi eSBteSBBdXRob3JpemF0aW9uIFNlcnZlciAoQVMpLiINCj4NCj4gRVBGcm9tQUNFMjogIFRoaXMg UkQgdXNlcyAvcmVnP2VwPSR7ZW5kcG9pbnR9JmQ9JHtkb21haW59IGFzDQo+IHJlZ2lzdHJhdGlv biBVUklzLiAgQW4gZW5kcG9pbnQgY2FuIG9ubHkgcmVnaXN0ZXIgaWYgaXQgaG9sZHMgYW4gQUNF LQ0KPiBBSUYgdG9rZW4gdG8gUE9TVCB0byB0aGF0IHJlc291cmNlIGlzc3VlZCBieSBteSBBdXRo b3JpemF0aW9uIFNlcnZlciAoQVMpLiAgVGhlIHRva2VuIG1heSBjb250YWluIHZhbHVlcyBmb3Ig ZmllbGRzIGluIHRoZSBVUkktcXVlcmllcyB3aGljaCBhcmUgdG8gYmUgZWl0aGVyIGVuZm9yY2Vk LCBvciBzZXQgaWYgbm90IHByZXNlbnQgaW4gdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LiAgRXhh bXBsZXMgYXJlIGVwLCBkLCBldC4NCj4NCj4gPg0KPiA+IFBORnJvbUFDRTogIlRoaXMgUkQgYWxs b3dzIHJlZ2lzdHJhdGlvbiBvZiBhcmJpdHJhcnkgZW5kcG9pbnRzLCBidXQNCj4gPiBhZHZlcnRp c2luZyBhbiBhdD0uLi4gKHJlZ2lzdHJhdGlvbikgb3Igb2w9Li4uIChsaW5rKSBhdHRyaWJ1dGUg KHNlZQ0KPiA+IGNvcmUtcHJvdG9jb2wtbmVnb3RpYXRpb24pIHJlcXVpcmVzIHRoYXQgdGhhdCB2 YWx1ZSBpcyBjb250YWluZWQgaW4NCj4gPiBhbiBBQ0UgdG9rZW4gZnJvbSBteSBBUy4iDQo+DQo+ IFJTRnJvbUFDRTogVGhpcyBSRCBhbGxvd3MgcmVnaXN0cmF0aW9uIG9mIGVuZHBvaW50cywgYnV0 IHJlc3RyaWN0cyB0aGUNCj4gcmVzb3VyY2VzIHRoYXQgY2FuIGJlIHJlZ2lzdGVyZWQuICBBbGwg cmVzb3VyY2VzIHJlZ2lzdGVyZWQgbXVzdCBiZSBmaWx0ZXJlZCBieSBtYXRjaGluZyBvbmUgb2Yg YSBudW1iZXIgb2YgcGF0dGVybnMgcG90ZW50aWFsbHkgd2l0aCB2YWx1ZXMgdGhhdCBjYW4gYmUg ZGVmYXVsdGVkIGluLg0KPg0KPiBKaW0NCj4NCj4gPg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzDQo+ ID4gQ2hyaXN0aWFuDQo+ID4NCj4gPiAtLQ0KPiA+IFRvIHVzZSByYXcgcG93ZXIgaXMgdG8gbWFr ZSB5b3Vyc2VsZiBpbmZpbml0ZWx5IHZ1bG5lcmFibGUgdG8gZ3JlYXRlciBwb3dlcnMuDQo+ID4g ICAtLSBCZW5lIEdlc3Nlcml0IGF4aW9tDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Mon Apr 23 05:11:59 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 04E8B127871 for ; Mon, 23 Apr 2018 05:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 z4u9DghtXY1g for ; Mon, 23 Apr 2018 05:11:54 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 8E2B2126BF7 for ; Mon, 23 Apr 2018 05:11:53 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id w3NCBnOw013400 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Apr 2018 14:11:49 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w3NCBhAe031430 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Apr 2018 14:11:49 +0200 Received: from DENBGAT9ERSMSX.ww902.siemens.net (139.22.70.191) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.389.1; Mon, 23 Apr 2018 14:11:41 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.4]) by DENBGAT9ERSMSX.ww902.siemens.net ([139.22.70.191]) with mapi id 14.03.0389.001; Mon, 23 Apr 2018 14:11:40 +0200 From: "Kovatsch, Matthias" To: =?iso-8859-1?Q?=27Christian_Ams=FCss=27?= CC: "core@ietf.org" , peter van der Stok , "Michael Koster (michaeljohnkoster@gmail.com)" , "Vicari, Norbert" Thread-Topic: Resouce Directory - generic base URIs (con / anchor) Thread-Index: AdPYvrfECZuTGRASR2+jYj6wC+OEZQAGajiAAIik3uA= Date: Mon, 23 Apr 2018 12:11:39 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CDA@DEFTHW99EL4MSX.ww902.siemens.net> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D2C@DEFTHW99EL4MSX.ww902.siemens.net> <20180420204957.GA6125@hephaistos.amsuess.com> In-Reply-To: <20180420204957.GA6125@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Resouce Directory - generic base URIs (con / anchor) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2018 12:11:57 -0000 > thanks for bringing this to the list. Sure :) > The ugly thing about is: Registrations that are sent in application/link-= format can not make use of a path component in the Base URI > (which the con is), because RFC6690's resolution rules strip away the Bas= e URI's path component by using Origin terminology. But the current "con" is already shadowing the Origin. I am currently missing the time to look it up myself: Does link-format enfo= rce absolute path URIs (i.e., starting with "/")? > That means that registrations that would use such a con would in practice= need to use a content format that does not use RFC6690 > resolution rules, and right now it is still under discussion whether link= s-json will be safe from that. Sounds like one more reason to have a proper links-json format that ignores= link-format baggage :) > The references in the registration body would all need to be in path-nosc= heme or path-empty form. (And given that link rewriting in > proxies is a fragile thing in general, devices using that should not use = path-absolut form anywhere). >=20 > Would that still work for you? I am not sure, I can follow here. My proposal would assume either absolute = or relative URIs in the registration body. All relative URIs are resolved u= sing the "con" base URI, following the URI RFC algorithm. "con" would be used by tools that register on behalf of devices. Such tools= must talk to the RD directly. If they go through a proxy that does re-writ= e magic to the body, then it is of course messing up the information and it= is the fault of whoever deployed that proxy. > > If there is a conflict with a deployed mechanism, we could look into > > adopting "anchor" and let RD use it similarly to "con", but allowing > > full base URIs (including paths). > > > > Or we align with RFC 8288 altogether and replace "con" with "anchor": > > https://tools.ietf.org/html/rfc8288#section-3.2 >=20 > We do use anchor for what RFC8288 intends it for: the Link Context (where= the link points from), which is faithfully expressed from what > is submitted in the registration. con does something different in that it= provides a Base URI to the representation transported in the > registering POST. RFC6690 has an unfortunate convolution of those things,= but RFC8288 keeps them neatly separate. I can see how this got messy when thinking about relative URIs... Anyhow, let's fix "con" then. Ciao, Matthias From nobody Mon Apr 23 05:17:25 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 C38A2126C89 for ; Mon, 23 Apr 2018 05:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 lEgGUiP6PdZV for ; Mon, 23 Apr 2018 05:17:22 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 E1332120047 for ; Mon, 23 Apr 2018 05:17:21 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w3NCGfcR011612 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Apr 2018 14:16:41 +0200 Received: from DEFTHW99ERJMSX.ww902.siemens.net (defthw99erjmsx.ww902.siemens.net [139.22.70.135]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w3NCGW7q014362 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Apr 2018 14:16:39 +0200 Received: from DENBGAT9ERNMSX.ww902.siemens.net (139.22.70.144) by DEFTHW99ERJMSX.ww902.siemens.net (139.22.70.135) with Microsoft SMTP Server (TLS) id 14.3.389.1; Mon, 23 Apr 2018 14:16:34 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.4]) by DENBGAT9ERNMSX.ww902.siemens.net ([139.22.70.144]) with mapi id 14.03.0389.001; Mon, 23 Apr 2018 14:16:33 +0200 From: "Kovatsch, Matthias" To: Hannes Tschofenig , Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "consultancy@vanderstok.org" , "'Carsten Bormann'" CC: "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0znBtoTmC857b0Co5UImt06WfqQCGI0AgAe4tOCAA8hngIAAuLvg Date: Mon, 23 Apr 2018 12:16:32 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 23 Apr 2018 12:17:24 -0000 PiBWb246IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bV0NCj4gPiBBcHBsaWNhdGlvbnMgd2lsbCB1c2UgdGhlIGFwcGxpY2F0aW9uLWRlZmluZWQgaWRl bnRpZmllciwgbm90IGEgaGFuZGxlIGdlbmVyYXRlZCBieSB0aGUgUkQsIG5vdCB0aGUgc2VjdXJp dHkgY29udGV4dC4NCj4gDQo+IFdobyBzYXlzIHRoYXQ/IElmIGFwcGxpY2F0aW9ucyBtYWtlIHNl Y3VyaXR5IGRlY2lzaW9ucyBiYXNlZCBvbiB1bmF1dGhlbnRpY2F0ZWQgcGFyYW1ldGVycyB0aGVu IHRoZXkgd2lsbCBiZSB0b2FzdC4NCg0KSSBhbSBub3Qgc2F5aW5nIHRoZXkgc2hvdWxkIG5vdCBh dXRoZW50aWNhdGUuDQpJIGFtIHNheWluZyB0aGF0IHRoZSBpZGVudGlmaWVyIG1pZ2h0IGJlIGRp ZmZlcmVudCBmb3IgYXV0aG9yaXphdGluZyB0aGUgcmVnaXN0cmF0aW9uIGFuZCBsb29rdXAgYnkg YXBwbGljYXRpb25zLiBUaGV5IG11c3QgYmUgY29ycmVsYXRhYmxlIG9mIGNvdXJzZTsgdGhlbSBi ZWluZyB0aGUgc2FtZSBpcyBhIHNwZWNpYWwgY2FzZSwgdGhhdCBjb3VsZCBiZSBkZXNpcmFibGUu IFlldCBzb21lb25lIHdobyBpcyBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3JpemVkIHNob3VsZCBi ZSBhbGxvd2VkIHRvIGludHJvZHVjZSBhZGRpdGlvbmFsIGlkZW50aWZpZXJzLg0KDQpDaWFvLA0K TWF0dGhpYXMNCg0K From nobody Tue Apr 24 02:27: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 3A98D124217 for ; Tue, 24 Apr 2018 02:27:47 -0700 (PDT) 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, 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 QncU2-TVjCD1 for ; Tue, 24 Apr 2018 02:27:44 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.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 5022D126DEE for ; Tue, 24 Apr 2018 02:27:44 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud7.xs4all.net with ESMTPA id AuEffDOT28U07AuEffqTeL; Tue, 24 Apr 2018 11:27:42 +0200 Received: from 2001:983:a264:1:ecb7:3eb8:e763:ecc4 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 Apr 2018 11:27:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 24 Apr 2018 11:27:41 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: consultancy@vanderstok.org, =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfB/g19ZTRxSEcbkQT2BYrAVuz/BRSU0MFWKQC0FmpeM4C2HyfCdHhKbB2r+c1oyya9EdmrMhvNJn+OgVeEvEUeLpRob9JNZDmrbPlPlK+9akFt61fZfY 5klDgw+vz4VS6fZJZhzoATZ5awOu6n752P5hYTMfkIAfJTA9FFIpZ12/jtO5HW29ULy8NS8Axhq0r4SlMTqeoVc+4LQ5gHTAc6ENCrxu8flsVXo2cjvpj60z vLy0hXZy/1F1bmknJoo9eGg56dpJ1WQEugBUy2skt5s= Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 09:27:47 -0000 Hannes Tschofenig schreef op 2018-04-23 05:08: > Hi Peter, > > The mailing list discussion reconfirms my worry that people will get > this wrong and will introduce security vulnerabilities. Well, I'm one of those getting it wrong, because I did not understand the worry. > > I am saying that the security protocol used to protect the > communication will have an authenticated identifier and this > identifier then has to be used for identification of the IoT device. > This identifier will then also be used for lookups . This I understand. If I do clearly follow, guidelines must be produced about the use of authorized RD accesses. Assume authorized access to the RD, using oauth-authz. I do surmise that the registration may then return an signed identifier instead the path name of the registration. The signed identifier can be used for updates. The payload will be encrypted, and thus the actual use of ep, and d can be maintained as specified in the lookup, but are hidden to others. Is that a correct extrapolated suggestion of your comments? probably there is a caveat I don't see. > > I am furthermore arguing that the multiple IoT device cannot share the > same identifier. sorry, what is a multiple IoT device? one with multiple registrations in the RD, or one with multiple links? or.... I agree with Jim that for third party registrations > we cannot completely get rid of the endpoint client name/endpoint name > functionality but for the third party registration you are most likely > using a different approach anyway. I am not sure anyone using the RD > specification for commissioning tool functionality today since the > main purpose of the RD document is for something entirely different. I do not agree with your conclusion. The use of RD is still being discussed as far as I know, and each SDO seems to have its own approach and use cases. The use of a CT is completely within scope to my knowledge. Thanks hannes for your comments. Looking forward to getting things more precise and understandable for me. Peter > > Ciao > Hannes > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 09 April 2018 15:04 > To: Hannes Tschofenig > Cc: Jaime Jiménez; core@ietf.org > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft > >> >> I am curious what we lose if we remove this identifier altogether. The >> only thing that comes to my mind is a debugging capability where you >> might want to test your system without any security protocol. > Hi Hannes, > > Probably, I completely misunderstand your suggestion. > Registrations in the RD need identification so that they can be > changed, removed , updated, etc... > Registrations are identified by the (ep, d) pair, unique within a given > RD. > Removing ep identifier will force you to find another identifier for a > registration......... > and you are back to square 1 it seems. > > > Peter > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please 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. From nobody Tue Apr 24 02:40:31 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 A7F9C120721 for ; Tue, 24 Apr 2018 02:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 i_W9tApu-J5C for ; Tue, 24 Apr 2018 02:40:27 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 B2088124217 for ; Tue, 24 Apr 2018 02:40:26 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud9.xs4all.net with ESMTPA id AuQwfGIydSQicAuQwfONVu; Tue, 24 Apr 2018 11:40:24 +0200 Received: from 2001:983:a264:1:ecb7:3eb8:e763:ecc4 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 Apr 2018 11:40:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 Apr 2018 11:40:22 +0200 From: peter van der Stok To: Jim Schaad Cc: "'Kovatsch, Matthias'" , =?UTF-8?Q?=27?= =?UTF-8?Q?Christian_Ams=C3=BCss=27?= , consultancy@vanderstok.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <001a01d3d900$9d919eb0$d8b4dc10$@augustcellars.com> References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <001a01d3d900$9d919eb0$d8b4dc10$@augustcellars.com> Message-ID: <4c5f4bcc2b4b39c083a7b334aa82b920@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfGH38WEa305Zh/wNaUhCspvDiHL/FU4NCGn2EoPy2R6dtiNicFxkaB0gl/qLUGugHrB+sD40HLodUifLs7pNkxJFn9ObfkQb0oatf9gPfBn5078czXFl yBHJMosCRA1BcFcca/1uispEVfWIH+IasKMYM0akSza62nzlO1mSaYvFAWBLXoE76DxB/C+jQAY+P6vs07OinMvAsGFEMrybbK5ECsuTFMA6fD+OHIeJCVF4 BwIJfMSDqgxtORe/LLLnUwjrAnr+EeucfOUWiRH6fbUjkLTCDR0I16LvMrssPUzk Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 09:40:28 -0000 >> >> Related to this is the proper definition of "ins", which unfortunately >> was >> moved over to the core-rd-dns-sd draft. "ins" is used to distinguish >> resources >> with the same "rt". Originally, it was used for resource within the >> same >> device (e.g., >> ;rt=temperature;ins=indoor,;rt=temperature;ins=outdoor). By >> now, it often is assumed to require global uniqueness. I claim that >> this is not >> required when "ep" is used correctly. Using a hierarchy of "d" -> "ep" >> -> "ins" >> provides more flexibility than making "ins" globally unique. "ins" can >> still have >> a global meaning (cf. indoor vs outdoor), but it should be re-usable >> for all >> resources with similar instance semantics. Uniqueness is achieved >> through >> "d" and "ep". >> >> I think "ins" should become part of the RD draft again to be defined >> together >> with "d" and "ep", as they are part of a larger discovery framework. > > If "ins" does not need to be handled in a special manner by the RD, > then I would see no reason for it to be part of the RD draft. Both > "ep" and "d" are treated in a special manner as the pair is required > to be globally unique in the RD. This is not a true statement for the > "ins" attribute even in the core-rd-dns-sd draft. > > Jim > "Ins" is used to specify the instance name for DNS records necessary for DNS-sd service specification the RD-DNS-SD draft specifies the rules to generate ins values As such it is totally proper that "ins" rules are specified in a separate draft, because "ins" treatment is disconnected from the special treatment specified for "ep" and "d". Matthias, Are you expressing that an additional need exists to distinguish registrations? Peter From nobody Tue Apr 24 03:38:08 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 D06EF127136 for ; Tue, 24 Apr 2018 03:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 mRFXKxNQrPTe for ; Tue, 24 Apr 2018 03:38:05 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00081.outbound.protection.outlook.com [40.107.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7445A1241F8 for ; Tue, 24 Apr 2018 03:38:04 -0700 (PDT) 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; bh=1/ws1LFfvLH2InbQ+yhML3C3iLLYja6vzQaifKRoXAk=; b=jKbtqVkK+rdrVtd/0jSBQiJJdGgO05iGt75OjNAF2nE5bOQRv2lzh0AL5rEQT4N/cOwCb9CBFLmmkAi9jxvFOrkWgw+n2p4EF90FTVUqePM8FfcXz1ySWiOlWbzDlU33t0OKemfEqHNhDD6OB/jlhICKFGrBUoIWUj5vb9YxkP4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1821.eurprd08.prod.outlook.com (10.168.67.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Tue, 24 Apr 2018 10:38:01 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Tue, 24 Apr 2018 10:38:01 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" CC: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBCAALM9gP//8agggADTwQD//7rfYADWabOA/+pTH0D/0qjNgP+lQLCA Date: Tue, 24 Apr 2018 10:38:01 +0000 Message-ID: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> In-Reply-To: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [103.40.135.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1821; 7:xXJD3cD0KB7Ql+zBt+XaMGNoZy3YZPQP7qicwulWycGfGGAtD4EaDRKR6ktFXTXAnmDWW1Zb1UWI5eNs3otUATK5vFpEKwO6Vay0Ygv4VKiaeBLkmTnJo4k/o6dw3JSzCkW71/aUNr0FKGdpczF+QhJZRXqLkVzgtWy+0FXF9Vl1RHZ+LD7XxZijWEIAX3Tbd/2pNpnA+CCFXlolMMP6PsbhxaD+Rsm8Fuv+FinP3OOxsUkmMkFZ29aB0oGSmXWA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1821; x-ms-traffictypediagnostic: VI1PR0801MB1821: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0801MB1821; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1821; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(376002)(366004)(39380400002)(346002)(396003)(199004)(189003)(13464003)(377424004)(40434004)(6916009)(2906002)(6116002)(7696005)(8936002)(316002)(5640700003)(102836004)(476003)(26005)(33656002)(105586002)(106356001)(93886005)(5250100002)(5890100001)(6506007)(59450400001)(446003)(66066001)(54906003)(9686003)(81166006)(76176011)(2351001)(2501003)(86362001)(1730700003)(3660700001)(7736002)(81156014)(14454004)(3280700002)(6246003)(11346002)(25786009)(68736007)(72206003)(6436002)(99286004)(53936002)(2900100001)(8676002)(486006)(53546011)(74316002)(478600001)(305945005)(55016002)(97736004)(229853002)(3846002)(4326008)(186003)(5660300001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1821; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: W/yPfJshQwo5oUl7orSdZurkI7mzAfidQt/4X3TNer7VLYgRArlZf6EvDIYzJC4EYOQTTGeOCY5nqks2SZuRAUNObaul3dQ7I0vwEfQoQDen1Rq+r3D6n2n0WYpdQUnGiOdJTnrqLhh/MrswMgR3zFQv+ZpFypCszUpRSqr27iG+d1gZIffwBPre0Q3cwquN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 395823ba-294a-4b7a-ace0-08d5a9cf744a X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 395823ba-294a-4b7a-ace0-08d5a9cf744a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 10:38:01.6387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1821 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 10:38:08 -0000 SGkgUGV0ZXIsDQoNClRoZSBwcm9ibGVtIGlzIGFjdHVhbGx5IGRvY3VtZW50ZWQgaW4gdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiB0aGUgUkQgZHJhZnQgYW5kIEkgbW9kaWZp ZWQgaXQgc2xpZ2h0bHkuDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgdGhyZWF0OiB0d28gZGV2 aWNlcyBBIGFuZCBCIGFyZSBtYW5hZ2VkIGJ5IGEgc2luZ2xlIHNlcnZlci4gIEJvdGggZGV2aWNl cyBoYXZlIHVuaXF1ZSwgcGVyLWRldmljZSBjcmVkZW50aWFscyBmb3IgdXNlIHdpdGggRFRMUyAo b3IgYW55IG90aGVyIHNlY3VyaXR5IHByb3RvY29sIHNpbmNlIHRoZXJlIGlzIG5vdGhpbmcgRFRM UyBzcGVjaWZpYyBoZXJlKS4NCg0KTm93LCBpbWFnaW5lIHRoYXQgZGV2aWNlIEEgd2FudHMgdG8g c2Fib3RhZ2UgZGV2aWNlIEIuICBEZXZpY2UgQSB1c2VzIGl0cyBvd24gY3JlZGVudGlhbHMgZHVy aW5nIHRoZSBEVExTIGV4Y2hhbmdlLiAgVGhlbiwgZGV2aWNlIEEgcHV0cyB0aGUgZW5kcG9pbnQg bmFtZSBvZiBkZXZpY2UgQiBpbnRvIHRoZSByZWdpc3RyYXRpb24gbWVzc2FnZS4NCg0KSWYgdGhl IFJEIHNlcnZlciBkb2VzIG5vdCBjaGVjayB3aGV0aGVyIHRoZSBpZGVudGlmaWVyIHByb3ZpZGVk IGluIHRoZSBEVExTIGhhbmRzaGFrZSBtYXRjaGVzIHRoZSBlbmRwb2ludCBuYW1lIHVzZWQgYXQg dGhlIENvQVAgbGF5ZXIgaW4gdGhlIHJlZ2lzdHJhdGlvbiBtZXNzYWdlIGFuZCBpZiB0aGUgc2Vy dmVyIHVzZXMgdGhlIGVuZHBvaW50IG5hbWUgdGhlbiBkZXZpY2UgQSBjYW4gaW1wZXJzb25hdGUg ZGV2aWNlIEIuDQoNCkRvZXMgdGhpcyBjb25jZXJuIG1ha2Ugc2Vuc2U/DQoNCkNpYW8NCkhhbm5l cw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwZXRlciB2YW4gZGVyIFN0 b2sgW21haWx0bzpzdG9rY29uc0B4czRhbGwubmxdDQpTZW50OiAyNCBBcHJpbCAyMDE4IDE2OjI4 DQpUbzogSGFubmVzIFRzY2hvZmVuaWcNCkNjOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzsg SmFpbWUgSmltw6luZXo7IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gRW5kcG9p bnQgQ2xpZW50IE5hbWUgLyBFbmRwb2ludCBOYW1lIGluIFJEIGRyYWZ0DQoNCg0KDQpIYW5uZXMg VHNjaG9mZW5pZyBzY2hyZWVmIG9wIDIwMTgtMDQtMjMgMDU6MDg6DQo+IEhpIFBldGVyLA0KPg0K PiBUaGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gcmVjb25maXJtcyBteSB3b3JyeSB0aGF0IHBl b3BsZSB3aWxsIGdldA0KPiB0aGlzIHdyb25nIGFuZCB3aWxsIGludHJvZHVjZSBzZWN1cml0eSB2 dWxuZXJhYmlsaXRpZXMuDQoNCldlbGwsIEknbSBvbmUgb2YgdGhvc2UgZ2V0dGluZyBpdCB3cm9u ZywgYmVjYXVzZSBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgd29ycnkuDQoNCj4NCj4gSSBhbSBz YXlpbmcgdGhhdCB0aGUgc2VjdXJpdHkgcHJvdG9jb2wgdXNlZCB0byBwcm90ZWN0IHRoZQ0KPiBj b21tdW5pY2F0aW9uIHdpbGwgaGF2ZSBhbiBhdXRoZW50aWNhdGVkIGlkZW50aWZpZXIgYW5kIHRo aXMNCj4gaWRlbnRpZmllciB0aGVuIGhhcyB0byBiZSB1c2VkIGZvciBpZGVudGlmaWNhdGlvbiBv ZiB0aGUgSW9UIGRldmljZS4NCj4gVGhpcyBpZGVudGlmaWVyIHdpbGwgdGhlbiBhbHNvIGJlIHVz ZWQgZm9yIGxvb2t1cHMgLg0KDQpUaGlzIEkgdW5kZXJzdGFuZC4gSWYgSSBkbyBjbGVhcmx5IGZv bGxvdywgZ3VpZGVsaW5lcyBtdXN0IGJlIHByb2R1Y2VkIGFib3V0IHRoZSB1c2Ugb2YgYXV0aG9y aXplZCBSRCBhY2Nlc3Nlcy4NCkFzc3VtZSBhdXRob3JpemVkIGFjY2VzcyB0byB0aGUgUkQsIHVz aW5nIG9hdXRoLWF1dGh6Lg0KSSBkbyBzdXJtaXNlIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBtYXkg dGhlbiByZXR1cm4gYW4gc2lnbmVkIGlkZW50aWZpZXIgaW5zdGVhZCB0aGUgcGF0aCBuYW1lIG9m IHRoZSByZWdpc3RyYXRpb24uDQpUaGUgc2lnbmVkIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgZm9y IHVwZGF0ZXMuDQpUaGUgcGF5bG9hZCB3aWxsIGJlIGVuY3J5cHRlZCwgYW5kIHRodXMgdGhlIGFj dHVhbCB1c2Ugb2YgZXAsIGFuZCBkIGNhbiBiZSBtYWludGFpbmVkIGFzIHNwZWNpZmllZCBpbiB0 aGUgbG9va3VwLCBidXQgYXJlIGhpZGRlbiB0byBvdGhlcnMuDQoNCklzIHRoYXQgYSBjb3JyZWN0 IGV4dHJhcG9sYXRlZCBzdWdnZXN0aW9uIG9mIHlvdXIgY29tbWVudHM/IHByb2JhYmx5IHRoZXJl IGlzIGEgY2F2ZWF0IEkgZG9uJ3Qgc2VlLg0KDQo+DQo+IEkgYW0gZnVydGhlcm1vcmUgYXJndWlu ZyB0aGF0IHRoZSBtdWx0aXBsZSBJb1QgZGV2aWNlIGNhbm5vdCBzaGFyZSB0aGUNCj4gc2FtZSBp ZGVudGlmaWVyLg0KDQpzb3JyeSwgd2hhdCBpcyBhIG11bHRpcGxlIElvVCBkZXZpY2U/IG9uZSB3 aXRoIG11bHRpcGxlIHJlZ2lzdHJhdGlvbnMgaW4gdGhlIFJELCBvciBvbmUgd2l0aCBtdWx0aXBs ZSBsaW5rcz8gb3IuLi4uDQoNCkkgYWdyZWUgd2l0aCBKaW0gdGhhdCBmb3IgdGhpcmQgcGFydHkg cmVnaXN0cmF0aW9ucw0KPiB3ZSBjYW5ub3QgY29tcGxldGVseSBnZXQgcmlkIG9mIHRoZSBlbmRw b2ludCBjbGllbnQgbmFtZS9lbmRwb2ludCBuYW1lDQo+IGZ1bmN0aW9uYWxpdHkgYnV0IGZvciB0 aGUgdGhpcmQgcGFydHkgcmVnaXN0cmF0aW9uIHlvdSBhcmUgbW9zdCBsaWtlbHkNCj4gdXNpbmcg YSBkaWZmZXJlbnQgYXBwcm9hY2ggYW55d2F5LiBJIGFtIG5vdCBzdXJlIGFueW9uZSB1c2luZyB0 aGUgUkQNCj4gc3BlY2lmaWNhdGlvbiBmb3IgY29tbWlzc2lvbmluZyB0b29sIGZ1bmN0aW9uYWxp dHkgdG9kYXkgc2luY2UgdGhlDQo+IG1haW4gcHVycG9zZSBvZiB0aGUgUkQgZG9jdW1lbnQgaXMg Zm9yIHNvbWV0aGluZyBlbnRpcmVseSBkaWZmZXJlbnQuDQoNCkkgZG8gbm90IGFncmVlIHdpdGgg eW91ciBjb25jbHVzaW9uLiBUaGUgdXNlIG9mIFJEIGlzIHN0aWxsIGJlaW5nIGRpc2N1c3NlZCBh cyBmYXIgYXMgSSBrbm93LCBhbmQgZWFjaCBTRE8gc2VlbXMgdG8gaGF2ZSBpdHMgb3duIGFwcHJv YWNoIGFuZCB1c2UgY2FzZXMuIFRoZSB1c2Ugb2YgYSBDVCBpcyBjb21wbGV0ZWx5IHdpdGhpbiBz Y29wZSB0byBteSBrbm93bGVkZ2UuDQoNCg0KVGhhbmtzIGhhbm5lcyBmb3IgeW91ciBjb21tZW50 cy4NCkxvb2tpbmcgZm9yd2FyZCB0byBnZXR0aW5nIHRoaW5ncyBtb3JlIHByZWNpc2UgYW5kIHVu ZGVyc3RhbmRhYmxlIGZvciBtZS4NCg0KUGV0ZXINCg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwZXRlciB2YW4gZGVyIFN0b2sg W21haWx0bzpzdG9rY29uc0B4czRhbGwubmxdDQo+IFNlbnQ6IDA5IEFwcmlsIDIwMTggMTU6MDQN Cj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQo+IENjOiBKYWltZSBKaW3DqW5lejsgY29yZUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIEVuZHBvaW50IENsaWVudCBOYW1lIC8gRW5kcG9p bnQgTmFtZSBpbiBSRCBkcmFmdA0KPg0KPj4NCj4+IEkgYW0gY3VyaW91cyB3aGF0IHdlIGxvc2Ug aWYgd2UgcmVtb3ZlIHRoaXMgaWRlbnRpZmllciBhbHRvZ2V0aGVyLg0KPj4gVGhlIG9ubHkgdGhp bmcgdGhhdCBjb21lcyB0byBteSBtaW5kIGlzIGEgZGVidWdnaW5nIGNhcGFiaWxpdHkgd2hlcmUN Cj4+IHlvdSBtaWdodCB3YW50IHRvIHRlc3QgeW91ciBzeXN0ZW0gd2l0aG91dCBhbnkgc2VjdXJp dHkgcHJvdG9jb2wuDQo+IEhpIEhhbm5lcywNCj4NCj4gUHJvYmFibHksIEkgY29tcGxldGVseSBt aXN1bmRlcnN0YW5kIHlvdXIgc3VnZ2VzdGlvbi4NCj4gUmVnaXN0cmF0aW9ucyBpbiB0aGUgUkQg bmVlZCBpZGVudGlmaWNhdGlvbiBzbyB0aGF0IHRoZXkgY2FuIGJlDQo+IGNoYW5nZWQsIHJlbW92 ZWQgLCB1cGRhdGVkLCBldGMuLi4NCj4gUmVnaXN0cmF0aW9ucyBhcmUgaWRlbnRpZmllZCBieSB0 aGUgKGVwLCBkKSBwYWlyLCB1bmlxdWUgd2l0aGluIGENCj4gZ2l2ZW4gUkQuDQo+IFJlbW92aW5n IGVwIGlkZW50aWZpZXIgd2lsbCBmb3JjZSB5b3UgdG8gZmluZCBhbm90aGVyIGlkZW50aWZpZXIg Zm9yIGENCj4gcmVnaXN0cmF0aW9uLi4uLi4uLi4uDQo+IGFuZCB5b3UgYXJlIGJhY2sgdG8gc3F1 YXJlIDEgaXQgc2VlbXMuDQo+DQo+DQo+IFBldGVyDQo+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlDQo+IGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkDQo+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UNCj4gdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yDQo+IGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCg== From nobody Tue Apr 24 03:48: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 C4F921243F6 for ; Tue, 24 Apr 2018 03:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 eUAJcy8I1ttY for ; Tue, 24 Apr 2018 03:48:39 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30040.outbound.protection.outlook.com [40.107.3.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D351241F8 for ; Tue, 24 Apr 2018 03:48:38 -0700 (PDT) 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; bh=mfArEIgZl4M2HGAH9K79Z1LM2IgPxTB1LqB2LmjeFAI=; b=Ttw61hwTsyONat2ljdwggTY0pkHQmJdSeUXLGI/lf+TWMcGYb+X1cBu6otsfya9zupAIxafrskCopR2lnKlQjdiPB0F8nsUBd6vh+CkM0v/g9m2r4SwfH5+nLh82buGxW8zoD4Tn1dFh15F5KhjPUrONoyhR6vOIyQl2NTl7lKM= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1600.eurprd08.prod.outlook.com (10.167.211.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Tue, 24 Apr 2018 10:48:36 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Tue, 24 Apr 2018 10:48:36 +0000 From: Hannes Tschofenig To: "Kovatsch, Matthias" , Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "consultancy@vanderstok.org" , 'Carsten Bormann' CC: "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0zm23rcsFhLKykKKsIPwEtlWPKQCOhQAgAec7ACAA+NkwIAAmP0AgAF5RCA= Date: Tue, 24 Apr 2018 10:48:36 +0000 Message-ID: References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> 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=Hannes.Tschofenig@arm.com; x-originating-ip: [103.40.135.60] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1600; 7:oz5Lh95zlSY2L7mYSPAF93zV34TwUpttgJJ2mQJDVucaq6EKFp4TQ4VYI2/DMka0Y8qpAf6zXXIVnf6/yJF+5rg7+47jUMe1cfG/wkLRI3Qhih8qCRn0YKtXRlX4rRupeXvBpYiRzTCMalcRkQyLL6E1yLGc5GuNKKPX3VvgjyokoqJKiNzmDu36AXYzUVDe7rBxO1fzSaMSiRadtmH671rlTqK1TxVuJ4tPJ6pQow7nTOsoC0Z3wgE9AHU23nmX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1600; x-ms-traffictypediagnostic: VI1PR0801MB1600: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(278428928389397)(192374486261705)(126837547833334); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231232)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1600; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1600; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(376002)(39860400002)(396003)(366004)(189003)(199004)(40434004)(13464003)(305945005)(74316002)(72206003)(8936002)(53936002)(478600001)(9686003)(86362001)(3280700002)(97736004)(2906002)(476003)(3660700001)(25786009)(55016002)(486006)(446003)(11346002)(68736007)(106356001)(3846002)(105586002)(6116002)(5660300001)(5890100001)(5250100002)(2900100001)(186003)(4326008)(229853002)(93886005)(316002)(26005)(99286004)(59450400001)(76176011)(33656002)(53546011)(6506007)(6436002)(2501003)(7696005)(102836004)(81166006)(81156014)(66066001)(8676002)(14454004)(7736002)(110136005)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1600; H:VI1PR0801MB2112.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: RRydpNYkWskruN+7UhXaKpeW00A7kcNGl2zOBmoPodR7BvJZu6YUC8Ghyze1AwzY5mD58TDhgnmN9pb0H3BgjxIpUNI2Ui5hFJZhJgmJKuRltUNkv7vEsiHl/4DzUFu0ZHWCQx5UJKMbQ5scsd1/c/GMxfTUPGq4UJAyqsdiTyOiWugOMR0IV5HSR5r2LgyU spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a25de167-5d4e-472a-f3f1-08d5a9d0ee7f X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a25de167-5d4e-472a-f3f1-08d5a9d0ee7f X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 10:48:36.1354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1600 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 10:48:41 -0000 SGkgTWF0dGhpYXMNCg0KSSBmZWFyIHRoYXQgeW91IGFyZSBjcmVhdGluZyBzZWN1cml0eSBob2xl cyB0aGF0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQgdG8gZml4IGFmdGVyd2FyZHMuDQpJdCBqdXN0 IGZlZWxzIHRoYXQgdGhlc2UgYXJlICJuaWNlIGlkZWFzIiB3aXRoIGxpbWl0ZWQgcHJhY3RpY2Fs IGV4cGVyaWVuY2UuIFZlcnkgbXVjaCBsaWtlIHRoZSBpZGVhIG9mIGRvaW5nIHRoZSB0aGlyZCBw YXJ0eSByZWdpc3RyYXRpb24gd2l0aCB0aGUgY29tbWlzc2lvbmluZyB0b29sIGFzIGRlZmluZWQg aW4gdGhlIFJEIHNwZWNpZmljYXRpb24uDQoNCkNpYW8NCkhhbm5lcw0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLb3ZhdHNjaCwgTWF0dGhpYXMgW21haWx0bzptYXR0aGlh cy5rb3ZhdHNjaEBzaWVtZW5zLmNvbV0NClNlbnQ6IDIzIEFwcmlsIDIwMTggMTk6MTcNClRvOiBI YW5uZXMgVHNjaG9mZW5pZzsgSmltIFNjaGFhZDsgJ0NocmlzdGlhbiBBbXPDvHNzJzsgY29uc3Vs dGFuY3lAdmFuZGVyc3Rvay5vcmc7ICdDYXJzdGVuIEJvcm1hbm4nDQpDYzogY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogQVc6IFtjb3JlXSBFbmRwb2ludCBDbGllbnQgTmFtZSAvIEVuZHBvaW50IE5h bWUgaW4gUkQgZHJhZnQNCg0KPiBWb246IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86SGFubmVz LlRzY2hvZmVuaWdAYXJtLmNvbV0NCj4gPiBBcHBsaWNhdGlvbnMgd2lsbCB1c2UgdGhlIGFwcGxp Y2F0aW9uLWRlZmluZWQgaWRlbnRpZmllciwgbm90IGEgaGFuZGxlIGdlbmVyYXRlZCBieSB0aGUg UkQsIG5vdCB0aGUgc2VjdXJpdHkgY29udGV4dC4NCj4NCj4gV2hvIHNheXMgdGhhdD8gSWYgYXBw bGljYXRpb25zIG1ha2Ugc2VjdXJpdHkgZGVjaXNpb25zIGJhc2VkIG9uIHVuYXV0aGVudGljYXRl ZCBwYXJhbWV0ZXJzIHRoZW4gdGhleSB3aWxsIGJlIHRvYXN0Lg0KDQpJIGFtIG5vdCBzYXlpbmcg dGhleSBzaG91bGQgbm90IGF1dGhlbnRpY2F0ZS4NCkkgYW0gc2F5aW5nIHRoYXQgdGhlIGlkZW50 aWZpZXIgbWlnaHQgYmUgZGlmZmVyZW50IGZvciBhdXRob3JpemF0aW5nIHRoZSByZWdpc3RyYXRp b24gYW5kIGxvb2t1cCBieSBhcHBsaWNhdGlvbnMuIFRoZXkgbXVzdCBiZSBjb3JyZWxhdGFibGUg b2YgY291cnNlOyB0aGVtIGJlaW5nIHRoZSBzYW1lIGlzIGEgc3BlY2lhbCBjYXNlLCB0aGF0IGNv dWxkIGJlIGRlc2lyYWJsZS4gWWV0IHNvbWVvbmUgd2hvIGlzIGF1dGhlbnRpY2F0ZWQgYW5kIGF1 dGhvcml6ZWQgc2hvdWxkIGJlIGFsbG93ZWQgdG8gaW50cm9kdWNlIGFkZGl0aW9uYWwgaWRlbnRp ZmllcnMuDQoNCkNpYW8sDQpNYXR0aGlhcw0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= From nobody Tue Apr 24 07:15: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 610CF124239 for ; Tue, 24 Apr 2018 07:15:38 -0700 (PDT) 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, 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 fUBygDMQGjvU for ; Tue, 24 Apr 2018 07:15:29 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 27B8D124C27 for ; Tue, 24 Apr 2018 07:15:29 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud8.xs4all.net with ESMTPA id Ayj6fMQkcopELAyj6f3ohX; Tue, 24 Apr 2018 16:15:27 +0200 Received: from 2001:983:a264:1:4123:29d5:1021:5b46 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 Apr 2018 16:15:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 24 Apr 2018 16:15:24 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: consultancy@vanderstok.org, =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> Message-ID: <65097d58ae30b8823b206001fffc8d91@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfBIgPd9LFsFtgFjt0nu93l/0qh3KtsPFmngJ7cp2wyiKdiXywFZuhMN4z1yuR2rj2e6Bb2Qd7R85nqyYZla8QNZXIBusORdrlrArN5DGHx9CeY8h5ip3 yUAWU3fuBDkUhG55hVsyFSu69c8F/1Fic07Qmo18VhuOMR+3uohInC93M4T8jzHj40awAJ/hKoQRvuxws5UDm9wRaVf72Uk0INJ2UuSPlDPGyQUpcwYoefnE Io8hIEznyN9tX2FtdepZbkje876j5U6/04ZiUjDmy/U= Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2018 14:15:38 -0000 Hannes Tschofenig schreef op 2018-04-24 12:38: > Hi Peter, > > The problem is actually documented in the security consideration > section of the RD draft and I modified it slightly. > > Consider the following threat: two devices A and B are managed by a > single server. Both devices have unique, per-device credentials for > use with DTLS (or any other security protocol since there is nothing > DTLS specific here). > > Now, imagine that device A wants to sabotage device B. Device A uses > its own credentials during the DTLS exchange. Then, device A puts the > endpoint name of device B into the registration message. > > If the RD server does not check whether the identifier provided in the > DTLS handshake matches the endpoint name used at the CoAP layer in the > registration message and if the server uses the endpoint name then > device A can impersonate device B. > > Does this concern make sense? Hi Hannes, thanks for the example. I think a more simple and as unnerving example is the following. Assume the RD has no registrations yet. Device A registers multiple times with different ep and d values covering a large spectrum of the ep, d value space. No other device will be able to register any more; all ep and d values are taken. Same problem, correct? Suppose A registers without ep and d values Suppose the RD returns an encrypted identifier. The encrypted identifier remains private to A. Somewhere there should be a lookup identifier, for example an IP address, to be filled into the registration by A. lookup identifier is needed because for example B wants to discover registrations with given attributes, B needs the identifier to send requests to the associated discovered device. And still A can create many registrations with as many possible IP addresses. Do you agree, with the examples? Do you have a remedy? I need to think a bit about it. Peter > > Ciao > Hannes > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 24 April 2018 16:28 > To: Hannes Tschofenig > Cc: consultancy@vanderstok.org; Jaime Jiménez; core@ietf.org > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft > > > > Hannes Tschofenig schreef op 2018-04-23 05:08: >> Hi Peter, >> >> The mailing list discussion reconfirms my worry that people will get >> this wrong and will introduce security vulnerabilities. > > Well, I'm one of those getting it wrong, because I did not understand > the worry. > >> >> I am saying that the security protocol used to protect the >> communication will have an authenticated identifier and this >> identifier then has to be used for identification of the IoT device. >> This identifier will then also be used for lookups . > > This I understand. If I do clearly follow, guidelines must be produced > about the use of authorized RD accesses. > Assume authorized access to the RD, using oauth-authz. > I do surmise that the registration may then return an signed > identifier instead the path name of the registration. > The signed identifier can be used for updates. > The payload will be encrypted, and thus the actual use of ep, and d > can be maintained as specified in the lookup, but are hidden to > others. > > Is that a correct extrapolated suggestion of your comments? probably > there is a caveat I don't see. > >> >> I am furthermore arguing that the multiple IoT device cannot share the >> same identifier. > > sorry, what is a multiple IoT device? one with multiple registrations > in the RD, or one with multiple links? or.... > > I agree with Jim that for third party registrations >> we cannot completely get rid of the endpoint client name/endpoint name >> functionality but for the third party registration you are most likely >> using a different approach anyway. I am not sure anyone using the RD >> specification for commissioning tool functionality today since the >> main purpose of the RD document is for something entirely different. > > I do not agree with your conclusion. The use of RD is still being > discussed as far as I know, and each SDO seems to have its own > approach and use cases. The use of a CT is completely within scope to > my knowledge. > > > Thanks hannes for your comments. > Looking forward to getting things more precise and understandable for > me. > > Peter > >> >> Ciao >> Hannes >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: 09 April 2018 15:04 >> To: Hannes Tschofenig >> Cc: Jaime Jiménez; core@ietf.org >> Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft >> >>> >>> I am curious what we lose if we remove this identifier altogether. >>> The only thing that comes to my mind is a debugging capability where >>> you might want to test your system without any security protocol. >> Hi Hannes, >> >> Probably, I completely misunderstand your suggestion. >> Registrations in the RD need identification so that they can be >> changed, removed , updated, etc... >> Registrations are identified by the (ep, d) pair, unique within a >> given RD. >> Removing ep identifier will force you to find another identifier for a >> registration......... >> and you are back to square 1 it seems. >> >> >> Peter >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please 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. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please 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. From nobody Tue Apr 24 19:17:20 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 D182C1241F3 for ; Tue, 24 Apr 2018 19:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 Pqn_XUaRynhe for ; Tue, 24 Apr 2018 19:17:15 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C1D120725 for ; Tue, 24 Apr 2018 19:17:14 -0700 (PDT) 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; bh=WUndv2Dt45bbLy6feOcWeFrnll+mckuENbQp7ME2hsU=; b=ZGg4cX6/isTtlmUnF1Y8nC+Gyv/NaIJFiQI5L6J8LTnNutECkzPdbvsqAX3F3GfnYDCiZg/WTLEclA+trEdAFLqvDljRHTMzBpuVHgesDinvI0TIqc2pI1MefvnA8S1uerHa6Juj8NJfbWlNTigIPn63P56KIzZhurvxqY83gv8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1392.eurprd08.prod.outlook.com (10.167.198.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Wed, 25 Apr 2018 02:17:10 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Wed, 25 Apr 2018 02:17:10 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" CC: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPMGk8Ajq5nOeuWRv+BrgbskCDzwf//7S4A//+qDBCAALM9gP//8agggADTwQD//7rfYADWabOA/+pTH0D/0qjNgP+lQLCA/0pB5wD+k7uScA== Date: Wed, 25 Apr 2018 02:17:10 +0000 Message-ID: References: <070801d3cc3f$8d59e0c0$a80da240$@augustcellars.com>, <7BA9B091-F489-4ED4-B6EC-5AD7D971D6F7@ericsson.com> <65097d58ae30b8823b206001fffc8d91@xs4all.nl> In-Reply-To: <65097d58ae30b8823b206001fffc8d91@xs4all.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=Hannes.Tschofenig@arm.com; x-originating-ip: [103.40.135.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1392; 7:hzlNAJT4YBJ41M/KTB5X9XeL0cNVtjX+ruRjktIC2rzHVdrpMeK+/GaXKTxQYe6heda4Yy1wFDuLJAPaimUstDqAB45nzQhEnhix4Yq0+Ee6Vz5e8x7+bGJkndgTBgenpy7VhPDxwIHbPJlVce14+HnF2sDb/jBmZxOmgt2PmrgiHHoORJ1ch5Yw5km8rly9WTIrtQycEqoLbyYa5pIIr2r/b2+fA3vqVgUM5JzTp6rUOOWDGc5CAS9VUEgYw/yj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1392; x-ms-traffictypediagnostic: VI1PR0801MB1392: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(176510541525296); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231232)(944501410)(52105095)(10201501046)(3002001)(6055026)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1392; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1392; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(39380400002)(346002)(376002)(189003)(377424004)(40434004)(51914003)(199004)(13464003)(229853002)(76176011)(3660700001)(8676002)(4326008)(7696005)(486006)(59450400001)(55016002)(305945005)(81166006)(6506007)(8936002)(476003)(86362001)(106356001)(53546011)(25786009)(11346002)(66066001)(446003)(74316002)(6246003)(1730700003)(81156014)(6916009)(7736002)(5890100001)(3280700002)(105586002)(316002)(97736004)(2501003)(5250100002)(99286004)(5660300001)(14454004)(2351001)(26005)(186003)(5640700003)(68736007)(3846002)(33656002)(478600001)(6116002)(2900100001)(72206003)(93886005)(2906002)(9686003)(6436002)(54906003)(53936002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1392; H:VI1PR0801MB2112.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: wxhquWF6TQvXM+8pp7w5itSdMVqbvPp1maBUjpLKsHODzpcczEnLGajrH6Vfo3EljiPSige0/8/K+vy2bxgifk4MIJ+eVHTboni5InTbBjl8+72csLS+qU+6TYU1tvWa7OE7lPmYdTsxoAGA+7gflb/e+re6fOlue9rq774tNV5SwdmIp956pc74NiQRO5C7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 83f4d458-b9b0-430e-6045-08d5aa52a6e9 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83f4d458-b9b0-430e-6045-08d5aa52a6e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 02:17:10.6052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1392 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2018 02:17:18 -0000 SGkgUGV0ZXIsDQoNCnRoYW5rcyBmb3IgdGhlIGV4YW1wbGUuDQpJIHRoaW5rIGEgbW9yZSBzaW1w bGUgYW5kIGFzIHVubmVydmluZyBleGFtcGxlIGlzIHRoZSBmb2xsb3dpbmcuDQpBc3N1bWUgdGhl IFJEIGhhcyBubyByZWdpc3RyYXRpb25zIHlldC4NCkRldmljZSBBIHJlZ2lzdGVycyBtdWx0aXBs ZSB0aW1lcyB3aXRoIGRpZmZlcmVudCBlcCBhbmQgZCB2YWx1ZXMgY292ZXJpbmcgYSBsYXJnZSBz cGVjdHJ1bSBvZiB0aGUgZXAsIGQgdmFsdWUgc3BhY2UuDQpObyBvdGhlciBkZXZpY2Ugd2lsbCBi ZSBhYmxlIHRvIHJlZ2lzdGVyIGFueSBtb3JlOyBhbGwgZXAgYW5kIGQgdmFsdWVzIGFyZSB0YWtl bi4NCg0KU2FtZSBwcm9ibGVtLCBjb3JyZWN0Pw0KDQpbSGFubmVzXSBZZXMuDQoNClN1cHBvc2Ug QSByZWdpc3RlcnMgd2l0aG91dCBlcCBhbmQgZCB2YWx1ZXMgU3VwcG9zZSB0aGUgUkQgcmV0dXJu cyBhbiBlbmNyeXB0ZWQgaWRlbnRpZmllci4NClRoZSBlbmNyeXB0ZWQgaWRlbnRpZmllciByZW1h aW5zIHByaXZhdGUgdG8gQS4NClNvbWV3aGVyZSB0aGVyZSBzaG91bGQgYmUgYSBsb29rdXAgaWRl bnRpZmllciwgZm9yIGV4YW1wbGUgYW4gSVAgYWRkcmVzcywgdG8gYmUgZmlsbGVkIGludG8gdGhl IHJlZ2lzdHJhdGlvbiBieSBBLg0KbG9va3VwIGlkZW50aWZpZXIgaXMgbmVlZGVkIGJlY2F1c2Ug Zm9yIGV4YW1wbGUgQiB3YW50cyB0byBkaXNjb3ZlciByZWdpc3RyYXRpb25zIHdpdGggZ2l2ZW4g YXR0cmlidXRlcywgQiBuZWVkcyB0aGUgaWRlbnRpZmllciB0byBzZW5kIHJlcXVlc3RzIHRvIHRo ZSBhc3NvY2lhdGVkIGRpc2NvdmVyZWQgZGV2aWNlLg0KDQpBbmQgc3RpbGwgQSBjYW4gY3JlYXRl IG1hbnkgcmVnaXN0cmF0aW9ucyB3aXRoIGFzIG1hbnkgcG9zc2libGUgSVAgYWRkcmVzc2VzLg0K DQpbSGFubmVzXSBSRCBkb2VzIG5vdCBwcm92aWRlIHN1Y2ggZW5jcnlwdGVkIGlkZW50aWZpZXIg YW5kIGhlbmNlIHRoZSBleGFtcGxlIGlzIG5vdCB2YWxpZC4NCg0KDQpEbyB5b3UgYWdyZWUsIHdp dGggdGhlIGV4YW1wbGVzPyBEbyB5b3UgaGF2ZSBhIHJlbWVkeT8NCkkgbmVlZCB0byB0aGluayBh IGJpdCBhYm91dCBpdC4NCg0KW0hhbm5lc10gVGhlIHByb2JsZW0gZ29lcyBhd2F5IHdoZW4gd2Ug dXNlIHRoZSBhdXRoZW50aWNhdGVkIGlkZW50aWZpZXIgdXNlZCBieSB0aGUgc2VjdXJpdHkgcHJv dG9jb2wuDQoNCkNpYW8NCkhhbm5lcw0KDQoNClBldGVyDQoNCg0KPg0KPiBDaWFvDQo+IEhhbm5l cw0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwZXRlciB2YW4g ZGVyIFN0b2sgW21haWx0bzpzdG9rY29uc0B4czRhbGwubmxdDQo+IFNlbnQ6IDI0IEFwcmlsIDIw MTggMTY6MjgNCj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQo+IENjOiBjb25zdWx0YW5jeUB2YW5k ZXJzdG9rLm9yZzsgSmFpbWUgSmltw6luZXo7IGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtjb3JlXSBFbmRwb2ludCBDbGllbnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQN Cj4NCj4NCj4NCj4gSGFubmVzIFRzY2hvZmVuaWcgc2NocmVlZiBvcCAyMDE4LTA0LTIzIDA1OjA4 Og0KPj4gSGkgUGV0ZXIsDQo+Pg0KPj4gVGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIHJlY29u ZmlybXMgbXkgd29ycnkgdGhhdCBwZW9wbGUgd2lsbCBnZXQNCj4+IHRoaXMgd3JvbmcgYW5kIHdp bGwgaW50cm9kdWNlIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcy4NCj4NCj4gV2VsbCwgSSdtIG9u ZSBvZiB0aG9zZSBnZXR0aW5nIGl0IHdyb25nLCBiZWNhdXNlIEkgZGlkIG5vdCB1bmRlcnN0YW5k DQo+IHRoZSB3b3JyeS4NCj4NCj4+DQo+PiBJIGFtIHNheWluZyB0aGF0IHRoZSBzZWN1cml0eSBw cm90b2NvbCB1c2VkIHRvIHByb3RlY3QgdGhlDQo+PiBjb21tdW5pY2F0aW9uIHdpbGwgaGF2ZSBh biBhdXRoZW50aWNhdGVkIGlkZW50aWZpZXIgYW5kIHRoaXMNCj4+IGlkZW50aWZpZXIgdGhlbiBo YXMgdG8gYmUgdXNlZCBmb3IgaWRlbnRpZmljYXRpb24gb2YgdGhlIElvVCBkZXZpY2UuDQo+PiBU aGlzIGlkZW50aWZpZXIgd2lsbCB0aGVuIGFsc28gYmUgdXNlZCBmb3IgbG9va3VwcyAuDQo+DQo+ IFRoaXMgSSB1bmRlcnN0YW5kLiBJZiBJIGRvIGNsZWFybHkgZm9sbG93LCBndWlkZWxpbmVzIG11 c3QgYmUgcHJvZHVjZWQNCj4gYWJvdXQgdGhlIHVzZSBvZiBhdXRob3JpemVkIFJEIGFjY2Vzc2Vz Lg0KPiBBc3N1bWUgYXV0aG9yaXplZCBhY2Nlc3MgdG8gdGhlIFJELCB1c2luZyBvYXV0aC1hdXRo ei4NCj4gSSBkbyBzdXJtaXNlIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBtYXkgdGhlbiByZXR1cm4g YW4gc2lnbmVkDQo+IGlkZW50aWZpZXIgaW5zdGVhZCB0aGUgcGF0aCBuYW1lIG9mIHRoZSByZWdp c3RyYXRpb24uDQo+IFRoZSBzaWduZWQgaWRlbnRpZmllciBjYW4gYmUgdXNlZCBmb3IgdXBkYXRl cy4NCj4gVGhlIHBheWxvYWQgd2lsbCBiZSBlbmNyeXB0ZWQsIGFuZCB0aHVzIHRoZSBhY3R1YWwg dXNlIG9mIGVwLCBhbmQgZA0KPiBjYW4gYmUgbWFpbnRhaW5lZCBhcyBzcGVjaWZpZWQgaW4gdGhl IGxvb2t1cCwgYnV0IGFyZSBoaWRkZW4gdG8NCj4gb3RoZXJzLg0KPg0KPiBJcyB0aGF0IGEgY29y cmVjdCBleHRyYXBvbGF0ZWQgc3VnZ2VzdGlvbiBvZiB5b3VyIGNvbW1lbnRzPyBwcm9iYWJseQ0K PiB0aGVyZSBpcyBhIGNhdmVhdCBJIGRvbid0IHNlZS4NCj4NCj4+DQo+PiBJIGFtIGZ1cnRoZXJt b3JlIGFyZ3VpbmcgdGhhdCB0aGUgbXVsdGlwbGUgSW9UIGRldmljZSBjYW5ub3Qgc2hhcmUNCj4+ IHRoZSBzYW1lIGlkZW50aWZpZXIuDQo+DQo+IHNvcnJ5LCB3aGF0IGlzIGEgbXVsdGlwbGUgSW9U IGRldmljZT8gb25lIHdpdGggbXVsdGlwbGUgcmVnaXN0cmF0aW9ucw0KPiBpbiB0aGUgUkQsIG9y IG9uZSB3aXRoIG11bHRpcGxlIGxpbmtzPyBvci4uLi4NCj4NCj4gSSBhZ3JlZSB3aXRoIEppbSB0 aGF0IGZvciB0aGlyZCBwYXJ0eSByZWdpc3RyYXRpb25zDQo+PiB3ZSBjYW5ub3QgY29tcGxldGVs eSBnZXQgcmlkIG9mIHRoZSBlbmRwb2ludCBjbGllbnQgbmFtZS9lbmRwb2ludA0KPj4gbmFtZSBm dW5jdGlvbmFsaXR5IGJ1dCBmb3IgdGhlIHRoaXJkIHBhcnR5IHJlZ2lzdHJhdGlvbiB5b3UgYXJl IG1vc3QNCj4+IGxpa2VseSB1c2luZyBhIGRpZmZlcmVudCBhcHByb2FjaCBhbnl3YXkuIEkgYW0g bm90IHN1cmUgYW55b25lIHVzaW5nDQo+PiB0aGUgUkQgc3BlY2lmaWNhdGlvbiBmb3IgY29tbWlz c2lvbmluZyB0b29sIGZ1bmN0aW9uYWxpdHkgdG9kYXkgc2luY2UNCj4+IHRoZSBtYWluIHB1cnBv c2Ugb2YgdGhlIFJEIGRvY3VtZW50IGlzIGZvciBzb21ldGhpbmcgZW50aXJlbHkgZGlmZmVyZW50 Lg0KPg0KPiBJIGRvIG5vdCBhZ3JlZSB3aXRoIHlvdXIgY29uY2x1c2lvbi4gVGhlIHVzZSBvZiBS RCBpcyBzdGlsbCBiZWluZw0KPiBkaXNjdXNzZWQgYXMgZmFyIGFzIEkga25vdywgYW5kIGVhY2gg U0RPIHNlZW1zIHRvIGhhdmUgaXRzIG93bg0KPiBhcHByb2FjaCBhbmQgdXNlIGNhc2VzLiBUaGUg dXNlIG9mIGEgQ1QgaXMgY29tcGxldGVseSB3aXRoaW4gc2NvcGUgdG8NCj4gbXkga25vd2xlZGdl Lg0KPg0KPg0KPiBUaGFua3MgaGFubmVzIGZvciB5b3VyIGNvbW1lbnRzLg0KPiBMb29raW5nIGZv cndhcmQgdG8gZ2V0dGluZyB0aGluZ3MgbW9yZSBwcmVjaXNlIGFuZCB1bmRlcnN0YW5kYWJsZSBm b3INCj4gbWUuDQo+DQo+IFBldGVyDQo+DQo+Pg0KPj4gQ2lhbw0KPj4gSGFubmVzDQo+Pg0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHBldGVyIHZhbiBkZXIgU3RvayBb bWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0NCj4+IFNlbnQ6IDA5IEFwcmlsIDIwMTggMTU6MDQN Cj4+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KPj4gQ2M6IEphaW1lIEppbcOpbmV6OyBjb3JlQGll dGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW2NvcmVdIEVuZHBvaW50IENsaWVudCBOYW1lIC8gRW5k cG9pbnQgTmFtZSBpbiBSRCBkcmFmdA0KPj4NCj4+Pg0KPj4+IEkgYW0gY3VyaW91cyB3aGF0IHdl IGxvc2UgaWYgd2UgcmVtb3ZlIHRoaXMgaWRlbnRpZmllciBhbHRvZ2V0aGVyLg0KPj4+IFRoZSBv bmx5IHRoaW5nIHRoYXQgY29tZXMgdG8gbXkgbWluZCBpcyBhIGRlYnVnZ2luZyBjYXBhYmlsaXR5 IHdoZXJlDQo+Pj4geW91IG1pZ2h0IHdhbnQgdG8gdGVzdCB5b3VyIHN5c3RlbSB3aXRob3V0IGFu eSBzZWN1cml0eSBwcm90b2NvbC4NCj4+IEhpIEhhbm5lcywNCj4+DQo+PiBQcm9iYWJseSwgSSBj b21wbGV0ZWx5IG1pc3VuZGVyc3RhbmQgeW91ciBzdWdnZXN0aW9uLg0KPj4gUmVnaXN0cmF0aW9u cyBpbiB0aGUgUkQgbmVlZCBpZGVudGlmaWNhdGlvbiBzbyB0aGF0IHRoZXkgY2FuIGJlDQo+PiBj aGFuZ2VkLCByZW1vdmVkICwgdXBkYXRlZCwgZXRjLi4uDQo+PiBSZWdpc3RyYXRpb25zIGFyZSBp ZGVudGlmaWVkIGJ5IHRoZSAoZXAsIGQpIHBhaXIsIHVuaXF1ZSB3aXRoaW4gYQ0KPj4gZ2l2ZW4g UkQuDQo+PiBSZW1vdmluZyBlcCBpZGVudGlmaWVyIHdpbGwgZm9yY2UgeW91IHRvIGZpbmQgYW5v dGhlciBpZGVudGlmaWVyIGZvcg0KPj4gYSByZWdpc3RyYXRpb24uLi4uLi4uLi4NCj4+IGFuZCB5 b3UgYXJlIGJhY2sgdG8gc3F1YXJlIDEgaXQgc2VlbXMuDQo+Pg0KPj4NCj4+IFBldGVyDQo+PiBJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZQ0KPj4gY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UNCj4+IHRoZSBjb250ZW50 cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBv cg0KPj4gY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPiBJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZQ0KPiBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlDQo+IHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvcg0K PiBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Wed Apr 25 07:13: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 86050126D3F for ; Wed, 25 Apr 2018 07:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 RYQPMrw0xqXM for ; Wed, 25 Apr 2018 07:13:32 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 4688F120047 for ; Wed, 25 Apr 2018 07:13:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,326,1520895600"; d="scan'208";a="263281664" Received: from carbonero250.irisa.fr ([131.254.250.10]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Apr 2018 16:13:30 +0200 From: Federico Sismondi Organization: INRIA To: core@ietf.org Message-ID: <09af5fa6-3ea0-1289-b5dd-01178dabb8ff@inria.fr> Date: Wed, 25 Apr 2018 16:13:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [core] CoAP interop testing tool now available in F-Interop platform X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2018 14:13:36 -0000 Hello all, We are pleased to announce that we have made available the CoAP interoperability testing tool in the F-Interop Platform (go.f-interop.eu) For those who don't know, F-Interop allows to automatically manage and facilitate the interoperability testing process. Some of the features provided by the tools are: - traces visualization (raw packet data, protocol and fields dissections, etc) - traces verification issuing (pass, fail, inconclusive) verdicts based on the test specification (see more below about the test specification) - facilitate the remote testing process by creating tunnels between the two implementations participating in the interop tests - host some CoAP reference implementations (for the time being CoAPthon and Californium clients and servers) which are ready to execute the interop test cases without human interaction The process for setting up an interoperability session is pretty simple, it just requires an account creation and in a few clicks you are ready to start doing some interoperability testing. Note that there are no fees or costs for using the platform. You can find a guided tour over the CoAP testing tool doc here: http://doc.f-interop.eu/interop/#guided-tour-coap-test-suite F-Interop Platform supports also the possibility to run interoperability tests between two remotely located users (please contact me if you are interested about this use case so I can explain how the session sharing/joining mechanism works). The tool is based on the test specification (written by Carsten Bormann) which has been previously used during ETSI's plugtests. The test specification and test cases currently implemented can be found here: http://doc.f-interop.eu/testsuites/coap For those interested, please send me an email in order to discuss if your implementation and desktop environment fit the needed requirements for running the tools. Regards, Federico -- Federico Sismondi Research Engineer DIONYSOS Research team INRIA/IRISA Rennes - Bretagne Atlantique Research Centre From nobody Wed Apr 25 13:56: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 2C72B12D7F4 for ; Wed, 25 Apr 2018 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gv1bjQB_jTlv for ; Wed, 25 Apr 2018 13:56:02 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (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 A0AF812D7ED for ; Wed, 25 Apr 2018 13:56:01 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w3PKtKXv003928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 22:55:20 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w3PKtJjJ011531 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 22:55:19 +0200 Received: from DEFTHW99ER8MSX.ww902.siemens.net (139.22.70.73) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.389.1; Wed, 25 Apr 2018 22:55:19 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.4]) by DEFTHW99ER8MSX.ww902.siemens.net ([139.22.70.73]) with mapi id 14.03.0389.001; Wed, 25 Apr 2018 22:55:18 +0200 From: "Kovatsch, Matthias" To: Hannes Tschofenig , Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "consultancy@vanderstok.org" , "'Carsten Bormann'" CC: "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0znBtoTmC857b0Co5UImt06WfqQCGI0AgAe4tOCAA8hngIAAuLvggAFZOgCAAlp+4A== Date: Wed, 25 Apr 2018 20:55:17 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17724@DEFTHW99EL4MSX.ww902.siemens.net> References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2018 20:56:04 -0000 RGVhciBIYW5uZXMNCg0KTXkgY29tbWVudCBpcyB0aGF0IHlvdXIgc29sdXRpb24gdG8gbGluayB0 aGUgRW5kcG9pbnQgQ2xpZW50IE5hbWUgdG8gdGhlIHJlZ2lzdHJhdGlvbiBhdXRoZW50aWNhdGlv biBkb2VzIG5vdCB3b3JrIGZvciBhdCBsZWFzdCB0d28gb2YgdGhlIGRlc2lyZWQgdXNlIGNhc2Vz Og0KLSBBIGNvbW1pc3Npb25pbmcgdG9vbCByZWdpc3RlcmluZyBhIGRldmljZSBvbiBpdHMgYmVo YWxmLCBhcyB0aGUgY29tbWlzc2lvbmluZyB0b29sIHNob3VsZCBub3QgaGF2ZSB0aGUgcHJpdmF0 ZSBrZXlzIG9yIHNpbWlsYXIgb2YgdGhlIGRldmljZS4NCi0gQXBwbGljYXRpb25zIHVzaW5nIEVu ZHBvaW50IENsaWVudCBOYW1lcyB0aGF0IGFyZSBkaWZmZXJlbnQgZnJvbSB0aGUgbmFtZXMgaW4g dGhlIGRldmljZSBjZXJ0aWZpY2F0ZXMvYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMgZm9yIHJl Z2lzdHJhdGlvbg0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91LCBob3dldmVyLCB0aGF0IHRoZSBS RCBtdXN0IGNsZWFybHkgc3RhdGUgdGhhdCB0aGUgcmVnaXN0ZXJpbmcgZW50aXR5IG11c3QgcHJv b2YgdGhhdCBpdCBpcyBhdXRob3JpemVkIHRvIHVzZSB0aGUgRW5kcG9pbnQgQ2xpZW50IE5hbWUg aXQgcmVnaXN0ZXJzLiBUaGlzIG1pZ2h0IGhhdmUgYmVlbiB0b28gaW1wbGljaXQgc28gZmFyIGFu ZCB0aGVyZSBkZWZpbml0ZWx5IHdhcyBub3QgZW5vdWdoIHdvcmsgdG8gZmlndXJlIHRoaXMgb3V0 IGZ1bGx5LiBUaGVyZSBhcmUgc2V2ZXJhbCB3YXlzIGhvdyB0byBkbyB0aGlzOyBJIHRoaW5rIHdl IHNob3VsZCBub3QgbGltaXQgaXQgdG8ganVzdCBvbmUgc2ltcGxlIHdheSB0aGF0IGJyZWFrcyBh dCBsZWFzdCB0d28gdXNlIGNhc2VzLiBCdXQgd2UgY2FuIGdpdmUgaXQsIGZvciBpbnN0YW5jZSwg YXMgbWluaW11bSBNVVNUIHdoZW4gdGhlcmUgaXMgbm8gb3RoZXIgd2F5IHRvIHByb29mIGF1dGhv cml6YXRpb24gdG8gdXNlIHRoZSBFbmRwb2ludCBDbGllbnQgTmFtZSBmb3IgcmVnaXN0cmF0aW9u Lg0KDQpPbmUgbW9yZSBnZW5lcmljIHdheSBjb3VsZCBiZSB0byByZXF1aXJlIGRldmljZSBhbmQg cmVnaXN0ZXJpbmcgZW50aXR5IHRvIGJlIHdpdGhpbiB0aGUgc2FtZSBkb21haW4sIHNvIHRoYXQg ImQiIGNhbiBiZSBhdXRoZW50aWNhdGVkLiBBIGNvbW1pc3Npb25pbmcgdG9vbCB3b3VsZCBuZWVk IHRvIGF1dGhlbnRpY2F0ZSBpdHMgZG9tYWluLCBidXQgdGhlbiBjYW4gdXNlIGFueSBFbmRwb2lu dCBDbGllbnQgTmFtZSB3aXRoaW4gdGhpcyBkb21haW4uDQoNCkNpYW8sDQpNYXR0aGlhcw0KDQoN Cj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEhhbm5lcyBUc2No b2ZlbmlnIFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbV0NCj4gR2VzZW5kZXQ6IERp ZW5zdGFnLCAyNC4gQXByaWwgMjAxOCAxMjo0OQ0KPiBBbjogS292YXRzY2gsIE1hdHRoaWFzIChD VCBSREEgSU9UIEVXVC1ERSk7IEppbSBTY2hhYWQ7ICdDaHJpc3RpYW4gQW1zw7xzcyc7IGNvbnN1 bHRhbmN5QHZhbmRlcnN0b2sub3JnOyAnQ2Fyc3RlbiBCb3JtYW5uJw0KPiBDYzogY29yZUBpZXRm Lm9yZw0KPiBCZXRyZWZmOiBSRTogW2NvcmVdIEVuZHBvaW50IENsaWVudCBOYW1lIC8gRW5kcG9p bnQgTmFtZSBpbiBSRCBkcmFmdA0KPiANCj4gSGkgTWF0dGhpYXMNCj4gDQo+IEkgZmVhciB0aGF0 IHlvdSBhcmUgY3JlYXRpbmcgc2VjdXJpdHkgaG9sZXMgdGhhdCB3aWxsIGJlIHZlcnkgZGlmZmlj dWx0IHRvIGZpeCBhZnRlcndhcmRzLg0KPiBJdCBqdXN0IGZlZWxzIHRoYXQgdGhlc2UgYXJlICJu aWNlIGlkZWFzIiB3aXRoIGxpbWl0ZWQgcHJhY3RpY2FsIGV4cGVyaWVuY2UuIFZlcnkgbXVjaCBs aWtlIHRoZSBpZGVhIG9mIGRvaW5nIHRoZSB0aGlyZCBwYXJ0eSByZWdpc3RyYXRpb24gd2l0aA0K PiB0aGUgY29tbWlzc2lvbmluZyB0b29sIGFzIGRlZmluZWQgaW4gdGhlIFJEIHNwZWNpZmljYXRp b24uDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEtvdmF0c2NoLCBNYXR0aGlhcyBbbWFpbHRvOm1hdHRoaWFzLmtvdmF0 c2NoQHNpZW1lbnMuY29tXQ0KPiBTZW50OiAyMyBBcHJpbCAyMDE4IDE5OjE3DQo+IFRvOiBIYW5u ZXMgVHNjaG9mZW5pZzsgSmltIFNjaGFhZDsgJ0NocmlzdGlhbiBBbXPDvHNzJzsgY29uc3VsdGFu Y3lAdmFuZGVyc3Rvay5vcmc7ICdDYXJzdGVuIEJvcm1hbm4nDQo+IENjOiBjb3JlQGlldGYub3Jn DQo+IFN1YmplY3Q6IEFXOiBbY29yZV0gRW5kcG9pbnQgQ2xpZW50IE5hbWUgLyBFbmRwb2ludCBO YW1lIGluIFJEIGRyYWZ0DQo+IA0KPiA+IFZvbjogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzpI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tXQ0KPiA+ID4gQXBwbGljYXRpb25zIHdpbGwgdXNlIHRo ZSBhcHBsaWNhdGlvbi1kZWZpbmVkIGlkZW50aWZpZXIsIG5vdCBhIGhhbmRsZSBnZW5lcmF0ZWQg YnkgdGhlIFJELCBub3QgdGhlIHNlY3VyaXR5IGNvbnRleHQuDQo+ID4NCj4gPiBXaG8gc2F5cyB0 aGF0PyBJZiBhcHBsaWNhdGlvbnMgbWFrZSBzZWN1cml0eSBkZWNpc2lvbnMgYmFzZWQgb24gdW5h dXRoZW50aWNhdGVkIHBhcmFtZXRlcnMgdGhlbiB0aGV5IHdpbGwgYmUgdG9hc3QuDQo+IA0KPiBJ IGFtIG5vdCBzYXlpbmcgdGhleSBzaG91bGQgbm90IGF1dGhlbnRpY2F0ZS4NCj4gSSBhbSBzYXlp bmcgdGhhdCB0aGUgaWRlbnRpZmllciBtaWdodCBiZSBkaWZmZXJlbnQgZm9yIGF1dGhvcml6YXRp bmcgdGhlIHJlZ2lzdHJhdGlvbiBhbmQgbG9va3VwIGJ5IGFwcGxpY2F0aW9ucy4gVGhleSBtdXN0 IGJlIGNvcnJlbGF0YWJsZQ0KPiBvZiBjb3Vyc2U7IHRoZW0gYmVpbmcgdGhlIHNhbWUgaXMgYSBz cGVjaWFsIGNhc2UsIHRoYXQgY291bGQgYmUgZGVzaXJhYmxlLiBZZXQgc29tZW9uZSB3aG8gaXMg YXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBzaG91bGQgYmUNCj4gYWxsb3dlZCB0byBpbnRy b2R1Y2UgYWRkaXRpb25hbCBpZGVudGlmaWVycy4NCj4gDQo+IENpYW8sDQo+IE1hdHRoaWFzDQo+ IA0KPiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZQ0KPiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvcg0KPiBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Wed Apr 25 14:30: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 AEBDE12D7F4 for ; Wed, 25 Apr 2018 14:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 nr-sM9i032Gs for ; Wed, 25 Apr 2018 14:30:10 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 4BE6D12D7F3 for ; Wed, 25 Apr 2018 14:30:10 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w3PLTcAv007353 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 23:29:38 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w3PLTcH3031130 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 23:29:38 +0200 Received: from DENBGAT9ER0MSX.ww902.siemens.net (139.22.70.177) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.389.1; Wed, 25 Apr 2018 23:29:37 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.4]) by DENBGAT9ER0MSX.ww902.siemens.net ([139.22.70.177]) with mapi id 14.03.0389.001; Wed, 25 Apr 2018 23:29:37 +0200 From: "Kovatsch, Matthias" To: "consultancy@vanderstok.org" , Jim Schaad CC: =?iso-8859-1?Q?=27Christian_Ams=FCss=27?= , "core@ietf.org" Thread-Topic: Definition of the ins target attribute - WAS: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPc2CJmMIAFfi1CQCiQbpKRtnOkzA== Date: Wed, 25 Apr 2018 21:29:36 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.49] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 25 Apr 2018 21:30:13 -0000 Dear all My motivation for raising this issue was that I learned that "ins" is used = differently from its (original) purpose. I agree that there is no special h= andling of "ins" by RD. Having it in the DNS-SD draft might shift its meani= ng or at least perception and definitely visibility. Writing its own draft = for just "ins" is overkill, though. "ins" has an important role within CoRE discovery and we should avoid that = people overlook it, because they think they do not need DNS-SD (and they do= not need it for CoRE discovery). So we need to nail down its definition an= d probably mention it in multiple drafts (with proper references). I read t= he text in core-rd-dns-sd and it is roughly fine, but sounds a bit like I h= ave to learn DNS-SD to do CoRE discovery. Also I am not sure about the foll= owing statements within the same section 2.1: > "SHOULD be unique across resources with the same Resource Type attribute = in the domain it is used." Is "domain" corresponding to RD's "d" parameter and attribute? > "This attribute is used by a Resource Directory to distinguish between mu= ltiple instances of the same resource type within the directory" Here it sounds like it needs to be unique across all resources with the sam= e Resource Type attribute in the RD. Logically and historically, I would have expected that "ins" MUST be unique= across all resources with the same Resource Type attribute in one device (= =3Dep). I don't know if there is a conflict with DNS-SD here, so that we ca= nnot define this. Yet a definition to be unique within "d" seems to aim for= application semantics: When unique within "ep", a device from the factory could already have "ins"= attributes for its resources, for instance, a weather station with two tem= perature sensors, one ins=3Dindoor, one ins=3Doutdoor. When unique within "d", someone had to rewrite the "ins" attributes, so tha= t they match the deployment or application, for instance, ins=3D"indoor kit= chen", ins=3D"indoor lobby", ins=3D"outdoor terrace", ins=3D"outdoor garage= ". Do we actually have rough consensus on what "ins" actually means and how it= should be used for discovery within CoRE? (There is a high chance that I just missed that due to being busy with othe= r stuff...) Best wishes, Matthias > -----Urspr=FCngliche Nachricht----- > Von: peter van der Stok [mailto:stokcons@xs4all.nl] > Gesendet: Dienstag, 24. April 2018 11:40 > An: Jim Schaad > Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Christian Ams=FCss'; consult= ancy@vanderstok.org; core@ietf.org > Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft >=20 >=20 > >> > >> Related to this is the proper definition of "ins", which > >> unfortunately was moved over to the core-rd-dns-sd draft. "ins" is > >> used to distinguish resources with the same "rt". Originally, it was > >> used for resource within the same device (e.g., > >> ;rt=3Dtemperature;ins=3Dindoor,;rt=3Dtemperature;ins=3Doutdo= or). By > >> now, it often is assumed to require global uniqueness. I claim that > >> this is not required when "ep" is used correctly. Using a hierarchy > >> of "d" -> "ep" > >> -> "ins" > >> provides more flexibility than making "ins" globally unique. "ins" > >> can still have a global meaning (cf. indoor vs outdoor), but it > >> should be re-usable for all resources with similar instance > >> semantics. Uniqueness is achieved through "d" and "ep". > >> > >> I think "ins" should become part of the RD draft again to be defined > >> together with "d" and "ep", as they are part of a larger discovery > >> framework. > > > > If "ins" does not need to be handled in a special manner by the RD, > > then I would see no reason for it to be part of the RD draft. Both > > "ep" and "d" are treated in a special manner as the pair is required > > to be globally unique in the RD. This is not a true statement for the > > "ins" attribute even in the core-rd-dns-sd draft. > > > > Jim > > > "Ins" is used to specify the instance name for DNS records necessary for = DNS-sd service specification the RD-DNS-SD draft specifies > the rules to generate ins values As such it is totally proper that "ins" = rules are specified in a separate draft, because "ins" treatment is > disconnected from the special treatment specified for "ep" and "d". >=20 > Matthias, Are you expressing that an additional need exists to distinguis= h registrations? >=20 > Peter From nobody Wed Apr 25 20:05: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 AC0A812DA01 for ; Wed, 25 Apr 2018 20:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 MlBPhnl--He1 for ; Wed, 25 Apr 2018 20:05:36 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30049.outbound.protection.outlook.com [40.107.3.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973891241F3 for ; Wed, 25 Apr 2018 20:05:35 -0700 (PDT) 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; bh=v7WKwoA28y2aDjWZuQkEMEwlQo34H5HSXDjGInuXVrU=; b=S6mbW8/wtURyU/P5+guPviuLS2e8/9+J6I0Di0opTaNbI+ahls43P9ULJ8IRMM2mk3Apz0Qrh7Jjyc5MPtQjtUpZneZqfHraFU5w5lCu1lK1DAco+QR5ZTklsiqOOxEvsrxEMrs8IDabM2zx5S3r0929iDLZAgst7XAaXUGodeE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2718.eurprd08.prod.outlook.com (10.166.198.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Thu, 26 Apr 2018 03:05:32 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Thu, 26 Apr 2018 03:05:32 +0000 From: Hannes Tschofenig To: "Kovatsch, Matthias" , Jim Schaad , =?utf-8?B?J0NocmlzdGlhbiBBbXPDvHNzJw==?= , "consultancy@vanderstok.org" , 'Carsten Bormann' CC: "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0zm23rcsFhLKykKKsIPwEtlWPKQCOhQAgAec7ACAA+NkwIAAmP0AgAF5RCCAAjxVgIAAZE/w Date: Thu, 26 Apr 2018 03:05:32 +0000 Message-ID: References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F17724@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17724@DEFTHW99EL4MSX.ww902.siemens.net> 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=Hannes.Tschofenig@arm.com; x-originating-ip: [103.40.135.59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2718; 7:DWg/boRYYuB4ZIJGjuCbHp00uoE+YFfbf+z0a7jtE6CXwLxQ7yz2aF7tWewwmDOsjoZ/gCyTB0gx/U/WrrEOM5MCl/PC3q9R/PjVKtw045HjsQjOezM11HzIMcN59JAj28F/HoRaot6CI+D0178S776uqDHFBlCgLv1kUa/N9jL2TFLb1jwBK1xUkGRxNtW93WNNQSXWMAwEeTREOlhA5Q3qOiWQuF+Asy+EAMXv6wjvTf2pikJyvocYH6y+L0wS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2718; x-ms-traffictypediagnostic: VI1PR0801MB2718: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(278428928389397)(192374486261705)(126837547833334); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231232)(944501410)(52105095)(6055026)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0801MB2718; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2718; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39380400002)(366004)(39860400002)(40434004)(13464003)(199004)(189003)(55016002)(72206003)(478600001)(74316002)(4326008)(11346002)(68736007)(6246003)(97736004)(305945005)(476003)(86362001)(25786009)(3660700001)(486006)(14454004)(3846002)(6116002)(446003)(2501003)(229853002)(2906002)(5250100002)(6436002)(5890100001)(2900100001)(3280700002)(106356001)(59450400001)(7736002)(6506007)(26005)(102836004)(316002)(8936002)(53546011)(186003)(93886005)(105586002)(76176011)(33656002)(110136005)(7696005)(81166006)(66066001)(81156014)(8676002)(99286004)(53936002)(5660300001)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2718; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oVG0NFVjTSCg91EV1+6syS5fD03QYTka+d4APHmA2lzR+vgMqZBlGixUvWY2lrcNH0+Ygv9OGCTuT0455yIvL+QwIeCdKIbTbKsUaqE1C+ELmTC4ix4RR2TFaHva7PInzCEYWP2lnyXmzIPHGKwNP0IdEbrcNHBVTOidbeqqfKbqoLrH+V0mNsxTAmEjVUaD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: cee5cbf2-6e44-4477-0e18-08d5ab2292c5 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: cee5cbf2-6e44-4477-0e18-08d5ab2292c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 03:05:32.1168 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2718 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2018 03:05:39 -0000 SGkgTWF0dGhpYXMsDQoNCkkgaGF2ZSBkb3VidHMgdGhhdCBhbnlvbmUgaXMgdXNpbmcgdGhlIHRo aXJkIHBhcnR5IHJlZ2lzdHJhdGlvbiBmdW5jdGlvbmFsaXR5IGZvciBhIGNvbW1pc3Npb25pbmcg dG9vbC4gSXMgU2llbWVucyBvciBhbnlvbmUgZWxzZSBkZXBsb3lpbmcgdGhpcyBmdW5jdGlvbmFs aXR5PyBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBnZXQgdGhpcyBpbnB1dC4NCg0KVGhlIHJl cXVpcmVtZW50IGZvciBhcHBsaWNhdGlvbnMgdXNpbmcgRW5kcG9pbnQgQ2xpZW50IE5hbWVzIHRo YXQgYXJlIGRpZmZlcmVudCBmcm9tIHRoZSBuYW1lcyBpbiB0aGUgZGV2aWNlIGNlcnRpZmljYXRl cy9hdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBmb3IgcmVnaXN0cmF0aW9uIGFwcGVhcnMgZnV6 enkgYW5kIG5vdCB3ZWxsIGp1c3RpZmllZC4gV2hhdCBpZGVudGlmaWVyIGRvIHlvdSBiZWxpZXZl IHlvdSBjYW4gcHV0IGluIGFuIGVuZHBvaW50IGNsaWVudCBuYW1lIGJ1dCBub3QgaW4gYSBzZWN1 cml0eSBwcm90b2NvbCBvciB3aGF0IGFyZSB0aGUgbmVlZHMgb2YgYW4gYXBwbGljYXRpb24gdGhh dCBjYW5ub3QgYmUgbWV0Pw0KDQpXZSBoYXZlIGJlZW4gd29ya2luZyBvbiBMd00yTSBhbmQgaGF2 ZSB1c2VkIGEgc3Vic2V0IG9mIHRoZSBSRCBmdW5jdGlvbmFsaXR5IGZvciBpdC4gU2VuZGluZyBh biBpZGVudGlmaWVyIGluIHRoZSBzZWN1cml0eSBwcm90b2NvbCBhbmQgYXQgdGhlIENvQVAgbGV2 ZWwgKGFzIHBhcnQgb2YgdGhlIEVuZHBvaW50IENsaWVudCBOYW1lIGluIHRoZSByZWdpc3RyYXRp b24pIGlzIGFsc28gd2FzdGluZyBieXRlcyBvbiB0aGUgd2lyZSAoaW4gYWRkaXRpb24gdG8gdGhl IHNlY3VyaXR5IGltcGxpY2F0aW9ucykuDQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogS292YXRzY2gsIE1hdHRoaWFzIFttYWlsdG86bWF0dGhpYXMu a292YXRzY2hAc2llbWVucy5jb21dDQpTZW50OiAyNiBBcHJpbCAyMDE4IDAzOjU1DQpUbzogSGFu bmVzIFRzY2hvZmVuaWc7IEppbSBTY2hhYWQ7ICdDaHJpc3RpYW4gQW1zw7xzcyc7IGNvbnN1bHRh bmN5QHZhbmRlcnN0b2sub3JnOyAnQ2Fyc3RlbiBCb3JtYW5uJw0KQ2M6IGNvcmVAaWV0Zi5vcmcN ClN1YmplY3Q6IEFXOiBbY29yZV0gRW5kcG9pbnQgQ2xpZW50IE5hbWUgLyBFbmRwb2ludCBOYW1l IGluIFJEIGRyYWZ0DQoNCkRlYXIgSGFubmVzDQoNCk15IGNvbW1lbnQgaXMgdGhhdCB5b3VyIHNv bHV0aW9uIHRvIGxpbmsgdGhlIEVuZHBvaW50IENsaWVudCBOYW1lIHRvIHRoZSByZWdpc3RyYXRp b24gYXV0aGVudGljYXRpb24gZG9lcyBub3Qgd29yayBmb3IgYXQgbGVhc3QgdHdvIG9mIHRoZSBk ZXNpcmVkIHVzZSBjYXNlczoNCi0gQSBjb21taXNzaW9uaW5nIHRvb2wgcmVnaXN0ZXJpbmcgYSBk ZXZpY2Ugb24gaXRzIGJlaGFsZiwgYXMgdGhlIGNvbW1pc3Npb25pbmcgdG9vbCBzaG91bGQgbm90 IGhhdmUgdGhlIHByaXZhdGUga2V5cyBvciBzaW1pbGFyIG9mIHRoZSBkZXZpY2UuDQotIEFwcGxp Y2F0aW9ucyB1c2luZyBFbmRwb2ludCBDbGllbnQgTmFtZXMgdGhhdCBhcmUgZGlmZmVyZW50IGZy b20gdGhlIG5hbWVzIGluIHRoZSBkZXZpY2UgY2VydGlmaWNhdGVzL2F1dGhlbnRpY2F0aW9uIGNy ZWRlbnRpYWxzIGZvciByZWdpc3RyYXRpb24NCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSwgaG93 ZXZlciwgdGhhdCB0aGUgUkQgbXVzdCBjbGVhcmx5IHN0YXRlIHRoYXQgdGhlIHJlZ2lzdGVyaW5n IGVudGl0eSBtdXN0IHByb29mIHRoYXQgaXQgaXMgYXV0aG9yaXplZCB0byB1c2UgdGhlIEVuZHBv aW50IENsaWVudCBOYW1lIGl0IHJlZ2lzdGVycy4gVGhpcyBtaWdodCBoYXZlIGJlZW4gdG9vIGlt cGxpY2l0IHNvIGZhciBhbmQgdGhlcmUgZGVmaW5pdGVseSB3YXMgbm90IGVub3VnaCB3b3JrIHRv IGZpZ3VyZSB0aGlzIG91dCBmdWxseS4gVGhlcmUgYXJlIHNldmVyYWwgd2F5cyBob3cgdG8gZG8g dGhpczsgSSB0aGluayB3ZSBzaG91bGQgbm90IGxpbWl0IGl0IHRvIGp1c3Qgb25lIHNpbXBsZSB3 YXkgdGhhdCBicmVha3MgYXQgbGVhc3QgdHdvIHVzZSBjYXNlcy4gQnV0IHdlIGNhbiBnaXZlIGl0 LCBmb3IgaW5zdGFuY2UsIGFzIG1pbmltdW0gTVVTVCB3aGVuIHRoZXJlIGlzIG5vIG90aGVyIHdh eSB0byBwcm9vZiBhdXRob3JpemF0aW9uIHRvIHVzZSB0aGUgRW5kcG9pbnQgQ2xpZW50IE5hbWUg Zm9yIHJlZ2lzdHJhdGlvbi4NCg0KT25lIG1vcmUgZ2VuZXJpYyB3YXkgY291bGQgYmUgdG8gcmVx dWlyZSBkZXZpY2UgYW5kIHJlZ2lzdGVyaW5nIGVudGl0eSB0byBiZSB3aXRoaW4gdGhlIHNhbWUg ZG9tYWluLCBzbyB0aGF0ICJkIiBjYW4gYmUgYXV0aGVudGljYXRlZC4gQSBjb21taXNzaW9uaW5n IHRvb2wgd291bGQgbmVlZCB0byBhdXRoZW50aWNhdGUgaXRzIGRvbWFpbiwgYnV0IHRoZW4gY2Fu IHVzZSBhbnkgRW5kcG9pbnQgQ2xpZW50IE5hbWUgd2l0aGluIHRoaXMgZG9tYWluLg0KDQpDaWFv LA0KTWF0dGhpYXMNCg0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4g Vm9uOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb21d DQo+IEdlc2VuZGV0OiBEaWVuc3RhZywgMjQuIEFwcmlsIDIwMTggMTI6NDkNCj4gQW46IEtvdmF0 c2NoLCBNYXR0aGlhcyAoQ1QgUkRBIElPVCBFV1QtREUpOyBKaW0gU2NoYWFkOyAnQ2hyaXN0aWFu IEFtc8O8c3MnOyBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzsgJ0NhcnN0ZW4gQm9ybWFubicN Cj4gQ2M6IGNvcmVAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUkU6IFtjb3JlXSBFbmRwb2ludCBDbGll bnQgTmFtZSAvIEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQNCj4NCj4gSGkgTWF0dGhpYXMNCj4N Cj4gSSBmZWFyIHRoYXQgeW91IGFyZSBjcmVhdGluZyBzZWN1cml0eSBob2xlcyB0aGF0IHdpbGwg YmUgdmVyeSBkaWZmaWN1bHQgdG8gZml4IGFmdGVyd2FyZHMuDQo+IEl0IGp1c3QgZmVlbHMgdGhh dCB0aGVzZSBhcmUgIm5pY2UgaWRlYXMiIHdpdGggbGltaXRlZCBwcmFjdGljYWwNCj4gZXhwZXJp ZW5jZS4gVmVyeSBtdWNoIGxpa2UgdGhlIGlkZWEgb2YgZG9pbmcgdGhlIHRoaXJkIHBhcnR5IHJl Z2lzdHJhdGlvbiB3aXRoIHRoZSBjb21taXNzaW9uaW5nIHRvb2wgYXMgZGVmaW5lZCBpbiB0aGUg UkQgc3BlY2lmaWNhdGlvbi4NCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4NCj4NCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS292YXRzY2gsIE1hdHRoaWFzIFttYWlsdG86bWF0 dGhpYXMua292YXRzY2hAc2llbWVucy5jb21dDQo+IFNlbnQ6IDIzIEFwcmlsIDIwMTggMTk6MTcN Cj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnOyBKaW0gU2NoYWFkOyAnQ2hyaXN0aWFuIEFtc8O8c3Mn OyBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzsgJ0NhcnN0ZW4gQm9ybWFubicNCj4gQ2M6IGNv cmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogQVc6IFtjb3JlXSBFbmRwb2ludCBDbGllbnQgTmFtZSAv IEVuZHBvaW50IE5hbWUgaW4gUkQgZHJhZnQNCj4NCj4gPiBWb246IEhhbm5lcyBUc2Nob2Zlbmln IFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbV0NCj4gPiA+IEFwcGxpY2F0aW9ucyB3 aWxsIHVzZSB0aGUgYXBwbGljYXRpb24tZGVmaW5lZCBpZGVudGlmaWVyLCBub3QgYSBoYW5kbGUg Z2VuZXJhdGVkIGJ5IHRoZSBSRCwgbm90IHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KPiA+DQo+ID4g V2hvIHNheXMgdGhhdD8gSWYgYXBwbGljYXRpb25zIG1ha2Ugc2VjdXJpdHkgZGVjaXNpb25zIGJh c2VkIG9uIHVuYXV0aGVudGljYXRlZCBwYXJhbWV0ZXJzIHRoZW4gdGhleSB3aWxsIGJlIHRvYXN0 Lg0KPg0KPiBJIGFtIG5vdCBzYXlpbmcgdGhleSBzaG91bGQgbm90IGF1dGhlbnRpY2F0ZS4NCj4g SSBhbSBzYXlpbmcgdGhhdCB0aGUgaWRlbnRpZmllciBtaWdodCBiZSBkaWZmZXJlbnQgZm9yIGF1 dGhvcml6YXRpbmcNCj4gdGhlIHJlZ2lzdHJhdGlvbiBhbmQgbG9va3VwIGJ5IGFwcGxpY2F0aW9u cy4gVGhleSBtdXN0IGJlIGNvcnJlbGF0YWJsZQ0KPiBvZiBjb3Vyc2U7IHRoZW0gYmVpbmcgdGhl IHNhbWUgaXMgYSBzcGVjaWFsIGNhc2UsIHRoYXQgY291bGQgYmUgZGVzaXJhYmxlLiBZZXQgc29t ZW9uZSB3aG8gaXMgYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBzaG91bGQgYmUgYWxsb3dl ZCB0byBpbnRyb2R1Y2UgYWRkaXRpb25hbCBpZGVudGlmaWVycy4NCj4NCj4gQ2lhbywNCj4gTWF0 dGhpYXMNCj4NCj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUNCj4gY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Apr 26 02:14: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 E7C431243FE for ; Thu, 26 Apr 2018 02:14:24 -0700 (PDT) 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, 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 Zn_AXkM9I6Yr for ; Thu, 26 Apr 2018 02:14:22 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 37896126579 for ; Thu, 26 Apr 2018 02:14:18 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud9.xs4all.net with ESMTPA id BcymfW4btSQicBcymfW937; Thu, 26 Apr 2018 11:14:16 +0200 Received: from 2001:983:a264:1:1048:cd99:db93:8719 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 26 Apr 2018 11:14:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 26 Apr 2018 11:14:16 +0200 From: peter van der Stok To: "Kovatsch, Matthias" Cc: consultancy@vanderstok.org, Jim Schaad , =?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: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@DEFTHW99EL4MSX.ww902.siemens.net> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17757@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfMO9UmjjXcVy83TN4u7cxAqhvedDqDt3iSLlSx0x+SppjMneBba5uVztDlLsulGDzBtGNi4hMiHGhfY2Tm1Bla8a0L5M30RacMN79UObIOjgYIW47eaZ nMLWkv+EDZJGJV97MHLyfAhm7ooLZBXg/ZoIcAy23vLAXhHleBTuDskFCQ9RO0JN0/BoLAT+JFozWca67CByZxvR9jVXBO0BsMjYmQ1CZ7aCTEuCULpxLVbV JhRg3qebI1pTqBgE+HIzXvBavafXco5n7Y7c2wU+frY7C2erXVUe+B+joC8HOvu0 Archived-At: Subject: Re: [core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2018 09:14:25 -0000 Hi Matthias, On of the confusing aspects is indeed the domain. Domain is used in two senses: + d= as a local domain definition within rd to group resources + domain as used in DNS In earlier RD texts a mapping was suggested between d= and the DNS domain. That was abandoned because unusable for most building installations as we know them. The mapping may be possible for other installations, but it certainly cannot be a general rule. The RD-DNS-Sd draft does not want to suggest that you need to learn DNS-SD to do core discovery, but you have to learn DNS-sd to get the RD to DNSSD mapping right. ins is an important attribute to select the service type instance needed for dnssd. I am happy to learn how you want to fit ins values into RD discovery. Possibly you need a new attribute in RD given that the mapping from RD to DNSSD is not always 1-1. Greetings, Peter Kovatsch, Matthias schreef op 2018-04-25 23:29: > Dear all > > My motivation for raising this issue was that I learned that "ins" is > used differently from its (original) purpose. I agree that there is no > special handling of "ins" by RD. Having it in the DNS-SD draft might > shift its meaning or at least perception and definitely visibility. > Writing its own draft for just "ins" is overkill, though. > > > "ins" has an important role within CoRE discovery and we should avoid > that people overlook it, because they think they do not need DNS-SD > (and they do not need it for CoRE discovery). So we need to nail down > its definition and probably mention it in multiple drafts (with proper > references). I read the text in core-rd-dns-sd and it is roughly fine, > but sounds a bit like I have to learn DNS-SD to do CoRE discovery. > Also I am not sure about the following statements within the same > section 2.1: > >> "SHOULD be unique across resources with the same Resource Type >> attribute in the domain it is used." > > Is "domain" corresponding to RD's "d" parameter and attribute? > >> "This attribute is used by a Resource Directory to distinguish between >> multiple instances of the same resource type within the directory" > > Here it sounds like it needs to be unique across all resources with > the same Resource Type attribute in the RD. > > > Logically and historically, I would have expected that "ins" MUST be > unique across all resources with the same Resource Type attribute in > one device (=ep). I don't know if there is a conflict with DNS-SD > here, so that we cannot define this. Yet a definition to be unique > within "d" seems to aim for application semantics: > > When unique within "ep", a device from the factory could already have > "ins" attributes for its resources, for instance, a weather station > with two temperature sensors, one ins=indoor, one ins=outdoor. > > When unique within "d", someone had to rewrite the "ins" attributes, > so that they match the deployment or application, for instance, > ins="indoor kitchen", ins="indoor lobby", ins="outdoor terrace", > ins="outdoor garage". > > > Do we actually have rough consensus on what "ins" actually means and > how it should be used for discovery within CoRE? > (There is a high chance that I just missed that due to being busy with > other stuff...) > > > Best wishes, > Matthias > > >> -----Ursprüngliche Nachricht----- >> Von: peter van der Stok [mailto:stokcons@xs4all.nl] >> Gesendet: Dienstag, 24. April 2018 11:40 >> An: Jim Schaad >> Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Christian Amsüss'; >> consultancy@vanderstok.org; core@ietf.org >> Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft >> >> >> >> >> >> Related to this is the proper definition of "ins", which >> >> unfortunately was moved over to the core-rd-dns-sd draft. "ins" is >> >> used to distinguish resources with the same "rt". Originally, it was >> >> used for resource within the same device (e.g., >> >> ;rt=temperature;ins=indoor,;rt=temperature;ins=outdoor). By >> >> now, it often is assumed to require global uniqueness. I claim that >> >> this is not required when "ep" is used correctly. Using a hierarchy >> >> of "d" -> "ep" >> >> -> "ins" >> >> provides more flexibility than making "ins" globally unique. "ins" >> >> can still have a global meaning (cf. indoor vs outdoor), but it >> >> should be re-usable for all resources with similar instance >> >> semantics. Uniqueness is achieved through "d" and "ep". >> >> >> >> I think "ins" should become part of the RD draft again to be defined >> >> together with "d" and "ep", as they are part of a larger discovery >> >> framework. >> > >> > If "ins" does not need to be handled in a special manner by the RD, >> > then I would see no reason for it to be part of the RD draft. Both >> > "ep" and "d" are treated in a special manner as the pair is required >> > to be globally unique in the RD. This is not a true statement for the >> > "ins" attribute even in the core-rd-dns-sd draft. >> > >> > Jim >> > >> "Ins" is used to specify the instance name for DNS records necessary >> for DNS-sd service specification the RD-DNS-SD draft specifies >> the rules to generate ins values As such it is totally proper that >> "ins" rules are specified in a separate draft, because "ins" treatment >> is >> disconnected from the special treatment specified for "ep" and "d". >> >> Matthias, Are you expressing that an additional need exists to >> distinguish registrations? >> >> Peter From nobody Thu Apr 26 02:34:03 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 E2E3912420B for ; Thu, 26 Apr 2018 02:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 u4RLYG5kEy6K for ; Thu, 26 Apr 2018 02:34:01 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 058D4126579 for ; Thu, 26 Apr 2018 02:34:00 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud9.xs4all.net with ESMTPA id BdHqfWEr8SQicBdHqfWFKG; Thu, 26 Apr 2018 11:33:59 +0200 Received: from 2001:983:a264:1:1048:cd99:db93:8719 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 26 Apr 2018 11:33:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Apr 2018 11:33:58 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: "Kovatsch, Matthias" , Jim Schaad , =?UTF-8?Q?=27Christian_Ams=C3=BCss=27?= , consultancy@vanderstok.org, 'Carsten Bormann' , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F17724@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfPeiU1S3PBteCxOu/5L0QzMQJxZd1I8rAZ9KL0NfXMpmoSCSSv5dn926QKXrW2z8hGrAiL0tlH5VX0btLMvRHwMw7NBrIiw4W1VPVuUu/KOyhowrVbsN wZDM6Q2UwbQ+QpzQDcU6Q8yQpJE4/cQoBMbn+vETeimZrqiWfTDfmfTLa6EgS8UTsYrX44Oi78/z4l9cP653k/v+6LCj8AXFhRvZWHrD8iQ840tMO+7+PBDu mibpmtPUU7lEhlsxpd+nDyLxLVwzepl8XMazIQHdI78VKPxG+53tJEwe+2EZBa2M+iHTeiU0nvPN/Zlz8avY3RvoMrD8rfXB1sY7agHCheQ= Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2018 09:34:03 -0000 Hi Hannes, This e-mail of you to Matthias answers my questions I had before. thanks. I was under the impression that you wanted to cater for malicious nodes that forged the authorization token. > > The requirement for applications using Endpoint Client Names that are > different from the names in the device certificates/authentication > credentials for registration appears fuzzy and not well justified. > What identifier do you believe you can put in an endpoint client name > but not in a security protocol or what are the needs of an application > that cannot be met? > For example, the d=value is typically installation dependent. To my knowledge, using d= is envisaged in building installations. at the same time, the ep=value does not need a value with a semantic meaning, so any identifier will do in my opinion. I could imagine that a claim with "d"= is added to the token when required. Same approach for installations which can afford the overhead and want human readable ep names. Peter From nobody Thu Apr 26 03:34: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 73893126C19 for ; Thu, 26 Apr 2018 03:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 sssEER69hbNo for ; Thu, 26 Apr 2018 03:34:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0044.outbound.protection.outlook.com [104.47.0.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615A612025C for ; Thu, 26 Apr 2018 03:34:40 -0700 (PDT) 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; bh=Jhc5ds7J+cGACDwzopHHFdVJ2qi1kWzhunpQflYQznk=; b=VBl07lPEh7mvM5ibcmabJ4vAdb9yDQBIa4GJJ3nxTD7UasYnuIgJcmcEsBSsqFC127Y4HW3JvHJjCyEtuVnrKGnbCA2fYA0LZM/XEdOZsg4AHDdOqNG2Qi6mRIAkbo+rxvSK10QYcXuF5Fvbk8eDRJArjIXnKIDTmj0KwHAGC8g= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1838.eurprd08.prod.outlook.com (10.168.68.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Thu, 26 Apr 2018 10:34:36 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Thu, 26 Apr 2018 10:34:36 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" CC: "Kovatsch, Matthias" , Jim Schaad , =?iso-8859-1?Q?=27Christian_Ams=FCss=27?= , 'Carsten Bormann' , "core@ietf.org" Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AQHT0zm23rcsFhLKykKKsIPwEtlWPKQCOhQAgAec7ACAA+NkwIAAmP0AgAF5RCCAAjxVgIAAZE/wgABvqgCAAA4LwA== Date: Thu, 26 Apr 2018 10:34:36 +0000 Message-ID: References: <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01F17724@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: 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=Hannes.Tschofenig@arm.com; x-originating-ip: [103.40.135.59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1838; 7:y1agymfsh1/xQIUunABmGwqgEwExqQr4Y+ImEeax5BUQ/RUYPR9ub0wDksi3NZUZC3gc/9DuwJEQgGHz/xRoAK31ZzKYK+imz3vO11pJWE6wzg/XyRH+kwuqpyx/3KXOFGKPpkla9ltO+KkK32WPzP9ZJZOkgqvENRACzwz3uWarTgF+I65p8/0P0iySPkP+sGzj70PWftokXOTAB89WYPUJ8uqw78qpmZ6cirkOuJEcdTekZgd8pfhp4O7jliXl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1838; x-ms-traffictypediagnostic: VI1PR0801MB1838: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1838; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1838; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(366004)(376002)(346002)(13464003)(40434004)(189003)(199004)(3280700002)(93886005)(26005)(486006)(1730700003)(102836004)(5250100002)(476003)(81166006)(2906002)(5640700003)(33656002)(8676002)(7736002)(105586002)(6506007)(9686003)(66066001)(8936002)(3660700001)(53546011)(2900100001)(55016002)(54906003)(6916009)(316002)(81156014)(59450400001)(11346002)(76176011)(446003)(6246003)(186003)(305945005)(106356001)(2351001)(53936002)(7696005)(14454004)(74316002)(3846002)(99286004)(25786009)(229853002)(2501003)(6436002)(5660300001)(5890100001)(72206003)(86362001)(4326008)(6116002)(68736007)(478600001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1838; H:VI1PR0801MB2112.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: Wvs8RQ4EshQXKHdh878YnN0kuEU9zBVRhPxaBlbl5ZYbyhwHxToRitivDXXO/YxPgWxKeqrLIfP65uBKN7MMjFlIqVCo/0Wqj2A95y2I3niLRkpnhsdeCJzoH9smflh8hodGQ8KPIFc+J26RoqZrJXIYDlZkdZ6qGoEMe4/9WWfFvfeJ6cc4ETxbvY5oiVoJ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: fc311cdb-b277-4a6d-b2e9-08d5ab614ec4 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc311cdb-b277-4a6d-b2e9-08d5ab614ec4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 10:34:36.3234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1838 Archived-At: Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Apr 2018 10:34:43 -0000 Great to hear that I managed to clarify the issue. Note that I am arguing for having the endpoint name in the RD become option= al since I notice the third party registration scenario (even though I cons= ider it somewhat half-baked). Ciao Hannes -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: 26 April 2018 16:34 To: Hannes Tschofenig Cc: Kovatsch, Matthias; Jim Schaad; 'Christian Ams=FCss'; consultancy@vande= rstok.org; 'Carsten Bormann'; core@ietf.org Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft Hi Hannes, This e-mail of you to Matthias answers my questions I had before. thanks. I was under the impression that you wanted to cater for malicious nodes tha= t forged the authorization token. > > The requirement for applications using Endpoint Client Names that are > different from the names in the device certificates/authentication > credentials for registration appears fuzzy and not well justified. > What identifier do you believe you can put in an endpoint client name > but not in a security protocol or what are the needs of an application > that cannot be met? > For example, the d=3Dvalue is typically installation dependent. To my knowledge, using d=3D is envisaged in building installations. at the same time, the ep=3Dvalue does not need a value with a semantic mean= ing, so any identifier will do in my opinion. I could imagine that a claim with "d"=3D is added to the token when require= d. Same approach for installations which can afford the overhead and want huma= n readable ep names. Peter 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. From nobody Sat Apr 28 10:35:09 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 661751242F7 for ; Sat, 28 Apr 2018 10:35:07 -0700 (PDT) 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, 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 soiJ_2yKNwM4 for ; Sat, 28 Apr 2018 10:35:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856DB1200B9 for ; Sat, 28 Apr 2018 10:35:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F5E120090 for ; Sat, 28 Apr 2018 13:46:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 84BA62645; Sat, 28 Apr 2018 13:34:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 82A8D2644 for ; Sat, 28 Apr 2018 13:34:55 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [core] OSCORE Inner/Outer duplication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 28 Apr 2018 17:35:07 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable section 4.0 of draft-ietf-core-object-security ends with: An OSCORE message may contain both an Inner and an Outer instance of a certain CoAP message field. Inner message fields are intended for the receiving endpoint, whereas Outer message fields are used to enable proxy operations. Inner and Outer message fields are processed independently. In Outer instance of a CoAP message field will be integrity protected if it= 's in the class I message area. Changes to it would cause the integrity check to fail and the entire message to be rejected. Such a message field is effectively read-only to proxies. If the message field instance is in the class U bucket, then it could be modified by proxies. If an instance also exists in the E or I buckets, then a receiver could determine if the copy in U bucket had been modified, assuming it is reasonable for the message fields to be the same! I think that the above text in section 4.0 should indicate that the two occurances of the fields (Inner and Outer) are semantically different, and receivers SHOULD NOT attempt to make sure they are identical. OSCORE uses this in 4.1.3.5. No-Response in different ways, for instance. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWuSwvICLcPvd0N1lAQJWwwgApP6qvKiqGKZ81vkx10m/HfJebASK3qqk vcalkwpoKUn/fDWH3U25d4Ac8iViYbyfPgU9EPXxBfs30sxlNtOAihKQCprHblo0 lMOlZHwH+dkTl4PGCT/WfWLqsyTaRTIHTYF3jGkPU13Bs6na1TgSaFCPoiorun2K E3811k825elArw8cXgYUZKPQQFOALe/QkXQVEX6OeOWH9NyliAaUDAsSUCTKz3MM UEjNhMVhUXd8GNQ5D/egonB+Pm+b4DyWTcaK4f+prhUtbUJLJQtGJd1zdBzgguX4 6HThWzl/Vj6WTx6ZWHUwAOIcHG1qvjt6WLhVTRFlXu5x/ELMyeUnmA== =J63b -----END PGP SIGNATURE----- --=-=-=--