From nobody Fri Jul 2 15:07:05 2021 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 637F33A0B3F; Fri, 2 Jul 2021 15:03:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526338139.26814.15620679827958666704@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:03:01 -0700 Archived-At: Subject: [core] core - Requested session has been scheduled for IETF 111 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:13 -0000 Dear Marco Tiloca, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (2:00 requested) Wednesday, 28 July 2021, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: People who must be present: Carsten Bormann Francesca Palombini Jaime Jimenez Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Fri Jul 2 15:26:14 2021 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 455A03A138E; Fri, 2 Jul 2021 15:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 B4xo88RMeY0o; Fri, 2 Jul 2021 15:26:03 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD3E3A1440; Fri, 2 Jul 2021 15:25:03 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GGqQM41Z3z2xGy; Sat, 3 Jul 2021 00:24:59 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 646957499.775813-aba90bbe3983f26778f7e4bc3ffe026f Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 3 Jul 2021 00:24:59 +0200 Message-Id: To: ace@ietf.org, core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF111: "FINAL" AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:26:13 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF111. Remember that further agenda changes can still happen. A number of changes have been made with respect to the draft agenda. Most notably, IOTOPS has moved on top of SECDISPATCH (was on top of RATS), but LAKE stays on RATS. All times *on my agenda* are in UTC (the default page is UTC-0700). Please forgive the 2430 and 2500, I'm way too lazy to write code to turn this into 0030 and 0100. (And it is advisable to ignore the fictional end time of the Wednesday plenary anyway.) https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 19, 2021 1900-2100 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, July 23, 2021 1900-2100 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, July 26, 2021 1900-2100 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - New Internet Protocols & Practical Congestion Control Rm 3 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 2130-2230 Session II Rm 1 ART wpack Web Packaging WG Rm 2 IRTF irtfopen IRTF Open Meeting Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG babel Babel routing protocol WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvwg Transport Area Working Group WG 2300-2500 Session III Rm 2 ART jsonpath JSON Path WG Rm 3 IRTF coinrg Computing in the Network Research Group Rm 5 OPS *** iotops IOT Operations WG Rm 8 SEC secdispatch Security Dispatch WG Rm 9 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, July 27, 2021 1900-2100 Session I Rm 1 ART sedate Serialising Extended Data About Times = and Events WG Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Interconnection and Routing & Monitoring Internet Traffic Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 6 RTG raw Reliable and Available Wireless WG Rm 7 SEC *** danish DANE AutheNtication for Iot Service = Hardening BOF Rm 8 TSV quic QUIC WG 2130-2230 Session II Rm 3 ART httpapi Building Blocks for HTTP APIs WG Rm 4 INT dnssd Extensions for Scalable DNS Service = Discovery WG Rm 7 SEC saag Security Area Open Meeting Rm 8 TSV taps Transport Services WG 2300-2500 Session III Rm 7 SEC ohttp Oblivious HTTP BOF WEDNESDAY, July 28, 2021 1900-2100 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services BOF Rm 4 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Privacy & Applications Rm 7 SEC tls Transport Layer Security WG 2130-2230 Session II Rm 2 ART uta Using TLS in Applications WG Rm 4 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 5 INT *** drip Drone Remote ID Protocol WG Rm 8 RTG rift Routing In Fat Trees WG Rm 9 SEC *** cose CBOR Object Signing and Encryption WG 2300-2440 IETF Plenary - Plenary THURSDAY, July 29, 2021 1900-2000 Session I Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 OPS v6ops IPv6 Operations WG Rm 7 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvwg Transport Area Working Group WG 2030-2130 Session II Rm 5 IRTF qirg Quantum Internet Research Group Rm 6 RTG rtgarea Routing Area Open Meeting Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 2200-2300 Session III Rm 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 2330-2430 Session IV Rm 4 IRTF panrg Path Aware Networking RG Rm 8 SEC emu EAP Method Update WG Rm 9 SEC *** teep Trusted Execution Environment = Provisioning WG FRIDAY, July 30, 2021 1900-2100 Session I Rm 1 ART webtrans WebTransport WG Rm 2 INT add Adaptive DNS Discovery WG Rm 5 RTG apn Application-aware Networking BOF Rm 6 SEC *** suit Software Updates for Internet of Things = WG 2130-2230 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 IRTF maprg Measurement and Analysis for Protocols Rm 5 RTG detnet Deterministic Networking WG Rm 6 SEC acme Automated Certificate Management = Environment WG Rm 7 SEC privacypass Privacy Pass WG 2300-2500 Session III Rm 1 INT intarea Internet Area Working Group WG Rm 2 IRTF cfrg Crypto Forum Rm 3 IRTF*** dinrg Decentralized Internet Infrastructure Rm 7 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 8 TSV (!) tsvarea Transport Area Open Meeting From nobody Sat Jul 3 09:25:42 2021 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 B8CFB3A1B26 for ; Sat, 3 Jul 2021 09:25:40 -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_HELO_NONE=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 Npft6wBsZ0Op for ; Sat, 3 Jul 2021 09:25:37 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B687E3A1B1E for ; Sat, 3 Jul 2021 09:25:37 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GHHPB469Zz2xGs; Sat, 3 Jul 2021 18:25:34 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 647022334.186482-e4640efcda183c644bd1da480c53d6bc Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 3 Jul 2021 18:25:34 +0200 Message-Id: To: core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Stand-alone version of SenML Data CT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2021 16:25:41 -0000 In previous meetings, we agreed to rid the SenML Data-CT document of = normative references that might slow it down, by incorporating the = required material in the document. I have prepared a pull request for that: https://github.com/core-wg/senml-data-ct/pull/3 I have asked for reviews via github. Independent of whether this can = really be done in the current summer time, I do plan to submit a -04 of = data-ct on Tuesday, so we have it ready for the interim on July 7. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 4 03:08:41 2021 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 0507E3A44EC for ; Sun, 4 Jul 2021 03:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 tz2JFifjTU2X for ; Sun, 4 Jul 2021 03:08:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8986B3A44E7 for ; Sun, 4 Jul 2021 03:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625393312; bh=6zue/rtvPi4sHbIcWDYuMxJUYwDh54CrNFC/CIFYZ+E=; h=X-UI-Sender-Class:To:From:Subject:Date; b=iHNzbfi7irkejx6xs6p1ohH8GIeaGGmP6ZSntcGIxG1k4ol1ZDmAivicbQEMYLS37 0peF/GEi8Abpkqvqlm3AyuO4zpqUXpMytFAg7a3pRQSrVm/nxpmQiWE8OJmBNB9F8M uFN2+9aDYrMqGT9Ms1MPv3GUrZtm8AcblAs3OL8o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([88.152.185.165]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MWRVh-1lgZim43y7-00XryK for ; Sun, 04 Jul 2021 12:08:32 +0200 To: "core@ietf.org" From: Achim Kraus Message-ID: <6e7a8ec1-121c-03ae-8e4a-f615e5b4d83a@gmx.net> Date: Sun, 4 Jul 2021 12:08:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:YpJiQ7Q+BxNXP4WU0xqwir9ndQzm2vbVMITzXYAJHHdpX01TFta 6NFCxQFDaaxYbV/G52l+1URZ/Rf3ODuu0IXB+LO7tgcvBybHdH8FCq+hgGcCGJASAKvKspF Z9y/3RtUgv7ToAH1ntrSzR2nblMqrexykElmhQKrsAAJzsJQR2S8Y5/Kjpp6O37l0cSryMQ PLRSE7aEbUczBwTe2I4Fg== X-UI-Out-Filterresults: notjunk:1;V03:K0:D0zCHdNlPVE=:1MdT4B3TTs+D1RuQdQqR4R 3euhO26h0wvHwT99slldQV1X8pww+CfjNvmrBjhfV1DOXqy0txadTH0vQelwF23f3BeOFvbQn eyWG826u9Ism5v24mAjVbenP2z9slJZceI9DqWxI0mO6X1O3Kxz2KVn3kBT0K4m6uCniawWXO S6Jd3rRfYm0jeyiQWodIdRV9bg+vRRjc/BJoeZMIYqtkTt6jOseg3g9qNhGLjMvH6XSj/1tPR mD/WNl69RiBEEFYv8pVVqadSJGQSPliPeCUCt3Aa7DQhUocZWowL0gIC7vZ33OD20LMJXMm7P Z1sgttvZ2dhmSjt3lkbdvy1JtSUnzGGcnmcgkNSezyWiRxqf0Y2s2UyiAO7GaLJl+JAmwviio 5zTkhPEDdT4yum1wzkTRErbUWnbAKKntEmAumw5gXCg6yMcv7i7P6vY/51XbrOyrTYHkyx76Z /iMs3uUI4ff2kCcw/L+E6XX3WxmsjwbKy17FQwcT17WSIM1E7j9fX9B9WvR+Xw0vTGrJFOaT9 JY+b00NLnvMBRALuCO+/+uTQ55dC/KXkSAt5mB9aKyuFWozMrnqhLxTngvHa/Te8U8dqx/SLd 9msiFCgiHEpsL/KYceqF1cIlb74Gmai6wHvmLmG1e9RYhMkN/N0IjpyLk6J27oHOTznPjpjJ7 O2SVxvy/Z2nmQcIM9c8z5eKg8b8XKL75vYHH+5UaOTfSYo9obrI9VwxkaAmiLJsv7Rax38F9U X5v55TzwlyfoL0hYw6HtqHOtlaC5g4qHGI3gYttkeFkDVxlPImvZ2W3U35OuQWilVV7KYN/Mm jEJFb0nR5x5STE0PvhEpa5dEUbhqhdpchW9d3yhs1l28xXKBfmuerG+gC+lNt/exNlYkb4Xj7 Oor5qOW5z390Y5eJJz6oDirwWnub8aLADjMf7zKsTTUC2q2AmTS9xqFbOYxt/l9Csz33/UW4g Of2wiZQj668akro27dnkP0eAup9ATXmsqwFiX00+p0KI83f9mLMlGObu6VQy26U+srNryZAjo qwoVovlvScTDfNawrTJYzSPUX42ebPbVKPvop32++EKvQzDyvEQCIhHzbBQhbQd4fKym6EUoe 8YtNf7rGNbGDvpyE2IadAXtynUGhKf3Hugs Archived-At: Subject: [core] RFC7252 - PROBING_RATE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 10:08:39 -0000 Hi list, I spent some time on redesign and cleanup the configuration in Eclipse/Californium. Doing so I currently struggling at the PROBING_RATE: 4.7. Congestion Control (https://datatracker.ietf.org/doc/html/rfc7252#section-4.7) > Unless this is modified by > additional congestion control optimizations, it MUST be chosen in > such a way that an endpoint does not exceed an average data rate of > PROBING_RATE in sending to another endpoint that does not respond. 4.8. Transmission Parameters (https://datatracker.ietf.org/doc/html/rfc7252#section-4.8) > ACK_TIMEOUT | 2 seconds > MAX_RETRANSMIT | 4 > PROBING_RATE | 1 byte/second With both, sending a CON request, e.g. about 20 bytes, and receiving no message back for the ACK_TIMEOUT, sending again 20 byte short after these 2s seems to violate the PROBING_RATE. Or may consider, a special definition of "average data rate". Assuming, that a "normal CON transfer" will then take 62 and sends the 20 bytes 5 times results in 1,6 bytes/second. So: Is there a intention to limit the bytes, which may be used for such a first request (e.g. 12 bytes will comply to the limit)? Or should a quiet phase be considered based on that calculation after that (e.g. 38s with the 20 bytes)? best regards Achim Kraus From nobody Sun Jul 4 04:31:29 2021 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 AC5E43A0C47 for ; Sun, 4 Jul 2021 04:31:27 -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_HELO_NONE=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 W9Y8maJd4GLc for ; Sun, 4 Jul 2021 04:31:24 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A61A3A0C44 for ; Sun, 4 Jul 2021 04:31:24 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GHmqF1MMRz2xGt; Sun, 4 Jul 2021 13:31:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Carsten Bormann In-Reply-To: <6e7a8ec1-121c-03ae-8e4a-f615e5b4d83a@gmx.net> Date: Sun, 4 Jul 2021 13:31:20 +0200 Cc: "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6e7a8ec1-121c-03ae-8e4a-f615e5b4d83a@gmx.net> To: Achim Kraus X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [core] RFC7252 - PROBING_RATE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 11:31:28 -0000 On 4. Jul 2021, at 12:08, Achim Kraus wrote: >=20 > With both, sending a CON request, e.g. about 20 bytes, and receiving = no > message back for the ACK_TIMEOUT, sending again 20 byte short after > these 2s seems to violate the PROBING_RATE. Outside millibit networks, any packet instantaneously exceeds the = default value of PROBING_RATE. So this is indeed meant as an average value over time =E2=80=94 an = application should not send a sustained rate of more than about 1 B/s to = a peer endpoint that might not be reachable (=E2=80=9Cinto thin air=E2=80=9D= ). > Or may consider, a special > definition of "average data rate". Assuming, that a "normal CON > transfer" will then take 62 and sends the 20 bytes 5 times results in > 1,6 bytes/second. Indeed, the value chosen for the default PROBING_RATE was oriented after = the average rate in which CON retries are sent. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 5 00:46:34 2021 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 779593A1E6B for ; Mon, 5 Jul 2021 00:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.338, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=gmx.net 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 WZTNcexcUWUu for ; Mon, 5 Jul 2021 00:46:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 799613A1E69 for ; Mon, 5 Jul 2021 00:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625471180; bh=6EB3C8kjK+77s+/NO9DdtNTdDzI6qQKVK2Adljd9Xpg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Lm/UQuloe/by0UOPcyKL5JckVKNJeFgCggt24UP8de1uUPiGqiUJCRcJ73QjGUMzc q46s+mW/TrOrw4vuAyPXbti82R4acIJzXKd/lJAn1CGoj+5YQlKSyWKqU2LjuP1cR0 G+xEYotZqze0uvmT+xLQF3zUWkyZh4aGnmldtjdE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([88.152.185.165]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MdvmY-1lRWzF3inG-00b6Pi; Mon, 05 Jul 2021 09:46:19 +0200 To: Carsten Bormann Cc: "core@ietf.org" References: <6e7a8ec1-121c-03ae-8e4a-f615e5b4d83a@gmx.net> From: Achim Kraus Message-ID: Date: Mon, 5 Jul 2021 09:46:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:KSsTDzJiqRv6DISn2CAYaNxlhq0G4aiISohb72j9iYkjTBshHeo LQLfMy5ZDS/sBRYi26lHjKXtfwEhkhJwdPuQByQhaAvje1bOIGf/CowFxZmxqr+FDjab8Wm f+Pn9f8nlNoRVgqV0JKV+t5kLBJsHQdEWBPvgdmQa3WvsvFiVQtvWNkf1sBdybreKt5g9BH Lg9GlIwaSDgrQLK14zJdw== X-UI-Out-Filterresults: notjunk:1;V03:K0:zSfJzP13Rdc=:4f7gZOYbTh7b62GSuH0jaP GIFH6zLlY42am+NOfH4WRywILd07uNdhGpc39vXZKiAyar2biMbGMXPC3Fmk2g7UpJjjXXu/L JFfFVrNZuHOJ2UylzutcuxCAZvC74hl9fOw8sqs039IaVAqtki6CCKFCTPauruLBGIEIEWrnN a+97QkDsQIJKPJ0pl0kMs7csES5RMRYQqJQkFqL94DUeCsjYcNIE8HhrPaXsLJbZQMenD+QoU akh+WCEXR/2Ktd8W6KN0NtUrZuj6EeyEbwvGaYELaYw6yVCzSYP4fUAPUDK7+4W9GrsmTimS1 VUptucrbwX2b5MHn4PnhEzxARRsfottqqD0S2iAtDsNPhDNMY+SsXzOJ0ggNHtsmff6cNciQ/ V3Z/noJP5nCxttNf6NKx55lqzV+sq89Yaaoq1iignudaAn2foYWMv+ET4REG5ZbnWn7QDbF0I DcBv2TT/DTjjjz77s7ATm5+6LDix4VFEXyOT5r2GO/s+5wfeMCdK3ucN5G/AqB8Tn9JFlC1K0 ucR+8KpiKE8zTSDQaRRAINhK16TVz2RBWakgJR3hYDGY9JH0x/iKa/jBuqf6BuVOIOFns8tJp DJqc2aGcs3oyt/FXsUdnjZjm3YtHadjC4s72Orrd0NZOFGgyJ9ehMBW/QHU4F6H/oHjIm6oT1 CeXyj0TBLx2FEifMdaPuZlICCQ9L07MqPZk+q9JW6n0aTDu8yQjICuub4rkFI9HCQY6C+ttUn c/Oalxz5ZkU4AeK+LQ7sM/YC4GGkGU/tusRvwZwpzommbxuHvXdACg+vTpCcEuDl7LFA9G/eU M3+kR8bYqjx4Zp/AdFaIS5R5B/pDJghPhnyN4HmiBBXKLRFt8oYlWHrysF6u725upFw0IxXUr h3Oo4O9lfrzmHfXYu/9Fsm3N1QnwwjqrZtn5yQZGBHiSROovvxtj2lQ29baQjGn4FgUEXJHeS q6daopICuy8P90XTowr0CcesSSIiRGLuszsa5JSK2HbJrIadSnzxhYWzGvurNSCOUOGcVljHN Tj8l9f5TENju49gWloYvyFxB796P3XZdGPO9nGrvat4mYZFQIV+rYbsMN0rG17YBQtHFVSCHc eY/ijnAZJ0Ht+b4YXprn3tzj0iexHYU80eD Archived-At: Subject: Re: [core] RFC7252 - PROBING_RATE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 07:46:33 -0000 Hi Carsten, Thanks for your answer! best regards Achim Am 04.07.21 um 13:31 schrieb Carsten Bormann: > On 4. Jul 2021, at 12:08, Achim Kraus wrote: >> >> With both, sending a CON request, e.g. about 20 bytes, and receiving no >> message back for the ACK_TIMEOUT, sending again 20 byte short after >> these 2s seems to violate the PROBING_RATE. > > Outside millibit networks, any packet instantaneously exceeds the defaul= t value of PROBING_RATE. > So this is indeed meant as an average value over time =E2=80=94 an appli= cation should not send a sustained rate of more than about 1 B/s to a peer= endpoint that might not be reachable (=E2=80=9Cinto thin air=E2=80=9D). > >> Or may consider, a special >> definition of "average data rate". Assuming, that a "normal CON >> transfer" will then take 62 and sends the 20 bytes 5 times results in >> 1,6 bytes/second. > > Indeed, the value chosen for the default PROBING_RATE was oriented after= the average rate in which CON retries are sent. > > Gr=C3=BC=C3=9Fe, Carsten > From nobody Mon Jul 5 08:27:27 2021 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 6EA863A1B89 for ; Mon, 5 Jul 2021 08:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 riPp8IFkVFBo for ; Mon, 5 Jul 2021 08:27:20 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2066.outbound.protection.outlook.com [40.107.21.66]) (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 A36BF3A1B8E for ; Mon, 5 Jul 2021 08:27:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CPue9Pu+BdHWgcDN5o+mL1rKfVDQ2E59zMYodWaOyFRHBQWrpK2vZ4BYeUXUULhzSJxJ2t/B9EHqVGAsml7BYDguma4LMDvjyi7KuD7Kh+59zq1smLosxxoghYbo+miwPB2U7DQgMfvsXlx9M7tQGFb1+IhlwxvpLc30q/X7ed4GK3P9fehkqj/fGO+vlVtVii+F/ba85spcIxZWMkw65OIHg9CajOCNFOie34D5zWpXM3oXV8bqIV6+C82WAyTG914NnSaT60wXYupicXi0ABE7rT0ImUOq506vcwMFXn5+hB+WPAVIEeKOswHwh/KhDoainYmmG/IQRE621AqUdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ffiLVUYvuQILhmTHTlMS+Az+b2oSCTHo7fRlE258fgg=; b=C80Ge9dRNm9j3aYnPq7ln2yQOi1yHL5IA4Uv8hPidgccfvm2txqx0b6At/GfZ0OIvIdYWwWUP892dEOw10Mm1egTBTej29vN2/BoCRK/P31le6shZyNbd5xTkiAp2bvqZP7xe2YvgExj+feCWq/FV2KM3MNJx28hvrtnRzHa5xk6B0+RbOa552LpttON1EN1OQjtJYOUo843jikjErgcwQfzrRFfWN/XVk7IX3TcYqlbhUEh+zDKczQEPjzLzqzx2ldqc7vcn81YncMchd8xDMPa5UMiKeJTsWR0M31fZR6cgxrlmdlb3XOBlb0qj/ykCgKkb4uua3jbb0DnOE5qHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ffiLVUYvuQILhmTHTlMS+Az+b2oSCTHo7fRlE258fgg=; b=HD14yDu4/xQxTul3BMVkCBDIXyONCvv8DwgC0dWr8jy1U0fmh8YmAEXjnoRx4fNtSPPoS6ZURS/PxIvOqoBXbqyVa+gvdQAhv5HksHEXy1PNm5zUpVxPi5le7Qr+g7UHIZnBQu2nOr3geRm5OlY3U4zIHNVypL3xlaM+RIujf80= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0408.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.23; Mon, 5 Jul 2021 15:27:16 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4287.033; Mon, 5 Jul 2021 15:27:16 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <7784c232-588d-d66d-67a8-2815ef7bd62e@ri.se> Date: Mon, 5 Jul 2021 17:27:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RKGbqnSpkjqbmVUY4J0LWRAPUgpbjFjIc" X-Originating-IP: [185.219.140.196] X-ClientProxiedBy: HE1PR0401CA0073.eurprd04.prod.outlook.com (2603:10a6:3:19::41) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.2] (185.219.140.196) by HE1PR0401CA0073.eurprd04.prod.outlook.com (2603:10a6:3:19::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22 via Frontend Transport; Mon, 5 Jul 2021 15:27:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1304e6fc-91cd-4b5b-2047-08d93fc95ece X-MS-TrafficTypeDiagnostic: DB6P189MB0408: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1360; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: H4rA14S+F0k2jP7o5a6sIMFiYjxqBDrf3b3weHuHB/tsOtcAAgVIXlf4diS9QcH0mS7zUB5HHfEDG9pAzq1U7UHIH5QMHJ03wp8QNMXLauqOsNukFvq/Y1ROBmWy8brMdb+lj82NaNwX+j/71VUBnkPRgQRFJxOKJkYuz7+amJ7JwVvFiAJ1v4a75vKjMEV1kGvnb/zu4pXExgjQT0hBNI4vKvxQyM9B0Q8lyBFYeCe4NOqVQ29307P/InSxFFRkDeaSEaDIiqRdz6zE9r5ZMLLzWX3qO1PLeQg3l61wGPLMTp1GzWCuDSsk4gskz0SHFL6KYB8ZZdWU5brXfWaGMCqIyFIL2ipPvTOJBxeKMzpKu6Yw9iCkbgek5FaeFxll0Y02VJ7x6fjHH1rrPmBoJn7rsKmS7xAtMyF7Qb4seJw+8Cr2bW2RUb7BhGrfoL5ldrxXLRQuXcbypmPp2cmmoF/bkLhJyh/ghM0Yf53F4CQwb9sosk1UnGrdJVjlAu0oLr1TUnj4JJ4fPs78Ua4uSqDvjcgEcdNC2wqQ01f8dVGIPWK0j9uCInxo/8U4btP4e1TTgR5G1aKN53koKsStGv1H4ysbrANyLp8LiFuQUZ9PflteRWl6WsvIuaDahtvYwm8RPPVOoPEdgp8m7ttq1WpPBUqHOxnhajLTcBCeDKISo3Q3dT/x2tCp5luT3IPhkC9o9aDpW/wmeKn1AhifkX/BzS5uG7qVdv2R/L1ZRplFIl1FQvogMOZT2JBYtoSUnagYvswWAoKQ8AOLyH72NpkbSeLXoXosLZP/XGdPYBd+/pHvwa2NBBvkuET+1v5F X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39850400004)(396003)(376002)(366004)(86362001)(2616005)(956004)(6486002)(31696002)(31686004)(66476007)(966005)(33964004)(478600001)(66556008)(36756003)(66946007)(66574015)(235185007)(186003)(44832011)(26005)(5660300002)(2906002)(21480400003)(16526019)(8936002)(38100700002)(8676002)(316002)(16576012)(6916009)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Skp1eWtWNzdlcUtIZU5hTFBUSkd1cXEwdDl5MmhsRENQY05kSzN6ODRHZHQ2?= =?utf-8?B?c2dmdktIOE16b0wrSWhDTWlLMGdYTTlMN3NUazlzcjBNaU8yYzcyazg2SE05?= =?utf-8?B?bkNpTVlmQ0liL3V1V3F1eXpva1o1OHZYcTFJazB3d0cySmtxc2RsRWNRZ1dI?= =?utf-8?B?THZKVi8wQ2k2NUpjUHM3U3kzS1pvN293RXIyVWVmTVBablQ5cXJrNGdpR1FK?= =?utf-8?B?K3VOT0pzRXBUaENpS096Ui9xYjVYOUVtTHVLR2dXd1hHeFVuVDd3RmtiQXVx?= =?utf-8?B?cHNLMjRDQ2M4YVdKRk8rRkRwVEFrSWdvc1ArUGFqNWZjWmF4enloMUsrcUYz?= =?utf-8?B?bWo5NExMRVFpdU9VZCt2dG1aeHVjcmErWFkrelMyckRTc3NXcVYvdmNmMkFJ?= =?utf-8?B?eG5Nbk5MRjVuTWVzaE9tSTRTRDNtY3RWV3BTZXdFUGIrSUNQckZ2TDF2VzB4?= =?utf-8?B?amo3ckZ6ZXduczBjRFJqZjk4QVZ2TzFVZXNTT09kRGpsQzlQRkJYeVd5VUZo?= =?utf-8?B?VWZMWUhQcGU1SS9WT3ZZcTlPbTY1czJlREZEUEhRRGw5VnVBZFFOSitURzZn?= =?utf-8?B?RDRzbG9vSktpZDIreXBtS01rR1FWU05MMnZFaXkzQlVnc29acmk5d3pjQ08z?= =?utf-8?B?N25VODVIQ3d0b1JBOVo4cGp0Y3ZQaFpZSHZaOXRrVEM4VWdWMUFpSklZc3Fq?= =?utf-8?B?T1FwNWFTSUx4MzhHWUlVZjJ4eU4wb3ZOcG9CbDhGazR6MEhWdCs0MVJyMktp?= =?utf-8?B?QmRnOUxwZFVHNkJZRVRjVTZUVkdXY3J2YlB5ckgvQkdycC9UaU1uamhXQ2lS?= =?utf-8?B?U0pPaEZkMGVoL2hFWHlOaC8xRWppbmJpUVZSSHhaU2JDS21HckJHVDZ5bGda?= =?utf-8?B?TE1rajVvK3l4R3FWWjh2NEtVU0ViZzJyaERVaWlaQ3c0cUc4dG5uOFZVOS9P?= =?utf-8?B?c3ZxMzJoenBETURSRnRyRFg1VmtLbXJPay9ITUdZUUFiYWtDUmVMaFJTV3Iz?= =?utf-8?B?NFViMEpDSzQ3SWVVNVRTNGo2emVnMmdKdWJlMXpWYU5sbmx1Vk0rTldIakVV?= =?utf-8?B?ZCszL1pWRUUvczd2TGJCeE5KdTB0Ylc2NkhQL0tYOFdPZUFYWjN1eUtqV0k2?= =?utf-8?B?WHVUMWlzMlR6ODQ1WFpnMGlXK2NYMFRQQ2VkRGpCZmJtQ0w1Q21xVmxEL2xi?= =?utf-8?B?YkMvMUZGTHcwMXB3d2FYK21BMFdpZGF2WXhRQ202bmgxak40Wm8zTlc1dDMw?= =?utf-8?B?NWpZSWNLcU0zZ0U3WEh4Nnk4K3ZBU2pWdGdHRkYzSWM2WEFGK3JUMWZ3Qms3?= =?utf-8?B?QkJoNTI3MjNSN3o2RzExOUdXOXp3WnhCM1VjZ1RxTDd2OTdSdEN1eS94aGNo?= =?utf-8?B?Yzc1OFUxY25pdi9aYzE4a3ZBRnlyUTRtbU0zMmQwc1FDNm0wRHNwbC9vWnVm?= =?utf-8?B?T29VY293N25sQnVTVmFiWEFISjE3K0R2KzZBNmtpc2RZRDdHSU1PT2dkYXQy?= =?utf-8?B?V01PNG5rbDl5MWNkYlFuMnJuU1dHY2FLbld3SWxZY3pBV1BONmpXMjQ4RWV4?= =?utf-8?B?VEptWWxLOUxrV2Urb2VlaVd4bXFrNGVxUEFLL3FDMGNvR2hJT3BkMEgvUGwv?= =?utf-8?B?VTlYSjcybWZTR1Z6ZlFGTG84V2F3ekZhaG1Dd1Y0NGhvVWdFckdhckpaZkg4?= =?utf-8?B?aU1sZjFYaHFJVGpMY3JIYUpIeWRaS1NPUTNnNVVERTFxNCtsUHozTnB1Q2RY?= =?utf-8?Q?iYNauZVdP+B3DZzONdfi9MHz0q74v3tALB/g4EE?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 1304e6fc-91cd-4b5b-2047-08d93fc95ece X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2021 15:27:16.3578 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QvAvYvZ4tM6sMyY63+Ae7V5m/vL7jY2u+ynq1iwWI9BJSxXfB8tGJl+d9+NwlmXnfCrNLIOjElpHOHMobdAAIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0408 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-07-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 15:27:26 -0000 --RKGbqnSpkjqbmVUY4J0LWRAPUgpbjFjIc Content-Type: multipart/mixed; boundary="QMVsqMNbeeYX2YjKahtw3BaVRjWeqWO3c"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <7784c232-588d-d66d-67a8-2815ef7bd62e@ri.se> Subject: [core] CoRE WG Virtual Interim 2021-07-07 --QMVsqMNbeeYX2YjKahtw3BaVRjWeqWO3c Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 July 7th at 14:00 UTC. The agenda and other pointers are available at [1]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-09/session/cor= e --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --QMVsqMNbeeYX2YjKahtw3BaVRjWeqWO3c-- --RKGbqnSpkjqbmVUY4J0LWRAPUgpbjFjIc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDjJNEFAwAAAAAACgkQ7iZktA5Y2kPz qQgApY9KPPx8X4G2e/0CO+Ohuq4eRG3v3ZWjxiZ75KkBOfb+sVd9qhHxqLITqrTct0S1Db4/AHNS C9Vct+ZKd6IwfGDv7j3scyCuUwjW1GBAyQN/qjXrb9OBZ9XkJD/GerlzQiFRLZIbd+Fi6SkH22Kl aZMqf0JaXql8Fpq/Ft3OQRjOU45fAOEiKp01JK6b2AoALhQe6IJ2F94mH+tFiAg+73rYVSXxqAqC ARGGgi1LSMA31darit5YSkIuyqmBGzAg2rOiT7Lul6uWeic6EUngoyEm/DHhq7OgVT4FQLTWjuDl LRqNUR9k+GjHhqh/i3/PjQf9O5jZH8KRSTBFxRZYkg== =o/Tx -----END PGP SIGNATURE----- --RKGbqnSpkjqbmVUY4J0LWRAPUgpbjFjIc-- From nobody Wed Jul 7 04:59:33 2021 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 5D3CF3A09BB for ; Wed, 7 Jul 2021 04:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 AfJXg-ryyR3R for ; Wed, 7 Jul 2021 04:59:27 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50066.outbound.protection.outlook.com [40.107.5.66]) (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 CF93F3A09C0 for ; Wed, 7 Jul 2021 04:59:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NzTYRwtPNXDFBHVvvxzv6wkkdw4W/MdRIPLz3X3/CD2eIZKDn6Q7AUfiMRKPAprrIkitfUlBwcZ1NfrtlZG41gUOBWG/VOroIbzmqlBPoYDwoQiOYU/WeFtSxtCj35tXfvxrjEPZ/oYb52pAS07oW9VADCP6rWbkRBla943xjSBexHBYlFefc9/ShGbSrwu+UNGmDJn9f19bdgoibqcEWvkEzuuhrSTOP+hxWoGBUU4/jyNDAePxgRRgCAvk0ih1YptsVVYewFQRZ/1bjfv9ogDyBHTejyECzFtu6yfEUKCEUiZETFCXD7thvjWJx67pzaBqbp95yiFVEp5IfmAIGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zC48Ye0pEWULB3Nh2eQocRk254vvDxWZYF8/am/oUgo=; b=Ngv7sVib9AeYKbk/u9Pp45B24qynkz2t4TDDoqT5vfF4fGLwyx9JDfxaL069zQNN6iO7GyrVA6yWRN2c5acH1XLFy9cRGHmUGRpb31YIh8m/9046RbKBDrNQSAetuldIl8JxqzgNLuf70FHhafKYYD+98MYBvpmySvMspXscBREc0CUv6T3ES87l0cE17lqfgWc79JvxaQTg18ksjwoNTFfAFfr/nV+MtNwjfhT78rOMNwEwIiQxOrthlSeFzNuO1hFN2X/gR7JJfUkePhmvusiJAAL9p9stjxIp/l3KnVwtblmqDLO/bsYj4ckGitgUIy8HEbtBMYpoQpO/6KsfGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zC48Ye0pEWULB3Nh2eQocRk254vvDxWZYF8/am/oUgo=; b=OX/OtbpWrVHP99CxHVllcBxhwVb2kceqeJBM+7XyTbQwFuCXQY06EyyhufpNdUia6FY/qZw0T6JJ/BCwU99+bob9TsHkrCymyKbrNdEz2OmMB832GaPc6GXSmiUqhBnPhJK+mQxhthjRkkqNdrFZxLPk9P5Oi+FDVOgKrL+TWtM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0104.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:27::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.26; Wed, 7 Jul 2021 11:59:23 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4287.033; Wed, 7 Jul 2021 11:59:23 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <7784c232-588d-d66d-67a8-2815ef7bd62e@ri.se> Message-ID: Date: Wed, 7 Jul 2021 13:59:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <7784c232-588d-d66d-67a8-2815ef7bd62e@ri.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4sMgnp2q3wLFjW7L2Rwc3Il8yfapb1KFh" X-ClientProxiedBy: HE1PR0102CA0033.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::46) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.7] (185.219.140.72) by HE1PR0102CA0033.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22 via Frontend Transport; Wed, 7 Jul 2021 11:59:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ef3f2e75-3817-449e-8f2d-08d9413ea8e4 X-MS-TrafficTypeDiagnostic: DB6P18901MB0104: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2958; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qPJP6YwNvziGvmpev/PpHlu4dKmnz95InIhN6e73alXRZdulUu9xSjyT66URaEuInvpPS22qHHWmIRt+XFHfHPPpE6EJteiQzmSitqN+atFdh/CgZyMUjVgMkGkP1ljj54IGr53ZbO0wZx8Bfq/JnNyisdpHxXni+fPm1kTZvn21Eud0U4W4UJ6uRedaLtCJlgoHFRwm8e8f4WWZOWHkdFB3X9oyJO2PW2SemRxbdHitT3KTX1OiN8JD1mijHqp2KFkRAZS9RqoRHP2BnP6XCN+dwNHlEPP/D+xVEPiFAiwZp5LA3deMkSYlUVItcbpuhVZCmdAkHNWQNagSerlOYM+uxjGBuXQ09ze/mBwRNtfPu/oClgiurxODyP6cconRyMQUxDjn3JXXInP23Js1vdkopviD8hUslb+EsfMMVo3VhEeWZlV62QzpPcI8BwQ23lCE0XNSBXfDtd2ThSJr+9QtWSQmsjFFXuXw6XAJ84xrkbLcbQhXW7KWY4ZVav/h22sw2Hc4kuk4LLvxKhv9LdZkSKdW9p6sCujfX7sXUrlr6yBKWmaw3lLdmYEAJak06DMoCrBl7XWX3l3F4RbjO8j+T4ekgcIuKqNvSdrGnZZ0jc5TBTV2fKWRRzCZDzZPzw/ZE2N68LsOFRAI/OKAPiKNVOQ8047bUHWGNZb1qcGDEZOmygaDO+fzPfkCJ9jX2GNedwkJKwzgDgty0qUdWVXtQD2yq8a9t4/Pbt/BAC/g/xzr9yroeJ7C+NSSH0M5ryTyjYGnUHfW2MGB+s1nSg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(346002)(396003)(136003)(366004)(66476007)(53546011)(186003)(16576012)(5660300002)(83380400001)(31686004)(956004)(66946007)(66574015)(66556008)(36756003)(44832011)(6486002)(31696002)(33964004)(235185007)(26005)(316002)(6916009)(8676002)(8936002)(2906002)(16799955002)(478600001)(2616005)(86362001)(966005)(38100700002)(21480400003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aTNIK21wV3czZ0JkTm9UUTdKaHNLa1NTSWFOK0h3cForaWU5eExhbjN0MStr?= =?utf-8?B?VGVDaHFuV3lDTGw4OEp2MkF6STd0RTBtSXZ5aDgzdVZoNmdlL0lZOVo5ZVNH?= =?utf-8?B?OXQxT2VpUGhabWhOSjFuMHl4bitYZGVtOGZQcG5tclBCMzdudDZvUHExZkxa?= =?utf-8?B?VnVhbkx0M2lSQ0t6bVh1djNpWllCRzJVcUhIKzA3WWt5QjNiaVhZeDhCamEx?= =?utf-8?B?SWNYbFE2aUpMV0paSGc2MmJjakVnUmJwRFdqTnNsZW1LVVNib3Z2bHkrYm52?= =?utf-8?B?Wjc3d2x2dHJRaFdZc01wS0ovMm9EME1MeGF0eTdHOFNyOTFyOUxoQXZ4eEcy?= =?utf-8?B?dFBheVFxSXZid3RWbU5WYllJeW1GcDM1QzV4VFpnNU15cWRsTnNtL0FLTURJ?= =?utf-8?B?RWV2RXNSY3pHRndKTGlFL1B4eVRDSWlMa1RxNldVNjVVNkx0dktLL3lLblp4?= =?utf-8?B?VzhNajd2eVZTbThQdVV0RmdjWmpqZ3NiMXpGdmJLbUdPQ2xUcTVxNWgzWEV5?= =?utf-8?B?c1RzSUNYMGZVcStQa0lzRk43NEFYUFBYYVdEOVRHVmZadytBNHoxN01LQkxN?= =?utf-8?B?M0JVc1YySmszU3BuemxRTFRQd1NFYkxkZDJ3NkhYeWhHL3lrOWNleTlzL0R3?= =?utf-8?B?UTVhQWExVGpyamtFdktFYVpod3Q5Y2hFWVY4SHUzOXFjZUVrbDMyMjhjWGI4?= =?utf-8?B?dFdhTkVJVEhsNXRmVGVVL2NDQjV5OGtxWm4yeWFPUThLTWN1ZmllS0RQMlVv?= =?utf-8?B?VmVHeW5ac3kvRUJTMlp1T0w2WGRXV3BkajNVQlU4VEJMUXY4QmJsbTFNQXNo?= =?utf-8?B?cmJON2RhRkIyWEtiUy9TVDF2ejdTdjZyKzA2TDF3UStlVkRHWVNWSldMUnVX?= =?utf-8?B?a29vRnNTODZQbTdTSGw0aUJRcXdEVXA3VXA1ZWlXZmNtZStVZk95NzlXa2tD?= =?utf-8?B?NXA3SHFpeVBSZStTSnQ3QjRDQ0RXR1ZoTURSM3AyejhtaXdXWHJqalh6R3Er?= =?utf-8?B?L0NzU0lQWmhhNEJlR1B2QUxUa0NYQWlRejZTS2lGK2pxZHpMVllCeFZtMlVX?= =?utf-8?B?dWJxUVhxbjR1ZXBoYkFrUlc2T1oxdUx6T0hNNExLd211Nm1MNnRYUm0vSkZM?= =?utf-8?B?T1pMNklXN1R1c1FlN1FLV0dDNU1xeFJtclJwR1RQWmp4V25rTHBtY21Ya2JH?= =?utf-8?B?eG40UG5LSFZFZEp5RjRZQmcwdXhmVmFIMVNpeDFubjZtNXV6Q0ttdlZheUxD?= =?utf-8?B?aTB4alllcTQxV3JtTk5zZmNFbzl1Z2hVQ2FjN212WHB3dWRwZEVydk9ZYjl1?= =?utf-8?B?RzVkSUtVSGluUUpQUVBIV1E2WlMyWktaRjd1dlBua2k2Y0Zra0lMZE5HMStZ?= =?utf-8?B?OGwrdEg0TWNZZkR0QnNYWDc0ZlpjOWF1Y2w0cEU5ZHVwNjJLOGdLRHhrQVdO?= =?utf-8?B?emxNMnA1YnhmRlQ2ZXlaQ2QvQ3BlNHpoeTE0ek4xaHdCdnRLcU5UK0E1ZlBY?= =?utf-8?B?MUo1aTZkVFVuK1BEaUR1NzJjaENseFdmVjRFcXo1MmpySzh4Vm9IRStDWHl2?= =?utf-8?B?SVRQeE1hMHQ2cWFiTGt6SnNjODhPWXVoY25zRjdncHowNFNjSFRKU0crVitZ?= =?utf-8?B?RjJvSHJKalNjZ3ozSVJCOGJlUjdNL0c5eE1XNTRpSG9Cb1R5eSt0Nm5SNzV5?= =?utf-8?B?aDNtaVU5cW5LR09wM0sxN3paa1hQbm8yblA2U1hRSDNmNDdBei9MZy80aXJa?= =?utf-8?Q?kvPVxIW4Bay2Qu08Mvo+EDRPfrnbAQxdxcQWI6E?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: ef3f2e75-3817-449e-8f2d-08d9413ea8e4 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2021 11:59:22.9493 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9I7LS5+0mNwNeYWdDFRLdpeAQszcJSvqMkf5kUnON8NVByrUgd+Z4/kYVGMViFpnfe335MTlzVQUiQTeHnLNyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0104 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-07-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 11:59:33 -0000 --4sMgnp2q3wLFjW7L2Rwc3Il8yfapb1KFh Content-Type: multipart/mixed; boundary="mgT6lMcEkJJR9G7oCfUtXvUdATb2dX4E4"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] CoRE WG Virtual Interim 2021-07-07 References: <7784c232-588d-d66d-67a8-2815ef7bd62e@ri.se> In-Reply-To: <7784c232-588d-d66d-67a8-2815ef7bd62e@ri.se> --mgT6lMcEkJJR9G7oCfUtXvUdATb2dX4E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we are having our virtual interim meeting in about=20 2 hours [1]. Please find below the information to join. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-09/session/cor= e =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-09-core Meeting link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm9e7a5d60740a53d0694df4397a9cbe8= c Meeting number: 185 294 9466 Password: constrained More ways to join Join by video system Dial 1852949466@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) Access code: 185 294 9466 On 2021-07-05 17:27, Marco Tiloca wrote: > Dear all, > > Just a reminder that we'll have a virtual interim meeting on=20 > Wednesday, July 7th at 14:00 UTC. > > The agenda and other pointers are available at [1]. > > Best, > Marco and Jaime > > [1]=20 > https://datatracker.ietf.org/meeting/interim-2021-core-09/session/core > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --mgT6lMcEkJJR9G7oCfUtXvUdATb2dX4E4-- --4sMgnp2q3wLFjW7L2Rwc3Il8yfapb1KFh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDllxgFAwAAAAAACgkQ7iZktA5Y2kN3 vAgAmxBWE7qU8tL+9tBFVmexgQmIyJ8uLpulS4zIXnZ66MRxWO13hFeTGY58gZhPB3uvXrFh38SC BLNvy9juaG1E+qeMfcjQo6lfgmzJQCW0XAclTVU1qC5gOZbGPkSNUM7Q8mmx6HyqNM14EESPsNOj X/tWe+naep3TkWBr0HFGMK4oHRK1lrLB3QYD/oxm76I1cNUwIiWUtjiUBpljSrkBLn2Di5WPNN6S MUENEjkV9sTFpGVQO48TAl7cUnQ+5bRzkzD05x5TjYO9dOE3s0p/GIIYCIqzQDh2pPeBWFrobE0r +8Opt2g1x9LoaPBueBz817oEWNMvc6UOrJjbDtGt5w== =nW3I -----END PGP SIGNATURE----- --4sMgnp2q3wLFjW7L2Rwc3Il8yfapb1KFh-- From nobody Thu Jul 8 12:11:53 2021 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 302753A162E; Thu, 8 Jul 2021 12:11:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162577151111.31401.17764488584373064062@ietfa.amsl.com> Date: Thu, 08 Jul 2021 12:11:51 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-data-ct-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 19:11:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : SenML Data Value Content-Format Indication Authors : Ari Keränen Carsten Bormann Filename : draft-ietf-core-senml-data-ct-04.txt Pages : 9 Date : 2021-07-08 Abstract: The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-data-ct-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 8 12:13:55 2021 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 EE0943A1641 for ; Thu, 8 Jul 2021 12:13:53 -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, SPF_HELO_NONE=0.001, 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 hB7BphzW-Cv1 for ; Thu, 8 Jul 2021 12:13:49 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8C83A164C for ; Thu, 8 Jul 2021 12:13:49 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GLQty2Sj4z2xG2; Thu, 8 Jul 2021 21:13:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162577151111.31401.17764488584373064062@ietfa.amsl.com> Date: Thu, 8 Jul 2021 21:13:46 +0200 X-Mao-Original-Outgoing-Id: 647464425.939309-b58ab5dc47373b10914812f6f575f31d Content-Transfer-Encoding: quoted-printable Message-Id: <774510DE-D78E-4699-A645-08FD3012A512@tzi.org> References: <162577151111.31401.17764488584373064062@ietfa.amsl.com> To: core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-data-ct-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 19:13:54 -0000 I believe this now addresses all WGLC comments (and implements what we = discussed on Wednesday). This is now ready for submission to the IESG. Gr=C3=BC=C3=9Fe, Carsten > On 2021-07-08, at 21:11, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : SenML Data Value Content-Format Indication > Authors : Ari Ker=C3=A4nen > Carsten Bormann > Filename : draft-ietf-core-senml-data-ct-04.txt > Pages : 9 > Date : 2021-07-08 >=20 > Abstract: > The Sensor Measurement Lists (SenML) media type supports multiple > types of values, from numbers to text strings and arbitrary binary > data values. In order to simplify processing of the data values, > this document proposes to specify a new SenML field for indicating > the Content-Format of the data. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-04.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-data-ct-04 From nobody Sat Jul 10 12:16:34 2021 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 5FB773A19AC for ; Sat, 10 Jul 2021 12:16:32 -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, SPF_HELO_NONE=0.001, 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 M2PE9fyR1w2a for ; Sat, 10 Jul 2021 12:16: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 1EF743A196D for ; Sat, 10 Jul 2021 12:16: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 789504016F for ; Sat, 10 Jul 2021 21:16:22 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3EA28D0 for ; Sat, 10 Jul 2021 21:16:21 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c62a:3c72:f391:2b9b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F1509101 for ; Sat, 10 Jul 2021 21:16:20 +0200 (CEST) Received: (nullmailer pid 521234 invoked by uid 1000); Sat, 10 Jul 2021 19:16:20 -0000 Date: Sat, 10 Jul 2021 21:16:20 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/B0jFqr4PUQbU7c8" Content-Disposition: inline Archived-At: Subject: [core] New version of draft-amsuess-core-transport-indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 19:16:33 -0000 --/B0jFqr4PUQbU7c8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, I've submitted a new version of transport-indication, which sets out to be a solution to the different-protocols situation we're having. Please have a look at the document, which should be pretty self-explanatory by now and includes several remarks on contentiuous points. Feedback on-list before the IETF would be much appreciated; at latest, I hope to get a chance to discuss this during the session. BR Christian > Date: Sat, 10 Jul 2021 12:07:38 -0700 > Name: draft-amsuess-core-transport-indication > Revision: 01 > Title: CoAP Protocol Indication > Document date: 2021-07-10 > Group: Individual Submission > Pages: 20 > URL: https://www.ietf.org/archive/id/draft-amsuess-core-transp= ort-indication-01.txt > Status: https://datatracker.ietf.org/doc/draft-amsuess-core-trans= port-indication/ > Html: https://www.ietf.org/archive/id/draft-amsuess-core-transp= ort-indication-01.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-amsuess-core-= transport-indication > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-amsuess-core-tr= ansport-indication-01 >=20 > Abstract: > The Constrained Application Protocol (CoAP, [RFC7252]) is available > over different transports (UDP, DTLS, TCP, TLS, WebSockets), but > lacks a way to unify these addresses. This document provides > terminology based on Web Linking [RFC8288] to express alternative > transports available to a device, and to optimize exchanges using > these. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --/B0jFqr4PUQbU7c8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmDp8gQACgkQOY0REtOk veF8rQ//QrUysAl11syM0Clb25Z7vzPiXJxIIoEHhO2ICbT6d4KaCul2z+2kmoku 0Hrw6vGO8e5DSYHQZKP7NrEhU0nZDyksYy+cn27R/Xrvp5htWGZCTLZzDYysALmr I2NkByrAhcloNAcDxC2zQFig30p2oaAqRhmo6TqKfp2QAqOBTMPACwWfl96wI00g +GjjDyye+P1txaHs5WGDNBFeBeN682CktxlrhzyTsVFY0C2mfEzGEJBE3wa1i0Wy 5fOCTt+5x2QnGs0Qc2/huVo3hI3f1nYqBF8CdISq1PEWaKVJd4Y/gD7hfw2WQEz7 k+iWDbYMUQjlwZ0eC+Ay3hiY25IS0XJP39CwQuZjFA6JYKxcjGvPRiCYe1oPoFdI 2AS5SUJr91ophoRTMm9sUEcGBJPvpHSrpctVN/zYE/D0hhm1AHenJ1+/BC9SnJnL oMwLc984x697c2NwSfpZgLNbcqPEGZbww08P6yrH+T0PD9eKxsSQffc04gEHwOgb QNxwwIO/LqSNO+1AHeLEa9BTXHOB6e4vOu/vqXqosRPsik/Ywbpt1WCJOrnbahGO roUDU02JGxiN8GnEkoT/Tz19lXfMzs8Bv6FceHB6X4K9Vl3J132+QGnqU6nXvTR3 EIG99onyW1To0msbCunNbEOV41n5k43IEWSwKN7Gx5hYmT7X/I4= =Qex8 -----END PGP SIGNATURE----- --/B0jFqr4PUQbU7c8-- From nobody Sun Jul 11 13:23:56 2021 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 B3F4A3A1CED for ; Sun, 11 Jul 2021 13:23:54 -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=[SPF_HELO_NONE=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 lpFeqH9c7sPz for ; Sun, 11 Jul 2021 13:23:52 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB433A1CE7 for ; Sun, 11 Jul 2021 13:23:51 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GNJJH55wVz2xGS; Sun, 11 Jul 2021 22:23:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Sun, 11 Jul 2021 22:23:43 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 647727823.304139-9b7779af522a5fcca37efa0cea9f6f44 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] New version of draft-amsuess-core-transport-indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2021 20:23:55 -0000 Interesting. I did a fast skim (more before 111), and my brain got = going in two directions: How important is it for a node to know whether the proxy offered = actually is on-origin (not really a proxy)? I=E2=80=99m trying to think = up how one would set up security (DTLS, OSCORE) to that proxy. Somehow, = 2.2 leaves me a bit hungry here (credentials may need to be mutual). Obviously, knowing that something =E2=80=9Cis a proxy=E2=80=9D doesn=E2=80= =99t mean the client can suddenly assume it is less-constrained (e.g., = with respect to achievable response-rates and fan-in/fan-outs), = power-affluent etc. =20 Maybe those semantics go beyond what we would want to indicate via = web-linking, but I think we should think more about how to make them = available for server/proxy selection. Nit: mechsnisms but In general the HTTP provisions the Alt-Svc separte Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 11 13:24:35 2021 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 7A5063A1CF5; Sun, 11 Jul 2021 13:24:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: core@ietf.org, draft-ietf-core-yang-cbor.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162603506943.16768.7153415282637683513@ietfa.amsl.com> Reply-To: Peter Yee Date: Sun, 11 Jul 2021 13:24:29 -0700 Archived-At: Subject: [core] Genart telechat review of draft-ietf-core-yang-cbor-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2021 20:24:30 -0000 Reviewer: Peter Yee 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-yang-cbor-16 Reviewer: Peter Yee Review Date: 2021-07-11 IETF LC End Date: 2021-03-17 IESG Telechat date: 2021-07-15 Summary: All of my previous comments have been addressed and the new material looks fine as well. [Ready] Major issues: None. Minor issues: None. Nits/editorial comments: None. From nobody Sun Jul 11 20:12:59 2021 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 616F73A2AF5 for ; Sun, 11 Jul 2021 20:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 p2w4Kr866o4u for ; Sun, 11 Jul 2021 20:12:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59DB3A2AF6 for ; Sun, 11 Jul 2021 20:12:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E33438C67; Sun, 11 Jul 2021 18:00:46 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Unp_yzbWv9Lo; Sun, 11 Jul 2021 18:00:30 -0400 (EDT) Received: from sandelman.ca (unknown [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4424638DF8; Sun, 11 Jul 2021 18:00:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2C011559; Sun, 11 Jul 2021 17:57:36 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FChristian=5FAms=3DC3=3DBCss=3F=3D?= , core@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] New version of draft-amsuess-core-transport-indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 03:12:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {I browsed the document even more quickly yesterday} Carsten Bormann wrote: > How important is it for a node to know whether the proxy offered > actually is on-origin (not really a proxy)? I=E2=80=99m trying to th= ink up how > one would set up security (DTLS, OSCORE) to that proxy. Somehow, 2.2 > leaves me a bit hungry here (credentials may need to be mutual). I agree. I think that sometimes a thing that's really a forward proxy doesn't really need/want to confuse clients with this concept. This does, in general, raise questions about identities, and I think that actually we need to take this into our thoughts. (D)TLS gives us subcerts as a tool. EDHOC lets us do security through the proxy. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDraU8ACgkQgItw+93Q 3WUA9Af/e6K0sQo4ZltOJCR1KBu5XJrM8gmYSlMS+BlFtMKHjz3hyYUZdfCGGxYp 6/pFKYOYTRNtMCZDjYIdY7wJLzfFFqWsl1Gn0cMPRBL+BPRbTwqJkbLPxC9G3zfV ktEzItq8O9+vbc7/pG4B1MP4d2sgHwrZKWEc2eQo6bAxndWkKpNfAD/2KVcB3qoU rj/3WgYoM+r/oE3Rl1YalOHwMS1FVTfiGFeaqIuBQclYNKnAjmsif8iWQWCVd0gG 4N6ZMm1imQgBNUqc1Owoc6+VO25rmL5IpDbJSYtfH3cJnbZxxigDD8rupInmdXdq 9iiaWIOyuutqqEbAoaRmrPN2qZTIuA== =ywbC -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 11 20:13:07 2021 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 69A0D3A2B02 for ; Sun, 11 Jul 2021 20:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 8wn5b7OGa4_D for ; Sun, 11 Jul 2021 20:12:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14D73A2AF9 for ; Sun, 11 Jul 2021 20:12:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8551638EA0 for ; Sun, 11 Jul 2021 18:22:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L_fvKsbUSs3e for ; Sun, 11 Jul 2021 18:22:07 -0400 (EDT) Received: from sandelman.ca (unknown [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A27F38E9F for ; Sun, 11 Jul 2021 18:22:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54EC548B for ; Sun, 11 Jul 2021 18:19:13 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] core-sid-16: possible rename of ietf-constrained-voucher to ietf-voucher-constrained X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 03:12:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, about: https://www.ietf.org/archive/id/draft-ietf-core-sid-16.html#name-initial-co= ntents-of-the-regi 2450 50 ietf-constrained-voucher [I-D.ietf-anima-constrained-voucher] 2500 50 ietf-constrained-voucher-request [I-D.ietf-anima-constrained-vouche= r] I will be proposing during the IETF111 meeting that we will rename the modules: 2450 50 ietf-voucher-constrained [I-D.ietf-anima-constrained-voucher] 2500 50 ietf-voucher-request-constrained [I-D.ietf-anima-constrained-vouche= r] I'm sure that this change to sid-16 can be done at or before AUTH48, or when IANA does their work. Maybe we need to put text in ietf-anima-constrained-voucher's IANA Considerations fixing the name clearly? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDrbmEACgkQgItw+93Q 3WXR0Af6As5FpkLWVFJRPsgbhPls9j82Sr41sLobJHCBaGGUc3hV92mopI1Djsc3 HlmkYXuIs+yFKPxEUIdEsENTIv3y0hJttpgvsMKWfs4jzpjWs9sRZOoZ9+kZPChe S8APMd7v4M8K5X4PUbHEOwICyDgsPIBC9STiZBtB4MfSTdE0RUnpPz6YRAQCyV8c AOZqEbI/ZhcMMSCjfiAdn4eVLIYj82BbEoD3hFHOdxtHBA7m13vuYeX5+iSwrTf+ tSv+25yQbWJtbZd6malU5++/bIK/OG7VdfSRTPuXUxe7wDaAsanHu4tKflpPYMIC 1J84mN4gcKEJSMucHCuCZ/hjsD60CA== =oe0f -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 11 22:02:42 2021 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 3EDAF3A31B8 for ; Sun, 11 Jul 2021 22:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 7a_d1lIkwFVd for ; Sun, 11 Jul 2021 22:02:36 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE73A3A31B2 for ; Sun, 11 Jul 2021 22:02:35 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GNWpr2C9Kz2xGt; Mon, 12 Jul 2021 07:02:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <26725.1626041953@localhost> Date: Mon, 12 Jul 2021 07:02:27 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 647758947.768126-bbf13400488f9b24e36f1a5306724177 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26725.1626041953@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] core-sid-16: possible rename of ietf-constrained-voucher to ietf-voucher-constrained X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 05:02:40 -0000 On 2021-07-12, at 00:19, Michael Richardson = wrote: >=20 > Maybe we need to put text in > ietf-anima-constrained-voucher's IANA Considerations fixing the name > clearly? Yes, please. Then it should be easy to fix in -sid. (Probably during the =E2=80=9Creact to IESG ballots=E2=80=9D phase we = are now in.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 12 01:17:35 2021 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 852203A1335 for ; Mon, 12 Jul 2021 01:17:33 -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=[SPF_HELO_NONE=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 ylmbJfzk2kil for ; Mon, 12 Jul 2021 01:17:29 -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 5C4583A133C for ; Mon, 12 Jul 2021 01:17:28 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4878840172; Mon, 12 Jul 2021 10:17:26 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4C83DD0; Mon, 12 Jul 2021 10:17:25 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:f05c:b262:9dc3:8627]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0D75126; Mon, 12 Jul 2021 10:17:25 +0200 (CEST) Received: (nullmailer pid 2310734 invoked by uid 1000); Mon, 12 Jul 2021 08:17:24 -0000 Date: Mon, 12 Jul 2021 10:17:24 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann , Michael Richardson Cc: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GI8W9oeiX6v3C08K" Content-Disposition: inline In-Reply-To: <20329.1626040656@localhost> Archived-At: Subject: Re: [core] New version of draft-amsuess-core-transport-indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 08:17:34 -0000 --GI8W9oeiX6v3C08K Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 11, 2021 at 10:23:43PM +0200, Carsten Bormann wrote: > How important is it for a node to know whether the proxy offered > actually is on-origin (not really a proxy)? On Sun, Jul 11, 2021 at 05:57:36PM -0400, Michael Richardson wrote: > I think that sometimes a thing that's really a forward proxy doesn't real= ly > need/want to confuse clients with this concept. "clients need not make the distinction at all" between same-host and any other proxies. I've introduced the same-host proxy terminology to make it easier to grasp how little a server needs to do to become a proxy for itself. If that's confusing for the client side, it may need reevaluation in the way it is written. > I=E2=80=99m trying to think up how one would set up security (DTLS, OSCOR= E) to > that proxy. Somehow, 2.2 leaves me a bit hungry here (credentials may > need to be mutual). Mutual credentials are something I have not considered; it's easy for same-host proxies, but an actual proxy would need quite some setup for that. With OSCORE, all the security aspects should be simple and straightforward (except when a proxy wants an *additional* security context on its own, for which a document is upcoming AFAICT). With (D)TLS, a proxy is necessarily trusted, so on its server-side it needs either a way to have a good-for-the-upstream-server certificate (which it could probably obtain even at run time), or a very powerful certificate ("Trust The Proxy. The Proxy is Mother, the Proxy is Father"), which sounds like an aweful thing and maybe shouldn't be condoned at all. (Like, if you can get such a certificate, instead get an ACME account and pull an origin certificate on demand; this is *not* about same-host proxies any more anyway). Mutual (D)TLS authentication through a proxy is even hairier, as again the proxy would need an "I Am All The Clients" certifciate. But well, in a world with (D)TLS and proxies, if you want both then the proxy *does* become ~"by its very nature a man-in-the-middle" (7252 section 11.2 citing 2616 section 15.7). > Obviously, knowing that something =E2=80=9Cis a proxy=E2=80=9D doesn=E2= =80=99t mean the client > can suddenly assume it is less-constrained (e.g., with respect to > achievable response-rates and fan-in/fan-outs), power-affluent etc. =20 Yes -- particularly when it is a suitable proxy only for a particular origin. > Maybe those semantics go beyond what we would want to indicate via > web-linking, but I think we should think more about how to make them > available for server/proxy selection. A lot of things could be said about a proxy ("I support FASOR and am close to your origin server, pick me for performance." -- "I have ample cache content, join the hive."); link target attributes can do a lot here, but I'd rather not specify anything here without a very good idea on how they would be used in practice. (For simple administrative information for human consumption, ;rel=3Dimpl-info;anchor=3D"the-proxy" would do) Possibly (considering both the hard questions on different-host proxies regarding security, and the distinction question), it'd benefit the document to treat third party proxy services more as an afterthought. Then, the security parts could be made stricter ("Just because it's through a proxy doesn't mean you can compromise on security"). Third party proxies would stay easy where OSCORE/EDHOC is used, and (D)TLS deployments need to go all the way with whichever tools are available there. (In which I do have little experience, never having deployed with them). BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --GI8W9oeiX6v3C08K Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmDr+pEACgkQOY0REtOk veEvcA/+MCnlUDo2TW9QskMDFtM/DxY27XtrO1tYXcMwQEbxQ3XZTbO3HjRz+/6v JthNcLubTjnyJj354KtuEU5Do0CRFaM4O8k25wPlS+J/8eFEkUaLDHCzKcYxYElR +q6xPkeYNfejPBTjseHRzdIm5DloiYTZ1s7io2s9yhlZLZyFGt7qPKhuQoK2kShJ PYvp6T2TWqS1JfLit1LBuj208gJf2Y9cDbD4U3GfutRNPCjzd79XSLrGSow7dYy1 OM4I8lqrr1m6llQ0Tkam9qp9HxOnoGQGobzAtNIa6LRdDL/I5D1mDkIAYrOkf3GE 4NwXEtCfLtbbzX278uXlur9E41EFJ3lOxPYUUibBJR/ARL4VMsJNPHp/M8u9mSVk W30Gur1g8a21Tf1zrqJuWHX671XWYAjXTHrxRHcXX0+Dq/IR+aagvvDecJqyhzaY tF2nxRqRh616sissj7yrycq6nAFvyH0JC+UVe98+6S/DpO4mmkD6Z0ri9UzTBRDJ OQPT203i/Fe7L6IzAs6l/EasgGGvMzRN78Mo15X4XZxnY6Q+d9W4SQxC62mC/hzt 8kew8o6QmTGSgCMABvb3oYI94N5WZAgq9AhMpWXqMvrw4ISTZUkFLQptasoZEsCX Mv4hCTN06Mwxv+b66qRZV+2l8TmHFt9kyCA6aIVDNd33tGc3l4U= =iQGu -----END PGP SIGNATURE----- --GI8W9oeiX6v3C08K-- From nobody Mon Jul 12 01:49:24 2021 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 8B6DD3A15B9; Mon, 12 Jul 2021 01:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.656 X-Spam-Level: X-Spam-Status: No, score=0.656 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 u8GiHr51rKu5; Mon, 12 Jul 2021 01:49:17 -0700 (PDT) Received: from forward2-smtp.messagingengine.com (forward2-smtp.messagingengine.com [66.111.4.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A7C3A15BC; Mon, 12 Jul 2021 01:49:14 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.nyi.internal (Postfix) with ESMTP id BA0891940110; Mon, 12 Jul 2021 04:49:11 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute5.internal (MEProxy); Mon, 12 Jul 2021 04:49:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=HKaGd6 BRSbdzT+Y7JO89XirYH7pALCP+gsTNGUUcQ+Q=; b=Nsyb9RW+arRDMfKE8O1Brl IyPrYHAOtrVXlRCpSaLRPpICeF88HL4Ikvb69IFj1zE2aOhePWdbm4HN8WVQusRR p8YwSL1coiDqLYSizAjS9NqsUyysJkDLm6v0M9mzTorGYxjaeRCo/hbbl4jCmynG Llg/19j8riIZ7HumvnVjZ3MtnqtfVGklQ2biEGLM2Vv4lC86v1iINH+60cTasazh h5IPiaL4lVliLy+oTEis9BbSoYs0muvuNhYaH1tHj7pXLW/yeY7PFPUqelcIx1/3 fZ3QnaXnfH3/Sk5aJsMDh3gPc6NBeu39uweMM5JSEIIMs+mc9rdSk3Zv1PF8fZaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddvgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgrihhmvggp lfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnhephf etfeeuvdefhfeuffegjeejleffueegfefhleekleejkeetteehteevfedvtdffnecuffho mhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41A5A420D22; Mon, 12 Jul 2021 04:49:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-531-g1160beca77-fm-20210705.001-g1160beca Mime-Version: 1.0 Message-Id: <81c36172-7258-4614-8062-9a2ebffe9ea2@www.fastmail.com> Date: Mon, 12 Jul 2021 11:48:46 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: draft-ietf-core-senml-data-ct.authors@ietf.org, core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] IPR call for draft-ietf-core-senml-data-ct X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 08:49:23 -0000 Dear CoRE and Data-CT authors, As part of the process and before IESG submission the chairs have to sol= icit knowledge of any IPR that may pertain to the work on https://datatr= acker.ietf.org/doc/html/draft-ietf-core-senml-data-ct-04=20 If there is IPR, it must be disclosed in compliance with IETF IPR rules = (i.e., RFCs 3669, 5378, and 8179). Please indicate if this has been don= e. If you are an author or contributor, you must reply to this email to ind= icate the IPR status. Ciao! --=20 Jaime Jim=C3=A9nez From nobody Mon Jul 12 03:32:21 2021 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 787A33A1247; Mon, 12 Jul 2021 03:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 WUU9K795tqRo; Mon, 12 Jul 2021 03:32:14 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC553A1241; Mon, 12 Jul 2021 03:32:14 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GNg7H49p2z2xHZ; Mon, 12 Jul 2021 12:32:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <81c36172-7258-4614-8062-9a2ebffe9ea2@www.fastmail.com> Date: Mon, 12 Jul 2021 12:32:11 +0200 Cc: draft-ietf-core-senml-data-ct.authors@ietf.org, core@ietf.org, Marco Tiloca X-Mao-Original-Outgoing-Id: 647778731.136013-4374187f9b191689c032826b4cabef11 Content-Transfer-Encoding: quoted-printable Message-Id: <6FA6A641-9AD6-40F4-B2B1-BE5D714C3B97@tzi.org> References: <81c36172-7258-4614-8062-9a2ebffe9ea2@www.fastmail.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] IPR call for draft-ietf-core-senml-data-ct X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 10:32:20 -0000 I am not personally aware of any patent claims that would read on this = specification. Gr=C3=BC=C3=9Fe, Carsten > On 2021-07-12, at 10:48, Jaime Jim=C3=A9nez wrote: >=20 > Dear CoRE and Data-CT authors, >=20 > As part of the process and before IESG submission the chairs have to = solicit knowledge of any IPR that may pertain to the work on = https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-data-ct-04=20= >=20 > If there is IPR, it must be disclosed in compliance with IETF IPR = rules (i.e., RFCs 3669, 5378, and 8179). Please indicate if this has = been done. >=20 > If you are an author or contributor, you must reply to this email to = indicate the IPR status. >=20 > Ciao! > --=20 > Jaime Jim=C3=A9nez From nobody Mon Jul 12 04:31:48 2021 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 2848F3A0C9E; Mon, 12 Jul 2021 04:31:46 -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: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162608950605.22475.7997969756940983013@ietfa.amsl.com> Date: Mon, 12 Jul 2021 04:31:46 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-conditional-attributes-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 11:31:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Conditional Attributes for Constrained RESTful Environments Authors : Michael Koster Bilhanan Silverajan Filename : draft-ietf-core-conditional-attributes-00.txt Pages : 17 Date : 2021-07-12 Abstract: This specification defines Conditional Notification and Control Attributes that work with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at TBD The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-conditional-attributes/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-core-conditional-attributes-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 04:52:17 2021 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 B50D63A103A; Mon, 12 Jul 2021 04:52:11 -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: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162609073170.4604.1243267675394084080@ietfa.amsl.com> Date: Mon, 12 Jul 2021 04:52:11 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 11:52:12 -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 : Dynamic Resource Linking for Constrained RESTful Environments Authors : Michael Koster Bilhanan Silverajan Filename : draft-ietf-core-dynlink-14.txt Pages : 14 Date : 2021-07-12 Abstract: This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). Editor note The git repository for the draft is found at https://github.com/core- wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 05:03:58 2021 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 812AE3A1127; Mon, 12 Jul 2021 05:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 YnuhSIXNP6jl; Mon, 12 Jul 2021 05:03:50 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2087.outbound.protection.outlook.com [40.107.20.87]) (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 59D253A1126; Mon, 12 Jul 2021 05:03:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YGgIsZryjecTUeT605qXg0ROKH4pzVE71aONQbm9tMfXG1Jz2DNc5Rl7wYTPfJomRxrcn2M5cf2whbZAckzlptB6LXdRo6AH7CdpU+QJyimdimeeMrfuHcYFgoECQUzEbPyYhfqeljhzKJdbcAQuD4ogI5e2AJpwHjusg0VU9nTBP3c7VWRk+6CJbovu26gYhlOOgBgQbU4jwgCgCz+8JYaqcBj1cDHrQzztzxj6fZJP0K/GblCfEF5bVgODLAY3y0eZzovDbuUBuDJdqXTy9EYT60KELeatlDO70rhLexuqYAz1qmefLxPOhUpiuu5k6Jdcpbbp6GSY8wBDmOs+8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E19UxWN+mIPXOvfynePvMvl5cItwejD64pEKeqKa3+8=; b=HUagBaPqLebuemYcBx5E/qIDKpA/eksp3AgeuL29H9QPKVN5ft6Tb1+sU7g1cdV2H5wGSFBzPsB2t04GePSdmc9Sh+BfFpoD7z7P6OMPWEVed/4+b6H4GUFDyrWENDzphIgGMENi8UDeAbqVN49MUc5vJcLCxYsCr/AVIX3AS+bcq2HDoAZcbGANnJ+nIYi0oE2qLJCbiUp8xmfXWKjDInyBGQyYhvwCdhBDALnc0qfqXDNlPl9srwqM4r/HnljEXtAIZ8i88YCCw74oMjNjcfWmKIEIKFEFO3srSERaUTHzZl8NIkz8rXDvSw7guj+3WHzoKs6sLRlrCUMkGdZf+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E19UxWN+mIPXOvfynePvMvl5cItwejD64pEKeqKa3+8=; b=qnLZ3Nf7zVTtXIRXLQ0nmAANiNPF10qWz1eP25sS0ovk0C1CacwdkuhxbgJnliXrFhZ60fCeGP0FrXNzf6NQNt2FbJnbeD6kXK5tnwHJGkn9np+dYUnojz/Wcf2P2w2RthgRkul98xsvBoVUmvGXmBFnERoGfzlVXr7L2W6wCbg= Received: from HE1PR07MB3226.eurprd07.prod.outlook.com (2603:10a6:7:33::20) by HE1PR0702MB3769.eurprd07.prod.outlook.com (2603:10a6:7:83::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.14; Mon, 12 Jul 2021 12:03:40 +0000 Received: from HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::94dd:3107:63f:4370]) by HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::94dd:3107:63f:4370%6]) with mapi id 15.20.4331.019; Mon, 12 Jul 2021 12:03:40 +0000 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Carsten Bormann , =?Windows-1252?Q?Jaime_Jim=E9nez?= CC: "draft-ietf-core-senml-data-ct.authors@ietf.org" , "core@ietf.org" , Marco Tiloca Thread-Topic: IPR call for draft-ietf-core-senml-data-ct Thread-Index: AQHXdvralZnJU4osnUyPac1mUxBdyqs/JGKAgAAZj64= Date: Mon, 12 Jul 2021 12:03:39 +0000 Message-ID: References: <81c36172-7258-4614-8062-9a2ebffe9ea2@www.fastmail.com>, <6FA6A641-9AD6-40F4-B2B1-BE5D714C3B97@tzi.org> In-Reply-To: <6FA6A641-9AD6-40F4-B2B1-BE5D714C3B97@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea8a9983-0838-4764-db71-08d9452d1654 x-ms-traffictypediagnostic: HE1PR0702MB3769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AM3YyJ4Or3vifTMV+zbMLWbQ6IamX4uiJTiejecf0UNYQQkR7fH4piaCAyLlI/Q47C5g9cq4C4f29FqPFnMz+PP9AhX0G5A7VC+ciAs67TiZofhd/o2lAQyR9MgtH6Bz3dTUXj2dJ7hSCWaE1v7xfyN1yf909GxtAG8eeWXEv8dcWKM8ZLskyln9bQjGTRrQ5LJKYF8ZzA7ofuQ5Gbj9QdBTnmjrrJtM5nToOLTro46HP/l2BvJmlgsE8861ybXfOL+2/eo4sJbgBPJzrKvU8uCDHvhRwcd9kl7NoqAcbKeHS5jjY8kPKD+i6NpvjSF3RptTVHxqJ85R/Cg9SXQIuei+MKh1A9/PVlRe+PNfYHZt1KmpPERkGU4RB8XzOuVeUx+zcW7dnd0Z6krE4GthEOwqMSeSJv3rw6L2UHxuCjxvsjsEVH81JEO0ava9J3KX44Tw1KdbV294oAMUCykkDA/m6a231ww5PPMVjpltT3ysXTiQGMtjpVf/KFh3oZgn+QEq6J7PpLad/m6HAXapSezt5D3yrKClPf2nOQcvGB7iZ9NT2knW4hpGpJbhfV7kKfBpnweDl62rKDREUNdA2MRWrWkDQaEIyW5eTQQc34byyzt7zCyvhIe4Bx95XWx8z+/8ZRF3XWDl+6ClN+PXL9MJVUSK1qsbDrYjTh+bVxXX12zxLZOyE3m3yPfxyk0RTQaQu+T6yjQcZTHGWoNTbckGLITpZ4fNxJEv8E4Eh38= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3226.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(966005)(83380400001)(66556008)(186003)(478600001)(66446008)(76116006)(54906003)(66476007)(110136005)(91956017)(64756008)(66946007)(316002)(38100700002)(2906002)(122000001)(33656002)(8936002)(4326008)(86362001)(6506007)(53546011)(166002)(52536014)(71200400001)(6486002)(5660300002)(8676002)(9686003)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?YjtPsqX+56Cj3vN9MoVARoFzw7x+8E1Lz6I07PxpxZk1/OBMPcnG77t3?= =?Windows-1252?Q?P13Mh1rhhCoV+MsAa9zmcdliBhteo4KfQPWc3bpGkcLvDmsXcaUWFkye?= =?Windows-1252?Q?oVnqAs/T1BHTYVJFOlp1WCoXFNcKvdxFUjgZAl9GDGUicaMZhlTwpnM4?= =?Windows-1252?Q?r0XJR/PDtqHPifCTElwFKL8C8BTxOayZWg2Nbrx5OyKKATk4srz/8tW9?= =?Windows-1252?Q?A3omnGQExfQeZ2gaBCQOXpzJnvOwhM625NWVsTdK2iVHAWnNRCpAhyGk?= =?Windows-1252?Q?TfwSmNzXXv35uHwXI7LAX8dmk9/djGD+k8yxkJMYo3O6bR/S05DP3jjM?= =?Windows-1252?Q?rbPQomR1fo/iEjlyZZGgVckSzYaNrQ6fgKbhrfxOVXv8riigKI8Cdpea?= =?Windows-1252?Q?ZILE+CMaNR1oJJ2eW66FmAVLcB90pBY8pGZK3tnAxQxKdtYk2h2kXVye?= =?Windows-1252?Q?WO0IpKqYYQYSDEXAx6RrPcovtaFDCEebl+jqmrA5Pwo1L7s3zQ3+77UV?= =?Windows-1252?Q?YbWqmDJLj/LqZuPTHnMyBD/IjIxU4FVvJTP9PzlWJOZufQbhYRAK4nxP?= =?Windows-1252?Q?ljN0W5bYF3Ma9wPTqCWF33gppbtJrGPOwJE9nLXe4p6zWlkUDtEixElv?= =?Windows-1252?Q?ncLU86JJrfcD/Y8fIJzJjw+8eIL/kzvVZX7IaYqi0Ny4d8Oz0VioGs82?= =?Windows-1252?Q?+ze3KqpDJ23kW5Rlz3HZPIYrOupBrst13+1l69B/pQ4hY5wT5dXPGCZB?= =?Windows-1252?Q?Hs+m2oxy+MSS3P12pVHgLiDmDQ+YjM1NPvsC9W1tCGUG1rLdc7jWf/oG?= =?Windows-1252?Q?I3vA2AS0/w4ZvxjThBIdSf/I+SdomAFQcQ2B+2GxAHsiQXBqGtY1Eg5S?= =?Windows-1252?Q?eW4d58W39IsBxHQR3jLRxXy0wxSch+ORp0/GRZ1UKhA4UhKiCN9qgfqS?= =?Windows-1252?Q?eEtmI55XU2BgY5ZM3JdNwNkUi4xM9l7T4rn6U4MOJCdg7WpqHSDZ1QW/?= =?Windows-1252?Q?VDSOVZOL07tCAfWRS7SK9b0AJAFK+Pka+Wbj/NygdJsneX+gMyFpCE0n?= =?Windows-1252?Q?PH841Xl4LoLpa3pA9QQl/zaY61XwBsTBzQI93YNl7/xsM/3DBBxSvDwY?= =?Windows-1252?Q?5fNqWd5PublAxeyioTjM0BiOQij4Vg7DWrpkHqkUiOiWHfzINJjcG+x6?= =?Windows-1252?Q?ZIQQIrlAbqkK+eKspgWBePN+l1tHhLRjBFQ89JvPMPaQLxvkErEo9Isi?= =?Windows-1252?Q?J/FFY21xhe9Q4u49zsCIyhSkodWj1vJgI+Jk+lcaKplYLqGH54TchnQV?= =?Windows-1252?Q?0z3q1tluXvNwtTlD8Hc3y38TVjdUwY29YnyXrTxmcsF8cdUpvMfIgLHx?= =?Windows-1252?Q?8KwcDEbXQzneaW7corMtiGENj3L4AnQitdfhBM4s5jF/xzH/pQQPXqai?= =?Windows-1252?Q?fY3V0fSpkSvGrBXyHqdZhQ=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PA4PR09MB4558620E725CB4AA4E7D355BAA159PA4PR09MB4558eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3226.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea8a9983-0838-4764-db71-08d9452d1654 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 12:03:39.9161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2mZN6XRcZKsKFtOedxsq35sLJWm0Qd4Z7cc6cGhbvHZE4tLW2pd3YncO28Aczw2X0OQkY6ob56NU+nenXcj3zUzc5kNR4/VhDs8n2hUtGRI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3769 Archived-At: Subject: Re: [core] IPR call for draft-ietf-core-senml-data-ct X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 12:03:57 -0000 --_000_PA4PR09MB4558620E725CB4AA4E7D355BAA159PA4PR09MB4558eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Same here, I=92m not aware of and patent claims that would read on this spe= c. Cheers, Ari ________________________________ From: Carsten Bormann Sent: Monday, July 12, 2021 1:32:11 PM To: Jaime Jim=E9nez Cc: draft-ietf-core-senml-data-ct.authors@ietf.org ; core@ietf.org ; Marco Tiloca Subject: Re: IPR call for draft-ietf-core-senml-data-ct I am not personally aware of any patent claims that would read on this spec= ification. Gr=FC=DFe, Carsten > On 2021-07-12, at 10:48, Jaime Jim=E9nez wrote: > > Dear CoRE and Data-CT authors, > > As part of the process and before IESG submission the chairs have to soli= cit knowledge of any IPR that may pertain to the work on https://datatracke= r.ietf.org/doc/html/draft-ietf-core-senml-data-ct-04 > > If there is IPR, it must be disclosed in compliance with IETF IPR rules (= i.e., RFCs 3669, 5378, and 8179). Please indicate if this has been done. > > If you are an author or contributor, you must reply to this email to indi= cate the IPR status. > > Ciao! > -- > Jaime Jim=E9nez --_000_PA4PR09MB4558620E725CB4AA4E7D355BAA159PA4PR09MB4558eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Same here, I=92m not aware of and patent claims that would read on this spe= c. 

Cheers,
Ari
From: Carsten Bormann <c= abo@tzi.org>
Sent: Monday, July 12, 2021 1:32:11 PM
To: Jaime Jim=E9nez <jaime@iki.fi>
Cc: draft-ietf-core-senml-data-ct.authors@ietf.org <draft-ietf-co= re-senml-data-ct.authors@ietf.org>; core@ietf.org <core@ietf.org>;= Marco Tiloca <marco.tiloca@ri.se>
Subject: Re: IPR call for draft-ietf-core-senml-data-ct
 
I am not personally aware of any patent claims tha= t would read on this specification.

Gr=FC=DFe, Carsten

> On 2021-07-12, at 10:48, Jaime Jim=E9nez <jaime@iki.fi> wrote: >
> Dear CoRE and Data-CT authors,
>
> As part of the process and before IESG submission the chairs have to s= olicit knowledge of any IPR that may pertain to the work on https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-data-ct-04 =
>
> If there is IPR, it must be disclosed in compliance with IETF IPR rule= s (i.e., RFCs 3669, 5378, and 8179).  Please indicate if this has been= done.
>
> If you are an author or contributor, you must reply to this email to i= ndicate the IPR status.
>
> Ciao!
> --
> Jaime Jim=E9nez

--_000_PA4PR09MB4558620E725CB4AA4E7D355BAA159PA4PR09MB4558eurp_-- From nobody Mon Jul 12 05:05:56 2021 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 2A8653A1165; Mon, 12 Jul 2021 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 1GTSnO0Hmvg0; Mon, 12 Jul 2021 05:05:47 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2045.outbound.protection.outlook.com [40.107.20.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8643A1163; Mon, 12 Jul 2021 05:05:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dOoqIWVhrbkWNpNY3uk3Uned3ow9D+aYTdsemyGYb9DQJfJal+IF/9zBkoLCMhllnCBpKgv8JW+9diStafhb3JtOjNRopMoaee1bcS5qZgn17NP8QSK74Kz1UwTzOztvwJlpkleq421sdi/GepIJJKbfxaSUkoayyHtihgheaZilsWbtwGtY03dO7/O1Hz3zG0373i0bqmCUmfVVN6ykw8dHe/ri8fgVzySSRoalBf4n5PVRCO7YsCb1pqJ0ibiPmeABwO8tnmKg/Gh1dkWI3GaHxLgV5EGkKOZYHDFo+pOeSw+xAWctn2zQ6Hp1MK0TGCZywcWCgLEoLWrUJFFRYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pVTMi/XtkPquNnpBy+cLM/IEw6rf4p7FLMqsGtR32Pc=; b=PpuWZBNUWzEdJ2sSBErGZ/tMPxmYk7rjljANleV2G9KLaPQvk/rap1l9EmWSFIPAG/3L6bU6XIdaoxZ0eB4hPWuOC7aCRsa77Gv2v81aFe2pRBJlcqe/B1pmWAt8Lt5w6Fn2SjAbSaHNn/PZEpVkATaE+aCupGwf2X+c4guDQJsYGCcZfnc2+jqKAzTC3rYgPYMrv/PJdQYvka8H+bXDZWLNuLDCYdFFIs03nUs9BhOoxvrXsfQdermzNjRrdTWb4YSZndamNFaQRfqXfCNekYQ/YqNLyCbvPyBHp2XJjZ/pcTZXa3plvpTCRzkiPvnkjkpOClEdFXoCWA/eOWiSEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pVTMi/XtkPquNnpBy+cLM/IEw6rf4p7FLMqsGtR32Pc=; b=o0b9qnii6rMflYWWVOAJXtk5yj36OcRXJWp+2VXzbHST/DzchmkE/SWKIiC16MdyWJFKvAumEnVVItVQr+JDHL/KNiqpdJ3e+mOEepJti6yHb5ZFXqCbLTa3IaVY30mk30pcygkVh7rmh6c/wHurwrYEgTCY3ROx3Bqt4mJVybg= Received: from HE1PR07MB3226.eurprd07.prod.outlook.com (2603:10a6:7:33::20) by HE1PR0702MB3769.eurprd07.prod.outlook.com (2603:10a6:7:83::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.14; Mon, 12 Jul 2021 12:05:45 +0000 Received: from HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::94dd:3107:63f:4370]) by HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::94dd:3107:63f:4370%6]) with mapi id 15.20.4331.019; Mon, 12 Jul 2021 12:05:45 +0000 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Carsten Bormann , =?Windows-1252?Q?Jaime_Jim=E9nez?= CC: "draft-ietf-core-senml-data-ct.authors@ietf.org" , "core@ietf.org" , Marco Tiloca Thread-Topic: IPR call for draft-ietf-core-senml-data-ct Thread-Index: AQHXdvralZnJU4osnUyPac1mUxBdyqs/JGKAgAAZj66AAACVZg== Date: Mon, 12 Jul 2021 12:05:45 +0000 Message-ID: References: <81c36172-7258-4614-8062-9a2ebffe9ea2@www.fastmail.com>, <6FA6A641-9AD6-40F4-B2B1-BE5D714C3B97@tzi.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38e90e95-ee37-4107-7d03-08d9452d60f5 x-ms-traffictypediagnostic: HE1PR0702MB3769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tOvWGa+me9HgoqI+As7H1R1PIqMWhnesnc+UyMHmZodxQKSk8QR48MxWorItDUPbkO0EwyGFCCU4K8FvQDnJiUgNzTyhj7HcPJ17Dv0fIG0guQoKRm/0gTbO63gTv+os8aTxEJ3XGJmTs2pBrv2SV8XaWExsklRyhn/v1Imo9hNkYsNABebSzpUBitYQOXG4gPZYahr3UBEw+I//RvM93Nf+VWlfKae/Emgx2WM6p5imKz+8LpsTjcke1b8McrYHeS8kaDo4s/L6qtNpikNcjIfar1elpT0PPPLnY0s9xqLd6aEUPkj/gvzDz+ydGwbGxpbaF/JgAGFLxHDIE+317RHLtLam/C5B9I8JbhOEbk/H5j5LzbJAeiqfbN50yDy19vMCNOusFtObc0IWUO45d2/4EyLjzzu4Ckt6glNEuu58DgRMzxdASYro0cLLRSw8x+fWCVii2iNI+28z0E2lHemYr+ocXsVSawtgc43zJZcx38fsToQxtEkq0j3wTDrq4YsoKzXfOePQyJh6LFk06+tvbkut1IrwufcPQxYFObPbVRAZurt69hN5WnF0aRzRFYdLyBplQxmSNmkrAneA9N1hg7qFa7ABmK1/7su8/HHpzo0VGVMqIpaP87Zk4qoHZfwTY6vt3XqeGfMxxXd68NB4dZTT21XO3oxyOlOFMe5IRpXTAR4dYEu3OLJ48cfNHvlzdWZ/Ocsu5AUhQcaAUX9tX077Ju47bHYiDZlDXes= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3226.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(966005)(83380400001)(66556008)(186003)(478600001)(66446008)(76116006)(54906003)(66476007)(110136005)(91956017)(64756008)(66946007)(316002)(38100700002)(2906002)(122000001)(33656002)(8936002)(4326008)(86362001)(6506007)(53546011)(166002)(52536014)(71200400001)(6486002)(5660300002)(2940100002)(8676002)(9686003)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ss1aWZNneR4cHTHYins+vlJphgNfPGY1KpodOroNzS7u98hVWteG9olj?= =?Windows-1252?Q?JepVOvH/vPW3JYIYNnMDnZKtf1/ne8H7LS3vq+Yw5SZtkGpbNKJh6q/t?= =?Windows-1252?Q?JZW2BNwjWY0igPSGc6WPvSvsmi6R0UcKp1jt1yZarvy+o3yGn3K5IZq3?= =?Windows-1252?Q?OPXF7qX6DP5h5AQdDJJ2fjDMpyWKhBakyGW7vFPJ8mWPAL7voRSJOMQM?= =?Windows-1252?Q?rrkWWMo7JO9+AgoUmUul0ARENGvZUsqFqnTn6XbK9UhDd9hRAQyEgm+q?= =?Windows-1252?Q?BgMOoelA3wqs+bSkT5pANWU7+8HpDZfMmuGCwv/eD1DhRiTAmWfYdaUr?= =?Windows-1252?Q?UcXy+Dvc0gDRgo4Eu3vbTYsPWnVMsjdQeH9jUxPEhLs3k+KFRjnIxQsf?= =?Windows-1252?Q?B4kHMDHQEkXoBWHbnZmtF0a809FhkU4ahKGp6FFGtAWREyg2N1rxGfhi?= =?Windows-1252?Q?SBm2RwHMW6iCP1D6JhHYVI05Q0LLcHvxD1ssHhVrn10fZnByr+i7hLEc?= =?Windows-1252?Q?fYt2IcCeHDtTcM96fOPJUvEH/5mzKMMjq1xZaHkHr+uImErOyDNxdKcF?= =?Windows-1252?Q?P/ca2/wOGTrE7dBOQYvDL+NTPAQiRKV76L+dtD3f50tT3Mnv/IQkmtbf?= =?Windows-1252?Q?KwQlHn6QTDti9CSy5TEt6v43sNFqfMFx9mof8O03lF8gXF3FL719UaEx?= =?Windows-1252?Q?wmoU1mA9CcFMZdG9E6Mcx2zhQwcLvfO3k2zVeQDfmbYDahn8M4+3OJSR?= =?Windows-1252?Q?e6rPBC8m4e6V3bJ091R8zpqd39PKTALS7yAl63eiwZFoUgb1zQlpAwOU?= =?Windows-1252?Q?9MEOLHKgrDGWdiNQ6qPvqijmwJlExZju0hzF0yqXvauTjkPpSmA0I/62?= =?Windows-1252?Q?FI7Rz30F0eHOnJImUqlDrbgmV+AgoLf29VtZUy0KEPJYAqQ1E2a/bcvE?= =?Windows-1252?Q?GjRVNfvu8XXaleg+eJfWj/HzPPHdT2StkqwB6ZwZNZIiIPSDSQK3e1Ra?= =?Windows-1252?Q?V47cugig0yn83it91wz5645MybmwWBUMB361lgKzu5Hm+yNgRgEimPhs?= =?Windows-1252?Q?0xPw+Tn+1rBG0DQw2SI+cgfnnpmCmqn36hIDPliLg7hP2PlJhmFatvsw?= =?Windows-1252?Q?clr/gigpcLHOBQhW/ZfewvPFhYMuTvLEWUKy5m0fggb/0ibqNfQg6MHZ?= =?Windows-1252?Q?fh1W10WAzXLLFpGk8/h9ABGGO/M+6tsFhBRA03bj4yBPZ664yaGN45+S?= =?Windows-1252?Q?5uExSz4ZCZE4/FhX0GZQYsnsQB29BloKagAhjxwM5KyCZK6BO+/PDntV?= =?Windows-1252?Q?pGB1ytQBSN72JvBwyTAxD1NSJyftcz7AXmPWPYEx3RAt/fr6DjH8faPl?= =?Windows-1252?Q?ZXcIlRNSnqlmF7KhJzTsSvGuj6JrGGgLVwQCUeAUx2rHfMp5tr12DIM5?= =?Windows-1252?Q?s2VTq+hAe6vZblAKffxFuw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PA4PR09MB4558A0944A4773493EAED759AA159PA4PR09MB4558eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3226.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38e90e95-ee37-4107-7d03-08d9452d60f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 12:05:45.1142 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NQq2e/oyQKt3czWo/SIehtHbjASjYSSXyj8D1JKHNZG7R+T0raebED5hOxVcq7wLi7YYjJ1QwfgzKX65jJkA2aVsBEEavdOq3BbhTRoRDmc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3769 Archived-At: Subject: Re: [core] IPR call for draft-ietf-core-senml-data-ct X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 12:05:53 -0000 --_000_PA4PR09MB4558A0944A4773493EAED759AA159PA4PR09MB4558eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (With typo below, meant to write =93any patent claims=94). Cheers, Ari ________________________________ From: Ari Ker=E4nen Sent: Monday, July 12, 2021 3:04 PM To: Carsten Bormann; Jaime Jim=E9nez Cc: draft-ietf-core-senml-data-ct.authors@ietf.org; core@ietf.org; Marco Ti= loca Subject: Re: IPR call for draft-ietf-core-senml-data-ct Same here, I=92m not aware of and patent claims that would read on this spe= c. Cheers, Ari ________________________________ From: Carsten Bormann Sent: Monday, July 12, 2021 1:32:11 PM To: Jaime Jim=E9nez Cc: draft-ietf-core-senml-data-ct.authors@ietf.org ; core@ietf.org ; Marco Tiloca Subject: Re: IPR call for draft-ietf-core-senml-data-ct I am not personally aware of any patent claims that would read on this spec= ification. Gr=FC=DFe, Carsten > On 2021-07-12, at 10:48, Jaime Jim=E9nez wrote: > > Dear CoRE and Data-CT authors, > > As part of the process and before IESG submission the chairs have to soli= cit knowledge of any IPR that may pertain to the work on https://datatracke= r.ietf.org/doc/html/draft-ietf-core-senml-data-ct-04 > > If there is IPR, it must be disclosed in compliance with IETF IPR rules (= i.e., RFCs 3669, 5378, and 8179). Please indicate if this has been done. > > If you are an author or contributor, you must reply to this email to indi= cate the IPR status. > > Ciao! > -- > Jaime Jim=E9nez --_000_PA4PR09MB4558A0944A4773493EAED759AA159PA4PR09MB4558eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
(With typo below, meant to write =93any patent claims=94).=  

Cheers,
Ari
From: Ari Ker=E4nen <ari.keranen@ericsson.com>
Sent: Monday, July 12, 2021 3:04 PM
To: Carsten Bormann; Jaime Jim=E9nez
Cc: draft-ietf-core-senml-data-ct.authors@ietf.org; core@ietf.org; M= arco Tiloca
Subject: Re: IPR call for draft-ietf-core-senml-data-ct
 
Same here, I=92m not aware of and patent claims that would read on this= spec. 

Cheers,
Ari
From: Carsten Bormann <c= abo@tzi.org>
Sent: Monday, July 12, 2021 1:32:11 PM
To: Jaime Jim=E9nez <jaime@iki.fi>
Cc: draft-ietf-core-senml-data-ct.authors@ietf.org <draft-ietf-co= re-senml-data-ct.authors@ietf.org>; core@ietf.org <core@ietf.org>;= Marco Tiloca <marco.tiloca@ri.se>
Subject: Re: IPR call for draft-ietf-core-senml-data-ct
 
I am not personally aware of any patent claims tha= t would read on this specification.

Gr=FC=DFe, Carsten

> On 2021-07-12, at 10:48, Jaime Jim=E9nez <jaime@iki.fi> wrote: >
> Dear CoRE and Data-CT authors,
>
> As part of the process and before IESG submission the chairs have to s= olicit knowledge of any IPR that may pertain to the work on https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-data-ct-04 =
>
> If there is IPR, it must be disclosed in compliance with IETF IPR rule= s (i.e., RFCs 3669, 5378, and 8179).  Please indicate if this has been= done.
>
> If you are an author or contributor, you must reply to this email to i= ndicate the IPR status.
>
> Ciao!
> --
> Jaime Jim=E9nez

--_000_PA4PR09MB4558A0944A4773493EAED759AA159PA4PR09MB4558eurp_-- From nobody Mon Jul 12 05:10:12 2021 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 1E2723A11D4; Mon, 12 Jul 2021 05:10:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jaime Jimenez via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Jaime Jimenez , core-chairs@ietf.org, core@ietf.org, iesg-secretary@ietf.org, jaime@iki.fi Message-ID: <162609181110.31114.9766537857598891813@ietfa.amsl.com> Date: Mon, 12 Jul 2021 05:10:11 -0700 Archived-At: Subject: [core] Publication has been requested for draft-ietf-core-senml-data-ct-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 12:10:11 -0000 Jaime Jimenez has requested publication of draft-ietf-core-senml-data-ct-04 as None on behalf of the CORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ From nobody Mon Jul 12 06:43:02 2021 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 A2CA53A1808; Mon, 12 Jul 2021 06:42:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162609737664.16568.10603150939299678746@ietfa.amsl.com> Date: Mon, 12 Jul 2021 06:42:56 -0700 Archived-At: Subject: [core] Lars Eggert's No Objection on draft-ietf-core-yang-cbor-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 13:42:57 -0000 Lars Eggert has entered the following ballot position for draft-ietf-core-yang-cbor-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Found terminology that should be reviewed for inclusivity: * Term "natively"; alternatives might be "built-in", "fundamental", "ingrained", "intrinsic", "original". See https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3.3. , paragraph 7, nit: > Section 6. The following examples shows the encoding of a 'hostname' leaf u > ^^^^^ You should probably use "show". Section 4. , paragraph 2, nit: > ta item (major type 5). A map is comprised of pairs of data items, with each > ^^^^^^^^^^^^^^^ Did you mean "comprises" or "consists of" or "is composed of"? Section 4.1. , paragraph 5, nit: > ection 3.3. The following examples shows the encoding of a 'system-state' co > ^^^^^ You should probably use "show". Section 5.2. , paragraph 7, nit: > e element -a byte string with a small number of bytes inside. For this case, > ^^^^^^^^^^^^^^^^^ Specify a number, remove phrase, use "a few", or use "some". Section 6.8. , paragraph 2, nit: > ized-key/key-data" (SID 1734) for user name "bob" and authorized-key "admin" > ^^^^^^^^^ It"s more common nowadays to write this noun as one word. Section 6.9. , paragraph 6, nit: > user" (SID 1730) corresponding to user name "jack". CBOR diagnostic notation > ^^^^^^^^^ It"s more common nowadays to write this noun as one word. Document references draft-ietf-core-sid-15, but -16 is the latest available revision. From nobody Mon Jul 12 06:47:08 2021 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 364FD3A1834; Mon, 12 Jul 2021 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=eggert.org 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 h4wIww_MCh-Y; Mon, 12 Jul 2021 06:47:01 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 07B643A1831; Mon, 12 Jul 2021 06:47:00 -0700 (PDT) Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 6569960034E; Mon, 12 Jul 2021 16:46:54 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626097614; bh=bErdf+ngoapwgJVILjtfx4JBGWlHML/Vf5RXOuPlZLk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Jehs6xjQEDH4JUEgS9ra0fzhOhsiGFEf11p+2fCndBHKfUzpiqtCNlGdPI4EjPGPg a60rtFV6reF2chJXOwVAFbmZ08bH6Qx6bAJ8GhHFgHyp5MtSFeuzGUwwbR14spOOlv WbBmgFpElFqc3hwhqYKIe1a6p8n/m2x+t23PGRhg= From: Lars Eggert Message-Id: <17194BEF-CE45-4632-A907-8048793FBC94@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_83C6FFB8-46FF-4949-9343-1AC9624C2364"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 12 Jul 2021 16:46:53 +0300 In-Reply-To: <162603506943.16768.7153415282637683513@ietfa.amsl.com> Cc: General Area Review Team , draft-ietf-core-yang-cbor.all@ietf.org, last-call@ietf.org, core@ietf.org To: Peter Yee References: <162603506943.16768.7153415282637683513@ietfa.amsl.com> X-MailScanner-ID: 6569960034E.A20A4 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] [Last-Call] Genart telechat review of draft-ietf-core-yang-cbor-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 13:47:06 -0000 --Apple-Mail=_83C6FFB8-46FF-4949-9343-1AC9624C2364 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Peter, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-7-11, at 23:24, Peter Yee via Datatracker = wrote: >=20 > Reviewer: Peter Yee > Review result: Ready >=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 wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-yang-cbor-16 > Reviewer: Peter Yee > Review Date: 2021-07-11 > IETF LC End Date: 2021-03-17 > IESG Telechat date: 2021-07-15 >=20 > Summary: All of my previous comments have been addressed and the new = material > looks fine as well. [Ready] >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: None. >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_83C6FFB8-46FF-4949-9343-1AC9624C2364 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDsR80ACgkQVLXDCb9w wVc5Tg/+LONgwOapgHwczmArv/Fn0I5AVoBLQi5Ee9vY729EVgqfpRvo6u7/I8sD VbSACR+UswaCkR+fgi5voKvFeu20L86DUJxumoOj2yt72nsg6J8f3Ly8HGSQt02n og52BhB8WCO0zN8RSFRl+NEK/pFghKwM84PxrSq+np6xltYonXHfzpVNKZR2gKoE Cjqf2M4/kfvVyeIXVvy0e9tqGsZSt4AMaG+eBdgVpt17UyPWDbpdexpihzJWSP+1 WUnpHNTwGgulQNhD7G+2+A4eqTllgrr/rrvCS7vBR849iVSu4+o5zyQIfLcPPghm wcFfVYiUjQPeuPOALhaPVMzEmnZx8WrAqx0wQ4uVH/LwDQwKclfVSqlHlE/wrYlt 1E6RY0s5dbddVK7DNaq4f/1dVADxkQ3b9Zr2UBKXwMYYi4COt0wcO/tAoATcSWaK unn9cWtkEvoS/2+8Mr/4kM66kfRrKQ9xwB1YmiyASCUcMarf+LKs3WCbZ7DPqd13 d0zEVffZLMLSp2Ryx/rC1T4eRvOOiWyU6eFdmj2gJFa4GpoBzrsq6QKF3sg3Zydz 80XQnghaoVgoQxVU+T/QLruZF7obShIds4Jlzn9RJN+8nY1X1V6n2frdPsbAWyDm xDjxVrEUuTWbNEFq8yeEZruk3M7lZv9uV1L9IRo3w9aHHm/1mwE= =eSLc -----END PGP SIGNATURE----- --Apple-Mail=_83C6FFB8-46FF-4949-9343-1AC9624C2364-- From nobody Mon Jul 12 07:06:11 2021 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 EB5773A19DC; Mon, 12 Jul 2021 07:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=eggert.org 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 L7fGIUSrY9lH; Mon, 12 Jul 2021 07:05:59 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 35BF33A19D0; Mon, 12 Jul 2021 07:05:45 -0700 (PDT) Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 4BCB560034E; Mon, 12 Jul 2021 17:05:39 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626098739; bh=Kt7rTlGf/y0pzzQQjKrPqS4Fee9daPVRSUG6L8FQyqA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=wH5V4ThsbAkRVWX1ULQpd/TXc56PoHY+WsgKCTEqmf6EmE4o2ACX/1LI6K4UsUBwI IUHo5wFUaM1sH+tf7Ws3OhgGuroM+EPrlJgN4AoWJNuCCGX2JmVR8vFRDVDIf+ciMr alVs0zu/zxZlmbvSPF2Rc8ekx0qDNVuvaNQpHSeU= From: Lars Eggert Message-Id: <3FCD1143-A5D3-4B67-AFC1-1508F7B3C7BE@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_4933D08D-EC12-4DBB-BB61-65BF4689A9D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 12 Jul 2021 17:05:38 +0300 In-Reply-To: <161591604910.2184.1526890406711267425@ietfa.amsl.com> Cc: General Area Review Team , last-call@ietf.org, draft-ietf-core-sid.all@ietf.org, core@ietf.org To: Linda Dunbar References: <161591604910.2184.1526890406711267425@ietfa.amsl.com> X-MailScanner-ID: 4BCB560034E.A4451 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] [Last-Call] Genart last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 14:06:09 -0000 --Apple-Mail=_4933D08D-EC12-4DBB-BB61-65BF4689A9D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Linda, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-3-16, at 19:34, Linda Dunbar via Datatracker = wrote: >=20 > Reviewer: Linda Dunbar > Review result: Not Ready >=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-sid-15 > Reviewer: Linda Dunbar > Review Date: 2021-03-16 > IETF LC End Date: 2021-03-17 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > This document introduces the globally unique 63-bits integers to = identify YANG > items which include data nodes, RPCs, their associated inputs/outputs, > notifications, YANG modules, submodules, and features. >=20 > Major issues: > - One of the benefits of YANG is its explicit naming and = human-understandable > notations. It will be a nightmare if all the YANG items are = represented by > integers. YANG items being represented by integers will be worse than = the TYPE > values in the TLVs. At least, the TLV types are in the context of the = protocols > and their messages. - It will be a tremendous amount of work to map = all YANG > items to globally unique integers. - YANG has been widely deployed = without the > numbering system. Which environment will need the integer = representations? Who > will validate the numbers used? How to validate the YANG modules = represented by > those "integers"? >=20 > - SID can be mistaken as Segment Identifiers (SID). Suggest using a = different > name. >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 > Best Regards, > Linda Dunbar >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_4933D08D-EC12-4DBB-BB61-65BF4689A9D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDsTDIACgkQVLXDCb9w wVeo+g//X5b41SpU4r8qKDb9BVORXZTxdORWn9U1JqgXGvHxwkIubzIS5SxzNPp1 C/dUJbxuQd5L36f6DpFG15aHmQaMsflMY8bFSu2gCjC/YLP1OG3vG1kmPJbHP92H 6mWD57Q9eSLKx82aQdxRi6Zpv5TxxB5TNAamLscUE0YJZOmNvU/kC/xr4f2WpYhm ksfmkNQG5XIIXnz4jOW/tmgQvVktcWSfAFJdWJJ/KWuCfEsOXcgngEe0QwoLl/6N FDdvP3IVgXNOyDDdIh41jNkL4Tgu8D7G8fwpMTqhUF9+b/HvBKgfPzgj+kBB+yH4 2pg6HqIS/JiDpHqih9RT94wm8l3jOa1NskyYmnxe61P1iXE5p78abOxALVLA6ZO4 Hcp3fMmgOmV13gLV3OtJyJlIhudBUBebuLPrcunTp2ug+gYrDVnPKpKGis9VyUUH 33jHWU4HBQq+XyTHbi1MtivsBlV5GbMLxKFknziMY4FSRK7pOnn5qlsQ/BJhVTTd FgK33doU+QjqNdnaf9NF7e0tPhivGi4yjZ4kI2nU3tkqXuzUgzKXeybrMGabIJfF uwXm5p7bkVpNda8xWgMx18L1kpYejqIjWdsk8bpMfpjyCo709B/ZugtV7E0xGN2W IdqQu9l2y1U7LEk2z+/8HGnoflPFOkKD+LBeEBUJa/yapMidgQw= =4wyZ -----END PGP SIGNATURE----- --Apple-Mail=_4933D08D-EC12-4DBB-BB61-65BF4689A9D4-- From nobody Mon Jul 12 08:35:32 2021 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 4F93E3A1FCD; Mon, 12 Jul 2021 08:35:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162610412226.20248.15090823864879976159@ietfa.amsl.com> Date: Mon, 12 Jul 2021 08:35:22 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-observe-multicast-notifications-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 15:35:30 -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 : Observe Notifications as CoAP Multicast Responses Authors : Marco Tiloca Rikard Höglund Christian Amsüss Francesca Palombini Filename : draft-ietf-core-observe-multicast-notifications-01.txt Pages : 77 Date : 2021-07-12 Abstract: The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe-multicast-notifications/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-observe-multicast-notifications-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-multicast-notifications-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 10:10:27 2021 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 382B23A22B2; Mon, 12 Jul 2021 10:10:25 -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: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162610982518.24456.17836994624740026153@ietfa.amsl.com> Date: Mon, 12 Jul 2021 10:10:25 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 17:10:25 -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 : Group Communication for the Constrained Application Protocol (CoAP) Authors : Esko Dijk Chonggang Wang Marco Tiloca Filename : draft-ietf-core-groupcomm-bis-04.txt Pages : 60 Date : 2021-07-12 Abstract: This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC7390, while it updates RFC7252 and RFC7641. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-groupcomm-bis-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 10:53:04 2021 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 6B2E13A24F4; Mon, 12 Jul 2021 10:52:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162611237838.21577.12509737380227780747@ietfa.amsl.com> Date: Mon, 12 Jul 2021 10:52:58 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 17:52:59 -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 : Group OSCORE - Secure Group Communication for CoAP Authors : Marco Tiloca Göran Selander Francesca Palombini John Preuss Mattsson Jiye Park Filename : draft-ietf-core-oscore-groupcomm-12.txt Pages : 97 Date : 2021-07-12 Abstract: This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-12.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 13:40:46 2021 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 322413A0CBD; Mon, 12 Jul 2021 13:40:40 -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: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162612244014.13061.12687395542923826667@ietfa.amsl.com> Date: Mon, 12 Jul 2021 13:40:40 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-href-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 20:40:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Resource Identifiers Authors : Carsten Bormann Henk Birkholz Filename : draft-ietf-core-href-05.txt Pages : 18 Date : 2021-07-12 Abstract: The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-href-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-href-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 14:43:11 2021 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 222A73A0DEA; Mon, 12 Jul 2021 14:43:09 -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: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162612618908.18742.14992885691560548725@ietfa.amsl.com> Date: Mon, 12 Jul 2021 14:43:09 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-edhoc-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 21:43:09 -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 : Combining EDHOC and OSCORE Authors : Francesca Palombini Marco Tiloca Rikard Hoeglund Stefan Hristozov Goeran Selander Filename : draft-ietf-core-oscore-edhoc-01.txt Pages : 17 Date : 2021-07-12 Abstract: This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP with the first subsequent OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-edhoc/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-edhoc-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 16:00:27 2021 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 3191E3A1684; Mon, 12 Jul 2021 16:00:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162613081317.26331.17084230218140543874@ietfa.amsl.com> Date: Mon, 12 Jul 2021 16:00:13 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 23:00:18 -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 : CoAP: Echo, Request-Tag, and Token Processing Authors : Christian Amsüss John Preuß Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-13.txt Pages : 38 Date : 2021-07-12 Abstract: This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-echo-request-tag-13.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 13 08:59:12 2021 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 870703A1981; Tue, 13 Jul 2021 08:59:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162619194652.5730.10916340155265302741@ietfa.amsl.com> Date: Tue, 13 Jul 2021 08:59:06 -0700 Archived-At: Subject: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 15:59:07 -0000 Robert Wilton has entered the following ballot position for draft-ietf-core-sid-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Thank you for this work, I believe that it likely to be useful, perhaps not only for constrained devices, it may also turn out to be popular for streaming telemetry. There are a couple of points that I would like to see discussed and perhaps addressed: (1) I would like further discussion regarding whether SIDs are bound just to the schema name, or the schema item definition. The draft states that if the definition is changed in a non-backwards-compatible (NBC) way then a new SID SHOULD be allocated. But I don't understand how this will work. Given that the .sid file would then contain exactly the same path but with different sids assigned (for every time the meaning of the definition changes), then how do consumers of the sid file know which sid to use for a given path (given that there is no indication in the .sid file)? Instead, I think that this is the wrong way to be handling NBC changes, and SIDs should be bound only to the schema path (i.e., the name of the item), and a new SID is only allocated if the name/path changes, and otherwise the same SID is used, even if the definition changes in a non-backwards-compatible way. (2) I think that this document should be clearer as to the relationship between SIDs and submodules (more details in the comment). (3) This draft makes use of the rc:yang-data extension. Was there any discussion about using "YANG Data Structure Extensions" (RFC 8791) instead, which is meant to be a cleaner formulation of the rc:yang-data extension, and without the dependency on RESTCONF? I would suggest that using RFC 8791 would be preferable if possible. (4) The policy in 7.4.2 for allocation a SID mega-range seems to aiming this towards organizations rather than individuals. The policy in 7.6 for the "IETF YANG SID Registry" requires an RFC. What is the mechanism if an individual or open source project wanted to get SIDs assigned for some of their YANG modules? I.e., should we be defining a separate mega-range, managed by IANA, with just Expert Review or Specification Required so that these modules could use SIDs allocated? Or do you envisage a separate entity taking up the responsibility for coordinating this? Regards, Rob ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Regarding the relationship between sids and submodules, I think is best summed up by this comment in the appendix: "Note that ".sid" files can only be generated for YANG modules and not for submodules." I.e., I don't think that sids should be allocated for the name of the submodule, and any items within a submodule are effectively allocated sids as part of processing the module that includes them. This topic should be addressed early in the document, and probably the existing references to submodule in the introduction and the YANG module can be removed. From nobody Tue Jul 13 10:38:53 2021 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 1DEF23A10B7; Tue, 13 Jul 2021 10:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 yVqX9OOYlrPx; Tue, 13 Jul 2021 10:38:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E887D3A10B6; Tue, 13 Jul 2021 10:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0310A38B40; Tue, 13 Jul 2021 13:41:34 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R4rgpkXy6zyg; Tue, 13 Jul 2021 13:41:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9882138B23; Tue, 13 Jul 2021 13:41:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E632451E; Tue, 13 Jul 2021 13:38:33 -0400 (EDT) From: Michael Richardson To: Robert Wilton , "The IESG" , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org In-Reply-To: <162619194652.5730.10916340155265302741@ietfa.amsl.com> References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 17:38:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Wilton via Datatracker wrote: > (1) I would like further discussion regarding whether SIDs are bound = just to > the schema name, or the schema item definition. I'm not sure I understand the question.... I guess schema name is the leaf = definition. > The draft states that if the > definition is changed in a non-backwards-compatible (NBC) way then a = new SID > SHOULD be allocated. True, I assume that this leads to a new YANG leaf name. > But I don't understand how this will work. Given that > the .sid file would then contain exactly the same path but with diffe= rent sids > assigned (for every time the meaning of the definition changes), then= how do > consumers of the sid file know which sid to use for a given path (giv= en that > there is no indication in the .sid file)? Instead, I think that this= is the > wrong way to be handling NBC changes, and SIDs should be bound only t= o the > schema path (i.e., the name of the item), and a new SID is only alloc= ated if > the name/path changes, and otherwise the same SID is used, even if the > definition changes in a non-backwards-compatible way. This is my understanding. > (3) This draft makes use of the rc:yang-data extension. Was there any > discussion about using "YANG Data Structure Extensions" (RFC 8791) in= stead, > which is meant to be a cleaner formulation of the rc:yang-data extens= ion, and > without the dependency on RESTCONF? I would suggest that using RFC 8= 791 would > be preferable if possible. I don't know of any such discussion, but I don't really understand the dist= inction. > (4) The policy in 7.4.2 for allocation a SID mega-range seems to aimi= ng this > towards organizations rather than individuals. Yes, the idea being that "Zigbee" or "IEEE" or ... would allocate a mega-ra= nge. > The policy in 7.6 for the "IETF > YANG SID Registry" requires an RFC. What is the mechanism if an indi= vidual or > open source project wanted to get SIDs assigned for some of their YAN= G modules? > I.e., should we be defining a separate mega-range, managed by IANA, w= ith just > Expert Review or Specification Required so that these modules could u= se SIDs > allocated? Or do you envisage a separate entity taking up the respon= sibility > for coordinating this? My impression was that there would be a mega-range operated outside of IANA for this (open source, non-RFC YANG module) kind of thing, but I think that the energy for doing that may have waned. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDtz5kACgkQgItw+93Q 3WXNugf+OB8IUAx5B4E5cYIdWExAbPMbvxNLyNzpiI2Aji5LjkLJKQzwWf57UykD AuGiduOELjLUW1mMuZG1XWIbosG7Vt8Q3qPnuGAYDPkxXaFXvR4AN9cu3ON5piGq 02PoRJ4FdCUOJuhUwYNuiX8pstHROjIgKOyMou1pzEZ2xgTUjKr3ktUP/bVO26Py R7Tu02oooz3ql8+unjc7fR910jRPxckT6RBr2rX0BmQA6cEUAq/jgsk6nIHk1IXM ImnbCwMaIRHa6+qOKL3KsqQgxiXP4c+nAip1wzTiDc20s0cxDN+/pbkt2FuL2EEI Wcqe/SeFhIcgRnCaLf3w3lDFDA6FgA== =Ndi4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 13 11:52:55 2021 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 2B9453A0C86; Tue, 13 Jul 2021 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Te0jURFd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GEeD480a 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 suae--dHZZ8a; Tue, 13 Jul 2021 11:52:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665883A0C84; Tue, 13 Jul 2021 11:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7566; q=dns/txt; s=iport; t=1626202365; x=1627411965; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Z9uYUzVYZdTpk4LqPneyqYnki2+6pXvhfmF+22mxL4c=; b=Te0jURFdGgyPaJi060k08QEj1aXvz9izxe5HmVzUfWB8W/qFj2xGLt7h frubv7an3vGKAcn8DMi7Ut8ip3QfO4ouHRyCSrlLPYx1bLqMV4No++HoP 0eYX76eZZaynNMWiYuobsL3svwM6nm4swRUS+evmnY5EgngO7Dn9KkfuJ E=; X-IPAS-Result: =?us-ascii?q?A0AkBACh4O1gl4kNJK1aHgEBCxIMQIFOC4FTUX5aNzGES?= =?us-ascii?q?INIA4U5iFcDmiyBLoElA1QLAQEBDQEBNwoEAQGBYIJ0AheCYAIlNQgOAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBAwESEREMA?= =?us-ascii?q?QEpDwsEAgEIEQQBAQECAiYCAgIwFQgIAgQBEggagk8BglUDDiEBDptMAYE6A?= =?us-ascii?q?oofeoEygQGCBwEBBgQEgTkCDkGDQRiCMgmBECqCe4QOgmiDeiccgUlEgRVDg?= =?us-ascii?q?mI+ggReAQECAYFfgxU2gi6DGwFnJyoBAS8xHxIHRiYBDmSUb4hsnw8KgySKM?= =?us-ascii?q?44lhXYSg2OLXJcalgaML5hUAgQCBAUCDgEBBoFdAzSBW3AVgyQJRxkOjh8MD?= =?us-ascii?q?QkVgmVUhRSFSnM4AgYBCQEBAwmHeQEB?= IronPort-PHdr: A9a23:8pJLMRJTQbuLEKz+1dmcuYUyDhhOgF28FhUc7JYqj7dHdOKo9seqM E/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB7gJfjmYig/F cIEX1Y2t32+OFJeTcD5YVCaq3au7DkUTxP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP IronPort-HdrOrdr: A9a23:yWZ/vavnkMWX29JJmVM2FUab7skC+YMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H9BEDyewKiyXcT2/heAV7CZniohILMFuFfBOTZskXd8kHFh4tgPO JbAtVD4b7LfBlHZKTBkXKF+r8bqbHtms3F9ISurUuFDzsaEZ2IhD0JbTpzZ3cGPTWucqBJcq Z0iPA3wwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnZ4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlXFtyssHfrWG1SYczHgNkHmpDp1L/sqq iLn/4UBbU315oWRBDtnfKi4Xi57N9k0Q6d9bbRuwqTnSW+fkNgNyKE7rgpLycwLCEbzYtBOe twrhKknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfRsRKEkjQpo+a07bWrHAUEcYZ 1TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYEit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tTKCXUOlZeXkbkzvdcPcb j6ISFlXF8JCjXT4Je1re52Gzj2MRCAYQg= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,237,1620691200"; d="scan'208";a="740894217" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jul 2021 18:52:19 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 16DIqJh1001399 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 13 Jul 2021 18:52:19 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 13 Jul 2021 13:52:19 -0500 Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 13 Jul 2021 13:52:18 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 13 Jul 2021 13:52:18 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y7I6Mb5rNpIxk1UwdyH2YCkYGPArTP43/0K1xXltS9hBJ43rQkjaqVwA2yhqFh29rqLiSVn2UH9mKM0NdCsQeevMi22zjOp63afA1esS9y6SbCXpelVC7pilXyZPJDdT1w6WG79/6c3IW6tj+DN97Tz2dsBX2QiIt8p/vZpJzkIdYN68IUSZ+ymG6tmv3pWANvC95YgSK4t8/QjaydlyQUpFim8RLfp7seD/+VE5rsUCnYF62RA4rV0xQ+XDYoDg9QFH6CZU4D91eW9yCpW7WyV8YFSAf6QQcRvd07uuiRxDiQmqC67PscNlvXOnjLhluDsevXU9PrQT2QetzT88HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z9uYUzVYZdTpk4LqPneyqYnki2+6pXvhfmF+22mxL4c=; b=BvX7ZCBhaKTHhD0tqQaVd/thmQtz0KoM6uvmBSMklz74MATvhf81ds87XZqMlCHq+CnHYkqeb+PAehK0kb1dNJsXXYCWb/fnbHtstEqgUIbBXb1y3q3i8JI37SmL/j5nxl+SmdnEusAnENHwspLwHprgJ0sS5DTfnG3YYBvf6oHoT49jNTlQRm/o4Z0gjgUxIiBlOA2S1xLmYptXqJUnhYfkInve54bM0BqVeH4t03PDj00Qzj2Lkgm7EHECnBc3WV10dK2YAyeGxgQVel4m3ie3z0yWp/sDFvRF/cSSOfqy6ClIZqT33ZzWDdAwcbWEWYSLoCkynxh+EtSFTBuTLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z9uYUzVYZdTpk4LqPneyqYnki2+6pXvhfmF+22mxL4c=; b=GEeD480adyMmbwgCeaSXUlJVTE9oQKd+4SaOlmrDOe1PsdRbcBTBW3UKCwRoPEcxnrqJZogRiRIiwyE9By3sUjGlNpon/zvtvsFjAYYyRHTBN6VDVwDzud/xObZcB7ZwOL1OX9rPP5qnFTF7eZKxy0Q1REMjN7fl0fxgOq3vpCc= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM4PR11MB5533.namprd11.prod.outlook.com (2603:10b6:5:38a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Tue, 13 Jul 2021 18:52:17 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.027; Tue, 13 Jul 2021 18:52:17 +0000 From: "Rob Wilton (rwilton)" To: Michael Richardson , The IESG , "draft-ietf-core-sid@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) Thread-Index: AQHXeAALE98pHaaPt0GwTNHeUw7K96tBK82AgAAPFvA= Date: Tue, 13 Jul 2021 18:52:17 +0000 Message-ID: References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> <26411.1626197913@localhost> In-Reply-To: <26411.1626197913@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 96ef437e-d712-4ecc-e68a-08d9462f567c x-ms-traffictypediagnostic: DM4PR11MB5533: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5T7Hh3iq9mNV5BCC3jH2edoL4FeQOwurtRgm8f55mVUM1H6LQvVPtXRiggsmrQQby42g55pfmzXCEaDlUGvnXjmqeRqG6hn6ugJn+QGwO1JnrrMvmB0bXZaN0hvVxhNOpaJpgz6n6giSP/43cHCHfJYMtGyGLwbDL6OhSgddyoUpHZ8jEwwTAZfIx+a2oCFNmKwwyTdp5BfAP1mFK2T5og22RchBs5LwmZTRjU/MW5gqAA9rz+u4eyzaTZm4XQYvemjnQDEf/Y+luBLeJciyju6A/uq4EZ4QAGv+gxcBtS11roI3rhh5QxukansjegW7N+9I5r/tolsDRY8xO/5U+BH3AMkxzURUQhRxqWnc0qwf7QvNKyh9tDo6E6+DgPR++XmtxxRhMoxWyGxJJXvxugaw9KOPGVPE1Rp3EWUam3CD5vJceB0mh7hgDHLWQgFS1P/6v6hCuqJoDO3UyGo0cl4/IGtpXS8TzQcCwUdRF9KAHzzBDzo6Dz2eMFXAY+glBm7oVpU8xN9G1T9PtAoECo81XOG+8zu0W6UR18XvPX/zM5sk+zFF3NTucKO6RgLjJaX4Q6c/9OgeLZ17TwH5qSVncHIZayelxER4gF5nA03co+U0yBhnBv5SVOXA83Vu0wAWZyi8KGPMibzby8pT6CVn7yhnN2UgQc0HHdFB6HwyBXbV3zIv6w5rIWvfdXFxKtQRHjR6/CNAz6RzO1n+liZzy72mV8KudH/W8G1b0E4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(396003)(136003)(39860400002)(66574015)(83380400001)(66556008)(26005)(5660300002)(8936002)(316002)(66476007)(33656002)(966005)(9686003)(186003)(110136005)(76116006)(64756008)(122000001)(38100700002)(52536014)(71200400001)(53546011)(6506007)(66446008)(7696005)(2906002)(86362001)(478600001)(8676002)(55016002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?STYzZTlaWmJkelp0Um42ZE5Tb1hPaUdFdUVYR1lSaGIyaE4vMTNQNE1DcFhw?= =?utf-8?B?c2N1bmhHUkZzby96cmtNOGVWV1JhWnBLNWZFbDdrYUk2MmRPSmZVV3RNejNx?= =?utf-8?B?c1d4MVowZmtzSWhxYXdBanhHekFJRTdPbURaT2x2M1E5RTl1MjRDaGpkSnY2?= =?utf-8?B?ZE5ZdTQwbmRXYVJTV1pUbnFYYmFMUXVzNkFudVBsd1BEWkFuY2RDOHdFZk81?= =?utf-8?B?ZStyQ2Nwc2ZoSDVJdTdNd2wrVDZnS3I0QlIzR081b0ptY1MwT3Z3U1pYSlEx?= =?utf-8?B?WWlWQ3hCVXRMRFBYZlM4TE5Dd2dIYy9iSDlZditzMllqNURYL1dwVllTdmtq?= =?utf-8?B?Z1JBeDhwQitmOXBMSUloemFhMEVsOW51Ni9oOUxhMU5EOGMzRTJkZnhrSmQ3?= =?utf-8?B?bUZBT0FSYVpudTdIaHd5QkRtY1psOGxqNDhmb0dlRk5tNDZSK0Y1WjJheTZ2?= =?utf-8?B?ZUZUcU9NZTI4UjJObDVOa3hpSmp6MnAveWhvU1BJMWQwQ1BxT0UvVTl6dGF0?= =?utf-8?B?OGZ4aldRbDlheWlYWFlEU1g1TTVvYVpJUXhqbzR4L0NOL1M4K2tEaUtTS1Nz?= =?utf-8?B?MUYvVVdWOGxlUzVJQ01odDNNT0JYNnhlNGQyYzBrUytZNTczbjFEN24yWm1G?= =?utf-8?B?NFd6WWJZK0VtWSt4L0czNWxmNXpacllGbDRGMjNJOTZNeHVDUkUySElWQUdi?= =?utf-8?B?ZDRxZGVpdStwS1FZK2tLem0rejhndE5RcnFHTC9RUUZuTm1Jd3lvejliWkND?= =?utf-8?B?SzhYY0NqVUN6ZVozaWNqYkQwSURRMHRQK1ZWdEYwd29YNlNocmNsVWYyNk5w?= =?utf-8?B?bVFZSnlVOUZreE1TYjNGVmRETGdLdHp1ZlBWeENVeklGYUs4bUhjdC9nQTB6?= =?utf-8?B?S3BScUZGdDNqWTFleVZLWFV1R0s2RXdjYmRGUzJKYXliU282bVhjSEtqeURh?= =?utf-8?B?aWowU2RpRFpWcEZvbDhtTGNVOVV6ZU5pRllhR2YrcUlIbnV1cU50aGRwTk1j?= =?utf-8?B?dWFrTGwyVU5mYVRETE1lelFYeStuV2lXcW1peUdTb05VOUpLdi9xY3RkUWZE?= =?utf-8?B?bFR6ajc2aGlMUmVzdE9pS21xbDFnMDhNOXUycWJCakdiNHl5U1d6bEpGQlgx?= =?utf-8?B?c1hzcWJwSVY3cjhzZWNkL1pnc2RJWWY3S3VudGFmSHlOTlVEN1NadWpIN2t5?= =?utf-8?B?U3hTaXlaQ2lOSFJud0N0SHlCMGl6RUl6b0VjQ0plOXJBTy9Vc3VSc3FqTTVV?= =?utf-8?B?VlI1RE8xZEgxeEZuZnFqWXR2dnhSMEV0eEUyQ2kzaEZVaW41T1FWSW1mb0dz?= =?utf-8?B?UVM2K1ZpVTBOK3UrZXRFT2gyMTBISDFXQzBjaG9lZ3F2L3VkUlZvUjg2NG1x?= =?utf-8?B?S2lBUW9sYnBCL3Vyc3dtWmgxNmgrYnVtY2t5cVJWL3NzcmhKR3pWcGJqakp3?= =?utf-8?B?MXZtYXNiUG1SSHdpTitJNW5VK01GUERIa2ZSNnZlY3Mvbyt5VkQrOWJEL1Vl?= =?utf-8?B?ZW5lcm9mSFo5NnUwUzNMblpDeldENkRaL3lxZXFLN1lHRWVHQkE4MTBpWFVz?= =?utf-8?B?ZG9Hc2c5WUhnVjA5ZnlvalpabWRNayt3R0tNS01TdVZVUjZrRm55Snl5Q3l0?= =?utf-8?B?UTNuSVNzdkh3ZDlxV0kvYXloTDNnUjJNQm9OWi9kSHEwR01UYzBraHA3WXBG?= =?utf-8?B?UmJJVkkrVWI5N0FRSURhbWVUT2tFdE9BZHpHbThGQjV5N1FYT0hlQnZCL3d2?= =?utf-8?Q?nwVO8F9YtM/3oQEZcoTKxFBDe6dDQxQN2Ugs1iS?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96ef437e-d712-4ecc-e68a-08d9462f567c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 18:52:17.7352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Tdhmi3+ktSJIV12AkJhe3db1e+lhYCT5IilnXW0P8y2GoVvzDcQY6yprUOV9oCGSGJXAxNJARkk2vbUB4T/lbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5533 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 18:52:51 -0000 SGkgTWljaGFlbCwNCg0KVGhhbmtzLiAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQo+IFNlbnQ6IDEzIEp1bHkgMjAyMSAxODoz OQ0KPiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+Ow0KPiBkcmFmdC1pZXRmLWNvcmUtc2lkQGlldGYub3JnOyBjb3Jl LWNoYWlyc0BpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIFJv YmVydCBXaWx0b24ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1zaWQtMTY6ICh3aXRoDQo+ IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiANCj4gUm9iZXJ0IFdpbHRvbiB2aWEgRGF0YXRy YWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiAgICAgPiAoMSkgSSB3b3VsZCBsaWtl IGZ1cnRoZXIgZGlzY3Vzc2lvbiByZWdhcmRpbmcgd2hldGhlciBTSURzIGFyZSBib3VuZCBqdXN0 DQo+IHRvDQo+ICAgICA+IHRoZSBzY2hlbWEgbmFtZSwgb3IgdGhlIHNjaGVtYSBpdGVtIGRlZmlu aXRpb24uDQo+IA0KPiBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbi4uLi4g SSBndWVzcyBzY2hlbWEgbmFtZSBpcyB0aGUgbGVhZg0KPiBkZWZpbml0aW9uLg0KDQpUaGUgc2No ZW1hIG5hbWUgKG9yIHBhdGgpLCBpcyBqdXN0IHRoZSBsb2NhdGlvbiB0byBhIGRhdGEgaXRlbSBk ZWZpbml0aW9uIChlLmcuLCBmb28pLg0KDQplLmcuLA0KbGVhZiBmb28gew0KICB0eXBlIHN0cmlu ZyB7DQogICAgbGVuICIxLi4xMCI7DQogIH0NCn0NCg0KVGhlIGRlZmluaXRpb24gb2YgZm9vIGNv dWxkIGNoYW5nZSwgd2l0aG91dCBjaGFuZ2luZyB0aGUgbmFtZS4gIEUuZy4sIGEgYmFja3dhcmRz LWNvbXBhdGlibGUgY2hhbmdlOg0KDQpsZWFmIGZvbyB7DQogIHR5cGUgc3RyaW5nIHsNCiAgICBs ZW4gIjEuLjIwIjsNCiAgfQ0KfQ0KDQpPciB0aGUgZGVmaW5pdGlvbiBvZiBmb28gY291bGQgY2hh bmdlIGluIGEgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIHdheS4gIEUuZy4sDQoNCmxlYWYgZm9v IHsNCiAgdHlwZSBpbnQzMjsNCn0NCg0KIFJGQyA3OTUwIGJhc2ljYWxseSBzdGF0ZXMgdGhhdCB0 aGlzIGlzIG5vdCBhbGxvd2VkLCBidXQgdGhlc2Ugc29ydHMgb2YgY2hhbmdlcyBoYXBwZW5zIGFu eXdheSAoZS5nLiwgdmVuZG9ycyBmaXhpbmcgYnVncywgb3IgYnVncyBpbiBzdGFuZGFyZCBZQU5H IG1vZGVscyksIGFuZCB0aGUgWUFORyB2ZXJzaW9uaW5nIHdvcmsgd2lsbCBhbGxvdyB0aGVzZSBz b3J0cyBvZiBjaGFuZ2VzIHdpdGggYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMuICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kdWxl LXZlcnNpb25pbmctMDMNCg0KQnV0IGluIGFsbCB0aGVzZSBjYXNlcywgbm8gbmV3IFNJRCBzaG91 bGQgYmUgYWxsb2NhdGVkLCBvciBvdGhlcndpc2UgeW91IHdpbGwgaGF2ZSB0d28gU0lEcyBhc3Np Z25lZCB0byB0aGUgc2FtZSBuYW1lL3BhdGguDQoNCg0KPiANCj4gICAgID4gVGhlIGRyYWZ0IHN0 YXRlcyB0aGF0IGlmIHRoZQ0KPiAgICAgPiBkZWZpbml0aW9uIGlzIGNoYW5nZWQgaW4gYSBub24t YmFja3dhcmRzLWNvbXBhdGlibGUgKE5CQykgd2F5IHRoZW4gYQ0KPiBuZXcgU0lEDQo+ICAgICA+ IFNIT1VMRCBiZSBhbGxvY2F0ZWQuDQo+IA0KPiBUcnVlLCBJIGFzc3VtZSB0aGF0IHRoaXMgbGVh ZHMgdG8gYSBuZXcgWUFORyBsZWFmIG5hbWUuDQoNCk9ubHkgaWYgdGhlIGF1dGhvciBnaXZlcyB0 aGUgZGVmaW5pdGlvbiBhIG5ldyBuYW1lLCBhbmQgZnJvbSBhIFNJRCBhbGxvY2F0aW9uIFBPViwg dGhpcyBpcyBqdXN0IGEgbmV3IGl0ZW0gbmFtZSBpbiB0aGUgc2NoZW1hLCBhbmQgaGVuY2UgbmVl ZHMgYSBuZXcgU0lELiAgSS5lLiwgdGhlIGFsbG9jYXRpb24gb2YgYSBuZXcgU0lEIGlzIHJlbGF0 ZWQgdG8gYSBuZXcgaXRlbSBuYW1lLCBub3QgYmVjYXVzZSBvZiBjaGFuZ2VzIGluIGEgZGVmaW5p dGlvbi4NCg0KPiANCj4gICAgID4gQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhpcyB3aWxs IHdvcmsuICBHaXZlbiB0aGF0DQo+ICAgICA+IHRoZSAuc2lkIGZpbGUgd291bGQgdGhlbiBjb250 YWluIGV4YWN0bHkgdGhlIHNhbWUgcGF0aCBidXQgd2l0aCBkaWZmZXJlbnQNCj4gc2lkcw0KPiAg ICAgPiBhc3NpZ25lZCAoZm9yIGV2ZXJ5IHRpbWUgdGhlIG1lYW5pbmcgb2YgdGhlIGRlZmluaXRp b24gY2hhbmdlcyksIHRoZW4NCj4gaG93IGRvDQo+ICAgICA+IGNvbnN1bWVycyBvZiB0aGUgc2lk IGZpbGUga25vdyB3aGljaCBzaWQgdG8gdXNlIGZvciBhIGdpdmVuIHBhdGggKGdpdmVuDQo+IHRo YXQNCj4gICAgID4gdGhlcmUgaXMgbm8gaW5kaWNhdGlvbiBpbiB0aGUgLnNpZCBmaWxlKT8gIElu c3RlYWQsIEkgdGhpbmsgdGhhdCB0aGlzIGlzIHRoZQ0KPiAgICAgPiB3cm9uZyB3YXkgdG8gYmUg aGFuZGxpbmcgTkJDIGNoYW5nZXMsIGFuZCBTSURzIHNob3VsZCBiZSBib3VuZCBvbmx5DQo+IHRv IHRoZQ0KPiAgICAgPiBzY2hlbWEgcGF0aCAoaS5lLiwgdGhlIG5hbWUgb2YgdGhlIGl0ZW0pLCBh bmQgYSBuZXcgU0lEIGlzIG9ubHkgYWxsb2NhdGVkDQo+IGlmDQo+ICAgICA+IHRoZSBuYW1lL3Bh dGggY2hhbmdlcywgYW5kIG90aGVyd2lzZSB0aGUgc2FtZSBTSUQgaXMgdXNlZCwgZXZlbiBpZiB0 aGUNCj4gICAgID4gZGVmaW5pdGlvbiBjaGFuZ2VzIGluIGEgbm9uLWJhY2t3YXJkcy1jb21wYXRp YmxlIHdheS4NCj4gDQo+IFRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZy4NCg0KT2theSwgSSB0aGlu ayB0aGF0IHRoZSB0ZXh0IHRoYXQgZGVzY3JpYmVzIHRoaXMgbmVlZCB0byBiZSB0d2Vha2VkLg0K DQoNCj4gDQo+ICAgICA+ICgzKSBUaGlzIGRyYWZ0IG1ha2VzIHVzZSBvZiB0aGUgcmM6eWFuZy1k YXRhIGV4dGVuc2lvbi4gIFdhcyB0aGVyZSBhbnkNCj4gICAgID4gZGlzY3Vzc2lvbiBhYm91dCB1 c2luZyAiWUFORyBEYXRhIFN0cnVjdHVyZSBFeHRlbnNpb25zIiAoUkZDIDg3OTEpDQo+IGluc3Rl YWQsDQo+ICAgICA+IHdoaWNoIGlzIG1lYW50IHRvIGJlIGEgY2xlYW5lciBmb3JtdWxhdGlvbiBv ZiB0aGUgcmM6eWFuZy1kYXRhIGV4dGVuc2lvbiwNCj4gYW5kDQo+ICAgICA+IHdpdGhvdXQgdGhl IGRlcGVuZGVuY3kgb24gUkVTVENPTkY/ICBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB1c2luZyBSRkMN Cj4gODc5MSB3b3VsZA0KPiAgICAgPiBiZSBwcmVmZXJhYmxlIGlmIHBvc3NpYmxlLg0KPiANCj4g SSBkb24ndCBrbm93IG9mIGFueSBzdWNoIGRpc2N1c3Npb24sIGJ1dCBJIGRvbid0IHJlYWxseSB1 bmRlcnN0YW5kIHRoZQ0KPiBkaXN0aW5jdGlvbi4NCg0KVGhlIG5ldyBSRkMgaXMgZWZmZWN0aXZl bHkgdGhlICJwcm9wZXIiIHdheSB0byBkbyBhY2hpZXZpbmcgdGhpcy4NCg0KSSB0aGluayB0aGF0 IGlzIG1heSBiZSBhcyBzaW1wbGUgYXMgY2hhbmdpbmc6DQoNCiAgICAgaW1wb3J0IGlldGYtcmVz dGNvbmYgew0KICAgICAgIHByZWZpeCByYzsNCiAgICAgICByZWZlcmVuY2UgIlJGQyA4MDQwOiBS RVNUQ09ORiBQcm90b2NvbC4iOw0KICAgICB9DQoNCiAgICAgcmM6eWFuZy1kYXRhIHNpZC1maWxl IHsNCiAgICAgICAgIHVzZXMgc2lkLWZpbGU7DQogICAgIH0NCg0KdG8NCg0KICAgICBpbXBvcnQg aWV0Zi15YW5nLXN0cnVjdHVyZS1leHQgew0KICAgICAgIHByZWZpeCBzeDsNCiAgICAgfQ0KDQog ICAgICBzeDpzdHJ1Y3R1cmUgc2lkLWZpbGUgew0KICAgICAgICAgdXNlcyBzaWQtZmlsZTsNCiAg ICAgfQ0KDQoNCg0KDQo+IA0KPiAgICAgPiAoNCkgVGhlIHBvbGljeSBpbiA3LjQuMiBmb3IgYWxs b2NhdGlvbiBhIFNJRCBtZWdhLXJhbmdlIHNlZW1zIHRvIGFpbWluZw0KPiB0aGlzDQo+ICAgICA+ IHRvd2FyZHMgb3JnYW5pemF0aW9ucyByYXRoZXIgdGhhbiBpbmRpdmlkdWFscy4NCj4gDQo+IFll cywgdGhlIGlkZWEgYmVpbmcgdGhhdCAiWmlnYmVlIiBvciAiSUVFRSIgb3IgLi4uIHdvdWxkIGFs bG9jYXRlIGEgbWVnYS1yYW5nZS4NCg0KWWVzLg0KDQo+IA0KPiAgICAgPiBUaGUgcG9saWN5IGlu IDcuNiBmb3IgdGhlICJJRVRGDQo+ICAgICA+IFlBTkcgU0lEIFJlZ2lzdHJ5IiByZXF1aXJlcyBh biBSRkMuICBXaGF0IGlzIHRoZSBtZWNoYW5pc20gaWYgYW4NCj4gaW5kaXZpZHVhbCBvcg0KPiAg ICAgPiBvcGVuIHNvdXJjZSBwcm9qZWN0IHdhbnRlZCB0byBnZXQgU0lEcyBhc3NpZ25lZCBmb3Ig c29tZSBvZiB0aGVpciBZQU5HDQo+IG1vZHVsZXM/DQo+IA0KPiAgICAgPiBJLmUuLCBzaG91bGQg d2UgYmUgZGVmaW5pbmcgYSBzZXBhcmF0ZSBtZWdhLXJhbmdlLCBtYW5hZ2VkIGJ5IElBTkEsDQo+ IHdpdGgganVzdA0KPiAgICAgPiBFeHBlcnQgUmV2aWV3IG9yIFNwZWNpZmljYXRpb24gUmVxdWly ZWQgc28gdGhhdCB0aGVzZSBtb2R1bGVzIGNvdWxkIHVzZQ0KPiBTSURzDQo+ICAgICA+IGFsbG9j YXRlZD8gIE9yIGRvIHlvdSBlbnZpc2FnZSBhIHNlcGFyYXRlIGVudGl0eSB0YWtpbmcgdXAgdGhl DQo+IHJlc3BvbnNpYmlsaXR5DQo+ICAgICA+IGZvciBjb29yZGluYXRpbmcgdGhpcz8NCj4gDQo+ IE15IGltcHJlc3Npb24gd2FzIHRoYXQgdGhlcmUgd291bGQgYmUgYSBtZWdhLXJhbmdlIG9wZXJh dGVkIG91dHNpZGUgb2YNCj4gSUFOQQ0KPiBmb3IgdGhpcyAob3BlbiBzb3VyY2UsIG5vbi1SRkMg WUFORyBtb2R1bGUpIGtpbmQgb2YgdGhpbmcsIGJ1dCBJIHRoaW5rIHRoYXQNCj4gdGhlIGVuZXJn eSBmb3IgZG9pbmcgdGhhdCBtYXkgaGF2ZSB3YW5lZC4NCg0KT2theS4gIElmIHRoZXJlIGlzIGEg bGFjayBvZiBlbmVyZ3kgdGhlcmUsIGRvIHlvdSB0aGluayB0aGF0IHRoaXMgaXMgc29tZXRoaW5n IHRoYXQgd2Ugc2hvdWxkIGJlIGFza2luZyBJQU5BIHRvIG1hbmFnZSAoaS5lLiwgaGF2ZSB0aGlz IGRyYWZ0IHNlcGFyYXRlIGEgc2VwYXJhdGUgbWVnYS1yYW5nZSBmb3IgdGhlc2Ugb3RoZXIgbW9k dWxlcyk/DQoNClRoYW5rcywNClJvYg0KDQoNCj4gDQo+IC0tDQo+IF0gICAgICAgICAgICAgICBO ZXZlciB0ZWxsIG1lIHRoZSBvZGRzISAgICAgICAgICAgICAgICAgfCBpcHY2IG1lc2ggbmV0d29y a3MgWw0KPiBdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3Mg ICAgICAgIHwgICAgSW9UIGFyY2hpdGVjdCAgIFsNCj4gXSAgICAgbWNyQHNhbmRlbG1hbi5jYSAg aHR0cDovL3d3dy5zYW5kZWxtYW4uY2EvICAgICAgICB8ICAgcnVieSBvbiByYWlscyAgICBbDQo+ IA0KPiANCj4gLS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQo+ICAgICAgICAgICAgU2FuZGVsbWFu IFNvZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCj4gDQo+IA0KPiANCg0K From nobody Tue Jul 13 12:00:56 2021 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 9E1793A0DFC; Tue, 13 Jul 2021 12:00:42 -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, SPF_HELO_NONE=0.001, 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 kEf9QAnLzxLT; Tue, 13 Jul 2021 12:00:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC993A0E9F; Tue, 13 Jul 2021 12:00:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 03FF138B2F; Tue, 13 Jul 2021 15:03:24 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 70k0OWVYUq70; Tue, 13 Jul 2021 15:03:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3B38638B2D; Tue, 13 Jul 2021 15:03:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 406A949D; Tue, 13 Jul 2021 15:00:24 -0400 (EDT) From: Michael Richardson To: "Rob Wilton \(rwilton\)" , The IESG , "draft-ietf-core-sid\@ietf.org" , "core-chairs\@ietf.org" , "core\@ietf.org" In-Reply-To: References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> <26411.1626197913@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 19:00:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rob Wilton (rwilton) wrote: > leaf foo { > type string { > len "1..20"; > } > } > Or the definition of foo could change in a non-backwards-compatible w= ay. E.g., > leaf foo { > type int32; > } > RFC 7950 basically states that this is not allowed, but these sorts of > changes happens anyway (e.g., vendors fixing bugs, or bugs in standard > YANG models), and the YANG versioning work will allow these sorts of > changes with appropriate mitigations. > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-v= ersioning-03 > But in all these cases, no new SID should be allocated, or otherwise > you will have two SIDs assigned to the same name/path. Encoding towards CBOR, the CBOR wouldn't care that much about the change in type, as the CBOR is self-describing in that way. So maybe it's okay if a new SID is not allocated. Where it would be a problem is if the change was from a 1-based count to a 0-based count, both encoded as integers. In that case, I really hope it would go from "foo" to "foo-0" or something like that. >> > The draft states that if the >> > definition is changed in a non-backwards-compatible (NBC) way then= a >> > new SID >> > SHOULD be allocated. >> >> True, I assume that this leads to a new YANG leaf name. > Only if the author gives the definition a new name, and from a SID > allocation POV, this is just a new item name in the schema, and hence > needs a new SID. I.e., the allocation of a new SID is related to a n= ew > item name, not because of changes in a definition. I agree that we have a problem enforcing at the pyang sid generation place that non-backwards compatible changes need new SIDs. That sounds like a tooling improvement, rather than a bug in the spec. >> > The policy in 7.6 for the "IETF >> > YANG SID Registry" requires an RFC. What is the mechanism if an >> > individual or >> > open source project wanted to get SIDs assigned for some of their = YANG >> > modules? >> >> > I.e., should we be defining a separate mega-range, managed by IANA, >> > with just >> > Expert Review or Specification Required so that these modules coul= d use >> > SIDs >> > allocated? Or do you envisage a separate entity taking up the >> > responsibility >> > for coordinating this? >> >> My impression was that there would be a mega-range operated outside = of >> IANA >> for this (open source, non-RFC YANG module) kind of thing, but I thi= nk that >> the energy for doing that may have waned. > Okay. If there is a lack of energy there, do you think that this is > something that we should be asking IANA to manage (i.e., have this > draft separate a separate mega-range for these other modules)? So, we should have a second mega-range allocation, with a FCFS considerations. I would be in favour of that. (It could also happen in a new document or via some other IESG action.) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDt4scACgkQgItw+93Q 3WUV2wf/ZL9e/Gf6SZPhX6eURT6hQs9Om4n2fm2YxMB5VZZKf060OEHgj8XYMxRw XOLY9RoD/edovMt6CJlUxOrCGBr52L6pq71IXw1T5iTwwe+bB9clFZxKNoQKHMpq W4eqTE4usoXTN235LfA66fJY1RBiWJC8Y5wpvL+l7MWHLubgMCw5tj78fBZgJQEI LegludjV+w58j5EgbJgV4VHZICzeMmFn+m8ryloxRQxrClyJywWLk9ndq5PV1Bad 8pyy7infVf/QLN0t6+s6Vdp30K13lZiFVX3XlEONsiwLYD6xZlgGvapAFKRn4zcf Mn4mQShjWk4l/785FEFsmdlSkOD/sw== =FVrB -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 13 12:15:00 2021 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 5F7053A0F49 for ; Tue, 13 Jul 2021 12:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M_dcq7FZloY for ; Tue, 13 Jul 2021 12:14:53 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 19AE73A0F41 for ; Tue, 13 Jul 2021 12:14:52 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id a18so31588991ljk.6 for ; Tue, 13 Jul 2021 12:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jxR1HBlu6JjH6FoCbYA6ZZbpb/YlOUqu1YvcAr9/bLc=; b=AUMB6OWYaJIFQ6H6iVfZU72wHbIs4ltt31X8l/m+LekyMHEaeFpMnEfcXknNw4kT6+ yVhM+SlmY/FkS3DFc/bMknNT+If+B3nMnHf6J1K7z/TIXh6I1ZeQA00/C5iZQRsiwEyq OamGC8clcoCy/rrZB7mBzpl8M1PWxISLvg6UcGtri1o2WjbgYu2GcEcOW3gKll0rIwEj 7wfN+iF8zZlgSgZ0/Ovhf5gn5agh/TDrlGHie8EKWa/QgyNxndbPA47+7QIg/TQwCCbc XFSeEBsnsTafWYcb9yotObKrL1ePS6DsU0Mq7N3yLjbKQYjqsTuYQAZkAnZVUPkSMR3x 4g4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jxR1HBlu6JjH6FoCbYA6ZZbpb/YlOUqu1YvcAr9/bLc=; b=HUqFCnvdtGOj/g/AZG8uUZhdV0cqjCFUL2pqGxjlBKd+M4meeMODwKO1Vmtl5FUbEr 4P9b9g3sbZlLcqv+tyUj6qNUrARgyKOWzc5kEYotTu3xpoOQx3kXQ0u6eB/nw4iVM8wK X4Wgqz6cDXioAG6cW50vBgVoXSen1tc/CQnTp0prBVSQociN9MAgXI3TdquHcjYuD55l Phoa5c+UNau2Rdf0tORutGaQ5uNrVSwUSaYgbA/SEKkEpSMdgAzmKtITGuZxBF6MRtoV N67e48h8IcZ7OEyBWQDq/diWBQpT2BcK3dqo028pG8sPCZGJbgL7FKWxVygblLjrtevl c9xw== X-Gm-Message-State: AOAM531v3kCWmdtYIvnX60erKBBafPHG5rz7KnBSQV/PZK+tzkqkklHD NsxSr5Yl9GP8Crvxe68axeUhBG8qUPkjnamIe6wcgQ== X-Google-Smtp-Source: ABdhPJyd3rpeOBRMQujn2iMMw1uSaXClE8p0UrMJDDskIVtC8esP7FXS0xl8PsXCUPomj/wSgIKEABKgK2/gH1v3Gg8= X-Received: by 2002:a2e:a546:: with SMTP id e6mr3547874ljn.43.1626203690033; Tue, 13 Jul 2021 12:14:50 -0700 (PDT) MIME-Version: 1.0 References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> <26411.1626197913@localhost> In-Reply-To: From: Andy Bierman Date: Tue, 13 Jul 2021 12:14:39 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Michael Richardson , The IESG , "draft-ietf-core-sid@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046f96d05c7060ddc" Archived-At: Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 19:14:59 -0000 --00000000000046f96d05c7060ddc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2021 at 11:53 AM Rob Wilton (rwilton) wrote: > Hi Michael, > > Thanks. Please see inline. > > > -----Original Message----- > > From: iesg On Behalf Of Michael Richardson > > Sent: 13 July 2021 18:39 > > To: Rob Wilton (rwilton) ; The IESG ; > > draft-ietf-core-sid@ietf.org; core-chairs@ietf.org; core@ietf.org > > Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: > (with > > DISCUSS and COMMENT) > > > > > > Robert Wilton via Datatracker wrote: > > > (1) I would like further discussion regarding whether SIDs are > bound just > > to > > > the schema name, or the schema item definition. > > > > I'm not sure I understand the question.... I guess schema name is the > leaf > > definition. > > The schema name (or path), is just the location to a data item definition > (e.g., foo). > > e.g., > leaf foo { > type string { > len "1..10"; > } > } > > The definition of foo could change, without changing the name. E.g., a > backwards-compatible change: > > leaf foo { > type string { > len "1..20"; > } > } > > Or the definition of foo could change in a non-backwards-compatible way. > E.g., > > leaf foo { > type int32; > } > > RFC 7950 basically states that this is not allowed, but these sorts of > changes happens anyway (e.g., vendors fixing bugs, or bugs in standard YA= NG > models), and the YANG versioning work will allow these sorts of changes > with appropriate mitigations. > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versi= oning-03 > > But in all these cases, no new SID should be allocated, or otherwise you > will have two SIDs assigned to the same name/path. > > The "item" list is a bit odd because the namespaces (module, identity, feature, data) do not exactly align with the YANG terminology. The draft should specify what happens if the namespace changes. It seems a new SID is needed and the old entry (different namespace) becomes obsolete. list item { key "namespace identifier"; unique "sid"; A SID is bound to the {namespace, identifier} tuple. The type of data node (e.g. container vs. leaf) does not impact this mapping. The data type (e.g. string vs int32) does not affect this mapping. Andy > > > > > The draft states that if the > > > definition is changed in a non-backwards-compatible (NBC) way the= n > a > > new SID > > > SHOULD be allocated. > > > > True, I assume that this leads to a new YANG leaf name. > > Only if the author gives the definition a new name, and from a SID > allocation POV, this is just a new item name in the schema, and hence nee= ds > a new SID. I.e., the allocation of a new SID is related to a new item > name, not because of changes in a definition. > > > > > > But I don't understand how this will work. Given that > > > the .sid file would then contain exactly the same path but with > different > > sids > > > assigned (for every time the meaning of the definition changes), > then > > how do > > > consumers of the sid file know which sid to use for a given path > (given > > that > > > there is no indication in the .sid file)? Instead, I think that > this is the > > > wrong way to be handling NBC changes, and SIDs should be bound on= ly > > to the > > > schema path (i.e., the name of the item), and a new SID is only > allocated > > if > > > the name/path changes, and otherwise the same SID is used, even i= f > the > > > definition changes in a non-backwards-compatible way. > > > > This is my understanding. > > Okay, I think that the text that describes this need to be tweaked. > > > > > > > (3) This draft makes use of the rc:yang-data extension. Was ther= e > any > > > discussion about using "YANG Data Structure Extensions" (RFC 8791= ) > > instead, > > > which is meant to be a cleaner formulation of the rc:yang-data > extension, > > and > > > without the dependency on RESTCONF? I would suggest that using R= FC > > 8791 would > > > be preferable if possible. > > > > I don't know of any such discussion, but I don't really understand the > > distinction. > > The new RFC is effectively the "proper" way to do achieving this. > > I think that is may be as simple as changing: > > import ietf-restconf { > prefix rc; > reference "RFC 8040: RESTCONF Protocol."; > } > > rc:yang-data sid-file { > uses sid-file; > } > > to > > import ietf-yang-structure-ext { > prefix sx; > } > > sx:structure sid-file { > uses sid-file; > } > > > > > > > > > (4) The policy in 7.4.2 for allocation a SID mega-range seems to > aiming > > this > > > towards organizations rather than individuals. > > > > Yes, the idea being that "Zigbee" or "IEEE" or ... would allocate a > mega-range. > > Yes. > > > > > > The policy in 7.6 for the "IETF > > > YANG SID Registry" requires an RFC. What is the mechanism if an > > individual or > > > open source project wanted to get SIDs assigned for some of their > YANG > > modules? > > > > > I.e., should we be defining a separate mega-range, managed by IAN= A, > > with just > > > Expert Review or Specification Required so that these modules > could use > > SIDs > > > allocated? Or do you envisage a separate entity taking up the > > responsibility > > > for coordinating this? > > > > My impression was that there would be a mega-range operated outside of > > IANA > > for this (open source, non-RFC YANG module) kind of thing, but I think > that > > the energy for doing that may have waned. > > Okay. If there is a lack of energy there, do you think that this is > something that we should be asking IANA to manage (i.e., have this draft > separate a separate mega-range for these other modules)? > > Thanks, > Rob > > > > > > -- > > ] Never tell me the odds! | ipv6 mesh > networks [ > > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > > -- > > Michael Richardson . o O ( IPv6 I=C3=B8T > consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000046f96d05c7060ddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 13, 2021 at 11:53 AM Rob = Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Michael,

Thanks.=C2=A0 Please see inline.

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: 13 July 2021 18:39
> To: Rob Wilton (rwilton) <rwilton@cisco.com>; The IESG <iesg@ietf.org>;
> draf= t-ietf-core-sid@ietf.org; core-chairs@ietf.org; core@ietf.org
> Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid= -16: (with
> DISCUSS and COMMENT)
>
>
> Robert Wilton via Datatracker <noreply@ietf.org> wrote:
>=C2=A0 =C2=A0 =C2=A0> (1) I would like further discussion regarding = whether SIDs are bound just
> to
>=C2=A0 =C2=A0 =C2=A0> the schema name, or the schema item definition= .
>
> I'm not sure I understand the question.... I guess schema name is = the leaf
> definition.

The schema name (or path), is just the location to a data item definition (= e.g., foo).

e.g.,
leaf foo {
=C2=A0 type string {
=C2=A0 =C2=A0 len "1..10";
=C2=A0 }
}

The definition of foo could change, without changing the name.=C2=A0 E.g., = a backwards-compatible change:

leaf foo {
=C2=A0 type string {
=C2=A0 =C2=A0 len "1..20";
=C2=A0 }
}

Or the definition of foo could change in a non-backwards-compatible way.=C2= =A0 E.g.,

leaf foo {
=C2=A0 type int32;
}

=C2=A0RFC 7950 basically states that this is not allowed, but these sorts o= f changes happens anyway (e.g., vendors fixing bugs, or bugs in standard YA= NG models), and the YANG versioning work will allow these sorts of changes = with appropriate mitigations.=C2=A0 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-ya= ng-module-versioning-03

But in all these cases, no new SID should be allocated, or otherwise you wi= ll have two SIDs assigned to the same name/path.



The "item" li= st is a bit odd because the namespaces (module, identity, feature, data)
do not exactly align with the YANG terminology.=C2=A0 The draft sho= uld specify what happens
if the namespace changes. It seems a new= SID is needed and the old entry (different namespace)
becomes ob= solete.


   list item {
        key "namespace identifier";
        unique "sid";


A SID is bound to the {namespace, identifier} tuple.
The type = of data node (e.g. container vs. leaf) does not impact this mapping.
<= div>The data type (e.g. string vs int32) does not affect this mapping.


Andy


>
>=C2=A0 =C2=A0 =C2=A0> The draft states that if the
>=C2=A0 =C2=A0 =C2=A0> definition is changed in a non-backwards-compa= tible (NBC) way then a
> new SID
>=C2=A0 =C2=A0 =C2=A0> SHOULD be allocated.
>
> True, I assume that this leads to a new YANG leaf name.

Only if the author gives the definition a new name, and from a SID allocati= on POV, this is just a new item name in the schema, and hence needs a new S= ID.=C2=A0 I.e., the allocation of a new SID is related to a new item name, = not because of changes in a definition.

>
>=C2=A0 =C2=A0 =C2=A0> But I don't understand how this will work.= =C2=A0 Given that
>=C2=A0 =C2=A0 =C2=A0> the .sid file would then contain exactly the s= ame path but with different
> sids
>=C2=A0 =C2=A0 =C2=A0> assigned (for every time the meaning of the de= finition changes), then
> how do
>=C2=A0 =C2=A0 =C2=A0> consumers of the sid file know which sid to us= e for a given path (given
> that
>=C2=A0 =C2=A0 =C2=A0> there is no indication in the .sid file)?=C2= =A0 Instead, I think that this is the
>=C2=A0 =C2=A0 =C2=A0> wrong way to be handling NBC changes, and SIDs= should be bound only
> to the
>=C2=A0 =C2=A0 =C2=A0> schema path (i.e., the name of the item), and = a new SID is only allocated
> if
>=C2=A0 =C2=A0 =C2=A0> the name/path changes, and otherwise the same = SID is used, even if the
>=C2=A0 =C2=A0 =C2=A0> definition changes in a non-backwards-compatib= le way.
>
> This is my understanding.

Okay, I think that the text that describes this need to be tweaked.


>
>=C2=A0 =C2=A0 =C2=A0> (3) This draft makes use of the rc:yang-data e= xtension.=C2=A0 Was there any
>=C2=A0 =C2=A0 =C2=A0> discussion about using "YANG Data Structu= re Extensions" (RFC 8791)
> instead,
>=C2=A0 =C2=A0 =C2=A0> which is meant to be a cleaner formulation of = the rc:yang-data extension,
> and
>=C2=A0 =C2=A0 =C2=A0> without the dependency on RESTCONF?=C2=A0 I wo= uld suggest that using RFC
> 8791 would
>=C2=A0 =C2=A0 =C2=A0> be preferable if possible.
>
> I don't know of any such discussion, but I don't really unders= tand the
> distinction.

The new RFC is effectively the "proper" way to do achieving this.=

I think that is may be as simple as changing:

=C2=A0 =C2=A0 =C2=A0import ietf-restconf {
=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix rc;
=C2=A0 =C2=A0 =C2=A0 =C2=A0reference "RFC 8040: RESTCONF Protocol.&quo= t;;
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0rc:yang-data sid-file {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses sid-file;
=C2=A0 =C2=A0 =C2=A0}

to

=C2=A0 =C2=A0 =C2=A0import ietf-yang-structure-ext {
=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix sx;
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 sx:structure sid-file {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses sid-file;
=C2=A0 =C2=A0 =C2=A0}




>
>=C2=A0 =C2=A0 =C2=A0> (4) The policy in 7.4.2 for allocation a SID m= ega-range seems to aiming
> this
>=C2=A0 =C2=A0 =C2=A0> towards organizations rather than individuals.=
>
> Yes, the idea being that "Zigbee" or "IEEE" or ...= would allocate a mega-range.

Yes.

>
>=C2=A0 =C2=A0 =C2=A0> The policy in 7.6 for the "IETF
>=C2=A0 =C2=A0 =C2=A0> YANG SID Registry" requires an RFC.=C2=A0= What is the mechanism if an
> individual or
>=C2=A0 =C2=A0 =C2=A0> open source project wanted to get SIDs assigne= d for some of their YANG
> modules?
>
>=C2=A0 =C2=A0 =C2=A0> I.e., should we be defining a separate mega-ra= nge, managed by IANA,
> with just
>=C2=A0 =C2=A0 =C2=A0> Expert Review or Specification Required so tha= t these modules could use
> SIDs
>=C2=A0 =C2=A0 =C2=A0> allocated?=C2=A0 Or do you envisage a separate= entity taking up the
> responsibility
>=C2=A0 =C2=A0 =C2=A0> for coordinating this?
>
> My impression was that there would be a mega-range operated outside of=
> IANA
> for this (open source, non-RFC YANG module) kind of thing, but I think= that
> the energy for doing that may have waned.

Okay.=C2=A0 If there is a lack of energy there, do you think that this is s= omething that we should be asking IANA to manage (i.e., have this draft sep= arate a separate mega-range for these other modules)?

Thanks,
Rob


>
> --
> ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me = the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ip= v6 mesh networks [
> ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
> ]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3= =B8T consulting )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sandelman Software Works Inc,= Ottawa and Worldwide
>
>
>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000046f96d05c7060ddc-- From nobody Tue Jul 13 15:33:22 2021 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 DB50F3A0DD4; Tue, 13 Jul 2021 15:33:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162621559930.12938.14682203115579801462@ietfa.amsl.com> Date: Tue, 13 Jul 2021 15:33:19 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-yang-cbor-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 22:33:20 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-yang-cbor-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) The statement "Bytes with no bits set at the end of the byte string are removed." in Section 6.7 seems confusing to the point of being potentially harmful, and I'm not sure why it needs to be there. In the context it appears in, it seems to leave the value to be used for the bit string offset in an ambiguous state. If the intent is that such strings should not be generated (and MAY/SHOULD/MUST be rejected by recipients), that's okay, but having them silently ignored is very surprising and may merit discussion. (2) I think we should discuss the relationship between this document and draft-ietf-core-sid, which are before the IESG at the same time. This document says that core-sid is "one example for" a specification defining the management of SIDs, but draft-ietf-core-sid claims to be the document that "defines the semantics, the registration, and assignment processes of YANG SIDs". I'm having a hard time seeing the two statements as compatible with each other, but maybe I'm missing something. (3) The second example of instance-identifier using SID (§6.13.1) seems malformed, with "key name country" appearing under both "list user" and "list authorized-key" and no "country" leaf within "list user" other than the one under "list authorized-key". (The actual identityref example appears to correctly only use "name" as the key for "list user" and not "list authorized-key".) (4) Relatedly, the second example of instance-identifier by name (§6.13.2) does not show a country for "authorized-key", and I'm not sure if that's a valid way to represent the given YANG element. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I can see why it would not make sense to do so in this document that is so tightly integrated with CORECONF, but is there any work to produce a CBOR encoding for the "structure" extension from RFC 8791? As a general note, I did not look particularly carefully at the example CBOR encodings, on the assumption that they were automatically generated as part of the document production process. Section 4.2 This specification supports two types of CBOR keys; SID as defined in Section 3.2 and names as defined in Section 3.3. I suggest making an explicit statement about whether the two types of keys can be comingled in the same container/etc, possibly just by forward-reference to the media-type parameter. Section 4.2.1 In the context of containers and other nodes from the data tree, CBOR map keys within inner CBOR maps can be encoded using deltas or SIDs. In the case of deltas, they MUST be encoded using a CBOR unsigned integer (major type 0) or CBOR negative integer (major type 1), depending on the actual delta value. [...] It's a little surprising that we only get this extended discussion on SID use in §4.2.1, when we already had §4.1.1 "Using SIDs in keys" that said almost nothing about it. Section 4.2.2 [...] A namespace-qualified name MUST be used each time the namespace of a schema node and its parent differ. In all other cases, the simple form of the name MUST be used. [...] We have a similar statement in §3.3 that is only "the simple form of the name SHOULD be used" for the latter sentence. It's not entirely clear to me what causes the strength of requirement to be different between the two cases. Section 4.6 Do we want to explicitly acknowledge the mismatch between the "xml" in "anyxml" and the actual CBOR contents? Section 5.2 The yang-data extensions encoded using names are carried in a CBOR map containing a single item pair. The key of this item is set to the namespace qualified name of the yang-data extension container; the value is set to the CBOR encoding of this container as defined in Section 3.3. I'm not sure if this is a nit or not, so putting it here: is §3.3 the right reference for the encoding of the container (vs. §4.2)? Section 6.6 Requiring the string form for enumeration constants in a union seems like a big loss on encoded size. Is it worth putting some discussion in the document (or an appendix thereto) about why other options like tagged integer are not usable? (Similar discussion might be relevant for the bits-in-union case.) While it's banal, we might also put an example of the integer-encoded form (as used by non-union contexts) so that the tagged-text-string example isn't the only one given. Leafs of type enumeration MUST be encoded using a CBOR unsigned integer (major type 0) or CBOR negative integer (major type 1), depending on the actual value. [...] I think we should also mention the tagged-text-string case here. Section 6.7 In a number of cases the array would only need to have one element - a byte string with a small number of bytes inside. For this case, it is expected to omit the array element and have only the byte array that would have been inside. [...] I think it is actually required (not just "expected") based on some later text. Section 6.10, 6.13 I strongly encourage explicit mention of the use of a CBOR tag when these elements appear inside a union, analogous to the text in §6.6 and 6.7. The list in §6.12 is pretty easy to miss, and the word "tag" does not appear at all in these sections. Section 7 This specification defines the media-type "application/yang- data+cbor", which can be used without parameters or with the parameter "id=name" or "id=sid". I think the media-type discussions should refer to the "id" parameter and the two possible values for that parameter ('=' is not allowed in a parameter name). This media-type represents a CBOR YANG document containing one or multiple data node values. Depending on the presence and value of the media-type parameter "id", each data node is identified by its associated namespace qualified name as defined in Section 3.3 ("id=name"), by its associated YANG SID (represented as a SID delta or via tag 47) as defined in Section 3.2 ("id=sid"), or either of these (no "id" parameter given). I think that for identityref and instance-identifier we don't use the tag 47 for absolute (non-delta) SIDs, at least outside of a union context. Section 8 It might be worth mentioning that when the 'id' parameter to the media type is used, it's important to properly reject identifiers of the other type, to avoid scenarios where different implementations interpret a given content in different ways. Section 10.1 It's not clear to me that RFC 6241 needs to be classified as normative, at least based on the one place in the text where we reference it. NITS Section 2 * child: A schema node defined as a child node of a container, a list, a case, a notification, an RPC input, an RPC output, an action input, or an action output. Is this enumeration of "parent" node types guaranteed to be fixed for all time, or should we consider a more generic wording to describe it? (Likewise for the "parent" definition.) Section 4 The example from RFC 7317 may have truncated a little too much of the content; "mandatory true" for choice transport, the "inet:" prefix for "type inet:host" and "inet:port-number", etc. Section 4.4.1 Deltas of list members are equal to the SID of the current schema node minus the SID of the 'list'. This seems redundant with the list of "Delta values are computed as follows" from §4.2.1. Section 4.5 * CBOR map keys of any inner schema nodes MUST be set to valid deltas or names. * The CBOR array MUST contain either unique scalar values (as a leaf-list, see Section 4.3), or maps (as a list, see Section 4.4). I think a parallel list structure would be "CBOR arrays MUST contain [...]". * CBOR map values MUST follow the encoding rules of one of the datatypes listed in Section 4. (A recursive reference, though I mostly trust the reader to pick out the relevant subsections.) Section 4.5.1 In some implementations, it might be simpler to use the absolute SID tag encoding for the anydata root element. The resulting encoding is as follows: Pedantically, what follows is diagnostic notation, not a CBOR encoding. Section 4.6 An anyxml schema node is used to serialize an arbitrary CBOR content, i.e., its value can be any CBOR binary object. anyxml value MAY contain CBOR data items tagged with one of the tags listed in Section 9.3. The tags listed in Section 9.3 SHALL be supported. The second sentence seems to both not start with a capital letter and have a singular/plural mismatch, both of which could be resolved by adding "An" at the start. Section 6.13.1 Single instance schema nodes MUST be encoded using a CBOR unsigned integer data item (major type 0) and set to the targeted schema node SID. Should we say something about the lack of a delta encoding in this context, analogous to §6.10.1? From nobody Tue Jul 13 15:35:40 2021 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 AF0F13A0E15; Tue, 13 Jul 2021 15:35:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162621573715.1426.3300364400283622807@ietfa.amsl.com> Date: Tue, 13 Jul 2021 15:35:37 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 22:35:38 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-sid-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I think there is a new security consideration with this work that is important to document clearly -- not only do we define a new type of identifier, but we define a file format and other mechanisms for disseminating that information. An entity that's processing application/yang-data+cbor; id=sid information needs to ensure that the .sid files (or other source of SID information) it uses for such processing came from a trustworthy authority (or at least the same source as the data file). It would be possible for malicious manipulation of .sid file contents to cause a message recipient to mis-interpret the received message without any indication of such tampering. (2) Per §7.4.2, YANG SID range registries with public ranges MUST include a reference to the ".sid" file for such ranges, but the IANA-managed YANG SID range registry established by §7.5 does not, in and of itself, make such a provision. This function seems to be served by the "IETF YANG SIG Registry" created by §7.6, so we may just need to point to the one registry from the other in order to remain internally consistent. (3) There may be another inconsistency to look into; Section 7.6.2 says that: * If another ".sid" file has already allocated SIDs for this YANG module (e.g. for older or newer versions of the YANG module), the YANG items are assigned the same SIDs as in the other ".sid" file. But we are supposed to allocate a new SID for a YANG item if its semantics change in a revision of the YANG module. Perhaps it's just the "for older or newer versions of the YANG module" phrase that needs tweaking? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The yangdoctors review mentioned the structure extension from RFC 8791, and the authors (understandably) expressed reluctance to make such a large change at this stage in the process. I'll note that the DOTS WG has recently completed work on a "bis" of RFC 8782, with primary aim of replacing yang-data with structures and minimal other changes. (A yangdoctors review of a related document was sufficiently insistent that structures are the right way to do this that the WG was convinced to put in the effort.) The yangdoctors review also asked why sid-file/module-name is optional, which was tagged for follow-up. I have the same question and am interested in the outcome of the discussion amongst the authors. If SIDs are supposed to be globally unique identifiers, the reference in the YANG module to "namespace" identifiers for individual allocations is puzzling to me. The presence of a namespace would typically allow for identifier reuse across namespaces (e.g., using the same SID integer value for an identity and a data node within the same module). I see how the current list structure makes it easy to have a single flat list of all identifier/sid mappings, but if the SIDs truly are globally unique, then the "namespace" should not be a list key, and might be less confusingly described as just indicating the type for which the SID is used. (It would also be possible to have separate lists for module SIDs, identity SIDs, etc., but it's not clear that doing so is actually the right approach.) Section 1 [...] If the meaning of an item changes, for example as a result from a non- backward compatible update of the YANG module, a new SID SHOULD be assigned to it. A new SID MUST always be assigned if the new meaning of the item is going to be referenced using a SID. That predicate seems in general unknowable ("you can't prove a negative", etc.), so it's tempting to just require that if the old semantics had a SID that the new semantics get one as well. Section 4 If the scope of a sid-file-version-identifier resets when the module revision is bumped, it seems highly unlikely that we'll need 64 bits of identifier for it. Section 5, 7.3 It's not entirely clear that we need to mention the content-type/content-format in this document, as we only indicate use of the JSON encoding for the .sid file and the use of SIDs in the application/yang-data+cbor; id=sid case seems adequately described by the existing treatment in draft-ietf-core-yang-cbor. Section 7.4.1 I appreciate that the "mega-range" allocations are sized for the appropriate SI prefix :) The information associated to the Organization name should not be publicly visible in the registry, but should be available. This information includes contact email and phone number and change controller email and phone number. Available to whom? Section 7.5.2 The size of the SID range allocated for a YANG module is recommended to be a multiple of 50 and to be at least 33% above the current number of YANG items. This headroom allows assignment within the same range of new YANG items introduced by subsequent revisions. The maximum SID range size is 1000. A larger size may be requested by the authors if this recommendation is considered insufficient. [...] If there's a maximum size for a range, then asking for a larger one is pointless. Please reword to indicate the actual intent (maybe s/maximum/typical expected/ or similar). In case a SID range is required before publishing the RFC due to implementations needing stable SID values, early allocation as defined in [BCP100] can be employed. As specified in Section 4.6 of [RFC8126], RFCs and by extension documents that are expected to become an RFC fulfill the requirement for "Specification Required" stated in Section 2 of [BCP100], which allows for the early allocation process to be employed. While the first bit of this is all true, the registry here doesn't use the "Specification Required" policy for any range, and early allocations are available for the "RFC Required" range. So we should probably tweak or remove the second sentence. Section 7.6.3 Early Allocations are made with a one-year period, after which they are expired. [BCP100] indicates that at most one renewal may be made. For the SID allocation a far more lenient stance is desired. 1. An extension of a referencing documents Early Allocation should update any referenced Early Allocations to expire no sooner than the referencing document. 2. The [BCP100] mechanism allows the IESG to provide a second renewal, and such an event may prompt some thought about how the collection of documents are being processed. The first point is rather curious, since it can have no normative force (this is not a BCP that would override BCP 100) and is merely a continnation of how a more lenient stance is desired. It's rather odd to see it written in this way. The second point seems to be the only really useful part, and in practice this IESG approval of second (and more!) renewals has become rather common, to the extent where a revision of BCP 100 has been discussed to change the discussion of extensions for early renewals. This is driven by the very generous size of the SID space and the often complex and deep dependencies of YANG modules. Often a core module with many dependencies will undergo extensive review, delaying the publication of other documents. Having many *dependencies* and taking a while shouldn't delay publication of anything else; however, having many other modules dependent on a core module would be likely to do so. Appendix A IIRC the mismatch between "ietf-system@2014-08-06.yang" and the toplevel "module-revision" of "2020-02-05" was noted by an earlier reviewer, but I'll mention it here just in case I do not remember correctly. NITS Section 1 SIDs are assigned permanently, items introduced by a new revision of a YANG module are added to the list of SIDs already assigned. If the comma splice Section 5 Each .sid file contains the mapping between the different string identifiers defined by a YANG module and a corresponding numeric value called YANG SID."; singular/plural mismatch "numeric value called YANG SID"/"string identifiers" From nobody Tue Jul 13 22:41:20 2021 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 D40E23A103E; Tue, 13 Jul 2021 22:41:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162624127733.15124.15333004711651272795@ietfa.amsl.com> Date: Tue, 13 Jul 2021 22:41:17 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 05:41:18 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-sid-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below two blocking DISCUSS points (which are probably misunderstandings of mine), some non-blocking COMMENT points (but replies would be appreciated), and one nit. I hope that this helps to improve the document, Regards, -éric -- Section 3 -- As a YANG model can have several YANG modules, was there a discussion in the WG whether the SID range is assigned per module or per model ? The IANA section seems to refer to an allocation per RFC, i.e., per model and not per module. -- Section 7.5.2 -- AFAIK, many YANG modules are not originating at the IETF (Open Config, vendor specifics modules, ...). How can those non-IETF modules get a SID as the two ways to get a SID are based on RFC (if I understand correctly this section). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == I will let my OPS and Management AD to comment on the use of 'YANG schema' rather than 'YANG module' and about the word 'item' for many YANG-related concepts. I know that Alex Pelov is an author but was there any discussion with LPWAN WG on this? No need to reply but the use of ".sid" to qualify a file format reminded me of MS-DOS... ;-) I am somehow concerned by having so many SIDs being generated as it requires being careful in generating them and having a scalability issue when using them as the 'mapping table' could become quite large. -- Abstract -- Suggest to add the reason why using SID in constrained environments for people outside of CORE WG ;-) -- Section 4 -- In addition to a reference to RFC 7951, why not simply adding that the the ".sid" file is encoded in JSON ? -- Section 7.4.1 -- Out of sheer curiosity, why using a decimal million rather than the usual power of 2 ? Again just out of curiosity ;-) -- Section 7.5.3 -- Suggest to either remove entries related to ietf-anima-constrained-voucher or move this I-D in the normative references section. == NIT == -- Section 1 -- Suggest to expand "YANG SID" again as the abstract is not really part of the document. From nobody Wed Jul 14 02:10:09 2021 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 109773A19D3; Wed, 14 Jul 2021 02:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=j3T/rS1+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Sm0juOOc 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 lFYuiZllgAoW; Wed, 14 Jul 2021 02:10:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB143A1742; Wed, 14 Jul 2021 02:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7752; q=dns/txt; s=iport; t=1626253801; x=1627463401; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Y5JgqaWbxWwCHmfOIVomcy7DUIfWtcyoNM7lYTHKuyY=; b=j3T/rS1+FLyBA/SwweFlnpKtfDFp7y2Vee1Je4+ayAMOnBb4dc0iBUDR b0V1vIqR+mF8GSbZO0wxxlP0hxFM6pz0snS9ArKF0AZcUR57xl+cvcaI0 AmDFaqiuiwnKC0MGePPg19GXHNKeF7/0ZSsHehA9jb8KNckfcDiPlA/XM s=; IronPort-PHdr: =?us-ascii?q?A9a23=3A1S1c4x8TwYilGP9uWMHoyV9kXcBvk679OAIY7?= =?us-ascii?q?p8ujfRFe/fr85fjORnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFW?= =?us-ascii?q?xIfz8lDmQsmDZ2eAEv3IfrvZip8F80RHFNg9muwZE5SHsu2blbOo3q0uDgVH?= =?us-ascii?q?Bi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AG4b3saNxV6o82cBcT07155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9Ar5K0tQ5uxoX5PwD080lKQFrrX5WI3DYO?= =?us-ascii?q?CIghrREGgP1/qG/9SkIVyCygc/79YgT0EdMqyKMbESt6+Ti2PUf6dCsbu6Ge?= =?us-ascii?q?KT9J3jJhxWPGZXgtRbnn5E43GgYytLrWd9dP4EPavZwvACiyureHwRYMj+LG?= =?us-ascii?q?ICRfL/q9rCk4+jSQIaBjY8gTP+zQ+A2frfKVy1zx0eWzRAzfMJ6m7eiTH04a?= =?us-ascii?q?2lrrWS1gLc7WnO9J5b8eGRieerRfb8yPT9GA+czjpAV74RHIFqewpF5t1H3W?= =?us-ascii?q?xa1eUkZS1QZvibpUmhJl1d6iGdpTUImAxemkMKj2Xo2kcKZafCNW8H4w0rv/?= =?us-ascii?q?MCTvKR0TtRgPhslK1MxG6XrJxREFfJmzn8/cHBU1VwmlOzumdKq59Zs5Vza/?= =?us-ascii?q?pWVFZql/1WwKqVKuZ1IAvqrIQ8VOV+BsDV4/hbNVuccnDCp2FqhNihRG46EB?= =?us-ascii?q?uKSlUL/pX96UkaoFlpi08DgMAPlHYJ85wwD5FC+uTfK6xt0LVDVNUfY65xDP?= =?us-ascii?q?oIBcG3FmvOSxTRN3/6GyWsKEjGAQO6l3fT2sR42AiHQu178HICouW3bLoDjx?= =?us-ascii?q?9AR6vHM7z64KF2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+EgCMqe5g/5NdJa1aHgEBCxIMQIM?= =?us-ascii?q?sUQd3WjcxhEiDSAOFOYhXA5otglMDVAsBAQENAQE1DAQBAYFggnQCF4JgAiU?= =?us-ascii?q?4EwIEAQEBEgEBBQEBAQIBBgRxE4VoDYZFAQEBAQMSEREMAQEpDwsEAgEIEQQ?= =?us-ascii?q?BAQECAiYCAgIwFQgIAgQBEggTB4JQglUDLwEOmzEBgToCih96gTKBAYIHAQE?= =?us-ascii?q?GBASBSUGDQxiCMgMGgRAqgnuEDoJog3onHIFJRIEVQ4JiPoJiAQECAYFFGoM?= =?us-ascii?q?VNoIugh8aWwYBYwQnASkCIA8xMQctPwEOZJEpg0aIbJ8PCoMkijOUGxKCMoE?= =?us-ascii?q?xonaWBoIbihSYVAIEAgQFAg4BAQaBciSBWXAVgyRQGQ6IHIYDDBYVgzmFFIV?= =?us-ascii?q?KczgCBgEJAQEDCYwMAQE?= X-IronPort-AV: E=Sophos;i="5.84,238,1620691200"; d="scan'208";a="886344109" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2021 09:09:55 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 16E99sMt032517 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2021 09:09:54 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 04:09:54 -0500 Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 04:09:54 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 14 Jul 2021 05:09:54 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XoN/zSSrH/bAp5bhRn2Xd3iCMD1kMn0ayDUkoNbhDIbGGv4JGZJb3eKNuJ39qp0OMs9LQMqmeLCqTqn08ZLnY3JYXo5y3PICOJ1xIEc/boP6Ex+crFnAMNsoOhKoJjbNhlIwv8QSoPhFYJeuEoD9N3faxaROweQu8I7a0H76zG52rBAsKmoBYW1+qhOazudGWC1dEVn3tI7VSWD4xnRZuW4A6zltZWbLZtlSHpexfp1crHKp0mdAe6bIf5VJFLpaCNmF2FgQHdnGU5grrOBaWE6X3v8/93i8bIg4snRq4twLymQMslyFoS8MdrWdV3t1D0hcJ/kfvUUgy1/2rmP2Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y5JgqaWbxWwCHmfOIVomcy7DUIfWtcyoNM7lYTHKuyY=; b=Gslsqi/jYGhre+3g/VEP/5c6NpPXwCam1xLfx2rZSxm67cFL7RuUTamtGT/fzyGjovH5PelSLoRUH9Sxr13/aTwhJSGMrynCjBqMWWqzxYamz/vUuOZBNwYLU0g+uLab82nPR5fjVTtGecdjcFK0i+rF9HoL2J4PC60K8MpJFXmGEjOufF1Tk88RtfN5TzSQ/mn3Pn73iVc6d+MMyMNGWWHak1qfl8s23Fo76NNebiVWrTC1YrJlJqzV9WF2ZWm3xbJb3UF9EyMVxgxO7e5HLWc0ajT5WJwfxc7kY7f/7x/GPIJD9cA534bwRyyags5jDOy8KeHXNeDplH5UnmR4yA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y5JgqaWbxWwCHmfOIVomcy7DUIfWtcyoNM7lYTHKuyY=; b=Sm0juOOcoS4K2zVaAVyWEy1cDM1k1BP1bTAJzeX+LDBkJJ75xWQc6yic+CNTFonrbFETqsiswBHH9USXysHzAGFW5H9iTv7vvYbyjik8n7JbgeNpMCp7z3rkoqum3tTkrAm5RyZfz4FiSnjziFg6c67qw8jwd1vII2KQXHXeg2A= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB2956.namprd11.prod.outlook.com (2603:10b6:5:64::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Wed, 14 Jul 2021 09:09:53 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4331.021; Wed, 14 Jul 2021 09:09:53 +0000 From: "Rob Wilton (rwilton)" To: Michael Richardson , The IESG , "draft-ietf-core-sid@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) Thread-Index: AQHXeAALE98pHaaPt0GwTNHeUw7K96tBK82AgAAPFvCAAAfIAIAA4oyw Date: Wed, 14 Jul 2021 09:09:52 +0000 Message-ID: References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> <26411.1626197913@localhost> <17256.1626202824@localhost> In-Reply-To: <17256.1626202824@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eff452da-1520-416c-32fe-08d946a72435 x-ms-traffictypediagnostic: DM6PR11MB2956: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2wiT0Volnq5gYQCGFhCRWoTSKpFQtSAA3bEsJ2QFGoqU8hsyKvL85zTuU7pJhoMvT8tGgHYENzHfozB5jaazyjS6zo+0EV6dTpYxHnGbwhhj8BE/Bf2wdXQ2j1ti/hHLaYzt4n3qKJ3kEkbQQ3I4ZvnelExs58V2uBBVHzKER9mWiaYqXula3sw4gh8M5Aum4Oq5tKFaIl5Bl2Pl/MQ0uY9imCMLWewvRglgSb9FzHwzb9/aVveDCOaIcjb4VMJsoQ9N02VT1xEiS6NgFxqHb0pR6GNS6Sjix/bOxJDEZrNnzdRr4bL0R0nW4NB+bhWcTXQz5Lr80ygfPQhk8O9XvsZvT0pV2qmuCF2ugoRURt3n/0WHEcAN5twMZ9JFx+Uj3O+UApxbq/1TZmHnRn2a2EvH2OBJth3ubKHFFmsBUn/NDQah1R339lZBmUULAzhQC4b4iiEcBl4n7tgdAHnWb4er0OfEdLVb2HvuRYVn8kY3BKBO0czcY7g4r4copKJsulA3m1+OTQm595hefwP/+HN3u1838mwzgQtbznobMNaDYo1Kp+2WFv3ZPOsoD6q+Uogj+sYOaHNBpIHTdONDvDU3lR7QS/bY7T00EgNt8mLU6amltmfMDDsEOw5bqqA6D0nKqc+Ev+phdz7+2gyYlkdsrxBd+jckyG2scWxcUzi5SZk7+IkNSTRKPBMs4ScAemYgcyeda29KNphxKtTJryfzwkkHlEH6nI7dYMHL9rIj3J9xPU+qOZ5upJ1KlPN79ucSEJClziMuXVppr6cWQytXp4syVQ1iyWfYtzu64bo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(376002)(346002)(396003)(39860400002)(86362001)(55016002)(52536014)(2906002)(122000001)(186003)(66574015)(71200400001)(38100700002)(26005)(478600001)(76116006)(6506007)(33656002)(5660300002)(110136005)(8676002)(9686003)(53546011)(66476007)(66556008)(64756008)(66446008)(66946007)(8936002)(7696005)(966005)(83380400001)(316002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MGYzY3JjaUovM3lneXI4RHFwVW12NFBaT1FNWmpJRkhUT0JYNSsxZUozTFF2?= =?utf-8?B?dmdncWJXbHpEWHo1bC9xRkdyejluUnhON0EzT1ZhaFhEM2xDVXdwdUZ4Ym9w?= =?utf-8?B?cnpRNThpbzZQcEhFNWNJMEhTMWpNWVhjREkyMDJKVHdXd1g0UHpNZjF6cGdx?= =?utf-8?B?WG8yMXo4eFhBZ3pQQ3gwU1diR1I5c1Vyd3hjaTcyc05NYVprZ2hSRVl6Q2hQ?= =?utf-8?B?WGQ3eG5OV1ZGQzRoLzljMWFzVGVta2FPR1IwbjFFS0NSOWk4Qk8vRFBuaE9E?= =?utf-8?B?SEtDaExhRStpRFBVVWQ4YmFpTktiUC9KY2ZrcnRTOUNTU2N3MTcwLzYrV25C?= =?utf-8?B?dnJNV01ER1BzVmZTOWlZNThPc3BpREI2TUk2aGM0QTJkN3UvTWVtN2lyNUNS?= =?utf-8?B?UFN0ODEwNWVPNXhNbGNPNWNPb3lwQVMvVHI5OGdLSEd6VDcrL3duVkl5UUR6?= =?utf-8?B?cGRzTndRZGdMOHRZM2ZjbXVuVi8vSGZuSVkwMm1QZzE4R1RrU3prZ3Fudjhs?= =?utf-8?B?b1FLTEFQTGFhbWI5Rm1EUnROV3VpaExsZDFlNDRNVW1OYlJqYkVQZHBXOWRW?= =?utf-8?B?ZVhoVGxUYmg4bzVHSVR2RmNQdEVicnZQSFVDdnNaa3gyNG4rQjlqTWFoREho?= =?utf-8?B?TlJzRkM4QjNleGxNUEZoeXJ1SkF1a2F6VnRVeXBab0lqZTdwdEZsTFVsTFor?= =?utf-8?B?NUh3SUpMc2hKeFpINWtnTDFJMzZFd3REcXg0a25vL2lqZWxGMldhK2UrNmVB?= =?utf-8?B?TTB6dzFQQlJpRjk4RHZvemllajl0R1h0ckdxTUNKNi9BazJlWFVnOU5qaEs5?= =?utf-8?B?ejcrREI1OFY4aWYvV3FqTjhwWEpheU9VQ2pzYzVnY0J6dUpQc29ZbmR1MWhH?= =?utf-8?B?bEo5MURhMEs1ckh0Nk5TYnJTZEd6MnNHS0tuekZudmxrSkFQUFlZUnZUb3h4?= =?utf-8?B?aWwrUjBaTmkweHJPcG1zTXdLWlFlR2ZJNHBNZk9UZUY1L1E5bk5UaExpS2Ni?= =?utf-8?B?eXR0am5aYXhudTB2Q1cxNnFrRU1YNzUreWtNT0ZOcW1PanFjcTB2SnJWVERm?= =?utf-8?B?WHVaTkR6MnJoMTNvRzd4MVJ0YUZuVTZyMHBkSjE4S09ZdnpGZ2lKRG9WVnZm?= =?utf-8?B?cXZoZHM1RHlhajFkZWJoQ1kvcnBlZE0weHBWV1pEUW83TmxmWitjK0txbktV?= =?utf-8?B?dHBVeWVSdkVXSW9ZNEdOSGNsRkNGcXdSL2hMYVpRMThEN0s1YWN5WDZXcjRy?= =?utf-8?B?TDNCazB3VUdzTG1DZVc4ZWUxbC9ZU05wNWMxUmc5VFE4M2hzQUhnS2JKZWxs?= =?utf-8?B?ODk2SmwyYm9PQXcrdGZrRFVOWlBsemlXVUdlMTlQdWx3YTVLUDlxcWw2MnJp?= =?utf-8?B?cEsvc24wV20rcXBWc2dMQWVHa2ppMWRTd0U0NDRVQTZobmFsUkdPM2RnWG42?= =?utf-8?B?SzdxTktBNXdwRlF1cUR4cytLV2RubXFYUjhEUm5FMUYwb1ZhLzBQNVBKdzhw?= =?utf-8?B?Q0IrRXNnQWVqTnhzYWFDNlVmV05Jb29sMGcvdm4zTlJTVDhOQTlaRDllMjF6?= =?utf-8?B?cXNnNWtKZU9YdWdSOGlZVTZ0MTBKMS9ibXV2UzNlWmhkUFllWTZTOEhTVHky?= =?utf-8?B?TkRDWDAxek9HQzhoNFRXS2VIaEpGalhFQ2x5eFA5V2tPQktDQUI4OEFKUWlI?= =?utf-8?B?YWFhMjkzcmwrUUtwVktLWVBrK3FSU1hjRmpQYkNEQzB5WG04SXZ2NnZiRk1B?= =?utf-8?Q?YM3tx+qwGDo5L6FZHCfza9PMdQ3CXJS1on6GiKE?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eff452da-1520-416c-32fe-08d946a72435 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 09:09:52.9051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dfNzPR4x7McDu/fALTo7dl3/ZbktfgXM/N/ihD1hHX+OcbPwUARJdXU7MBY+EYK0vds/mi/0Q1R8gvgARzMGOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2956 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 09:10:07 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQo+IFNlbnQ6IDEzIEp1bHkgMjAyMSAyMDowMA0K PiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+Ow0KPiBkcmFmdC1pZXRmLWNvcmUtc2lkQGlldGYub3JnOyBjb3JlLWNo YWlyc0BpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIFJvYmVy dCBXaWx0b24ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1zaWQtMTY6ICh3aXRoDQo+IERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiANCj4gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0 b25AY2lzY28uY29tPiB3cm90ZToNCj4gICAgID4gbGVhZiBmb28gew0KPiAgICAgPiB0eXBlIHN0 cmluZyB7DQo+ICAgICA+IGxlbiAiMS4uMjAiOw0KPiAgICAgPiB9DQo+ICAgICA+IH0NCj4gDQo+ ICAgICA+IE9yIHRoZSBkZWZpbml0aW9uIG9mIGZvbyBjb3VsZCBjaGFuZ2UgaW4gYSBub24tYmFj a3dhcmRzLWNvbXBhdGlibGUNCj4gd2F5LiAgRS5nLiwNCj4gDQo+ICAgICA+IGxlYWYgZm9vIHsN Cj4gICAgID4gdHlwZSBpbnQzMjsNCj4gICAgID4gfQ0KPiANCj4gICAgID4gUkZDIDc5NTAgYmFz aWNhbGx5IHN0YXRlcyB0aGF0IHRoaXMgaXMgbm90IGFsbG93ZWQsIGJ1dCB0aGVzZSBzb3J0cyBv Zg0KPiAgICAgPiBjaGFuZ2VzIGhhcHBlbnMgYW55d2F5IChlLmcuLCB2ZW5kb3JzIGZpeGluZyBi dWdzLCBvciBidWdzIGluIHN0YW5kYXJkDQo+ICAgICA+IFlBTkcgbW9kZWxzKSwgYW5kIHRoZSBZ QU5HIHZlcnNpb25pbmcgd29yayB3aWxsIGFsbG93IHRoZXNlIHNvcnRzIG9mDQo+ICAgICA+IGNo YW5nZXMgd2l0aCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucy4NCj4gICAgID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC15YW5nLW1vZHVsZS0N Cj4gdmVyc2lvbmluZy0wMw0KPiANCj4gICAgID4gQnV0IGluIGFsbCB0aGVzZSBjYXNlcywgbm8g bmV3IFNJRCBzaG91bGQgYmUgYWxsb2NhdGVkLCBvciBvdGhlcndpc2UNCj4gICAgID4geW91IHdp bGwgaGF2ZSB0d28gU0lEcyBhc3NpZ25lZCB0byB0aGUgc2FtZSBuYW1lL3BhdGguDQo+IA0KPiBF bmNvZGluZyB0b3dhcmRzIENCT1IsIHRoZSBDQk9SIHdvdWxkbid0IGNhcmUgdGhhdCBtdWNoIGFi b3V0IHRoZQ0KPiBjaGFuZ2UgaW4NCj4gdHlwZSwgYXMgdGhlIENCT1IgaXMgc2VsZi1kZXNjcmli aW5nIGluIHRoYXQgd2F5Lg0KPiBTbyBtYXliZSBpdCdzIG9rYXkgaWYgYSBuZXcgU0lEIGlzIG5v dCBhbGxvY2F0ZWQuDQo+IA0KPiBXaGVyZSBpdCB3b3VsZCBiZSBhIHByb2JsZW0gaXMgaWYgdGhl IGNoYW5nZSB3YXMgZnJvbSBhIDEtYmFzZWQgY291bnQgdG8gYQ0KPiAwLWJhc2VkIGNvdW50LCBi b3RoIGVuY29kZWQgYXMgaW50ZWdlcnMuICBJbiB0aGF0IGNhc2UsIEkgcmVhbGx5IGhvcGUgaXQN Cj4gd291bGQgZ28gZnJvbSAiZm9vIiB0byAiZm9vLTAiIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQu DQoNClllcywgYnV0IHRoaXMgaXNuJ3QgYW4gaXNzdWUgc3BlY2lmaWMgdG8gU0lEcyBvciB0aGUg Q0JPUiBlbmNvZGluZy4gIFRoaXMgY29uY2VybiBzaG91bGQgYmUgbGVmdCB0byB0aGUgY29yZSBZ QU5HIHNwZWNzLg0KDQpXaXRoIHJlZ3VsYXIgWUFORywgeW91IGhhdmUgYSBwcm9ibGVtIGlmIHRo ZSBjbGllbnQgYW5kIHNlcnZlciBhcmUgdXNpbmcgaW5jb21wYXRpYmxlIGRlZmluaXRpb25zIG9m IHRoZSBzY2hlbWEgbm9kZXMuICBUaGlzIGlzIGEga25vd24gaXNzdWUsIGFuZCB0aGUgc29sdXRp b24gdG8gdGhpcyBwcm9ibGVtIGlzIGVpdGhlciBub3QgZG8gdGhpcyAoZS5nLiwgYXMgcGVyIFJG QyA3OTUwIHNlY3Rpb24gMTEgbW9kdWxlIHVwZGF0ZSBndWlkZWxpbmVzKSBvciBtYW5hZ2UgdGhp cyBpcyBpbiBhIHdheSB0aGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciBjYW4gaGFuZGxlIHRoZSBj aGFuZ2VzICh3aGljaCBpcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBZQU5HIHZlcnNpb25pbmcgd29y ayBpcyBwcm92aWRpbmcgYSBzb2x1dGlvbiBmb3IpLg0KDQpCdXQgYXQgdGhlIGVuZCBvZiB0aGUg ZGF5LCBhIFNJRCBpcyBqdXN0IGEgbW9yZSBlZmZpY2llbnQgd2F5IG9mIGVuY29kaW5nIHRoZSBp dGVtIG5hbWUgd2l0aGluIGEgZ2l2ZW4gbW9kdWxlLiAgSS5lLiwgaXQgYWxsb3dzIG9uZSB0byB1 c2UgYW4gaW50ZWdlciBpbnN0ZWFkIG9mICJtb2R1bGUtZm9vOmxlYWYtYmFyIi4gIEl0IGNhbm5v dCBoYXZlIGFueSBzZW1hbnRpYyBiZXlvbmQgdGhhdC4gIElmIHRoZSBpdGVtIG5hbWUgY2hhbmdl cyB0aGVuIGEgbmV3IFNJRCBpcyBhbGxvY2F0ZWQuICBJZiB0aGUgaXRlbSBuYW1lIHN0YXlzIHRo ZSBzYW1lLCBidXQgdGhlIGRlZmluaXRpb24gY2hhbmdlcywgdGhlbiB0aGUgc2FtZSBTSUQgaXMg dXNlZC4NCg0KQW5keSdzIGNvbW1lbnQgYWxzbyBzdW1tZWQgdGhpcyB1cCB3ZWxsLg0KDQoNCj4g DQo+ICAgICA+PiA+IFRoZSBkcmFmdCBzdGF0ZXMgdGhhdCBpZiB0aGUNCj4gICAgID4+ID4gZGVm aW5pdGlvbiBpcyBjaGFuZ2VkIGluIGEgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIChOQkMpIHdh eSB0aGVuDQo+IGENCj4gICAgID4+ID4gbmV3IFNJRA0KPiAgICAgPj4gPiBTSE9VTEQgYmUgYWxs b2NhdGVkLg0KPiAgICAgPj4NCj4gICAgID4+IFRydWUsIEkgYXNzdW1lIHRoYXQgdGhpcyBsZWFk cyB0byBhIG5ldyBZQU5HIGxlYWYgbmFtZS4NCj4gDQo+ICAgICA+IE9ubHkgaWYgdGhlIGF1dGhv ciBnaXZlcyB0aGUgZGVmaW5pdGlvbiBhIG5ldyBuYW1lLCBhbmQgZnJvbSBhIFNJRA0KPiAgICAg PiBhbGxvY2F0aW9uIFBPViwgdGhpcyBpcyBqdXN0IGEgbmV3IGl0ZW0gbmFtZSBpbiB0aGUgc2No ZW1hLCBhbmQgaGVuY2UNCj4gICAgID4gbmVlZHMgYSBuZXcgU0lELiAgSS5lLiwgdGhlIGFsbG9j YXRpb24gb2YgYSBuZXcgU0lEIGlzIHJlbGF0ZWQgdG8gYSBuZXcNCj4gICAgID4gaXRlbSBuYW1l LCBub3QgYmVjYXVzZSBvZiBjaGFuZ2VzIGluIGEgZGVmaW5pdGlvbi4NCj4gDQo+IEkgYWdyZWUg dGhhdCB3ZSBoYXZlIGEgcHJvYmxlbSBlbmZvcmNpbmcgYXQgdGhlIHB5YW5nIHNpZCBnZW5lcmF0 aW9uIHBsYWNlDQo+IHRoYXQgbm9uLWJhY2t3YXJkcyBjb21wYXRpYmxlIGNoYW5nZXMgbmVlZCBu ZXcgU0lEcy4gIFRoYXQgc291bmRzIGxpa2UgYQ0KPiB0b29saW5nIGltcHJvdmVtZW50LCByYXRo ZXIgdGhhbiBhIGJ1ZyBpbiB0aGUgc3BlYy4NCg0KSSBkaXNhZ3JlZS4gIFRoZSBzcGVjIHNob3Vs ZCBvbmx5IGJlIGJpbmRpbmcgdGhlIFNJRCB0byB0aGUgc2NoZW1hIG5vZGUgbmFtZSwgbm90IGl0 cyBkZWZpbml0aW9uLg0KDQpPdGhlcndpc2UsIHlvdSB3aWxsIGVuZCB1cCB3aXRoIFNJRCBmaWxl cyB0aGF0IGxvb2sgbGlrZSB0aGlzIChpZiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgaG9zdG5hbWUg aGFzIGNoYW5nZWQpOg0KDQogICAgICAgIHsNCiAgICAgICAgICAibmFtZXNwYWNlIjogImRhdGEi LA0KICAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vaG9zdG5hbWUi LA0KICAgICAgICAgICJzaWQiOiAxNzUyDQogICAgICAgIH0sDQogICAgICAgIHsNCiAgICAgICAg ICAibmFtZXNwYWNlIjogImRhdGEiLA0KICAgICAgICAgICJpZGVudGlmaWVyIjogIi9pZXRmLXN5 c3RlbTpzeXN0ZW0vaG9zdG5hbWUiLA0KICAgICAgICAgICJzaWQiOiAxODc5DQogICAgICAgIH0s DQogICAgICAgIHsNCiAgICAgICAgICAibmFtZXNwYWNlIjogImRhdGEiLA0KICAgICAgICAgICJp ZGVudGlmaWVyIjogIi9pZXRmLXN5c3RlbTpzeXN0ZW0vaG9zdG5hbWUiLA0KICAgICAgICAgICJz aWQiOiAyMDExDQogICAgICAgIH0sDQoNCkhvdyBkb2VzIHRoZSBzZXJ2ZXIga25vdyB3aGF0IHZh bHVlIHRvIHVzZSB3aGVuIGVuY29kaW5nIGl0PyAgRG9lcyBhIGNsaWVudCBoYXZlIHRvIGhhbmRs ZSBkZWNvZGluZyBhbGwgdGhlc2UgU0lEIHZhbHVlcz8gIE5vdGluZyB0aGF0IHRoZXJlIGlzIG5v IGV4dHJhIGluZm9ybWF0aW9uIGluIHRoZSBTSUQgZmlsZSB0byBpbmRpY2F0ZSBob3cgdGhlc2Ug c2hvdWxkIGJlIHByb2Nlc3NlZCBkaWZmZXJlbnRseS4NCg0KDQoNCg0KPiANCj4gICAgID4+ID4g VGhlIHBvbGljeSBpbiA3LjYgZm9yIHRoZSAiSUVURg0KPiAgICAgPj4gPiBZQU5HIFNJRCBSZWdp c3RyeSIgcmVxdWlyZXMgYW4gUkZDLiAgV2hhdCBpcyB0aGUgbWVjaGFuaXNtIGlmIGFuDQo+ICAg ICA+PiA+IGluZGl2aWR1YWwgb3INCj4gICAgID4+ID4gb3BlbiBzb3VyY2UgcHJvamVjdCB3YW50 ZWQgdG8gZ2V0IFNJRHMgYXNzaWduZWQgZm9yIHNvbWUgb2YgdGhlaXINCj4gWUFORw0KPiAgICAg Pj4gPiBtb2R1bGVzPw0KPiAgICAgPj4NCj4gICAgID4+ID4gSS5lLiwgc2hvdWxkIHdlIGJlIGRl ZmluaW5nIGEgc2VwYXJhdGUgbWVnYS1yYW5nZSwgbWFuYWdlZCBieSBJQU5BLA0KPiAgICAgPj4g PiB3aXRoIGp1c3QNCj4gICAgID4+ID4gRXhwZXJ0IFJldmlldyBvciBTcGVjaWZpY2F0aW9uIFJl cXVpcmVkIHNvIHRoYXQgdGhlc2UgbW9kdWxlcyBjb3VsZA0KPiB1c2UNCj4gICAgID4+ID4gU0lE cw0KPiAgICAgPj4gPiBhbGxvY2F0ZWQ/ICBPciBkbyB5b3UgZW52aXNhZ2UgYSBzZXBhcmF0ZSBl bnRpdHkgdGFraW5nIHVwIHRoZQ0KPiAgICAgPj4gPiByZXNwb25zaWJpbGl0eQ0KPiAgICAgPj4g PiBmb3IgY29vcmRpbmF0aW5nIHRoaXM/DQo+ICAgICA+Pg0KPiAgICAgPj4gTXkgaW1wcmVzc2lv biB3YXMgdGhhdCB0aGVyZSB3b3VsZCBiZSBhIG1lZ2EtcmFuZ2Ugb3BlcmF0ZWQgb3V0c2lkZQ0K PiBvZg0KPiAgICAgPj4gSUFOQQ0KPiAgICAgPj4gZm9yIHRoaXMgKG9wZW4gc291cmNlLCBub24t UkZDIFlBTkcgbW9kdWxlKSBraW5kIG9mIHRoaW5nLCBidXQgSSB0aGluaw0KPiB0aGF0DQo+ICAg ICA+PiB0aGUgZW5lcmd5IGZvciBkb2luZyB0aGF0IG1heSBoYXZlIHdhbmVkLg0KPiANCj4gICAg ID4gT2theS4gIElmIHRoZXJlIGlzIGEgbGFjayBvZiBlbmVyZ3kgdGhlcmUsIGRvIHlvdSB0aGlu ayB0aGF0IHRoaXMgaXMNCj4gICAgID4gc29tZXRoaW5nIHRoYXQgd2Ugc2hvdWxkIGJlIGFza2lu ZyBJQU5BIHRvIG1hbmFnZSAoaS5lLiwgaGF2ZSB0aGlzDQo+ICAgICA+IGRyYWZ0IHNlcGFyYXRl IGEgc2VwYXJhdGUgbWVnYS1yYW5nZSBmb3IgdGhlc2Ugb3RoZXIgbW9kdWxlcyk/DQo+IA0KPiBT bywgd2Ugc2hvdWxkIGhhdmUgYSBzZWNvbmQgbWVnYS1yYW5nZSBhbGxvY2F0aW9uLCB3aXRoIGEg RkNGUw0KPiBjb25zaWRlcmF0aW9ucy4gIEkgd291bGQgYmUgaW4gZmF2b3VyIG9mIHRoYXQuDQo+ IChJdCBjb3VsZCBhbHNvIGhhcHBlbiBpbiBhIG5ldyBkb2N1bWVudCBvciB2aWEgc29tZSBvdGhl ciBJRVNHIGFjdGlvbi4pDQoNClRoYW5rcywNClJvYg0KDQoNCj4gDQo+IC0tDQo+IE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNv bnN1bHRpbmcgKQ0KPiAgICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90 dGF3YSBhbmQgV29ybGR3aWRlDQo= From nobody Wed Jul 14 03:03:29 2021 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 B153A3A0C87; Wed, 14 Jul 2021 03:03:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162625700369.11227.18056605126082947991@ietfa.amsl.com> Date: Wed, 14 Jul 2021 03:03:23 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-yang-cbor-16=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 10:03:24 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-yang-cbor-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Special thanks to Marco Tiloca for his shepherd's write-up, which contains a good summary of the WG consensus and the doc reviews. Please find below 2 non-blocking COMMENT points. I hope that this helps to improve the document, Regards, -éric == COMMENTS == A generic comment about the operational issue of supporting TWO ways to encode a data node: either normal string or the SID. This means that either there is a 2-way negotiation mechanism or that all CORE nodes must support both encoding and have agreed on a common SID mappings. Section 7 only briefly touches this issue with "Content-Type" but not with "Accept". -- Section 4.2.1 & 4.4.1 -- BTW, I like the idea of encoding a container with sequential SID and the delta CBOR encoding ;-) From nobody Wed Jul 14 04:05:18 2021 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 81E1E3A0827; Wed, 14 Jul 2021 04:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.896 X-Spam-Level: X-Spam-Status: No, score=-11.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mW/efcv5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lfEHV/Me 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 yG2AaqAjtIms; Wed, 14 Jul 2021 04:05:12 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEC33A0823; Wed, 14 Jul 2021 04:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7654; q=dns/txt; s=iport; t=1626260711; x=1627470311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1B0MkPXuCYV0rRIB4d7iHYCQnrEuu3QBpeCiIZi3vBI=; b=mW/efcv5v/07uWPH/7N5C+o4h5U2G7q5IgPAOyXY1aGxKkJOkCaljX2s SoI/qsQeKkF/CR255DbsP0BDXAYLXId0N4imueBQdz6bymnXAXL8DJRNd ZIR4g7j46ikkoO/wIutBKOemBJdw35qpbTqL01HwxMbHNoHCQzCxZfd2M c=; X-IPAS-Result: =?us-ascii?q?A0A5AACSxO5gl5NdJa1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UcFAQELAYFSUX5aNzGESINIA4U5iFkDgSaOQ4pEgS4UgREDVAsBAQENAQEqC?= =?us-ascii?q?wwEAQGEVAIXgmECJTYHDgIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBA?= =?us-ascii?q?QEBAWiFaA2GRQEBAQECAQEBEBERDAEBLAsBCwQCAQgRBAEBAwImAgICJQsVB?= =?us-ascii?q?QMIAgQBDQUIGoJPAYJVAw4hAQ6bMQGBOgKKH3qBMoEBggcBAQYEBIFJQYMyG?= =?us-ascii?q?IIyAwaBECoBgnqEDoJJH4N6JxyBSUSBFUOCYj6CYgEBAQKBKAESAQMggxU2g?= =?us-ascii?q?i6CHlwZagQYCgUIDAgIBgIgOxgeB2AFBQMOZJEtNYMNp3sKgySKM5QbEoNji?= =?us-ascii?q?1yXGoU0kFKCG4oUk1UPhHACBAIEBQIOAQEGNYEtCihrWBEHcBU7gmlQGQ6OH?= =?us-ascii?q?wwNCRWDOYUUhUpzAjYCBgEJAQEDCQGMCwEB?= IronPort-PHdr: A9a23:+UMauhbteH+GgKDlLscxzhn/LTAzhN3EVzX9orIsiqlFdeKo+JGxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoJ//xZCt8F 8NHBxdp+nihOh1TH8DzL1TZvny162sUHRPyfQp4L+j4AMjclcOyguuz4JbUJQ5PgWnVXA== IronPort-HdrOrdr: A9a23:DxHI3KPnXGGDfMBcT0f155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHPlOkMgs1NaZLUfbUQ6TTL2KgrGSuAEIdxeOk9K1kJ 0QD5SWa+eATWSS7/yKmjVQeuxIqLLsnczY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKH Pz3LsimxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlul9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4oow3TX+0OVjbZaKvq/VQMO0aeSAZER4Y DxSiIbToBOArXqDzmISFXWqlLdOX0Vmg7fIBej8AveSIrCNWgH4w4rv/METvMfgHBQ4e2UmZ g7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuJYO5gLZvt3+9Kq1wVh4SKbpXZt VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFoi/A3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki956IfII9FrN1CXaZ4u6fatK 6xJW+whFRCMn4GU/f+rqGj2iq9NFmAYQ== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,238,1620691200"; d="scan'208";a="721135689" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2021 11:04:52 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 16EB4qkp014702 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2021 11:04:52 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 06:04:52 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 06:04:51 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 14 Jul 2021 06:04:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P2VP0qblC3br8o+I76Xzx3MM9ET8iWls/tbUM5A3eVA6oROARE9VQKiTCo61C4nVX5P8lDCEm+tZnYYVODAl31exNfUmCrnI2GhKixCqeLbaDmQj/dWBxu/kmZpj2I4L5+sTFkyjyUr9/NIZjTZvMDxhVlrvAOfIiAS50NJzU5T93KcLUxbD8IgeYUMDcnEAdGvXT5nvD3+pEklF4EFG+OB11CmDZzJVTqYoDAdSge9TT/JkBTx43Zy8y410Vuu9c1+a8VO2XZm1n0ojz/M75sPgW7efNdjzIpqCsHJOyts+q1o+eXKgBaUGibz3CkbZaYIaU51xHeLJmbw5w41E+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1B0MkPXuCYV0rRIB4d7iHYCQnrEuu3QBpeCiIZi3vBI=; b=TD1qdgyN3hAU1keg/8SGJ0H8CBwSx1JDjHhOB5EJY46TqBsGhSSewh0ZPe6xC9nYzOcjz/Py+0M/cwNPUxRzw0wcn3mUuvMpq/bQ/f3qw+JJG25glLn2xxGw2OQV+BbbI0FrhYf7vQfZjBhqtlB6+zrY41rzknEN93xAdzAQBN15vPYcPDG/re9TKEGEIwlOHTSlD8ZLTx2u5MazX6ugm1NtUnxVjwueUG8/UrsPjM1JtSsDePv7sc2a+zd8AnZ/ea393Wyy0CL4zlDhgheAjWXqRLVpKfVo6ZkCp4uc3/GjAtkknn9HQprmEEeQtH3P3HVaiIfPrBpsJh9ETrSK3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1B0MkPXuCYV0rRIB4d7iHYCQnrEuu3QBpeCiIZi3vBI=; b=lfEHV/MevD4axF925bNUpu0oGZjIpU7+DV4pFoibaCeWL8Y0RbAdQ/Q/B3pop6YPUYS/Puv61VhaFR28Hicot7rOQtMBaGJxncIRpB9Cb1GGs6krdYGtAfmGNKc4CBQ6nE+r1Dzt8KkjAxT6Ow17fsaDQ3Ko4EgqNmPfcxtc5Kk= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB4012.namprd11.prod.outlook.com (2603:10b6:5:6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Wed, 14 Jul 2021 11:04:50 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4331.021; Wed, 14 Jul 2021 11:04:50 +0000 From: "Rob Wilton (rwilton)" To: "Eric Vyncke (evyncke)" , The IESG , "draft-ietf-core-sid@ietf.org" CC: "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1j?= =?utf-8?Q?ore-sid-16:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXeHLwbcCzBxzHpUK9Esnj41U3kKtCQHgg Date: Wed, 14 Jul 2021 11:04:50 +0000 Message-ID: References: <162624127733.15124.15333004711651272795@ietfa.amsl.com> In-Reply-To: <162624127733.15124.15333004711651272795@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5a93f85-c286-4256-eb89-08d946b73351 x-ms-traffictypediagnostic: DM6PR11MB4012: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EwNbtCgLN9xrJsYPdEGdm5qfzw5DAXFlIcvrsLum0w2Ye2Z4G+gDdw8BVOjhA8SnJhD33zy8DJ8RhabS1hOvmcVc8lRmxgLH3URpYvAISlUd9iwHHVXkRQWUveV3lE6axKzP3fxf+MejfKOv35XcJTaH5ox5Oikko9/pi+z02xZj2GE7ypruZLNH/8kyIbgjDdGhePjs2mY2QUe0/aMpRFqmeLW0vIeJBSF1nmixPW/0EkUmhoUSQNabTb9xWp5hbHDPB7PuCSmESKntO+8mQ0jdIf2tywvkrob7CG3gFj8Eemy4HqvA7lTdIydQ47wBPL//+1GdV7R7IBMuZK08JHxOGBtKdkgAQlnU1ne2yKa1GtAcAAMSjAj9Nj/KPTUxxOnyn+CuUoFL25zBnNmLmIg10f7aZQltJl4kL0kLEKv+dfzfSmGFgmSdmOU0VdUi0ISO0n37Z6FavjmndogZP1BaSzZgsYBu+kQXzBPHsw1h1uRmh46TBllels49g4k4IiyeSzuVjWycah7iojhxxXmUSbmTTepY3m8fFGPvf7HEgESIQJ4WE6cejpJ30ZGOhX9vPo4SlRWjhMRJunW2LLfkpVSudOQI5Wo1R7rQ++9qmHflEqbuAVayV1TRO9XZ3P8z5a/oc6A0ODXMjQveeCwteQRc6MI4LOOs34WxdG52/6qKeaCqWv6IbTwsis9QFurC5hzcKw8QdPjrasEHz0uf49oCbtaBK4hxTj6IAKsdRcC/6V/i3OhKlKlBNEc0o2Uq8j8ksCsWwNgExgo0C/xYUbcKPq3qbkXiO+ETEussudp6lyPpxUJXSGVgLETNtFSOIo9pouxUZI0JsYe53w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(39860400002)(396003)(9686003)(186003)(71200400001)(5660300002)(66446008)(86362001)(2906002)(66946007)(4326008)(76116006)(66476007)(26005)(66574015)(66556008)(64756008)(83380400001)(224303003)(52536014)(54906003)(53546011)(6506007)(450100002)(8936002)(110136005)(55016002)(33656002)(122000001)(7696005)(478600001)(966005)(316002)(38100700002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cWorZzlCdUVxMHdtQm43R2JIbEI5WGN4ek42T0k1aTNJSk1kUk5oTDdTVWR1?= =?utf-8?B?RUlCWm1IMUdDajl4cU00VkxISlF1SDBIV21TUFhLbm1hU2ZZN0tZMjdhMnlU?= =?utf-8?B?dGNMUkcreE1FUWJVWnhlZUVkSE92cHVJWGlIRVBIcjF2aXB0NmZhN2REK0dS?= =?utf-8?B?dEFjTDkwKzRjek5acWdpek5UTGZRWjRpQlFMUUlZMm9PVUZvZ0xzdDNaTUNO?= =?utf-8?B?Z3BhQXBsS0lyUCs3VjNjTjRHcEdPYzRIN2RvT01kV0tndHkrVlhaTjQxTE9G?= =?utf-8?B?bWUwc0JjdU5uNS9yVTRZN2hQUUpqc0Q1RldvVFh5OFVtRWxzQUpZenlycDJi?= =?utf-8?B?dmlOdGVSWG1Mdm5veTFDNnE2YkJ3d3d3MVhVWklUN2l3THdTRzZhM3RRMUFC?= =?utf-8?B?VlJxTk94SjFFemNET3JLajBxTFkxNTNLTHBYSmV1c25hbkFzL0dSOEsxNXJM?= =?utf-8?B?Sks1S0dVd2ZvZDQwM3BJRGVhNHp5SFRNQ2t6Z3hXd0d5eVZwUGhOU3JKVkdF?= =?utf-8?B?OWU0ZVkvUFF6VmgvZkxxTUFDbzlOUnNncjhBWnFFT0ZWQUM1VUV1c0tWRS9U?= =?utf-8?B?MTlNb2xOMHlRYXRPT2FSZE1HVGxUeDM3VWUvbWJEaGhIS0FpeDdvQnFLQitD?= =?utf-8?B?a3RQK0RNazkyWkhzS2kwcU54dkI4MXZQb0dEbDVucGxnT3VORzQrSHc3UC9w?= =?utf-8?B?RXp5Si85aERQVURWZkp4N0xlTlBZemNSMVRqa1Y4V0FKYW9kL1BoVUtTdlRL?= =?utf-8?B?aTRPa0ZGUm9YY0llQUhJWGxGYmNYTFFkV1lqeUtpekNoY2dSRWN2OFFTTDNw?= =?utf-8?B?VWZyd2NqZWNxWkFwUGpuendrWUxQalFPUXFFMnYrTVJBcmRZWHFpcmIxOWJ2?= =?utf-8?B?M3JFckhWWG81UGREcDc3OWlXa0Z1Q1lad3hnRGd2M2hwK1g3SUdjMk1OeU03?= =?utf-8?B?MXkwcGI0OFl4dk1nbGtDSXRpbWcrNFd1cTlzQWpFVkRTNGhtU2lod2VYekg1?= =?utf-8?B?RC83d3RFMG5KNjNDTjFHNlErVm1lQXBwcWF1cW5ZUm82b1pXWVVSd2lUS0xB?= =?utf-8?B?bEpsbnZ1dG9FcVFwNFRyVzNuSXJWdWZqUXBmckdKVm1NMVVRODdiYitYVFQ2?= =?utf-8?B?RzdWTjl6UXQyeTJUY3FoTkpoTkZTWVJoLzVlNklSY0JzalY1QVZTU096cmtM?= =?utf-8?B?WitpdjdlTU5meVhLYTVmL2dsa2ZDRSswTzBBQWFMTnJxaXNaY0RORkVIMlk3?= =?utf-8?B?SVRVVisxZGdXM3Y5dEVsYjdESUMrWmZMbGxQN3ZXeVI3TWo4YTFrdVh2Ly9W?= =?utf-8?B?OTArVWlJdzZ1UXpHdHFUWGZ2TytmK1lXYzVPMmlERUtnNytoMEtXUFhyRGI4?= =?utf-8?B?aGpONTQ3WjFLSmhtWGxxYWh0OTd3b05iV1YyR2lnblZvc1laSDVwV2luRjcw?= =?utf-8?B?cVBRdVo0c21ieUhiUFIwNDVBN0VpY0VSVDlTZXFleDRJVmtkeFBvdG14cEYx?= =?utf-8?B?Z2ppbFRvZ1pYQ1dYZXdYT3FpclQ2VWUyUzZEMElPcW9JQTM1TG1GMllQRUdv?= =?utf-8?B?d3lDZmVvNlVzRENJZnVrMFkvQTF5bUhjQndvVExSRTRjbHV0VFRzUCtoSXMx?= =?utf-8?B?c0gvcU9HVjJWWVV6dVF3b05lSVhhbGxrZXhyOGRQNVB4eU9zemhFdDRIL1FV?= =?utf-8?B?N0lqR3JjYnVNQkt5TE9Kb29xbTdvbm1zYkJheXJxYTNRdWQrVUlhUE9hQjlF?= =?utf-8?Q?MrgOCUCtpbIrF6aoWR+2tQ4Oq0IPRgvFxBXNH7/?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5a93f85-c286-4256-eb89-08d946b73351 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 11:04:50.2257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M84QiFVeYiJUzpBPXdmoWA8UpT0mkqgnyUd5L2S4ytiWriKOB2EzdJXxCPI5Bg1WTXpetWIISYJanPLm7ODIsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4012 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 11:05:17 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSA8Y29yZS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Ygw4lyaWMgVnluY2tlIHZpYQ0KPiBEYXRhdHJhY2tl cg0KPiBTZW50OiAxNCBKdWx5IDIwMjEgMDY6NDENCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1jb3JlLXNpZEBpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0 Zi5vcmc7IGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2NvcmVdIMOJcmljIFZ5bmNrZSdzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLXNpZC0xNjogKHdpdGggRElTQ1VTUw0KPiBhbmQgQ09N TUVOVCkNCj4gDQo+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1jb3JlLXNpZC0xNjogRGlzY3Vzcw0KPiANCj4g V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNv cmUtc2lkLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1 bWVudC4NCj4gDQo+IFBsZWFzZSBmaW5kIGJlbG93IHR3byBibG9ja2luZyBESVNDVVNTIHBvaW50 cyAod2hpY2ggYXJlIHByb2JhYmx5DQo+IG1pc3VuZGVyc3RhbmRpbmdzIG9mIG1pbmUpLCBzb21l IG5vbi1ibG9ja2luZyBDT01NRU5UIHBvaW50cyAoYnV0DQo+IHJlcGxpZXMgd291bGQNCj4gYmUg YXBwcmVjaWF0ZWQpLCBhbmQgb25lIG5pdC4NCj4gDQo+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMg dG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gLcOpcmljDQo+ IA0KPiAtLSBTZWN0aW9uIDMgLS0NCj4gQXMgYSBZQU5HIG1vZGVsIGNhbiBoYXZlIHNldmVyYWwg WUFORyBtb2R1bGVzLCB3YXMgdGhlcmUgYSBkaXNjdXNzaW9uIGluDQo+IHRoZSBXRw0KPiB3aGV0 aGVyIHRoZSBTSUQgcmFuZ2UgaXMgYXNzaWduZWQgcGVyIG1vZHVsZSBvciBwZXIgbW9kZWwgPyBU aGUgSUFOQQ0KPiBzZWN0aW9uDQo+IHNlZW1zIHRvIHJlZmVyIHRvIGFuIGFsbG9jYXRpb24gcGVy IFJGQywgaS5lLiwgcGVyIG1vZGVsIGFuZCBub3QgcGVyIG1vZHVsZS4NCg0KSSBwcmVzdW1lIHRo YXQgdGhlIGFsbG9jYXRpb24gaXMgZG9uZSBwZXIgbW9kdWxlLg0KDQpPbiB0aGlzIHBvaW50LCBJ IHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHVzZSB0aGUgcGhyYXNlICJSZXdvcmsg WUFORyBtb2R1bGUiIHJhdGhlciB0aGFuICJSZXdvcmsgWUFORyBtb2RlbCIgaW4gdGhlIGRpYWdy YW0gaW4gQy4xLg0KDQoNCj4gDQo+IC0tIFNlY3Rpb24gNy41LjIgLS0NCj4gQUZBSUssIG1hbnkg WUFORyBtb2R1bGVzIGFyZSBub3Qgb3JpZ2luYXRpbmcgYXQgdGhlIElFVEYgKE9wZW4gQ29uZmln LA0KPiB2ZW5kb3INCj4gc3BlY2lmaWNzIG1vZHVsZXMsIC4uLikuIEhvdyBjYW4gdGhvc2Ugbm9u LUlFVEYgbW9kdWxlcyBnZXQgYSBTSUQgYXMgdGhlIHR3bw0KPiB3YXlzIHRvIGdldCBhIFNJRCBh cmUgYmFzZWQgb24gUkZDIChpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IHRoaXMgc2VjdGlvbiku DQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IA0KPiA9PSBDT01NRU5UUyA9PQ0KPiANCj4gSSB3aWxsIGxldCBteSBPUFMgYW5kIE1hbmFnZW1l bnQgQUQgdG8gY29tbWVudCBvbiB0aGUgdXNlIG9mICdZQU5HDQo+IHNjaGVtYScNCj4gcmF0aGVy IHRoYW4gJ1lBTkcgbW9kdWxlJyBhbmQgYWJvdXQgdGhlIHdvcmQgJ2l0ZW0nIGZvciBtYW55IFlB TkctDQo+IHJlbGF0ZWQNCj4gY29uY2VwdHMuDQoNClRoaXMgaXMgYSBnb29kIHBvaW50LiAgSSBt aXNzZWQgaXQgZm9yIHRoaXMgZG9jdW1lbnQsIGJ1dCBwbGFubmVkIHRvIHJhaXNlIGluIG15IFlB TkcgQ0JPUiBlbmNvZGluZyBkb2MgcmV2aWV3Lg0KDQpUaGlzIGRvY3VtZW50IHRhbGtzIGFib3V0 IGEgc2NoZW1hLW5vZGUgcGF0aCAocHVsbGluZyBpbiB0aGUgdGVybXMgZm9yIHNjaGVtYSBub2Rl IGFuZCBzY2hlbWEgdHJlZSBmcm9tIFJGQyA3OTUwKS4gIEhvd2V2ZXIsIHRoZSBTSUQgZmlsZSB0 aGF0IGhhcyBiZWVuIGdlbmVyYXRlZCBkb2VzIG5vdCBzZWVtIHRvIGZvbGxvdyB0aGUgc2NoZW1h IHRyZWUsIGJ1dCBpbnN0ZWFkLCBpdCBsZWF2ZXMgb3V0IGFueSBub2RlcyBpbiB0aGUgc2NoZW1h IHRyZWUgdGhhdCBkb24ndCBleGlzdCBhcyBkYXRhIG5vZGVzLCBleGNlcHQgZm9yIHJwY3MsIGFj dGlvbnMsIG9yIG5vdGlmaWNhdGlvbiBub2Rlcy4gICBTcGVjaWZpY2FsbHksIEkgd291bGQgbm90 IGV4cGVjdCB0byBzZWUgU0lEcyBmb3IgJ2Nhc2UnLCAnY2hvaWNlJywgJ2lucHV0JyBhbmQgJ291 dHB1dCcgbm9kZXMgdGhhdCBleGlzdCBpbiB0aGUgWUFORyBzY2hlbWEgdHJlZSwgYnV0IGRvbuKA mXQgZXhpc3QgaW4gdGhlIFlBTkcgZGF0YSB0cmVlLg0KDQpTbywgSSB0aGluayB0aGF0IHRoaXMg ZG9jdW1lbnQgcHJvYmFibHkgbmVlZHMgdG86DQogLSBJbXBvcnQgImRhdGEgbm9kZSIgZnJvbSBS RkMgNzk1MC4NCiAtIFVwZGF0ZSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGFsZ29yaXRobSB1c2Vk IHRvIGdlbmVyYXRlIFNJRHMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgZm9sbG93aW5nICJzY2hlbWEg bm9kZXMiIGFyZSBlbGlkZWQgZnJvbSB0aGUgJ3NjaGVtYSBwYXRoJyB0aGF0IGlzIGdlbmVyYXRl ZCAoJ2Nob2ljZScsICdjYXNlJywgJ2lucHV0JywgJ291dHB1dCcpLCBidXQgdGhlaXIgY2hpbGQg bm9kZXMgYXJlIHByb2Nlc3NlZC4gIE9yIHRoaXMgY291bGQgYmUgc3RhdGVkIGluIHRoZSByZXZl cnNlIHNlbnNlIHRoYXQgU0lEcyBzaG91bGQgYmUgZGVmaW5lZCBmb3IgYWxsIGRhdGEgbm9kZXMg YW5kIGFsc28gInJwYyIsICJub3RpZmljYXRpb24iLCBhbmQgImFjdGlvbiIgc2NoZW1hIG5vZGVz Lg0KDQpUaGlzIGJsb2NrIG9mIHRleHQgaW4gQXBwZW5kaXggQiBhbHNvIHNlZW1zIHRvIGJlIHdy b25nOg0KDQogICBOb3RlIGFsc28gdGhhdCBSUEMgb3IgYWN0aW9uICJpbnB1dCIgYW5kICJvdXRw dXQiIGRhdGEgbm9kZXMgTVVTVA0KICAgYWx3YXlzIGJlIGFzc2lnbmVkIFNJRHMgZXZlbiBpZiB0 aGV5IGRvbid0IGNvbnRhaW4gZGF0YSBub2Rlcy4gIFRoZQ0KICAgcmVhc29uIGZvciB0aGlzIHJl cXVpcmVtZW50IGlzIHRoYXQgb3RoZXIgbW9kdWxlcyBjYW4gYXVnbWVudCB0aGUNCiAgIGdpdmVu IG1vZHVsZSBhbmQgdGhvc2UgU0lEcyBtaWdodCBiZSBuZWNlc3NhcnkuDQoNCkkgZG9uJ3QgdGhp bmsgdGhhdCB5b3Ugd2FudCB0byBnaXZlICJpbnB1dCIgYW5kICJvdXRwdXQiIGRhdGEgbm9kZXMg U0lEcywgYmVjYXVzZSB0aGV5IGRvbid0IGFwcGVhciBpbiB0aGUgZGF0YSB0cmVlIGVuY29kaW5n LCBlLmcuLCB0aGUgWUFORyBDQk9SIGRyYWZ0IGluZGljYXRlcyB0aGF0IHRoZXNlIGFyZSBjYWxj dWxhdGVkIHJlbGF0aXZlIHRvIHRoZSBSUEMgbm9kZSBpdHNlbGYsIG5vdCB0aGUgJ2lucHV0JyBv ciAnb3V0cHV0JyBub2RlcyB0aGF0IGRvbid0IGFwcGVhciBpbiB0aGUgZGF0YSB0cmVlLg0KDQpU aGFua3MsDQpSb2INCg0KDQo+IA0KPiBJIGtub3cgdGhhdCBBbGV4IFBlbG92IGlzIGFuIGF1dGhv ciBidXQgd2FzIHRoZXJlIGFueSBkaXNjdXNzaW9uIHdpdGggTFBXQU4NCj4gV0cNCj4gb24gdGhp cz8NCj4gDQo+IE5vIG5lZWQgdG8gcmVwbHkgYnV0IHRoZSB1c2Ugb2YgIi5zaWQiIHRvIHF1YWxp ZnkgYSBmaWxlIGZvcm1hdCByZW1pbmRlZCBtZSBvZg0KPiBNUy1ET1MuLi4gOy0pDQo+IA0KPiBJ IGFtIHNvbWVob3cgY29uY2VybmVkIGJ5IGhhdmluZyBzbyBtYW55IFNJRHMgYmVpbmcgZ2VuZXJh dGVkIGFzIGl0DQo+IHJlcXVpcmVzDQo+IGJlaW5nIGNhcmVmdWwgaW4gZ2VuZXJhdGluZyB0aGVt IGFuZCBoYXZpbmcgYSBzY2FsYWJpbGl0eSBpc3N1ZSB3aGVuIHVzaW5nDQo+IHRoZW0NCj4gYXMg dGhlICdtYXBwaW5nIHRhYmxlJyBjb3VsZCBiZWNvbWUgcXVpdGUgbGFyZ2UuDQo+IA0KPiAtLSBB YnN0cmFjdCAtLQ0KPiBTdWdnZXN0IHRvIGFkZCB0aGUgcmVhc29uIHdoeSB1c2luZyBTSUQgaW4g Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzIGZvcg0KPiBwZW9wbGUNCj4gb3V0c2lkZSBvZiBDT1JF IFdHIDstKQ0KPiANCj4gLS0gU2VjdGlvbiA0IC0tDQo+IEluIGFkZGl0aW9uIHRvIGEgcmVmZXJl bmNlIHRvIFJGQyA3OTUxLCB3aHkgbm90IHNpbXBseSBhZGRpbmcgdGhhdCB0aGUgdGhlDQo+ICIu c2lkIiBmaWxlIGlzIGVuY29kZWQgaW4gSlNPTiA/DQo+IA0KPiAtLSBTZWN0aW9uIDcuNC4xIC0t DQo+IE91dCBvZiBzaGVlciBjdXJpb3NpdHksIHdoeSB1c2luZyBhIGRlY2ltYWwgbWlsbGlvbiBy YXRoZXIgdGhhbiB0aGUgdXN1YWwNCj4gcG93ZXINCj4gb2YgMiA/IEFnYWluIGp1c3Qgb3V0IG9m IGN1cmlvc2l0eSA7LSkNCj4gDQo+IC0tIFNlY3Rpb24gNy41LjMgLS0NCj4gU3VnZ2VzdCB0byBl aXRoZXIgcmVtb3ZlIGVudHJpZXMgcmVsYXRlZCB0byBpZXRmLWFuaW1hLWNvbnN0cmFpbmVkLXZv dWNoZXINCj4gb3INCj4gbW92ZSB0aGlzIEktRCBpbiB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMg c2VjdGlvbi4NCj4gDQo+ID09IE5JVCA9PQ0KPiANCj4gLS0gU2VjdGlvbiAxIC0tDQo+IFN1Z2dl c3QgdG8gZXhwYW5kICJZQU5HIFNJRCIgYWdhaW4gYXMgdGhlIGFic3RyYWN0IGlzIG5vdCByZWFs bHkgcGFydCBvZiB0aGUNCj4gZG9jdW1lbnQuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+ IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3JlDQo= From nobody Wed Jul 14 08:15:35 2021 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 A9F143A1E1E; Wed, 14 Jul 2021 08:15:22 -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, SPF_HELO_NONE=0.001, 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 0oglGvlSoyzS; Wed, 14 Jul 2021 08:15:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9873A1E1B; Wed, 14 Jul 2021 08:15:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8335738B57; Wed, 14 Jul 2021 11:18:12 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n5cEWoiXfhBq; Wed, 14 Jul 2021 11:18:09 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A2D538B4B; Wed, 14 Jul 2021 11:18:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 50534375; Wed, 14 Jul 2021 11:15:11 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3Fq=3F=3DC3=3D89ric=5FVyncke=3F=3D?= cc: "The IESG" , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org In-Reply-To: <162624127733.15124.15333004711651272795@ietfa.amsl.com> References: <162624127733.15124.15333004711651272795@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 15:15:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =C3=89ric Vyncke via Datatracker wrote: > -- Section 7.5.2 -- > AFAIK, many YANG modules are not originating at the IETF (Open Config= , vendor > specifics modules, ...). How can those non-IETF modules get a SID as = the two > ways to get a SID are based on RFC (if I understand correctly this se= ction). {Speaking as an interesting party who has a SID dependancy in draft-ietf-anima-constrained-voucher, and who are doing interop next week during the hackathon...} The original intention was that there would be multiple providers of SIDs v= ia mega-range allocations (7.4), and that most major entities would allocate that way. I see no reason why larger vendors couldn't allocate that as wel= l. Section 7.4 is Expert Review. The authors originally operated a web interface, and were hoping to hand th= at to IANA and/or secretariat. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDu/34ACgkQgItw+93Q 3WXoqAf4s7sB1sbe6dhmxqbXem7oxq9OZmHI5zoda5FwsZriLMgY2Y4A7sTqoyQD 1y7KQCR2fDnSf969jwCE+gaAItsJxMc3uzGMriik2selfnXjHrcIkZiTRE6jd2Y4 +CIG114R8c43C3GhXjXfr60FlyiV3kh+XHTUWE5SJ2bm/mUBRqA4Q0q5S7IVOfPO 4yutjhVMecLpvOzDxu6O1PKyjlf/6cYB3Oq2tTeYF28EEy4Np0/5HDOEt+7mCg0a 3O27Ddl6EJVyNMMLU3Kbj/81LXl4GvsXPda/VXXg8xOru6i0z5SGFeZHitrnkHu1 mLYVMjG4w36n941On0RnixrESs8P =cX6p -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 14 09:53:17 2021 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 0135E3A1F63; Wed, 14 Jul 2021 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtZktxEqCEHK; Wed, 14 Jul 2021 09:53:11 -0700 (PDT) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DB83A24D4; Wed, 14 Jul 2021 09:53:00 -0700 (PDT) Received: from dooku.sandelman.ca (cpef81d0f835a73-cmf81d0f835a70.sdns.net.rogers.com [174.116.10.168]) by relay.sandelman.ca (Postfix) with ESMTPS id 1BFDF1F479; Wed, 14 Jul 2021 16:52:58 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id D8C691A0484; Wed, 14 Jul 2021 12:52:55 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , draft-ietf-core-sid@ietf.org cc: "The IESG" , core-chairs@ietf.org, core@ietf.org In-reply-to: <162621573715.1426.3300364400283622807@ietfa.amsl.com> References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> Comments: In-reply-to Benjamin Kaduk via Datatracker message dated "Tue, 13 Jul 2021 15:35:37 -0700." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Wed, 14 Jul 2021 12:52:55 -0400 Message-ID: <219605.1626281575@dooku> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 16:53:15 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk via Datatracker wrote: > (1) I think there is a new security consideration with this work that > is important to document clearly -- not only do we define a new type of > identifier, but we define a file format and other mechanisms for > disseminating that information. An entity that's processing > application/yang-data+cbor; id=sid information needs to ensure that the > .sid files (or other source of SID information) it uses for such > processing came from a trustworthy authority (or at least the same > source as the data file). It would be possible for malicious > manipulation of .sid file contents to cause a message recipient to > mis-interpret the received message without any indication of such > tampering. You are right. While I guess it is conceptually correct to think that someone will create some universal CORECONF recipient that can process .sid files and do something real, I think that such a situation is probably not sane. We also don't sign YANG files, except that, they are embedded in RFCs, which are now signed. (I don't think we have resolved the question of how/if/when we provide the sid file to IANA when part of another RFC. In theory, IANA creates the sid file when the YANG module is first provided. In practice, we need it for interop work prior to WGLC) We are using sid files for draft-ietf-anima-constrained-voucher, and we have at least five implementations that we will test next week. I don't think that any of us did anything other than transcribe the SID files into a #define/enum or equivalent. Now, we are working on YANG-at-rest rather than RPC. Even if we got to the point where we could more sensibly pull .sid files into our source code in more automated fashion, there is still the question of semantics of what we are doing. I suppose that we could ask IANA to JOSE sign the SID files. If this is really something that we think we should do, then let's have a discussion with IANA about doing that, and then write a new document. So, let me propose this text: OLD: 6. Security Considerations This document defines a new type of identifier used to encode data models defined in YANG [RFC7950]. As such, this identifier does not contribute to any new security issues in addition of those identified for the specific protocols or contexts for which it is used. NEW: 6. Security Considerations This document defines a new type of identifier used to encode data models defined in YANG [RFC7950]. This new identifier maps semantic contents to integers, and if the source of this mapping is not trusted, then new security might be occur if an attacker can control the mapping. At the time of writing, it is expected that the SID files will be processed by a software developer, within a software development environment. Developers are advised to only import SID files from authoritative sources. IANA is the authoritative source for IETF managed YANG modules. Conceptually, SID files could be processed by unconstrained target systems such as network management systems. Such systems need to take extra care to make sure that they are only processing SID files from the same authoritative source as the YANG modules that they are using. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmDvFmYACgkQlUzhVv38 QpC+xwf/Ys4vu+X+pFDIN1eBNqW7njlrp6whlIefraoXty+eJyFeL7EhjQabT6qd mt7S6QyQxpRyqThc10E1O6pOqLbsZV8xF+cv3TdRp0PkuU0UKKz5bxUsHvtqEsfC gkIfEVrBn/dRZmqsenH0/F/p072vWrlEpImDEVZvCeSEx4rizKv60m+m+HnenoF6 0VrisncEb47UlLEOUuY+AU+r6Kbjk6ix5BmqOIr/aGU/qFtoT0mGMzEeSnN//iYz xuxlu+FnZMoFusw4Nwy4cB7p8GvPxcHpcojq0lICZx9tl1hRiDjzAIgwhhqRmXPE +bobu3s5LpLn26UjZFROt0j6XKQJ9A== =45Py -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 14 10:22:02 2021 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 A87F43A0141 for ; Wed, 14 Jul 2021 10:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 jle_WOKyGGfH for ; Wed, 14 Jul 2021 10:21:55 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60069.outbound.protection.outlook.com [40.107.6.69]) (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 6502B3A0128 for ; Wed, 14 Jul 2021 10:21:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g80o1o6Q8tdLYVbkaZcM9lQDgxXTkEF5Ku0QjeDv/mzz5OhFjRJEymx7GJeahmsOya/Xw/Psmna/i0nc9FUmbEb9LHFFEkoLz2YYcy0HkabS24dTs1KRNvwT+gCoaTg+qn7UG3ZhFeEcuEahnKYSMXoBX1gHnGxp8N9d2Q6ED/mtdbDWG3C097Xi+JsfljA/E0skgL5hn615ddpCO7169lCrumZk86BcB/ylO927kz05YIDMrb75tF9301eQ2nLYkHDMoGvkQssKxzqAgej6rj5oS/MUIbW6wpNwdPd8vrdjwnPA+MsH7dAYdU80QYeevF1QtgqjrZzlw4nbHjW30g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10O7dBKrtdPwMX96NsRltywYyszWs+np7KdbaHy8Pj4=; b=KXjCC3gG8VgeJqQi/5jchQCJS1IFJNuBDTU41bgwJKw6psiQZSfAkDJ1uTXCTWweFraqtszGpQEmUEKeiCPetWODuNnTbBmwrZ/9jNgZ7o7FGVKsQul1LEGf7rSd7xm+NLJbIP57HAZJaBBXSNH7p4JpxwVEGgzHwxeVggseAVMeheuWRnfl8ifSpdDO/PDO5jDttARxtNy8s87pXB75KOBWuumYXwWqnCGHV46I6QuZWziTVCrH4opuhJccU/PDMJqKIW7gFuF98TIZmAVMs4R9j8USF+H7aF/66B2Vaa1uKXnMtGR8PlFM+z4gVK4tb9PSn9wZnQ0fZomyq54wPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10O7dBKrtdPwMX96NsRltywYyszWs+np7KdbaHy8Pj4=; b=K0ENiIMEjmL7w5hOy1NjE+xESDXJyCdW/yv/5yzHBgMAbvPE4Bd55OUXrYmIJjbEY2597feO2zkyKE2KPG8Hpq21tjxgfOgdwCdy5ZCQMW7nJmoKaL5/qHm6jrxKhaWz27TbgQYB1deb7friPHBKG11HL+CVdMz4GIK+pJshs2E= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1323.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Wed, 14 Jul 2021 17:21:52 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4308.027; Wed, 14 Jul 2021 17:21:52 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Wed, 14 Jul 2021 19:21:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4cNmjzzqul5kIEWkIVqcPeV5H7eohnjAI" X-ClientProxiedBy: HE1PR0402CA0042.eurprd04.prod.outlook.com (2603:10a6:7:7c::31) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.3] (185.219.140.246) by HE1PR0402CA0042.eurprd04.prod.outlook.com (2603:10a6:7:7c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Wed, 14 Jul 2021 17:21:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8b9605a2-fabd-484e-3d25-08d946ebdf44 X-MS-TrafficTypeDiagnostic: DBBP189MB1323: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 28Aifc6KoCFz2FMspIHKWJeRnNcfNVHYMMc1yYyieC0OzhoYrPcObHKK0NmLy38S4RUx5B4n+2nQXuncMaa0aD0wnkDNOSAhu3vFlV4be9xn/LZ9VAzLYdUb/dDQHnz/x3fSOy+tV9hDslxXR6g0d1scNFF6gX0Fz5Hkxmyo8ZuxWY23deb6A39jwnnCj4RiznP1oYxWzXWU2E9KzLyAnoIyEDXtwq+/fR7WWP3QtHXMarpVVGB4ZB9lF54Yc+HYgxvzh1iS/3y2cY9Nv7TuZadDR2zTFDZG9S2H3YY9qm4/CJca+6NUkpvdhknr7d5m4F2xRarBbmmjowVkD0Puxjl4RJ78H86wWfM1FlQR1aP2ypiWj4uKA/BbA+AK9QjbInNn6G5PEodSgu12lF8OQ2SvIt8NF01e1HOLa3cj7mI0V6NgW5J1dYjo6hj6HMRHaCh4Jriyu0/HvaXVwO4S7GfwTlWo/V0REcugJM80OUBt32StwPzjn9UPH4uEHdKxBXhNMESjHvk2lj13Aq0752srBxqj7mDPEmYvMDxHERWVH2broc8TLKg/32z9AAHoEC/ZP+zEexuI/ieWs3r0Y/OfGsWhmZfVZLiOwHxhmedV/Bpje4ejxSf5mTfck8AgG91ePW/NTWgwiwyvRZb3i8NDdJ+QgCfzA8ns9jRXWV2ktFRGw21V8TLgPGJkBT4aJjv8dV4schEiP/iJj8Nmmpq+1sUHyLBJYmz8d6C/tuBkzFzbbyEWQM5bGgkBJlx6NgAdll8lNdQXtzv7zBWl6lB38eQVO249zf6zmVyaU3WFaA2AcnNHvnAsweHMP3Hf X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39840400004)(376002)(396003)(136003)(366004)(36756003)(38100700002)(21480400003)(966005)(316002)(478600001)(6486002)(16576012)(31696002)(2906002)(8676002)(66946007)(6916009)(31686004)(83380400001)(66556008)(33964004)(8936002)(235185007)(956004)(5660300002)(44832011)(26005)(66476007)(86362001)(186003)(2616005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ano4VGxBOWNxWkExb3BKNTJPMks3UEhrUXF3Z3p2dUR2dExHcVRXOUlqMncv?= =?utf-8?B?bnpiMWxxRHV5WTRpYmoycFJkWjhHcFNWcG9GRXdnNjFvdThSYnhvRWxicnZD?= =?utf-8?B?Z0pXWm9YZUZ3R0RyNUgraDRsdVhEZjl1R3hxWGRKa0dLam1BZk96Vi9Xa2Zz?= =?utf-8?B?WWNxazJzYngyR3dwMFlYS1VHNkM5SkJDU1gwU0hOYnd1OWxlZGd5OCtoTitJ?= =?utf-8?B?YVFkcHZPL3J3Vmw4NlNySFBENjRUeDJ2NHFVSThtMkpVR1ZpRTBrY3p3cE9F?= =?utf-8?B?ZlIvR3BnektpWEJHK0lGUUh5ZFpEZjIvM1g4bEpHZ0pjMjRuYlNyY3BYUlFF?= =?utf-8?B?bkYzbCtuQ3JqL3JTSEVjMVJrSzZxZEJ5TnYrcWpYYUZlOVJJL1JlbmorSjJF?= =?utf-8?B?c1hmYmIzajFYanlvcFk4aXZyM3Z1SzBTQzFKQm1RR1dMU0Rma004NWVRWmN4?= =?utf-8?B?MFNmNXgzUjVPNUV1QmF4SU11OUlDaE52UVZrenNuWnVwV1hnbFVWb0ZpZk5D?= =?utf-8?B?cjg3bFhTck9EY3g3RDQ3dkNPcXRndHdoaDdzZ0syS3c0QmpuRWt0UXZwUWdm?= =?utf-8?B?QWlBMFdKc3lERlB0VXNkSXJTekRQLzhyN1dvZmNiL0JrQmdFR2VQZFRsUjNM?= =?utf-8?B?R2QxK1k1enNoaG93K2RmbnVQc0RFTVJ3N0ZuVlRhTWtwSkJxYUtXMEZocjlY?= =?utf-8?B?blhWVVRpSWhnNmlFL0tJdEZodGFDTWJubnRyNU91czhxZWIzc0pqM2VRaFBL?= =?utf-8?B?aDhtd2YydXRENGFMdWx6MlJjUkNXcG9GMjB0UjFDTEpUK1BxcUZtYlh3RWRK?= =?utf-8?B?MmN5VEVUTlJsaCtZVURLRHlPRTI0dDRhZWZ3WjM3RzBEbThPYWVqT3pvSnk5?= =?utf-8?B?dnUzdDJTaTBCSzVEWEpIZjJOWWQ2NmV5aGRWOUIvdVVReVRRWi9pcWNHeFZC?= =?utf-8?B?UDRIVUYxQzc4cHpwSUgrVWhIanY5bzlJcHZxL25BbzBYR01YWHl5TW1MVWJ6?= =?utf-8?B?QjBaTWhGNGZYT3N3QkNJODRWNDNSV1JmTUllR2JBakU4SGxKNm1iMEs2aElY?= =?utf-8?B?NWU4L3FFb1h5bE5yUkhWbkRUajduc0RONkNMekJDMGVQZVAwNXpnK0RodmJF?= =?utf-8?B?dE53SzlLRTc3a1ZzUW9IZEF4NWNHNWt4RHZyUEZCYWFjQ0ZKWTRUVVhnajBU?= =?utf-8?B?OWxVOVdtVXVGWVRFRHkrdVppdWFwV2h2TVk4Mmpwck5WMDdSd24rZnQxaS9x?= =?utf-8?B?U1FYQTVaS0RPUVBUWm1LNHZ6Z2FMRzd0YllyVTVDWURQdXVTZXRTMjNkTlVJ?= =?utf-8?B?b0l4OVpqM1BGL1NlbGE5ZUNnS21oV25ORm15aEtHTDI1aWtsR0ppbXRvZHR4?= =?utf-8?B?N0NERkp6RC9jM1ZJam15SW03c3ZjUTVkN0picEc0MHVnYWQzRUh2Rjc2UWxh?= =?utf-8?B?SisvZW1UL0d4R1VIWXVnUmluOTdOQXBreTN4YjlMaEY3WHNMcnArbEpxMHhG?= =?utf-8?B?UUZLK0poZ2JJNHV1N2FBcklGZHFDV3c1djZaYWp5MHJHYjhsS01kNWtYOGlV?= =?utf-8?B?U1I3dDIveU1ZR1VqVEVEOE53aU1NK3RpaXRORlAwSnNnYXVCMllKZmV6TE5N?= =?utf-8?B?Ti9wUnNJQUxsWlRQSG1Dc2dXVXRYQVVyNVZ4N2o2a0d0VmZwVkJJM0NKakVP?= =?utf-8?B?Z3hobHMvblRCNVlmdkdjODVDMGZNeEh4TC9GR3ExZ0pFS1FoTEllbDVSckZl?= =?utf-8?Q?9ZQHB0KrcgFbdLmcEC1MANNI0Imcf0PbddiB5Vd?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 8b9605a2-fabd-484e-3d25-08d946ebdf44 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2021 17:21:52.8328 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mcMOdWFbL0A4BA2uDZtbrQIYFLXm6BNa42dcUL/RE/iGJBK330Gi8eWrhEQ0HoiaPzO0sJPQNal65QBwgEKX4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1323 Archived-At: Subject: [core] CoRE Agenda for IETF 111 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 17:22:01 -0000 --4cNmjzzqul5kIEWkIVqcPeV5H7eohnjAI Content-Type: multipart/mixed; boundary="6x1ms9bVzHyg5yRqaYOAcGCIpi1JVQFUq"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE Agenda for IETF 111 --6x1ms9bVzHyg5yRqaYOAcGCIpi1JVQFUq Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, An agenda based on what has been submitted and on recently ongoing=20 activities is now available at: https://datatracker.ietf.org/doc/agenda-111-core/ Those who want to run a slot, please: - check the person suggested to run the slot and possibly provide an=20 alternative; - check that the estimated time for the slot is ok Please, send a mail with this information or other comments to=20 core-chairs@ietf.org Best, Marco and Jaime --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --6x1ms9bVzHyg5yRqaYOAcGCIpi1JVQFUq-- --4cNmjzzqul5kIEWkIVqcPeV5H7eohnjAI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDvHS4FAwAAAAAACgkQ7iZktA5Y2kNe DQf+LZEh4vFxPiIos/RNEVwvqSiBwHx4M24WFrCYaAPAXlzI0sw2SuXKRnfxeTPjozXW2Iw5Ncq7 aakwBzaBhUQL1UAtITuYeZOXPgl3btNRmNS547EWjkodkIyAJKvzK2ABEJRMR8lAglejrabi2ZTW ZtN8S73liI1VX44i7MoBWg/We+/bVybaC1wVP2VeQKON75ICNT2qjhyhgV6rJfQDBrAb+WbcfUkI zAaUupeJ+8JkoJ0x6w0wYaXvVC/IamjszzgLrYcG/mSb+xE8G4cIsTM07mQnOn2pCyElOtKnMpNn z8Mr95UGOrvtsdT5HHue3ugtdMBuuPFcfwmsYRFByg== =DxEd -----END PGP SIGNATURE----- --4cNmjzzqul5kIEWkIVqcPeV5H7eohnjAI-- From nobody Wed Jul 14 10:32:40 2021 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 080EC3A0919; Wed, 14 Jul 2021 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoghFCrqlYbN; Wed, 14 Jul 2021 10:32:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 943E33A091C; Wed, 14 Jul 2021 10:32:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16EHWOZw025502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 13:32:31 -0400 Date: Wed, 14 Jul 2021 10:32:23 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: draft-ietf-core-sid@ietf.org, The IESG , core-chairs@ietf.org, core@ietf.org Message-ID: <20210714173223.GD74365@kduck.mit.edu> References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> <219605.1626281575@dooku> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <219605.1626281575@dooku> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 17:32:38 -0000 On Wed, Jul 14, 2021 at 12:52:55PM -0400, Michael Richardson wrote: > > Benjamin Kaduk via Datatracker wrote: > > (1) I think there is a new security consideration with this work that > > is important to document clearly -- not only do we define a new type of > > identifier, but we define a file format and other mechanisms for > > disseminating that information. An entity that's processing > > application/yang-data+cbor; id=sid information needs to ensure that the > > .sid files (or other source of SID information) it uses for such > > processing came from a trustworthy authority (or at least the same > > source as the data file). It would be possible for malicious > > manipulation of .sid file contents to cause a message recipient to > > mis-interpret the received message without any indication of such > > tampering. > > You are right. > While I guess it is conceptually correct to think that someone will create > some universal CORECONF recipient that can process .sid files and do > something real, I think that such a situation is probably not sane. I don't expect it to be the common case, right -- people will just hardcode in their software the SIDs they care about. But they do still have to get the SID information from somewhere (as you note in your proposed text below)... > We also don't sign YANG files, except that, they are embedded in RFCs, which > are now signed. ... and "obtained from IANA over https" seems like it would qualify as use of a trusted authority for both .sid files and YANG modules, under most threat models. > (I don't think we have resolved the question of how/if/when we provide the sid > file to IANA when part of another RFC. In theory, IANA creates the sid file > when the YANG module is first provided. In practice, we need it for interop > work prior to WGLC) (Also an interesting question, but probably not something that needs to be enshrined in the RFC.) > We are using sid files for draft-ietf-anima-constrained-voucher, and we have > at least five implementations that we will test next week. > I don't think that any of us did anything other than transcribe the SID files > into a #define/enum or equivalent. > Now, we are working on YANG-at-rest rather than RPC. > > Even if we got to the point where we could more sensibly pull .sid files into > our source code in more automated fashion, there is still the question of > semantics of what we are doing. > > I suppose that we could ask IANA to JOSE sign the SID files. > If this is really something that we think we should do, then let's have a > discussion with IANA about doing that, and then write a new document. Sure, I'm not proposing to hold up this document until there's a new technical solution, but rather to document the topic. > So, let me propose this text: > > OLD: > 6. Security Considerations > > This document defines a new type of identifier used to encode data > models defined in YANG [RFC7950]. As such, this identifier does not > contribute to any new security issues in addition of those identified > for the specific protocols or contexts for which it is used. > > NEW: > 6. Security Considerations > > This document defines a new type of identifier used to encode data > models defined in YANG [RFC7950]. This new identifier maps semantic > contents to integers, and if the source of this mapping is not trusted, > then new security might be occur if an attacker can control the mapping. "new security might be occur" doesn't make much sense to me, but "new security risks might occur" would. > At the time of writing, it is expected that the SID files will be > processed by a software developer, within a software development > environment. Developers are advised to only import SID files from > authoritative sources. IANA is the authoritative source for IETF managed > YANG modules. This looks really good, thanks. > Conceptually, SID files could be processed by unconstrained target > systems such as network management systems. Such systems need to take > extra care to make sure that they are only processing SID files from the > same authoritative source as the YANG modules that they are using. This topic also seems worth covering, so thanks for including it. It's not entirely clear to me that it's a security requirement to use the exact same source for YANG module and SID files or some other trustworthy authority might be acceptable, so we might want to think about this some more. Thanks again, Ben From nobody Wed Jul 14 12:32:58 2021 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 8DA733A0CDC; Wed, 14 Jul 2021 12:32: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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 tSnlxhP4tz6u; Wed, 14 Jul 2021 12:32:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31623A0CC7; Wed, 14 Jul 2021 12:32:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EB4CB389E6; Wed, 14 Jul 2021 15:35:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zplOzNcTKJDI; Wed, 14 Jul 2021 15:35:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D1BB389E5; Wed, 14 Jul 2021 15:35:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C6969486; Wed, 14 Jul 2021 15:32:41 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-core-sid@ietf.org, The IESG , core-chairs@ietf.org, core@ietf.org In-Reply-To: <20210714173223.GD74365@kduck.mit.edu> References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> <219605.1626281575@dooku> <20210714173223.GD74365@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 19:32:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {again, not an author of this document} Benjamin Kaduk wrote: >> (I don't think we have resolved the question of how/if/when we provi= de the sid >> file to IANA when part of another RFC. In theory, IANA creates the s= id file >> when the YANG module is first provided. In practice, we need it for = interop >> work prior to WGLC) > (Also an interesting question, but probably not something that needs = to be > enshrined in the RFC.) Someone has to document some interaction with IANA. I guess draft-ietf-anima-constrained-voucher, close to WGLC, will show us whether we got things right or not :-) {insert curse about living in interesting times} ... >> Conceptually, SID files could be processed by unconstrained target >> systems such as network management systems. Such systems need to ta= ke >> extra care to make sure that they are only processing SID files from= the >> same authoritative source as the YANG modules that they are using. > This topic also seems worth covering, so thanks for including it. > It's not entirely clear to me that it's a security requirement to use= the > exact same source for YANG module and SID files or some other trustwo= rthy > authority might be acceptable, so we might want to think about this s= ome > more. I'm just trying to say: if you trusted IANA for the .yang, then trust them for .sid. If your source of truth was IEEE, then get the .sid from them to= o. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDvO9kACgkQgItw+93Q 3WVG+Af+NOG6oUL7WAI+F6E9yVRpvFrnD46kMcP7PGKW2+rU19+KGC8Y4armEQcA rqQ/xgHyRX45npihdOqFBkW0fMhfdprVYrPwot3LUYYwBLZNEIuiTViLU3dWMQwW 88FoebcrNuDe6VEMuw0opEgIisaA7Y99OpVtOodalZ0Lp9VkeRPrtj+geI5Y6eGg 0EB+EBziHjj6wKoPvnyUk5Zqwrf30Nw876//QII+uEZ+QbCMqNTNFbFZrqLmJeiG TGrh/yVLahP8yQ9ov05Zk3FjBDYDZ15xfqXarEAfKUlhzYeM02SObMsVBhmVYvFx VGMoHVnMfQRFF3Ww0coYf4hyI1fGbg== =Aom0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 14 13:57:12 2021 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 60EDF3A08F8; Wed, 14 Jul 2021 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T6LU2YrY4PQ; Wed, 14 Jul 2021 13:57:01 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3813A08E7; Wed, 14 Jul 2021 13:57:01 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GQ8vH43yZz2xP6; Wed, 14 Jul 2021 22:56:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <24058.1626275711@localhost> Date: Wed, 14 Jul 2021 22:56:59 +0200 Cc: =?us-ascii?B?PT91dGYtOD9xPz1DMz04OXJpY19WeW5ja2U/PQ==?= , The IESG , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 647989019.129517-cd30c0edf16f16189e3d302c10be84cd Content-Transfer-Encoding: quoted-printable Message-Id: <577D49C6-9071-49C3-90B6-8EC45D955A84@tzi.org> References: <162624127733.15124.15333004711651272795@ietfa.amsl.com> <24058.1626275711@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 20:57:07 -0000 On 2021-07-14, at 17:15, Michael Richardson = wrote: >=20 > The authors originally operated a web interface, and were hoping to = hand that > to IANA and/or secretariat. That interface is still there: https://comi.space I just got myself a SID range of 1000 SIDs at 1010000. Obviously, this second megarange needs to be in the megarange registry. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 14 14:05:19 2021 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 657CC3A0C51; Wed, 14 Jul 2021 14:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Tf1CNWfx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZkeNaHkH 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 qSWM3ByYys25; Wed, 14 Jul 2021 14:05:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AF43A0C4E; Wed, 14 Jul 2021 14:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2994; q=dns/txt; s=iport; t=1626296707; x=1627506307; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=phRxRdNbMzHLPMARA+RqdwfT2zmXnNRDKSqRbBFhFrU=; b=Tf1CNWfxGpLc/aKEzY8Dqal8K1SLnEjKqwBiMjuAj9TMQw5TOufitWtO b1SsfiAdhFRyy0MXvT7lj8mHp9Ew11hioVztW8WXhMNMDaTCGZSdHET2G oFYX593NybkigRVvqRFWQoUWNWUiOLhgtKkUZIBzyBRTyxXNq5FFfQx3F 4=; X-IPAS-Result: =?us-ascii?q?A0BnBAAbUe9gl4wNJK1agQmBWYFTUYFYNzGESINIA4U5i?= =?us-ascii?q?FwDgSaZB4EugSUDVAsBAQENAQFBBAEBgWCCdAIXgmICJTYHDgIEAQEBAQMCA?= =?us-ascii?q?wEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GRQEBAQQSEREMAQEpDgELB?= =?us-ascii?q?AIBCBEDAQIBAgImAgICMBUFAwgCBA4FIoJPglYDLwGbcAGBOgKKH3qBMoEBg?= =?us-ascii?q?gcBAQYEBIVKGIIyCYEQKoJ7hA6CSYQZJxyBSUSBFSccgmI+hESDFzaCLoQBg?= =?us-ascii?q?U4EEgcHXgURkkaDDad8CoMkmFmFXQUmpluFNbVXAgQCBAUCDgEBBjWBLQ4kg?= =?us-ascii?q?VtwFWUBgj5QGQ6OKw0JFYM5il5zOAIGAQkBAQMJAYwcAQE?= IronPort-PHdr: A9a23:UKUbrBVwjc44n8b6TDMSuAlz/LHV8K0eAWYlg6HPw5pVe6Kv8pDnN UqZ7vw+xFPKXICO7fVChqKWtq37QmUP7N6Ht2xKa51DURIJyKB01wwtCcKIEwv3efjtaSFpB 81EWFJh+ni9d0NcS47yYlTIqSi06jgfUhz0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1a h6xqFa5iw== IronPort-HdrOrdr: A9a23:jX2c66pd5HgipGfpjN4+Q6saV5ufL9V00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90KnpewK6yXbsibNhfYtKLzOWxldAS7sSrrcKogeQWhEWk9Q86U 4OSdkENDSdNykesS++2njFLz9C+qjEzEnLv5al854Fd2gDAMsMg3Ybe2Sm+w9NNXR77PECZf yhD7981kKdkAMsH72G7xc+Loz+juyOsKijTQ8NBhYh5gXLpyiv8qTGHx+R2Qpbey9TwJ85mF K11jDR1+GGibWW2xXc32jc49B9g9360OZOA8SKl4w8NijssAC1f45sMofy+Azd4dvfr2rCou O8+ivIDP4Ds085uVvF+icF7jOQlgrGLUWSk2Nwz0GT/PARDwhKevapzbgpAicxrXBQ4O2VFM lwrjykX109N2KeoM213am7a/kh/HDE0kYKgKodiWdSXpAZb6IUpYsD/FlNGJNFBy7i7ps7ed MeQf00ycwmOm9yVUqp9FWHAebcKEgbD1ODWAwPq8aV2z9ZkDRwyFYZ3tUWmjMF+IgmQ5dJ6u zYOuAw/Ys+AfM+fOZ4HqMMUMG3AmvCTVbFN3+TO03uEOUCN2jWo5D67b0p7KWheYAOzpE1hJ PdOWko+VLau3ieQfFm+ac7vCwlbF/NKQgF+/surqSR4IeMMYYDGRfzP2wTrw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,240,1620691200"; d="scan'208";a="741486207" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2021 21:05:06 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 16EL56jS029307 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2021 21:05:06 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 16:05:06 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 17:05:05 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 14 Jul 2021 16:05:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h6pGLYFuN4kBVYJYbor0TgXUnpU6DGt7555yhYqYZP7X7527UANJMzklAJXPaUDhRaB25jllgvt+vHW5NlphRarmsHSX5DADZWJ3hMwWXPexCU9LN0NNYQE6k8m/ahfjUQxYriY5egBbpYsTXvjyB7b9Fz9inXqUxZEcV2vBJgAclHyCt49tyZtjCdVfAyLAz8pvwK+/ZeA7rqSBP2csvkpzUY9BKuOJj+dNKuJiGuGgAz8X8e4UEPrCqS+acSCyCp0bOcGotJb9Fa7s/Md04dsb8UP9m5GXRAL4xLM/UtWX1Y2giULo0x1OV5pisFei66k5pWHwVx/TPy2GkwwGFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=phRxRdNbMzHLPMARA+RqdwfT2zmXnNRDKSqRbBFhFrU=; b=QwW+j4Lq7i2Qm6KBIcJakhAimvjobDdYaitnruZjOGv6zTunBK2l8yLawrC+zjmioNlq+kf526E2r3jvpphSDYKa89rLg+xqZaFIPR9ZsfJTDvDiOR5byurLMy3T3W5S9JUoGqDMQE6jR9WrC81PutYWzZKEXr3WL9dfqriD6EwubVZm4bGVWaT6fZXYEKHbe/0D5A0jcToJ8uEOyMWFNzgJtYFVJ5yf14YoTPPlBRas4lKqI8NzMZE9yl/jW/U+4yl1dt86sfh9Fc/X+ZyNwqzdXvozZw3zXZU1ii8MsqEOfon2ffJP1at3UFU52l5ajYv5HVEM5BJB+foPOeupKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=phRxRdNbMzHLPMARA+RqdwfT2zmXnNRDKSqRbBFhFrU=; b=ZkeNaHkHT8xGZyGr+ugT8AGcJDDdO87ReQ0nRK2+GCeVE6YlD+B/cXZ38eRR52dOprYUHww+5LXMHxl9HPEKYfNz0yROs5Eqh1uVCUdb+5L/+X8BkrNf562M1HP7Dd6JdCApTvLHkzD3EljkzBNfD2HuEYJwkrdmwifzbSw2IPQ= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5095.namprd11.prod.outlook.com (2603:10b6:510:3b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Wed, 14 Jul 2021 21:05:03 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64%4]) with mapi id 15.20.4308.027; Wed, 14 Jul 2021 21:05:03 +0000 From: "Eric Vyncke (evyncke)" To: Michael Richardson CC: The IESG , "draft-ietf-core-sid@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1j?= =?utf-8?Q?ore-sid-16:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXeMMJbcCzBxzHpUK9Esnj41U3kKtDF9MA Date: Wed, 14 Jul 2021 21:05:03 +0000 Message-ID: <56A784BB-D77C-47D3-A630-EDC789A2CFDC@cisco.com> References: <162624127733.15124.15333004711651272795@ietfa.amsl.com> <24058.1626275711@localhost> In-Reply-To: <24058.1626275711@localhost> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c715bfc-4677-4a7e-a0b7-08d9470b0cea x-ms-traffictypediagnostic: PH0PR11MB5095: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zZRGiWdzx3UifRma3ln7y1h3No/NzpnQlIcngyW7KLFaN9iSkWCUiIxZ0yxdGxIoxnfNTThGUp+5H+KWeMv026lRFmFUBkKVanbEJWZBSa/MR/deimgaasBznreqY3zpZq+OR+XwXFrgWvoGC3z0+rLwCP3hyBxcczNOj5PvDlY7rIJYvavdUwzkEKdlmkWw69FI6G3sGDun2r7W9QPlIlA3F17K4Ezz8T1dmJICaiEVp05M7KOw1vh9hlioI323O8urwNlkGqXQuR+R2do4KSN+zXCV22n4p0aIkBl6DOm9d5F3M+qPXcmyH2mA3Dv8zeEbua2kz7iPalM2kKMQ6WBLSMjrXhD0tOuMvVSzBfzvLY9ZG9ZtrRA8i/nYgNo+Cmae9+tkidJYUJqgcYXMcjPVMs2yeI1BbsjH2HXSmqf0Gr60KL7YNkneJAPBK6AnSgNGe40BzVF51lcCO2SfRnpHUpB5ro/w6w6MIrGa2/Tin5BQ2bM/qavFpxT6+JQDlQwZBjI6URk8ifeGwgJOHqtq8vir5yuJYE08kMb+YkUYhFxs9+MScjCe+kHkCjsmDzcSQ5gpgz7Xza5SyLFTJ82rPBQCiP7Yy/O/+Jb3TLKUZetGhy+BE64GPp8zH6lTiP4pFQYV2rsAetpfOD31NmyAYiBC8i0Xvy4Nxlgchjww0vjkNkXDU6mz+HjVVzoetQ3HB7We8DVwT70r7Amw5fCEFCvEDZp8FNkVpGD14borng3SDKGlDkdvoc7DWDyQ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(346002)(39860400002)(136003)(376002)(38100700002)(36756003)(83380400001)(5660300002)(66574015)(122000001)(71200400001)(186003)(66556008)(4326008)(66946007)(76116006)(66476007)(6506007)(53546011)(91956017)(478600001)(66446008)(2616005)(33656002)(316002)(6512007)(8936002)(86362001)(6486002)(54906003)(64756008)(2906002)(224303003)(38070700004)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WDBDNlFxVGdaaDEzM0pHc21HYVZaVldlVTlHOTFlcnNuQTRiMUxSWU9RMlJp?= =?utf-8?B?MVZxRlFwNVJlVnpiSTlGMENvZys2SW5uaHBhZ3R5ajB5NFJPY0pZME9lTlRF?= =?utf-8?B?RWxtTUhDZzROcmwzbTBvdVVDdHJjNDVtSlpxM20ya2FJY28zdjAxZCszbmYv?= =?utf-8?B?d2htK0JWZms0bm1WZytReFNicGFuUXBsU0N3SlBPQVk3UGNweGt6ckQ2Q0hM?= =?utf-8?B?eXpOclNOWGpiNTJiOGJ4YlNpOEdRQjZ2dHUwUktXdG1LR1NlQXgzNmdiL3Rr?= =?utf-8?B?Tjk2ZTJxT1Y0Z2Y1aFJYTDdzdVptR3N0Y3A0VW5aL3hlcjNaQjIwQkdWTjBP?= =?utf-8?B?SlNTTzNVamZGU2JBVVd2QVlRTGxya0QrcXJCVHppSVVFUERFWlFYNnJWWVRU?= =?utf-8?B?VVgxMk5HR3pnbncreUhwRFBCOHJ5VXpXZ0JwdnVlU0R6djkxZVlKTEZ2RUFC?= =?utf-8?B?SUdjdmZoU1lPcDk5OUN2dk8veXFCMjV6SDE5Y3FnR2dNOTBZUW1ScEN4enFJ?= =?utf-8?B?SFBKaFZLZE1VVWRZc1FVMm92OVp0NWsrZFpMMDdwSEt2ZXZORzdLOEE1bWVj?= =?utf-8?B?bUJSVVBOVzhRUDZLQjJpNVp2ZWlHZGEyNUt2QXRYM1l1bVR5dU9COXpYWTNj?= =?utf-8?B?akJpVllhRElqNGJ2ZDV2UTRIc2FHbG9KcDdkV08wNy9oQmNtREdMOEtCYXJq?= =?utf-8?B?aVdjVkRQOEJiN1VGNnQ3RE0wTU9uU2JkcklVUFk0ZXowYkd3UGlrSmxrQmRu?= =?utf-8?B?RUk3bkNCWEx1bVRHb29ESnZDdVlqL3lxODYvNkFzUjNkU0k4ZXBlckJKTXIw?= =?utf-8?B?aWQrTDVzd0xDNlRJOElZeGJiR2FmWWdJVVdZN3hKYnNOTEx3Tm51Q05WaFEw?= =?utf-8?B?dSs1VG50S3hwbENkOFZTUTVyUkpYK2tjcEpGK0xPZDRaR01LMDlCS1BQU1J3?= =?utf-8?B?SGkwblNGdWpDZjVKSFd5TVBibHJyUFpuTFoyK3llcU5OZGVkeHZvK051cTNt?= =?utf-8?B?MlhNT1ZOalJGWWJJanFkVmNQQk5rdCtaVCsrQnJmeGM2UFZxa2xUYzRPVGx2?= =?utf-8?B?ZEtWNVc3c08yNnNLQUxjQ3VBS055c2QzT0ZPMFplRjBjL3lQbHZ2UmdzNnRU?= =?utf-8?B?QkJZb28zV2RDdkFpSWRib0tkUnEyMVdVQTB5TUdQblVacXZrSFlIQzkrcE5W?= =?utf-8?B?R2RkVXhoRlc3VHdheGQ2RGtiL1JOSlZzZW80VU94QnBPbU9VcUlCUVFLWTVx?= =?utf-8?B?YWMySjZlU05wTHFxQ0dBZkZzZTVEdnhMOFBhMU8wN0JTdHdoNC9COVkxRGl5?= =?utf-8?B?MkxRNDlMWndCRDcxZUVtY0FJejNpNklZVElDWVN4MmxwYjU1WEFyRVN3ampB?= =?utf-8?B?MWVFZ3V3c2M3bEpDK0tTalAyRk9HcFdOMHRTdlNaL09sWUxTRzN5L1ZpM1pn?= =?utf-8?B?ZVdDcXJPNHlCeEo2VitIclNySUxlaThUSXppNDRMbnVrZS9nTkdDNHNxcG03?= =?utf-8?B?d2x6SzdOK3ppckwxeFFoVWhWSmpMZUVDb0p2a1BRSGE3emRxYVNRWFhLbkRW?= =?utf-8?B?eW94OG1mU1MzR1QrMnlnRWE4OG9CdU0vTmNJcHZuSUFjM2t2b1EyRXRJL0xW?= =?utf-8?B?dlY5V0hsT1poWmNVUmZ0VnF0aGF0cksrUDVjZExkeGFoNHRaQW82d01xdjRz?= =?utf-8?B?TWlrVnJDVURWWTh6MTBDOGpORzVvaVcxMTlhcWVaRTQ5SGpqSHdTRk9kYS94?= =?utf-8?B?VG1jRUQvWHVEU25qajFqY1Fvemx5alJ1SW92c3d1alVNdFlrM2xZWkVNWUsr?= =?utf-8?B?cmIwWEoraGxFYjZMSnZyV3JEUG1CbklDSXI1ZGZuNHhEUzFjazNkcWJLNUZ2?= =?utf-8?B?Wm9OYlN4VVMyNXkvTTNvR3hsQ1RWVEpncXM0dHYrVGJGdGc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <314DFDEB561FAE42A3F858FBC03F8824@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c715bfc-4677-4a7e-a0b7-08d9470b0cea X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 21:05:03.5296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G2d6NZcZFiivvHTtR5yEoMR6StxkbeAHRjGl3pRQQsws8x2B0YohkNckEj46+SQLszfmCdX+2FwA8X/yp3EO5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5095 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 21:05:13 -0000 VGhhbmsgeW91IE1pY2hhZWwgZm9yIHlvdXIgcmVwbHkgYXMgSSBkaWQgbm90IHJlYWxpemUgdGhl IHVzZWZ1bG5lc3Mgb2Ygc2VjdGlvbiA3LjQuDQoNClRoZSBZQU5HIFNJRCBtZWdhLXJhbmdlIHJl Z2lzdHJ5IHdvdWxkIGluZGVlZCBiZSBPSyBmb3IgT3BlbiBDb25maWcgYW5kIG1ham9yIHZlbmRv cnMuIEFzIGEgbWVnYS1yYW5nZSBpcyAxLjAwMC4wMDAgKHJvdWdobHkgMioqMjApIGVudHJpZXMg Zm9yIGEgNjMtYml0IHZhbHVlLCB0aGlzIGxlYXZlcyAyKio0MCBtZWdhLXJhbmdlcywgYmFzaWNh bGx5IGluZmluaXRlLiBXaXRoIHRoaXMgaHVnZSBhbW91bnQgb2YgbWVnYS1yYW5nZXMsIEkgd29u ZGVyIHdoZXRoZXIgRkNGUyB3b3VsZCBub3QgaGF2ZSBiZWVuIGVub3VnaCBvciBhdCBsZWFzdCBJ IGhvcGUgdGhhdCB0aGUgZXhwZXJ0IHdpbGwgYmUgdmVyeSBsZW5pZW50IHRvIGFsbG93IGEgbmV3 IG1lZ2EtcmFuZ2UuDQoNCkkgd2lsbCByZW1vdmUgdGhpcyBibG9ja2luZyBESVNDVVNTIHBvaW50 IHRvbW9ycm93IChnZXR0aW5nIGxhdGUgaGVyZSkuDQoNCk15IG90aGVyIERJU0NVU1MgcG9pbnQg YWJvdXQgYSByYW5nZSBwZXIgUkZDIG9yIHBlciBtb2R1bGUgaXMgc3RpbGwgdW5jbGVhciB0aG91 Z2ggYXMgdGhlcmUgY2FuIGJlIG11bHRpcGxlIG1vZHVsZXMgcGVyIFJGQyAoaGVuY2UgdGhlIHRl eHQgaXMgaW5jb25zaXN0ZW50KS4NCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4N CkRhdGU6IFdlZG5lc2RheSwgMTQgSnVseSAyMDIxIGF0IDE3OjE1DQpUbzogRXJpYyBWeW5ja2Ug PGV2eW5ja2VAY2lzY28uY29tPg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgPGRyYWZ0 LWlldGYtY29yZS1zaWRAaWV0Zi5vcmc+LCA8Y29yZS1jaGFpcnNAaWV0Zi5vcmc+LCA8Y29yZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gw4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLWNvcmUtc2lkLTE2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoNCiAg ICDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToN CiAgICAgICAgPiAtLSBTZWN0aW9uIDcuNS4yIC0tDQogICAgICAgID4gQUZBSUssIG1hbnkgWUFO RyBtb2R1bGVzIGFyZSBub3Qgb3JpZ2luYXRpbmcgYXQgdGhlIElFVEYgKE9wZW4gQ29uZmlnLCB2 ZW5kb3INCiAgICAgICAgPiBzcGVjaWZpY3MgbW9kdWxlcywgLi4uKS4gSG93IGNhbiB0aG9zZSBu b24tSUVURiBtb2R1bGVzIGdldCBhIFNJRCBhcyB0aGUgdHdvDQogICAgICAgID4gd2F5cyB0byBn ZXQgYSBTSUQgYXJlIGJhc2VkIG9uIFJGQyAoaWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB0aGlz IHNlY3Rpb24pLg0KDQogICAge1NwZWFraW5nIGFzIGFuIGludGVyZXN0aW5nIHBhcnR5IHdobyBo YXMgYSBTSUQgZGVwZW5kYW5jeSBpbg0KICAgIGRyYWZ0LWlldGYtYW5pbWEtY29uc3RyYWluZWQt dm91Y2hlciwgYW5kIHdobyBhcmUgZG9pbmcgaW50ZXJvcCBuZXh0IHdlZWsNCiAgICBkdXJpbmcg dGhlIGhhY2thdGhvbi4uLn0NCg0KICAgIFRoZSBvcmlnaW5hbCBpbnRlbnRpb24gd2FzIHRoYXQg dGhlcmUgd291bGQgYmUgbXVsdGlwbGUgcHJvdmlkZXJzIG9mIFNJRHMgdmlhDQogICAgbWVnYS1y YW5nZSBhbGxvY2F0aW9ucyAoNy40KSwgYW5kIHRoYXQgbW9zdCBtYWpvciBlbnRpdGllcyB3b3Vs ZCBhbGxvY2F0ZQ0KICAgIHRoYXQgd2F5LiAgSSBzZWUgbm8gcmVhc29uIHdoeSBsYXJnZXIgdmVu ZG9ycyBjb3VsZG4ndCBhbGxvY2F0ZSB0aGF0IGFzIHdlbGwuDQogICAgU2VjdGlvbiA3LjQgaXMg RXhwZXJ0IFJldmlldy4NCg0KICAgIFRoZSBhdXRob3JzIG9yaWdpbmFsbHkgb3BlcmF0ZWQgYSB3 ZWIgaW50ZXJmYWNlLCBhbmQgd2VyZSBob3BpbmcgdG8gaGFuZCB0aGF0DQogICAgdG8gSUFOQSBh bmQvb3Igc2VjcmV0YXJpYXQuDQoNCg0KICAgIC0tDQogICAgTWljaGFlbCBSaWNoYXJkc29uIDxt Y3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQog ICAgICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdv cmxkd2lkZQ0KDQoNCg0KDQoNCg== From nobody Wed Jul 14 15:58:50 2021 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 15F743A08C6 for ; Wed, 14 Jul 2021 15:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.113 X-Spam-Level: X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL-lMJtGvLEr for ; Wed, 14 Jul 2021 15:58:40 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 6E6213A0891 for ; Wed, 14 Jul 2021 15:58:39 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id a18so6390428lfs.10 for ; Wed, 14 Jul 2021 15:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0safpUPt0f4bPK6FjWWyfb1pnJgt13ti72NRQvKAjcM=; b=2P/x1xfpcx60ROgfRMFEWKZxhGn7XiLbZ/g6pqX16QpmES/FNH/d+BAsntty83qOgM EqaT+T9x+1o81aav1GVVGtEsnZOBi4YqasDEfNOj2K9TfziLc9pAGgOXIsEFTRiJfjnH 6Hl8x9xXepoJmfsUMzj8pW3zjKrEII5cwU57ZQBY2aKX/rpk21k60KXaOubcK3nNykB1 MW95kMPQaeoAF/9zrkg/t5O18m0IFlTVE1UXagnLBSvyzDklLPVtq60lOINJ6/H3nEIh V7l6fyz6LU0GUa5w03Rw4HLs512CPl0pAzS8TJ5bApOK4ZyMoAJLohfMouDFbkl8yV8d yrMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0safpUPt0f4bPK6FjWWyfb1pnJgt13ti72NRQvKAjcM=; b=EC6HwLnwwycx9psvFtKwfiu6GjSvm9lKNHei12GrDR6oANDN0iJ5awBmaDudV9MMuT j74JJufcLiN6b2iIZf3PLF/Hmp9MwhXuxHDmzKW5wPnK+FiBdJMAFYBdtBCFRWyhdE5l eTmNB5litMFG1eNFAUQe7kgNvVJQKCP/99A1UVgVXUwvSSx9K1KClooxGm6raEJf4fQH naFcJc4uI9UjshVE9zXSsPYNx8WD1+NkZLSZkKFxP/rsTh4bwyTNpliKuD2wggo86q1M v67SyomAtTXpxtN3VQez/EidjVGZE1A0daXzDN9j0GIdVIHEJ+J0wWNwHcJn/+fVZKpq RK1A== X-Gm-Message-State: AOAM531sJBpvgNewohcPpqXB1bjDjXBdSVcY+dspe8zr0Yv9z+bAE1fe 8OjoBaJd5mh18zzlDRBiWmDqlcIAWb68W3QmBKV+Mw== X-Google-Smtp-Source: ABdhPJw7KMpLSD1mhvSgtYCNPJ07IUy/cyl5kjHOHf7pBgvK0rhDzH5vtbxMsLZJZdm+zUIOIf0G169XAstUS4IZzXE= X-Received: by 2002:a19:c707:: with SMTP id x7mr344835lff.38.1626303512305; Wed, 14 Jul 2021 15:58:32 -0700 (PDT) MIME-Version: 1.0 References: <162624127733.15124.15333004711651272795@ietfa.amsl.com> <24058.1626275711@localhost> <577D49C6-9071-49C3-90B6-8EC45D955A84@tzi.org> In-Reply-To: <577D49C6-9071-49C3-90B6-8EC45D955A84@tzi.org> From: Andy Bierman Date: Wed, 14 Jul 2021 15:58:21 -0700 Message-ID: To: Carsten Bormann Cc: Michael Richardson , =?UTF-8?B?w4lyaWMgVnluY2tl?= , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, The IESG , Core Content-Type: multipart/alternative; boundary="00000000000025ff2f05c71d4b7a" Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-sid-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 22:58:48 -0000 --00000000000025ff2f05c71d4b7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 14, 2021 at 1:57 PM Carsten Bormann wrote: > On 2021-07-14, at 17:15, Michael Richardson wrote= : > > > > The authors originally operated a web interface, and were hoping to han= d > that > > to IANA and/or secretariat. > > That interface is still there: > > https://comi.space What is the official plan to assign ranges to each IETF YANG module? (Sorry if this is a different draft). Looking through this WEB site, the SID assignments seem very ad-hoc and manually derived, and extremely prone to human error. I am not worried about hackers tampering with the SID files as much as the administration of the micro-ranges to be sloppy and poorly done. Hopefully there will be tools that detect overlapping assignment errors and tools that automatically assign ranges to a module and record the assignment in an official database. A "SID Lookup" tool would also help developers and operators debug implementations. > > I just got myself a SID range of 1000 SIDs at 1010000. > Obviously, this second megarange needs to be in the megarange registry. > > Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000025ff2f05c71d4b7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 14, 2021 at 1:57 PM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On 2021-07-14, a= t 17:15, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
> The authors originally operated a web interface, and were hoping to ha= nd that
> to IANA and/or secretariat.

That interface is still there:

https:/= /comi.space


What is the = official plan to assign ranges to each IETF YANG module?
(Sorry i= f this is a different draft).

Looking through this= WEB site, the=C2=A0SID assignments seem very ad-hoc and manually derived,<= /div>
and extremely prone to human error.=C2=A0 I am not worried about = hackers
tampering with the SID files as much as the administratio= n of the micro-ranges
to be sloppy and poorly done.
Hopefully there will be tools that detect overlapping assignmen= t errors
and tools that automatically assign ranges to a module a= nd record the=C2=A0
assignment in an official database. A "S= ID Lookup" tool would also help
developers and operators deb= ug implementations.




I just got myself a SID range of 1000 SIDs at 1010000.
Obviously, this second megarange needs to be in the megarange registry.

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


Andy
=C2=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000025ff2f05c71d4b7a-- From nobody Wed Jul 14 17:05:15 2021 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 E1BE93A0EF4; Wed, 14 Jul 2021 17:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <162630750933.24049.4916902988643286347@ietfa.amsl.com> Date: Wed, 14 Jul 2021 17:05:09 -0700 Archived-At: Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-sid-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 00:05:10 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-sid-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the DISCUSS positions of Ben Kaduk, Éric Vyncke, and Rob Wilton. ** YANG module. Typo. “list assignment-range”. s/the the/the/ ** Appendix B. Assignment of SIDs to YANG items can be automated, the recommended process to assign SIDs is as follows: ... 4. If the number of items exceeds the SID range(s) allocated to a YANG module, an extra range is added for subsequent assignments. What’s the expected automated approach for adding extra ranges. I was under the impression that getting more SIDs required an IANA request to allocate them them "YANG SID Range Registry"? From nobody Wed Jul 14 21:29:09 2021 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 3DB953A1AE2; Wed, 14 Jul 2021 21:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 MFIB732u93Gv; Wed, 14 Jul 2021 21:29:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A98F23A1ADE; Wed, 14 Jul 2021 21:29:05 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16F4Svl0013842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 00:29:03 -0400 Date: Wed, 14 Jul 2021 21:28:56 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: draft-ietf-core-sid@ietf.org, The IESG , core-chairs@ietf.org, core@ietf.org Message-ID: <20210715042856.GL74365@kduck.mit.edu> References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> <219605.1626281575@dooku> <20210714173223.GD74365@kduck.mit.edu> <5344.1626291161@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5344.1626291161@localhost> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 04:29:07 -0000 On Wed, Jul 14, 2021 at 03:32:41PM -0400, Michael Richardson wrote: > > {again, not an author of this document} (thanks for the reminder!) > Benjamin Kaduk wrote: > >> (I don't think we have resolved the question of how/if/when we provide the sid > >> file to IANA when part of another RFC. In theory, IANA creates the sid file > >> when the YANG module is first provided. In practice, we need it for interop > >> work prior to WGLC) > > > (Also an interesting question, but probably not something that needs to be > > enshrined in the RFC.) > > Someone has to document some interaction with IANA. > I guess draft-ietf-anima-constrained-voucher, close to WGLC, will show us > whether we got things right or not :-) > {insert curse about living in interesting times} > > ... > > >> Conceptually, SID files could be processed by unconstrained target > >> systems such as network management systems. Such systems need to take > >> extra care to make sure that they are only processing SID files from the > >> same authoritative source as the YANG modules that they are using. > > > This topic also seems worth covering, so thanks for including it. > > It's not entirely clear to me that it's a security requirement to use the > > exact same source for YANG module and SID files or some other trustworthy > > authority might be acceptable, so we might want to think about this some > > more. > > I'm just trying to say: if you trusted IANA for the .yang, then trust them > for .sid. If your source of truth was IEEE, then get the .sid from them too. And I'm saying that doing that is clearly safe and a defensible course of action. There may also be other safe courses of action, though, so I don't want to commit us to "need to use the same source for YANG modules and SID files" without having it be a considered decision. -Ben From nobody Wed Jul 14 23:30:33 2021 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 736973A1E9F; Wed, 14 Jul 2021 23:30:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162633062845.15354.15922725362070438996@ietfa.amsl.com> Date: Wed, 14 Jul 2021 23:30:28 -0700 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-yang-cbor-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 06:30:29 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-yang-cbor-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Benjamin's second DISCUSS point. Section 2 imports the term "schema tree" which is not used in this document. In Section 9.1, "Required Parameters" should be "N/A", not "none". See RFC 6838 Section 5.6. The layout of the table in Section 9.3 is a little confusing. For instance, the first two rows are collectively describing a single entry, I think, but that's not obvious given there are horizontal lines between them. From nobody Thu Jul 15 00:42:48 2021 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 891033A20D0; Thu, 15 Jul 2021 00:42:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162633496253.21694.2180902924580266802@ietfa.amsl.com> Date: Thu, 15 Jul 2021 00:42:42 -0700 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-sid-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 07:42:43 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-sid-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1: It's a bit weird to have requirements language in an Introduction. Section 7, generally: Thanks for providing advice for the Designated Experts for each of the created registries. This is a not-exactly-uncommon oversight. Section 7.4.1: * "The size of the registered SID block. The size MUST be one million (1 000 000) SIDs." -- Seems a waste of a registry column if it's always this one value. Maybe this should instead be the highest SID in the block? * "The information associated to the Organization name should not be publicly visible in the registry, but should be available." -- Why not, and available how? Section 7.5.2: * "The maximum SID range size is 1000. A larger size may be requested by the authors if this recommendation is considered insufficient." -- This is a contradiction. Should "maximum" be "default"? * "RFCs and by extension documents that are expected to become an RFC fulfill the requirement for "Specification Required" stated in..." -- I think you mean "RFC Required". From nobody Thu Jul 15 02:29:10 2021 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 E5C1F3A243C; Thu, 15 Jul 2021 02:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <162634134491.20957.9891384677904460366@ietfa.amsl.com> Date: Thu, 15 Jul 2021 02:29:04 -0700 Archived-At: Subject: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 09:29:05 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-core-sid-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be very easy to resolve and I want to make sure that we understand the situation here better - *Section 3 : says - "The creation of this new version of the ".sid" file SHOULD be performed using an automated tool" If this is supposed to be the automation process written in appendix B then putting a reference here makes sense. If not, then as this is very important tool, more information need to be added here in this specification (like, where to find it, who create and maintains it, any reference to such an existing tools). Also I am missing what consequences one need to consider if the process is not automated. If this is same as written in the introduction - "Assignment of SIDs to YANG items can be automated. For more details how this can be achieved, please consult Appendix B." Then we have two kind of instructions for the same thing - "can be" and a normative "SHOULD". Hence it need to be clarified which one should prevail. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the efforts in this document. * I support Robert Wilton's Discuss and Benjamin Kaduk's discuss no.2 One more clarification comment - * Section 7.5.2: says - " The maximum SID range size is 1000. A larger size may be requested by the authors if this recommendation is considered insufficient. It is important to note that an additional SID range can be allocated to an existing YANG module if the initial range is exhausted." I have hard time understanding the mentioning of the maximum SID range here. does this mean this document sets the maximum range to 1000 but others can have more? please clarify. From nobody Thu Jul 15 06:35:24 2021 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 497F13A0650; Thu, 15 Jul 2021 06:35:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162635612227.22030.13513408024494659570@ietfa.amsl.com> Date: Thu, 15 Jul 2021 06:35:22 -0700 Archived-At: Subject: [core] Robert Wilton's Discuss on draft-ietf-core-yang-cbor-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 13:35:23 -0000 Robert Wilton has entered the following ballot position for draft-ietf-core-yang-cbor-16: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document, it is good work, and I think that there specification is almost there, but that the text could be tightened up in a few places. 1. The document should be clearer on its use of terminology around schema nodes. Mostly the encoding related to YANG data nodes, not YANG schema nodes. I've provided more information in the comments section. 2. As also raised by Ben, this document should probably cover the YANG data structure extension in RFC 8791. This could potentially be done in addition to rc:yang-data, but perhaps better in its place. 3. Did the WG consider supporting encoding YANG metadata (RFC 7952)? Presumably this would be expected to be covered as future work? 4. How does the CBOR encoding of SIDs apply to YANG features? This draft references features and the SID draft allows SIDs for them, but I don't understand how they are used in the encoding (since features don't appear in the instance data, they are only at the schema level). 5. I also support Ben's second discuss point. I think that as written, this draft needs a normative reference to the SID draft. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and the yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 8949). When I read the abstract, it raises the question about what is left out. Hence, I am wondering whether it wouldn't be better to just describe it as encoding YANG data tree instance data. However, I see that the description effectively mirrors the abstract for the YANG JSON encoding (RFC 7951), so it is at least consistent. 2. I find this document (along with the SID draft), somewhat confusing in that it references YANG schema nodes, but in most cases, it probably only cares about the subset of YAND schema nodes that represent itemsthat are present in data tree instantiation. RFC 7950 calls such 'schema nodes' as 'data nodes'. For example, 'choice', 'case', 'input' and 'output' exist as nodes in the YANG schema tree, but are not data nodes and don't appear as instantiated data nodes. Where this causes problems are in the definitions of: 'child' - (e.g., 'case' cannot be a child of a 'container' only a child of a 'choice', and equivalently for the definition of 'parent'. This definitions are not heavily used and could perhaps be removed? Hence my suggestion to clarify the text are: - potentially import and use data node rather than schema node. Note that data node, as defined in RFC 7950, is a subset of schema nodes, so you still need the text saying an instance of a data node. Arguably, the RFC 7950 definition of a data node is somewhat confusing. - please check everywhere where 'schema node' or 'data node' turns up in the text to ensure that you are referencing instances of that schema node rather than the schema node itself. E.g., the second paragraph in section 3 states 'where each child schema node is encoded ...', but this should be an instance of child schema node. - ensure that if you are referring to the parent or child of a 'schema node' that the logic skip out the schema nodes that don't get encoded in the data tree. E.g., when calculating SIDs. 3. I think that some of the references to submodules are not quite right. Basically, the CBOR encoding should not need to concern itself about submodules at all, since logically, it works with the module schema (which logically incorporates the submodules). E.g., perhaps you could mention this in the introduction, referencing section 4.2.1 (4th paragraph in particular) of RFC 7950? Hence: In section 2: * item: A schema node, an identity, a module, a submodule, or a feature defined using the YANG modeling language. I think that this should exclude submodule (and possibly feature as well). In section 3.2: YANG modules, submodules, and features I don't think that you want submodules in this list (and perhaps not features either). And in: 6.13.1. SIDs as instance-identifier SIDs uniquely identify a schema node. In the case of a single instance schema node, i.e., a schema node defined at the root of a YANG module or submodule or schema nodes defined within a container, the SID is sufficient to identify this instance. I would remove "or submodule" from this text. Effectively, the text about modules already covers this. 4. Please check the text that describes how lists are encoded. Section 4.2 seems to suggest that they are encoded as a CBOR Map, section 4.4 states that they are encoded as an array. I presume that the answer is that they encode the list is an array, and each list entry is a Map. 5. Values of 'bits' types defined in a 'union' type MUST be encoded using a CBOR text string data item (major type 3) and MUST contain a space-separated sequence of names of 'bits' that are set It might be helpful to have a quick sentence to justify why this is done. Regards, Rob From nobody Thu Jul 15 10:18:38 2021 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 B3D2D3A0F2E; Thu, 15 Jul 2021 10:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyJ-wvZVCdyS; Thu, 15 Jul 2021 10:18:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92BAD3A0F01; Thu, 15 Jul 2021 10:18:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F020338A8C; Thu, 15 Jul 2021 13:21:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XH_yB_yF3GC8; Thu, 15 Jul 2021 13:21:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA28538A56; Thu, 15 Jul 2021 13:21:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D85D0641; Thu, 15 Jul 2021 13:17:58 -0400 (EDT) From: Michael Richardson To: Roman Danyliw , "The IESG" , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org In-Reply-To: <162630750933.24049.4916902988643286347@ietfa.amsl.com> References: <162630750933.24049.4916902988643286347@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-sid-16: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 17:18:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roman Danyliw via Datatracker wrote: >> ... >> 4. If the number of items exceeds the SID range(s) allocated to a >> YANG module, an extra range is added for subsequent assignments. > What=E2=80=99s the expected automated approach for adding extra range= s. I was under > the impression that getting more SIDs required an IANA request to all= ocate them > them "YANG SID Range Registry"? Yes, that's correct. A human has to add the extra range, once they have acquired it. The allocation of the SIDs is to schema names/paths is automated. The interaction with IANA is not :-) (but, comi.space had an API, I think) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDwbcYACgkQgItw+93Q 3WUJ2wf+OuiiQxHgJ9oW9bK31IL7a68XS5zOQmL3RYznZrks9OwwyMzp7i2pNgvT WqKRE/NkvB7ztpzHp6S1lkVzX4orbcIDYTvNlP+SsjAO3JgBRlR7zlFazMHp2Tkq IeK+gGCmuy8QJ4o9kvfJ7rH4APL0DEOcuIcJThZsc/w+vHEC536ByXiKrQZ1cdMP YdhtM43X9u+8/LIeYUwBYCStcJvqTy3n4XtP9qkyRpVG8rNVcOr0NtffePd64/2M +Ke3ZQ9ZTQaN9AXxR4k/4WxNnvAcc0J4F5p/k0UOY3P7hjXSx0CXx5DVs7NtaAAQ fDi4hapm/YdOU0th3VqmrdVopPjYUg== =p1Ts -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 15 10:52:24 2021 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 D55A83A1532; Thu, 15 Jul 2021 10:52:18 -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, SPF_HELO_NONE=0.001, 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 CknMsPBNeOYz; Thu, 15 Jul 2021 10:52:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD29F3A1528; Thu, 15 Jul 2021 10:52:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 90AC238A94; Thu, 15 Jul 2021 13:55:13 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PzJR62rnmWWR; Thu, 15 Jul 2021 13:55:09 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5276E38A89; Thu, 15 Jul 2021 13:55:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E8E4D641; Thu, 15 Jul 2021 13:52:06 -0400 (EDT) From: Michael Richardson To: Zaheduzzaman Sarker cc: "The IESG" , draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org In-Reply-To: <162634134491.20957.9891384677904460366@ietfa.amsl.com> References: <162634134491.20957.9891384677904460366@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 17:52:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Zaheduzzaman Sarker via Datatracker wrote: > *Section 3 : says - > "The creation of this new version of the ".sid" file > SHOULD be performed using an automated tool" > If this is supposed to be the automation process written in appendix = B then > putting a reference here makes sense. If not, then as this is very im= portant > tool, more information need to be added here in this specification (l= ike, > where to find it, who create and maintains it, any reference to such = an > existing tools). Also I am missing what consequences one need to cons= ider if > the process is not automated. If this is same as written in the > introduction - it's in pyang 2.1 since late 2019. I don't know what the current practice towards referencing pyang. > "Assignment of SIDs to YANG items can be automated. For more details > how this can be achieved, please consult Appendix B." > Then we have two kind of instructions for the same thing - "can be" a= nd a > normative "SHOULD". Hence it need to be clarified which one should pr= evail. Good point. >> maximum SID range size is 1000. A larger size may be requested by >> the authors if this recommendation is considered insufficient. It is >> important to note that an additional SID range can be allocated to an >> existing YANG module if the initial range is exhausted." > I have hard time understanding the mentioning of the maximum SID rang= e here. > does this mean this document sets the maximum range to 1000 but other= s can > have more? please clarify. Each of my ANIMA modules uses around 15 SID values from a range of 50. (that's draft-ietf-anima-constrained-voucher, which is among the first user= s) I think that if you write a module that requires more than 1000 SID values that you might be doing something wrong, and so more consultation is warranted. Otherwise, small ranges should be given away like the candy on the IANA des= k. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDwdcYACgkQgItw+93Q 3WW++ggAoEcgEQk09TJxgs8SDJnIlLSE+1nZtH1M2S8HnWe3qa9JZCESOcNQv9dW 57DhlZwGdJOmLsfQFgmjeFP7oaVkslBacMX5RK8sDu7ZQI1tnYrf9pzt7SKzx+Xa VRNgXihM2B2qfyQyE/nAlmodlIciEXDNK/rzRC/yHxdSYDeOV0Kl7b+tzwE/lUan 7dbUFKlUJSwSeuN2gfSlsmK9TM0+l0F3P7gCXDdMBIEVxZV7tUQLcZhlL2WUZGAn onCYy2U39j3iSmlWkfN71Gi+EyAmIJwo6Z9JIagoY/+NaALS9Z7pWZiBfJQXdXOV IG0wvAhOoZmUU5wz78/grpIqoHrTpg== =WeP3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 16 04:37:31 2021 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 E6DDD3A333B for ; Fri, 16 Jul 2021 04:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 4t3VBbsiqgi1 for ; Fri, 16 Jul 2021 04:37:24 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2081.outbound.protection.outlook.com [40.107.21.81]) (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 7311F3A333A for ; Fri, 16 Jul 2021 04:37:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FqyPNT8NF4fJLHxBh7QJphX3bbIzQ3I9HD/OKCuBmEl8svTC48UGwDLS57RBhYn02t9vBm+ehPNW2crqPANFbt4Ln0E5S7tBO+e5VmP5U+QE3eYJWRfy+B6twEdFIj9cW6MlVIzpMNLE4T0QMGdV5bWI+Az1bkgha09Oa9OIP31G+GBMCaK41sJUOrPZExOpqDk6QRA5qZD7JN1sfouZt6wDedC8lGTeaG4+J0htUrgOh/er5uWTTI0U5iueWFSQ+jA8q4FLyDOKDC4l3x020B54FHw0ea8RWX7/DoczfNFzSJbYEBlYpb5OBPnFgPaHimN7pMc/hA4ejXuMHbVYaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCeAZSt9UsvPtGrcumPTSmfrMX/rj9dw7mhkBun8uzg=; b=Wb0DYQCzfNAyVCeseuy9UpUOLZA02MGwrvKKVsRQgVWBgaolp6bI9uDwr3kPR6x72kCFG4xkuM+YjKoj4t4j5H7OYywbTZDdPjvI1dWL61FtuPqgaLBpeWYvOW9u2fZNae29UoS6R0DoLn4ROUSWBkgfVDrPU95JR+OYioMJDmOQT3ExmbCSit0fwd0atpP83h33teA+Cj7CF18pvP59bqVDXida3sb4kwSz3VuK7jqwrjxwY6cSg1KbViyVI7MiB3VMHYYTPa90TYK5UwgvZOaQ/ETBUtBa6LwxuUtvst9/lg3B5yoaTbTBRqEJwF2k9OULfTgafm7R6w1ivr13NA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCeAZSt9UsvPtGrcumPTSmfrMX/rj9dw7mhkBun8uzg=; b=JHdef8+iKD6Lkp2nrVpSY8eJgA6tmGmqtK4V1qzVnPEZ7NY2HPowZQXvI+M5JZ3tX8xa8FrXWtrbV9m4uHU0R9d1F5tFIxbtfbWpPWgbyS4ofTT6iLABqxn4fX3gWX8fJbWwC7arWSSOJmqpvEdRHvou1OxT91MKK80dIg04J4w= Received: from AM9P189MB1571.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:30d::9) by AM8P189MB1363.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:237::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Fri, 16 Jul 2021 11:37:21 +0000 Received: from AM9P189MB1571.EURP189.PROD.OUTLOOK.COM ([fe80::8c90:1aa4:4f3c:6b4f]) by AM9P189MB1571.EURP189.PROD.OUTLOOK.COM ([fe80::8c90:1aa4:4f3c:6b4f%5]) with mapi id 15.20.4331.026; Fri, 16 Jul 2021 11:37:21 +0000 From: =?iso-8859-1?Q?Rikard_H=F6glund?= To: "core@ietf.org" Thread-Topic: New Version Notification for draft-hoeglund-core-oscore-key-limits-01.txt Thread-Index: AQHXdyt0OY5GC2TKS0uS2E+ievEvI6tFffR7 Date: Fri, 16 Jul 2021 11:37:21 +0000 Message-ID: References: <162610065278.15528.15134519536449122090@ietfa.amsl.com> In-Reply-To: <162610065278.15528.15134519536449122090@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29f463d3-0242-4c6f-8400-08d9484e1322 x-ms-traffictypediagnostic: AM8P189MB1363: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5km5I7OSKQ6tys7QZmwP6s3V0i1rVEPUhQfvLzqHJGLJXX9f/jX7iOV3Sfu3Rb5PuDV1Tl2mZs3Z0NwPzi58R8muTJe+R4Q8ML82uPgpvffLRcygkVFtoa2cXHjtsFvCpPyjuJMKFaDiDkHXskpyK5knOMqprMGKUOdKVmnIxXKI86AhakiaAeT9uY5+wnliTaLq71yxDBEyiC4zqtkbHE8DPJvagAXQfBp6A0TSgkVtIuA9x5pzuREe3L/eIYTayYVcLjppVjiz2UHNMWjmGoTpr+XAYpvhlh6tv6UhVX8vWvyALVSlahTxhZbqDwUD1N+pDM71Iv6ytNuOLmG+inHW2+iM6RmowQ0/o198o5t9BKqmamUajuwAPdF5gmdyzoZK6Xnyu+ljWhy8THGbx1xudIXaZtmcOBZHIvIE20/yognrdtYtLJ/Oeh+pF/7uyv7C9RgpEPkT2pnMQQ7BzVMaNzGKBIiZmcMoqd0/Rybt8ysjDjtasKhtJSy2oI/6tuhKyZ/YmKBHp0fqraXXnWDAq/Nfn02nfzLpgSsRBnrnq7fJxB/n/B0AQJIwvRSC7dIS1ekPhCg5yMBvD/XPpzBFuBlzcSzq+7zmas/txM9gdHP9QQW5JEwx6bOQq88ja9AEHL0E7raVn3/RHRP3E5VPYIAssrCB48WcPdoggG6uRmXQKbF8lx4NPp/2XApm7Avf4bGxyi5xNgbrhp+VcW3DWlW1NOFphn/lE/6MjjU8a15tmthNFUiS0WIkxa9qJxEACQ9UiQdKLbZ+EmcPpwNOoXrUbGAGNS8XG/J6pu0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P189MB1571.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(39850400004)(136003)(376002)(7696005)(66574015)(83380400001)(52536014)(2906002)(122000001)(9686003)(38100700002)(166002)(15650500001)(71200400001)(86362001)(19627405001)(6916009)(478600001)(45080400002)(316002)(76116006)(966005)(8676002)(55016002)(8936002)(5660300002)(53546011)(66556008)(6506007)(64756008)(186003)(66946007)(26005)(33656002)(66446008)(66476007)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ClLk06KPv5HeHoObUZYYBxOuqgn5ddUuxL2Rrsjv6y9sALnrtoiW1/zw9M?= =?iso-8859-1?Q?cs/yUDqqApj9MG8NUxriAU8+UufkcE/h1b6hSsj/A8/D5OFeNMWwP3NKXK?= =?iso-8859-1?Q?vsR7X0VbLz+idnmqlzPbFNUubxcd/1+QuunZVci1Y6jCstTkPXadK629nh?= =?iso-8859-1?Q?e5V3JEh+d155VuSXtEuQabnkA8V7CxGZX3td6dNYW/WIMLNsK39XSda0kP?= =?iso-8859-1?Q?cCo4KYnms8MKlmou+6SeBHr7OABbgu8solu4G7XHJGMFgklr5JEGzaPeax?= =?iso-8859-1?Q?T7/W+taPWdBRPVzufPm2o9l7n01Cx3E2XxtTG9jyBtJC6Gv2TjGaK9hywQ?= =?iso-8859-1?Q?sLcjStNkrqi0BegmoMP9yEzL7GpQ3c/X9nSqC8VU3YoDC0KPwPcbac8JSv?= =?iso-8859-1?Q?3d9dA5oZ11KJR89v4pY26frhpqeEzXvcClusfaUY9BGgZoRPm05SNRY3M5?= =?iso-8859-1?Q?jOuXR5daYpTzDuU82muLqwwXB/a9M19azzJojuUHzkziQZxBxewF1P2mFK?= =?iso-8859-1?Q?PrIqzWc3nL0lER9QxvFmrvjlGeefd+VjRNXQ/Mt0+73LSPA+yyoXhS2e4F?= =?iso-8859-1?Q?FupbxAqD+kxwh5ktBE7lkEXD3tXDs0K0JfwBHfSXjtgDDWTWRKcomDf/6w?= =?iso-8859-1?Q?sreBQ/zbMyMoMfYUn98y+eBEVl25RQ60tC4qXcfuRGV3SHDtfVVK9SVtcJ?= =?iso-8859-1?Q?cah5tCsK4oKbTfRL9U/vnYFkZZeU5T3ri7aTGfKvQQabBdtwLGawY65qYf?= =?iso-8859-1?Q?DaKPKWGUS1+uxSTUAZIXFvJ61uDc9/MStnxEiIG/UaywjRaepglqPaU6Ug?= =?iso-8859-1?Q?skGudiNwQIk8vmC2dB+VyUrpYbsumyjZC20B8cbqgbmMmUTpSbrbC96gnJ?= =?iso-8859-1?Q?BamYmx8Ws8je7HhX0qIq5mk2oRQkdhIDeBgtJMgUCqORFTpRjHgcw3SGTw?= =?iso-8859-1?Q?UK3kBNmfia8VZT7rZS+U4A/RAGk47H4O3G0pVlnVGVDRcjwLuTh7JEhrGq?= =?iso-8859-1?Q?uMl7RiUGJznPmcR/iF3K8xTbDE9V/yR60A4POeDvJd5ih+Rlqt1R+/remh?= =?iso-8859-1?Q?DMlS3vnOlyb4WMKJKg88TDV34uuh20XJNuR4Jd8JU4Z0kgaMzx0niJajve?= =?iso-8859-1?Q?xmTT3YKxea8Z+3aTSzKc9s5qCezrxUrSYWoIWhQei5EZmeY2shBAe17ffP?= =?iso-8859-1?Q?VTy6Vo+/ZfL0yjShALhg23rHxJojemeKiXxeunf6lZ+PAKXpyRlr2nfgEr?= =?iso-8859-1?Q?jUfLRQVnWp+v6yBrD0lQ0fkxo39J1wc5bKO+LbyGKGCj4ib6voQhBnKYUB?= =?iso-8859-1?Q?3gWquuSPRGJBmqdF5fVF3CSOQBfESc9hZvpcwB2H1vbi0os=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM9P189MB1571439A130A663EC13540A783119AM9P189MB1571EURP_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P189MB1571.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 29f463d3-0242-4c6f-8400-08d9484e1322 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2021 11:37:21.4188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I41nMdDfbvKHnSXC4ewyTst2fwDH1MoFOswP//2QjQzTWqwvTvN92dgkudDzymgi3zDdbZxLKue/PmFDH5L7BQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P189MB1363 Archived-At: Subject: [core] New Version Notification for draft-hoeglund-core-oscore-key-limits-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 11:37:30 -0000 --_000_AM9P189MB1571439A130A663EC13540A783119AM9P189MB1571EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello CoRE, We have submitted an update for the draft "Key Update for OSCORE" --- previ= ously known as "AEAD Key Usage Limits in OSCORE". https://datatracker.ietf.org/doc/html/draft-hoeglund-core-oscore-key-limits= -01 This document considers the CFRG draft at [1], and accordingly defines how = two peers using OSCORE must take limits of the used AEAD algorithm into acc= ount, and what steps to take in order to preserve the security of their com= munications, e.g., performing a rekeying. Also, this document specifies a l= ightweight method that two peers can use to update their keying material an= d establish a new OSCORE Security Context. Building on what discussed during the CoRE interim at [2], this update cove= rs especially the following points: 1) The proposed key limits have been revised, mostly based on input from Jo= hn Mattsson as per slide 11 of [3]. 2) As reflected by the title change, the document scope has been broadened = to include also a key update method, that the two peers can use to update t= heir OSCORE Security Context. Comments are very welcome! [1] https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/ [2] https://datatracker.ietf.org/meeting/interim-2021-core-04/session/core [3] https://datatracker.ietf.org/meeting/110/materials/slides-110-saag-anal= ysis-of-usage-limits-of-aead-algorithms-00.pdf Best wishes Rikard H=F6glund ________________________________ From: internet-drafts@ietf.org Sent: Monday, July 12, 2021 16:37 To: Rikard H=F6glund ; Marco Tiloca ; Rikard H=F6glund Subject: New Version Notification for draft-hoeglund-core-oscore-key-limits= -01.txt A new version of I-D, draft-hoeglund-core-oscore-key-limits-01.txt has been successfully submitted by Rikard H=F6glund and posted to the IETF repository. Name: draft-hoeglund-core-oscore-key-limits Revision: 01 Title: Key Update for OSCORE Document date: 2021-07-12 Group: Individual Submission Pages: 21 URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hoeglund-core-oscore-key-limit= s-01.txt&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d= 08d94542969d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63761697455768147= 5%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha= WwiLCJXVCI6Mn0%3D%7C1000&sdata=3DkPrsqBxyArLYJ%2F2GStdR3Y1ue4tc1Q7AVCID= mMY%2FjgU%3D&reserved=3D0 Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hoeglund-core-oscore-key-limits= %2F&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08d94= 542969d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557681475%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C1000&sdata=3Dt8CQXg608X5QAk9MjfScx%2FhojlgBXtonN%2BeDcKX= PAqE%3D&reserved=3D0 Html: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-hoeglund-core-oscore-key-limit= s-01.html&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00= d08d94542969d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6376169745576864= 45%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h= aWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DKqlGT%2F2atIi30rDaEEqMiU%2FVypdFhismY= AffqvK%2FtCA%3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hoeglund-core-oscore-key= -limits&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d0= 8d94542969d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557686445= %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW= wiLCJXVCI6Mn0%3D%7C1000&sdata=3D6KdeONArX%2Bc3VJSmMt%2BWKC0VpFm3UgGvrL8= bleKT5qo%3D&reserved=3D0 Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-hoeglund-core-oscore-key-lim= its-01&data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08= d94542969d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557686445%= 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw= iLCJXVCI6Mn0%3D%7C1000&sdata=3DitYHNW%2FKFsWR7x3cn50HsrKLKqN7wb9wazh3Hq= eEQiE%3D&reserved=3D0 Abstract: Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. This document defines how two OSCORE peers must follow these limits and what steps they must take to preserve the security of their communications. Therefore, this document updates RFC8613. Furthermore, this document specifies a lightweight method that two peers can use to update their keying material and establish a new OSCORE Security Context. The IETF Secretariat --_000_AM9P189MB1571439A130A663EC13540A783119AM9P189MB1571EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello CoRE,

We have submitted an update for the draft "Key Update for OSCORE&= quot; --- previously known as "AEAD Key Usage Limits in OSCORE".<= /div>

This document considers the CFRG draft at [1], and accordingly defines= how two peers using OSCORE must take limits of the used AEAD algorithm int= o account, and what steps to take in order to preserve the security of thei= r communications, e.g., performing a rekeying. Also, this document specifies a lightweight method that two pe= ers can use to update their keying material and establish a new OSCORE Secu= rity Context.

Building on what discussed during the CoRE interim at [2], this update= covers especially the following points:
1) The proposed key limits have been revised, mostly based on input fr= om John Mattsson as per slide 11 of [3].
2) As reflected by the title change, the document scope has been broad= ened to include also a key update method, that the two peers can use to upd= ate their OSCORE Security Context.

Comments are very welcome!


Best wishes
Rikard H=F6glund

From: internet-drafts@ietf.= org <internet-drafts@ietf.org>
Sent: Monday, July 12, 2021 16:37
To: Rikard H=F6glund <rikard.hoglund@ri.se>; Marco Tiloca <= marco.tiloca@ri.se>; Rikard H=F6glund <rikard.hoglund@ri.se>
Subject: New Version Notification for draft-hoeglund-core-oscore-key= -limits-01.txt
 

A new version of I-D, draft-hoeglund-core-oscore-key-limits-01.txt
has been successfully submitted by Rikard H=F6glund and posted to the
IETF repository.

Name:           draft-hoe= glund-core-oscore-key-limits
Revision:       01
Title:          Key Update for= OSCORE
Document date:  2021-07-12
Group:          Individual Sub= mission
Pages:          21
URL:            https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-hoeglund-core-oscore-key-limits-01.txt&amp= ;data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08d94542969d= %7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557681475%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&amp;sdata=3DkPrsqBxyArLYJ%2F2GStdR3Y1ue4tc1Q7AVCIDmMY%2Fjg= U%3D&amp;reserved=3D0
Status:         https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-hoeglund-core-oscore-key-limits%2F&amp;data= =3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08d94542969d%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557681475%7CUnknown%7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&amp;sdata=3Dt8CQXg608X5QAk9MjfScx%2FhojlgBXtonN%2BeDcKXPAqE%3D&= amp;amp;reserved=3D0
Html:           https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-hoeglund-core-oscore-key-limits-01.html&am= p;data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08d94542969= d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557686445%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C1000&amp;sdata=3DKqlGT%2F2atIi30rDaEEqMiU%2FVypdFhismYAffqvK%2= FtCA%3D&amp;reserved=3D0
Htmlized:       https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hoeglund-core-oscore-key-limits&amp;= data=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08d94542969d%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557686445%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&amp;sdata=3D6KdeONArX%2Bc3VJSmMt%2BWKC0VpFm3UgGvrL8bleKT5qo= %3D&amp;reserved=3D0
Diff:           https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-hoeglund-core-oscore-key-limits-01&amp;d= ata=3D04%7C01%7Crikard.hoglund%40ri.se%7Ca852159407fe4157e00d08d94542969d%7= C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616974557686445%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0= %3D%7C1000&amp;sdata=3DitYHNW%2FKFsWR7x3cn50HsrKLKqN7wb9wazh3HqeEQiE%3D= &amp;reserved=3D0

Abstract:
   Object Security for Constrained RESTful Environments (OSCORE) = uses
   AEAD algorithms to ensure confidentiality and integrity of exc= hanged
   messages.  Due to known issues allowing forgery attacks a= gainst AEAD
   algorithms, limits should be followed on the number of times a=
   specific key is used for encryption or decryption.  This = document
   defines how two OSCORE peers must follow these limits and what= steps
   they must take to preserve the security of their communication= s.
   Therefore, this document updates RFC8613.  Furthermore, t= his document
   specifies a lightweight method that two peers can use to updat= e their
   keying material and establish a new OSCORE Security Context.
            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat


--_000_AM9P189MB1571439A130A663EC13540A783119AM9P189MB1571EURP_-- From nobody Fri Jul 16 05:28:43 2021 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 393523A34CE for ; Fri, 16 Jul 2021 05:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 c1cy8E8Hi_-J for ; Fri, 16 Jul 2021 05:28:34 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2053.outbound.protection.outlook.com [40.107.21.53]) (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 928333A34CF for ; Fri, 16 Jul 2021 05:28:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kd0OXqpQpZM9d5/eifRHCA4z9b7t/LruwITjDRWc9qKsm57pda564iHn3Vb3I6GUmHHmWOAA+Vp8emGwJG0xOyP0YKTZ1g1/Z2gaBQxggo9Cd06lBLrK9YilAISezUOKBfOzmWre+1XQEBlRjgLbpIUrQVaWOBW9O+gbipk6xgTyYsy1HfkaHF0hvoHZYhAx9FFp33bU7LMp06wlTu6aDQzkeqh+IVCkyJq1TEaklsiXEGnnqQw3TBnVEFGEg0UleZ9UiVOUKSOunlBmPdrAbH4g5rWUguFsDIBeXe3yep+tyvMAYsEb8n7uBe+jOwURt81j0/mma3gkz3Dw6mTS0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wiEXWbqXL8PDvWgTLsbXxIaXrQ881Nm0wbNh5a4WSZU=; b=DcJ2z1/Xn0wIwyrNMOFoISdHAw76+GrQYg7svZt7CTlWIRTeOiJU09HFided4GrpQ7NrIhI1/4jimy63dalZwPvLUaW2kcKuIRmP5C9jzk9SLphDulCkwIlkMEuXDqQ7bDnSUscf0mDI4mW+o1TDFpKh4srq4qitTfaTpXJGSKmBzhLsR5z8KRzltJO0wB6ym5kM0QUyQSU+N1QPM+2CKgf8xdLNrr+3jeM/FCQt0rJ6UPZCrZy3UGf3xc+y8smIHcy5Qw4ygHoN+erEevlWwEmTGzL0AgNn7fNQD8/bgqcCYZ6OnO7uPDAidlgvFaCiHxxQwDnWEFtD6XDdGB9f2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wiEXWbqXL8PDvWgTLsbXxIaXrQ881Nm0wbNh5a4WSZU=; b=UmlP2UU4wp1Jzvh2mo4OmnlPow7HnFZ7Sgih2sDVhZbzXf3ATzio0qjb9uKRzPremTSesDoClIzczBwwDq/SWyiqQSNeTmVpps3McHBzmcBQkIxsGO6FPhxwh98OmjvgV2ODhgaC/c64mXbC6VUvI18oI7JE765axUGV0zgIcRM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1419.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1ed::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23; Fri, 16 Jul 2021 12:28:25 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4308.027; Fri, 16 Jul 2021 12:28:25 +0000 References: <162610412226.20248.15090823864879976159@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <162610412226.20248.15090823864879976159@ietfa.amsl.com> Message-ID: <85ae40fa-b0bc-e94f-effd-7f43d36b2776@ri.se> Date: Fri, 16 Jul 2021 14:28:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <162610412226.20248.15090823864879976159@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VikaOcchjy7gFLh7HVEIsNN12QmN6QMSg" X-ClientProxiedBy: HE1PR0402CA0028.eurprd04.prod.outlook.com (2603:10a6:7:7c::17) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.3] (185.219.140.159) by HE1PR0402CA0028.eurprd04.prod.outlook.com (2603:10a6:7:7c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Fri, 16 Jul 2021 12:28:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f893b8c7-41d8-4dca-c40f-08d94855357c X-MS-TrafficTypeDiagnostic: DBBP189MB1419: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fkvUWENzTlK5z6fnxnydtYFDpzd5bylUDBSBXVJFK2WY3t2BPHGLTP2dlxStFLwB2uJM46T/1L8WYyV1io/np6KQ1rY1c+vXr1R0cfJuJGMd4P01QGw0/yDuI5Nt9Y67B9vDzmwND0/SYo/fj015Eo/7B2Ydfike9rP96ZCaAqJwZeAa/K0x1psWq2AeQw2wVI7NJviMnlS3afV1diYYPryA+6HQT1suRBblItTD5hb4OI+TTWcBosD9POuU+4I7Dvony57zQCHHyK4C/nDvZZHJqgUciPGpuTtWj/+JargVHS2W7MHWpqw+AiPM7Nm/B2uurUSKfxg2X9tt5ee/ueNTmM1IpQyaYS8KwnCxEpEtrDqSiaaZlW2r3Xkaj/TdoeaTB0pu2tpKMy7oN0zqK/79caASjO4ZpnB9P6YekuKOqUgLvJse2ygXgU8KUWbkJYNCK9njmMl5+HB89lscDzNEu8v7IYThstxTTe5y5Kp4cy5NwrrpyXAnSPL8pOVwC1gIkUBJJ3k9Q6Zh0DnSRZppzHbNajhUMiNYlCP51ul8SlhuPs6RZBYpdweSlCXCuoAbvnwLwJnFjePHDn2EK5IdFR4tRu++JavX/sGLLasMd6ny8DWekdItPyXRg8RCYJxIlI6HcXx5rkdrxud5QIJ51QS6IqN8WViD1M1SAn4H9c2Wx1l1Zq7w7cozN61rM0vj20RsbCiWSYdQzTzvfY90ic945rCidrrvuw8j0pZcD5T6PB9ML83ZLA2s9Yrh768NmdRuJoAe6NiSNbhn6530aXzn6wJc6lp5Ak0fCBJPSrjiV+QkgZKQ86jhjMe4 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(136003)(39860400002)(376002)(2906002)(31696002)(6486002)(45080400002)(26005)(966005)(31686004)(15650500001)(38100700002)(186003)(36756003)(478600001)(86362001)(83380400001)(21480400003)(6916009)(66574015)(44832011)(956004)(2616005)(66556008)(5660300002)(235185007)(8936002)(66476007)(8676002)(166002)(33964004)(16576012)(66946007)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZDRZUE9OQmUwYWFHUkZGMEtSaXN5M3FjNHY0TVZVdUt5b0JRb3pBWmhEVUM3?= =?utf-8?B?YWhVbG04R2M3ZW1tM1JOTFRPRFRVSXpDcDJTQTJaRkszR0hCZ25NbUdHbElO?= =?utf-8?B?R3ZOUDBHamFkUGNmdWx4eXMvM3F0RVpLTzdvK1ZPdmw0WDdLelZUenIxd1cy?= =?utf-8?B?S0srRUxCamlicTBYQUFpeXFFNDVqVHAyRVZJOERGbktrVi9Tb3dQWHBvTnBt?= =?utf-8?B?L08xaEluM1QyRTBBZ1UzTDZFVWFxL1AxMTJ1RXVSWi9KLyt5THNhM21QMGsy?= =?utf-8?B?MUxYbkdKVG0wampXQ1FXdEUxaVRheEw3dVd1UHp0SVFxTzYwaFRoNGVXRU1H?= =?utf-8?B?TG44QlgyM1ZmcUhsZzNzNlRLL05sbE4vWkV4ZXFULzFrZFIxU3BEYWkvSFRh?= =?utf-8?B?VjRXNFRjOWFPSlQyOWNWaUhhTVdEMUpxanc5ZTlWenliRHN4MldlcVBQM25I?= =?utf-8?B?dDZLUE5Icm1Rek5KNmNGbzZpRExzVWFOMjBMTXVJcG5vSGR5V3JzKzA1Zlpw?= =?utf-8?B?dUhWVHo0Z0NlQXRGUlpvUFNwUHBDUGZUS0RnOTd5ZFNRU0QvUHF0VWwrK0Nw?= =?utf-8?B?T1ZlaER4Vm9RNExMZThCbDd0bUJZZmU5UitNaXBMQ0JObXRUYU80ZmNGbWNP?= =?utf-8?B?eTFpWW5qUHVHd2I1Wmk5Rm5tTzBtdmxFeWwzUWtBMXk4L2tyQm0ySm14Mklp?= =?utf-8?B?ZGlFTkk1dkd0TTIxQWxqeFV2Q1Y3U2ZIWFZFbXhOZmFhcmk4LzNoN0xTM3pB?= =?utf-8?B?REEya0dCdWlHL1htamg2WDZWckpjMHdoZ2R1eWVEYzJPaTh3R20zTGtNQlhr?= =?utf-8?B?aDFOR3BNSkxvcVM4MExGaUlUQmYwdkoxd0Q5ZHFyNmNDTnUxUklFS3BES1F6?= =?utf-8?B?WHlFQmtjWUt2MUVYN3hqaWNmWEFGcVhrRGxtb0pLTzMrT3lnSUpDUWNManVT?= =?utf-8?B?N1lmM0t2dkllQ0ZPYi9aRVlHbXV3ZlpLL3J3Mm5rZTQzdGhjTHRzR2xtVU1w?= =?utf-8?B?MTVSRUR6dUU3dEpRVVNXQ2ZyV0krZHIvblRoY1ppU3hpQ3RyOGRFcUNNMkdO?= =?utf-8?B?cUJGQzlIUjl6eWRGbjFGeHlmV0I1SkdMUmxmZ0FsTkt4cUpTcGt5NDFna3gw?= =?utf-8?B?NmZoUGw5MmltaUxjN1ZZWWxDa0grZzRsOGtwTnJOdGRobUt0aTFmMXovRUto?= =?utf-8?B?bUtBYmdqOVUra2NDeUV1S2pDdnBqWDAxYlNJVmdFMGU0ZzZrOVdPNlh3cXQy?= =?utf-8?B?RlZ5UXhTcXRxSmxsMUM1aGZCd1RKdUgrNHJteGt1ZHNLMXljS29xR0ZkL0Iv?= =?utf-8?B?OUs0cENOVVRiZGtrUG5CNHRmRE82bkRzS2ZtTmRGNFdKdzBTZ1NLaHlwNlpJ?= =?utf-8?B?d2p3ekN2WE1CUFVNSG5kdHpsN2pDNTdLSFlqMFlhekNCa0xvOXJ5a0hucmNj?= =?utf-8?B?ZWdtQzAvL3ZSRVdrUHM2ajQvSmhHV0Y3RVNJT3hubTc1RFBHVXY5UGJ1WjI5?= =?utf-8?B?YWZBOStRWlZyRm9VWi9yTjRzZTBtbFdrd3ZEbkNEMWYyU3Znc1dMWWdDVnRG?= =?utf-8?B?d1RlaHVOdjR5T1JDWUdyVDZNMHFVSW1ERkNhTFpHT2N6ZERXWFE1MFdQL2Va?= =?utf-8?B?TUcyZnJVUlJXSnZyaVhXcmxpRlR5eGFrTzcxRnFBM2tmUkZIZDYrWHRlNzZJ?= =?utf-8?B?YVJsMWRtLytzOCswYWRZdS9CTlN0VGdzNjNURHNjM3AyazFqZDJlaGg5bjVO?= =?utf-8?Q?lHKq570+I6rTAAFqKxeD5WqwHNq+Lu86AXwt/eT?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f893b8c7-41d8-4dca-c40f-08d94855357c X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2021 12:28:25.7490 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: k30Hnt5VgpVmG9qlgzfHVeBFefGQFiHgjYeu/MdpQZHmvJ6uMFe1SrcapMVpu60t7ykCt8ePL1IlfEVju4nf7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1419 Archived-At: Subject: [core] Fwd: I-D Action: draft-ietf-core-observe-multicast-notifications-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 12:28:40 -0000 --VikaOcchjy7gFLh7HVEIsNN12QmN6QMSg Content-Type: multipart/mixed; boundary="jho7GGKBCsTkTrFxMyjnoRgVr3LzFkSHp"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <85ae40fa-b0bc-e94f-effd-7f43d36b2776@ri.se> Subject: Fwd: [core] I-D Action: draft-ietf-core-observe-multicast-notifications-01.txt References: <162610412226.20248.15090823864879976159@ietfa.amsl.com> In-Reply-To: <162610412226.20248.15090823864879976159@ietfa.amsl.com> --jho7GGKBCsTkTrFxMyjnoRgVr3LzFkSHp Content-Type: multipart/alternative; boundary="------------C9044495F04E6536AA819277" Content-Language: en-US This is a multi-part message in MIME format. --------------C9044495F04E6536AA819277 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, We have submitted an update for the draft "Observe Notifications as CoAP = Multicast Responses". https://datatracker.ietf.org/doc/html/draft-ietf-core-observe-multicast-n= otifications-01 The document describes how a CoAP server can send Observe notifications=20 over multicast, and how Group OSCORE can be used to protect such=20 notifications. This update is especially about the following points. 1) Simplified cancellation of the group observation, with no need for=20 the server to use an explicit cancellation request. 2) If the server provides clients with information to join the right=20 OSCORE group, the parameters and their semantics are aligned with the=20 latest updates in draft-ietf-core-oscore-groupcomm-12 and=20 draft-ietf-ace-key-groupcomm-oscore-11. 3) Improved Appendix C about the server self-managing the OSCORE group=20 and Appendix D about using Cacheable OSCORE [1]. 4) Added a new Appendix G, which provides a discussed example when using = together a proxy, Group OSCORE and Cacheable OSCORE [1]. Comments are very welcome! Best, /Marco [1] https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/ -------- Forwarded Message -------- Subject: [core] I-D Action:=20 draft-ietf-core-observe-multicast-notifications-01.txt Date: Mon, 12 Jul 2021 08:35:22 -0700 From: internet-drafts@ietf.org Reply-To: core@ietf.org To: i-d-announce@ietf.org CC: core@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Constrained RESTful Environments WG of=20 the IETF. Title : Observe Notifications as CoAP Multicast Responses Authors : Marco Tiloca Rikard H=C3=B6glund Christian Ams=C3=BCss Francesca Palombini Filename : draft-ietf-core-observe-multicast-notifications-01.txt Pages : 77 Date : 2021-07-12 Abstract: The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. The IETF datatracker status page for this draft is: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-ietf-core-observe-multicast-notifications%2= F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149aeb1043e18b5608d9454= ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617009728442257%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi= LCJXVCI6Mn0%3D%7C1000&sdata=3Dn0bXpuLi3jp3X4Qw7iQYqlywymJlZvOfyAZsjts= 9xj4%3D&reserved=3D0 There is also an HTML version available at: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-ietf-core-observe-multicast-notifications-= 01.html&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149aeb1043e18b560= 8d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6376170097284422= 57%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik= 1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DByI1NU5O0p9zuxWsvpSqP%2BJuMNU%2Fo= whkR8%2FTfY0CG3M%3D&reserved=3D0 A diff from the previous version is available at: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-observe-multicast-notification= s-01&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149aeb1043e18b5608d9= 454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617009728452226%= 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha= WwiLCJXVCI6Mn0%3D%7C1000&sdata=3DaNV18b4G63Khkpu8RvRGJuHqUd2zcfQ40MQc= al7W2to%3D&reserved=3D0 Internet-Drafts are also available by anonymous FTP at: https://eur02.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.org%2Finternet-drafts%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1c= e2149aeb1043e18b5608d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0= %7C637617009728452226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DiSw%2BRsdLPfyu= BxlBLWW6f34%2BnbybWIzYGQO644eURZE%3D&reserved=3D0 _______________________________________________ core mailing list core@ietf.org https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca%40r= i.se%7C1ce2149aeb1043e18b5608d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e= 8%7C0%7C0%7C637617009728452226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D91hJF= LnDeDrBmLf5tdrqOl0d61cSHkYzPIAp9uQt504%3D&reserved=3D0 --------------C9044495F04E6536AA819277 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have submitted an update for the draft "Observe Notifications as CoAP Multicast Responses".

https://datat= racker.ietf.org/doc/html/draft-ietf-core-observe-multicast-notifications-= 01


The document describes how a CoAP server can send Observe notifications over multicast, and how Group OSCORE can be used to protect such notifications.

This update is especially about the following points.

1) Simplified cancellation of the group observation, with no need for the server to use an explicit cancellation request.

2) If the server provides clients with information to join the right OSCORE group, the parameters and their semantics are aligned with the latest updates in draft-ietf-core-oscore-groupcomm-12 and draft-ietf-ace-key-groupcomm-oscore-11.

3) Improved Appendix C about the server self-managing the OSCORE group and Appendix D about using Cacheable OSCORE [1].

4) Added a new Appendix G, which provides a discussed example when using together a proxy, Group OSCORE and Cacheable OSCORE [1].


Comments are very welcome!

Best,
/Marco

[1] https://datatracker.ietf.org/= doc/draft-amsuess-core-cachable-oscore/


-------- Forwarded Message -------- =
Sub= ject: [core] I-D Action: draft-ietf-core-observe-multicast-notifications-01.txt
Dat= e: Mon, 12 Jul 2021 08:35:22 -0700
Fro= m: internet-drafts@ietf.org
Rep= ly-To: core@ietf.org
To:= i-d-announce@ietf.org
CC:= core@ietf.org



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 : Observe Notifications as CoAP Multicast Responses
Authors : Marco Tiloca
Rikard H=C3=B6glund
Christian Ams=C3=BCss
Francesca Palombini
Filename : draft-ietf-core-observe-multicast-notifications-01.txt Pages : 77
Date : 2021-07-12

Abstract:
The Constrained Application Protocol (CoAP) allows clients to
"observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the<= br> server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and
RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of
a same resource on a same shared Token value. Besides, this document
defines how Group OSCORE can be used to protect multicast
notifications end-to-end between the server and the observer clients.


The IETF datatracker status page for this draft is:
https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-observe-multicast-notific= ations%2F&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149aeb1043e= 18b5608d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6376170097= 28442257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB= TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Dn0bXpuLi3jp3X4Qw7iQYqly= wymJlZvOfyAZsjts9xj4%3D&amp;reserved=3D0

There is also an HTML version available at:
https://eur02.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-core-observe-multi= cast-notifications-01.html&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%= 7C1ce2149aeb1043e18b5608d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0= %7C0%7C637617009728442257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DByI1NU= 5O0p9zuxWsvpSqP%2BJuMNU%2FowhkR8%2FTfY0CG3M%3D&amp;reserved=3D0
A diff from the previous version is available at:
https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A= %2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-observe-multicast-n= otifications-01&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149ae= b1043e18b5608d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6376= 17009728452226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz= IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DaNV18b4G63Khkpu8R= vRGJuHqUd2zcfQ40MQcal7W2to%3D&amp;reserved=3D0


Internet-Drafts are also available by anonymous FTP at:
https://eur02.safelinks.protection.o= utlook.com/?url=3Dftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;d= ata=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149aeb1043e18b5608d9454ac649%7= C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617009728452226%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI= 6Mn0%3D%7C1000&amp;sdata=3DiSw%2BRsdLPfyuBxlBLWW6f34%2BnbybWIzYGQO644= eURZE%3D&amp;reserved=3D0


_______________________________________________
core mailing list
core@ietf.org
https://eur02.safelinks.protect= ion.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F= core&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C1ce2149aeb1043e18b56= 08d9454ac649%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617009728452= 226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I= k1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D91hJFLnDeDrBmLf5tdrqOl0d61cS= HkYzPIAp9uQt504%3D&amp;reserved=3D0
--------------C9044495F04E6536AA819277-- --jho7GGKBCsTkTrFxMyjnoRgVr3LzFkSHp-- --VikaOcchjy7gFLh7HVEIsNN12QmN6QMSg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDxe2cFAwAAAAAACgkQ7iZktA5Y2kOJ 4AgAo+jKHcvKj4Qgr4DeXy/+12UATnmSa/MAGPtxXlgd2qz/xDfpwwv50RpIAHyxBcfSfSOTgwm9 idYG8MDH4SW7JDZhH/HYtRALWqRGlZflJODrJdbbAXpmkhjv0UzCc41TnGodsikuAMiIepaNhlf/ NGvFV7q3aOiQjbrj66iUqDqsO+Of+i99PiDfI2itzKsXH/HtBloSPWFvSpxNgkOx9Izd3LagXfRr 3TNIE2S1UW3vn1JaEX4s+0ZFu8YJlsr6WLSWEw6Q8ztfPHCodpljw+6Gs5gmejHtWjP6OuckRkal HrEHeZzBqc/PYXijyvMiMQAbKiUdD+PVbNmXFt/Cyg== =+lt4 -----END PGP SIGNATURE----- --VikaOcchjy7gFLh7HVEIsNN12QmN6QMSg-- From nobody Fri Jul 16 05:30:40 2021 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 DBEF33A34DC for ; Fri, 16 Jul 2021 05:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 e9ahrpcRRktk for ; Fri, 16 Jul 2021 05:30:31 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20078.outbound.protection.outlook.com [40.107.2.78]) (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 4E3E23A34DD for ; Fri, 16 Jul 2021 05:30:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DuB8rzACA8M4wcksU02vJtX3dPhM0eMknfEoykA1PObI/Ad1NJ6d1nTpyHqMUhm69sowtfzOJlqk2p2qHOR3cSD5jvkUTa2qzA9niRp8WNuL2LJJQusgTF1ts/JVbuWFA3KD0a6G6C/8z5JP6sdrsLIeBncX580jfiZGC1tJnO8gp4s5WS8kmBijYEvv6P4EZcJLAg8g1W7OrGTDll0Xzsx58ZXoIL5QEzafsOuNE+E36g3MFq42mQ+i/FZp3OOinF3uxEqTKAT/TJOnuKAvhEKKxZmJDGxdmOs9QYAirq43zWOVCiT5jx9uZfw23pvuHIaejY7NJmelwNfnPxHJVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JdajiInAz+OBSQc/nh/zP/PVYpboyvyTtGQ1tWoH8BY=; b=DTkgiEgpqolgmzzPsGnfqqrU01cidixlqwvEJv/8JCamv9S3GrL7vyKrqBXKdziFckoTQ08TuqStJueYNauXSzR/k8rweCeh330yVoIdDBTgqPTYI0v50NjFZZnaK0hfw7h3wiZUwykUyw3ZI/LIsdDy1Sdn+Q0rtEADNM6XskFdSSZJd15ursVbiLuaba6SMSX1y01VLqNtpHmA1ULPynZ93/2+LzjbrJqn2gUsamKCuq3oVGiRkEXL3WwXFUo6dIg1IfAlKSwmkFlKVqGkCbzyFe7hm/hUvIRdEl1qGPCnKzShBArKNSFH+K6yGCX7qPjTOKti99p5H9MLPmczfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JdajiInAz+OBSQc/nh/zP/PVYpboyvyTtGQ1tWoH8BY=; b=YHQFfh7IrieAaCj2WxMeudqXo61V+XzVS8nr1yHA7PYop5hd0vW3Sh9/E53hbQumDzgA15H2d/xJ9ib2vgrO/xyXkoBEJwvd0MU0TQzVFeETskwKKkVJHvmzfxNjOv8iWfdW+gJaRseVi7act1txWsGryUWCNDnibWv6bytDXSU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0280.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:35::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.26; Fri, 16 Jul 2021 12:30:27 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4308.027; Fri, 16 Jul 2021 12:30:27 +0000 References: <162610841517.25212.13705237650915658068@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <162610841517.25212.13705237650915658068@ietfa.amsl.com> Message-ID: <6aa2f77f-0676-2c9e-13e0-2966b1435724@ri.se> Date: Fri, 16 Jul 2021 14:30:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <162610841517.25212.13705237650915658068@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7LriaLgmBlMXTBCvvjhW4GuHw2oUPLOly" X-ClientProxiedBy: HE1PR0402CA0025.eurprd04.prod.outlook.com (2603:10a6:7:7c::14) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.3] (185.219.140.159) by HE1PR0402CA0025.eurprd04.prod.outlook.com (2603:10a6:7:7c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Fri, 16 Jul 2021 12:30:27 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 63c6c9c8-f564-448a-c41c-08d948557e1e X-MS-TrafficTypeDiagnostic: DB6P189MB0280: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NVALMKj+RHAOg72WTBv7Fn27i3z89kuqIT9LU4uaWT7zTAMMeHwGeqXhOWdBv61zcfw0X3yHfarrsD7WqepC6QEou35cIZgV2og0Kcls3pJjQ3IsF2F5e9ZyacHB75XgnlN8J4iB3LlSpaJFzPnG+TBCh89KWZTFfMDXBhVQCLpGCv1M8aE8Y5fLj4asw7ZdPEPpJWwXr/Tx/FBB41+7Of9yhgK9rHfKTW8RLUb8YCNT7CD2vZGMtbD8fxloJVZSefjSiiBj2VkXxcGuSdY9RCgSD3+oFTHhrkjTeSaPJGao0slED/CpYd2LpLibq/f/xeojOOo3klmCYZ6ih3Wjj7vPQMIOIbr/Ygv5U+SqhNlUdJyboFsHpU/jUvHpFaXUfWKLFY+fNdDSP7IIKlQYMatUGp8dMUfL04c/H4piaIRFBM86h3q8bRitJi/Svi7d7/zOfGgeMI46yRkiaujR5sSB7Ou5lzh3VsMzj2cN4KHLGBLbf/wwS2zqnZ8nPAXRh2uMM4ySY5f6fLCvLk/ZBw0Z6S8uQDDE6I8oLLSEafSQ6K3GihDTrn59doRvrNuW4um/9Qsprll00DUS1Vmcf/NRvgYx0wMQPjeq2M5uDRjggO5YO1Ccf6q7ffDZsv6UHNMxw1JW6SKu34djrI71Hszy9K2toANPJa2gV8BrXIxZ+apdg4ajz60eYt82GkrzxuULxSZPFcpqOyvjMiie7ZTmQ6yeq5vrvreegP2Q66dizYYck/anrgC+HUkJAQy7UNoPTP2hawOUdVZh6y8L6IKxsS+O/nr3bt1PnKGXYE5BHHJ62ZhbJN1sr1b3cBsA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(39860400002)(396003)(376002)(2616005)(6486002)(966005)(478600001)(956004)(33964004)(31696002)(45080400002)(186003)(2906002)(5660300002)(86362001)(26005)(8936002)(31686004)(6916009)(235185007)(8676002)(21480400003)(44832011)(16576012)(66946007)(38100700002)(166002)(15650500001)(66556008)(316002)(83380400001)(66476007)(36756003)(66574015)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d25HY1AxVTBGMHJyN0JBa2FnbmlMemdrQUtxb0hPWmFmVDk4QytxWlJ1V21I?= =?utf-8?B?ZFZmNW5LUndhRmFCSXQ2ckF3aFVqWWlqZjhPZTJJbXNKM2ZhWW9nbUhrZUhM?= =?utf-8?B?QTRCSmkvVlFzaW1JN1VZN0p3Tmo2VXpiSDNqQTFXeml2ZnhmWXFNU2V3ck04?= =?utf-8?B?YmZXUk4vSWVxSUtxNFNncGp5V0ZvRlluM3RKamNMbGNacUsvVS9pa3FCRmU4?= =?utf-8?B?WWZUZmRqVUhwVkNEb1MrZWhpeFFwWHRadFUvVEhqMHZWaW5kMEJFZmh4ckhp?= =?utf-8?B?UStPUlhNQ01DRHBDOTFHcjVIbU9uRVpkT0EyYlE5eGM1M056YkZYdGJCRWtq?= =?utf-8?B?K1k5U3Y0TzUybXV6K3ZUTUd4VzFvMlkrclA2bmZ3bDRNb2JDdlV0UjNOYVY0?= =?utf-8?B?UE9ZZXRGQlJzWnAvUHZPK3hTL1Y5b1lUMWN5dkhhUTF3Z1pLWExDa05QNUxq?= =?utf-8?B?Q2xrT3l1WnFMU25xbS9FWXBqRk4zWGo2aTZHK3hJTyszelNFbG03REZxYlgv?= =?utf-8?B?anoxRDBtOExHK21GZWVJaEFYQ09VdFFQMlhCakNaOERXMUk4Qi9GY2g1MXZU?= =?utf-8?B?cTlhY1ZmNFpsWXFGTzNmV0w3b1hjeCtoTG9aWFc5cC9jQ3BETzZON3FheU01?= =?utf-8?B?VC9vQlBBQzk3MW5IMDRjNDRsNnJER1R4dFcxbWZNcVRPSzE0QVEweXRoTmxJ?= =?utf-8?B?OWs1OUpnUFVKK3R2WWFEUGlDNE1kd3AwQTQra0dHRXVyK3ljYmtvS3BwSk5Z?= =?utf-8?B?ZkNSdnlHdWlUblRFSm5sYjNuOThEeCsrWGhGcWZWT1I1eUhNMkN1UkZLL0FC?= =?utf-8?B?ZElrN1lXMlZLbDc1dXFQMmoyK0E4c2Y1dkVuUVNVQXNWNlcvUkZWZUZYZ25k?= =?utf-8?B?VlhsR3dKTldFdDFydkM0eHhaK3Q1ektzYjZremtrTDVuTlFKVmd1ZUM1ZHc1?= =?utf-8?B?LzFIeTczNXI0VEVtT2FpdEpKOFJqOFBVKzJSalVLUGpKNTlBbFhENDNiYTBm?= =?utf-8?B?QTAydkdZZ3htVWtQYStoRmdiMEF3MlFnRXhwTmpQQk5vNUM1NjBuYjFQSDZl?= =?utf-8?B?UldwS2VkbzlxdUJvK0puekFSdGxjcUhQVWdxZGVqcDNzdGsxVjNVWFloMUNK?= =?utf-8?B?cFFwZ2RNdjlCMHl6bTJKbHYxNi9RWVBDK1o3WnUrWkxkRStUQmdYR1U4b2ty?= =?utf-8?B?aVYyQnZIQ0lpUUlDZDFSaWtYdXJlUXpsaDV3clNSb0F6bnFMZFNvem92S1I2?= =?utf-8?B?SjRGZHoweHJsQnpJLytxaE5oTmJhQ0VhalVodlo0WVlFNG5tU0NRU0JmTzhW?= =?utf-8?B?d0VpcVQ0UVl3UFM2S25BZVBhNi80bWJaWnBRS3U4Y0pZOWlIeFdSNmV2b3RQ?= =?utf-8?B?T2pacldyTDdCMmhEMlREZWpIbVZ5QUs4cENMZVN6OWdFRUVlUmdkbDlPU0pI?= =?utf-8?B?OWxyeFRyMktKd01paFZiQnNqSUtGZ09vSkRla0tEd1ZWbW90S1ltS1d3Vld3?= =?utf-8?B?aVBDS1NHUTdFcWp3UEQ3aDhBWVBqN2VveUpucERHcE1xOEJkamhvRUppRmxH?= =?utf-8?B?cDFRZC9LeG9paVJEa0ZmZE5HdTlheWF4dlYzUWhFTjR2bHU0TGRXQzhuZ25R?= =?utf-8?B?eGw0ajZsZ0FldENWV1RLR2xtU0dlNGhBcXlFU1NXVStFb3ZtRStMOERlckhu?= =?utf-8?B?bVQvcUo3ZGZkMjY5M0NIM3ZZV0ZBV1k2OHJoR0gzUlI1Z1VnZC9ncm5ZWnVk?= =?utf-8?Q?rCD7mXYr1FBmtDyuMWwwG2CvnOIEyJLcmeMLelL?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 63c6c9c8-f564-448a-c41c-08d948557e1e X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2021 12:30:27.6136 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: m79ijmwtyHYsceXU+Qf5MtQRV55pSHFP1EbVuGCFN6cuq/5noiFIOpUn+wq/7l/dSfey7gdeMI/ckc25QzwPow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0280 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 12:30:39 -0000 --7LriaLgmBlMXTBCvvjhW4GuHw2oUPLOly Content-Type: multipart/mixed; boundary="VNl9AXeBPWCu4g2CSJMYli6aZYSeD1LdV"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <6aa2f77f-0676-2c9e-13e0-2966b1435724@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-09.txt References: <162610841517.25212.13705237650915658068@ietfa.amsl.com> In-Reply-To: <162610841517.25212.13705237650915658068@ietfa.amsl.com> --VNl9AXeBPWCu4g2CSJMYli6aZYSeD1LdV Content-Type: multipart/alternative; boundary="------------326D9E9B35B0E2994AD1A39E" Content-Language: en-US This is a multi-part message in MIME format. --------------326D9E9B35B0E2994AD1A39E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an updated version of=20 draft-tiloca-core-oscore-discovery https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-discovery-= 09 The document describes how to use the CoRE Resource Directory for=20 discovering OSCORE groups and retrieving information to join them=20 through their Group Manager. This update is especially about aligning with the latest version -12 of=20 draft-ietf-core-oscore-groupcomm , with respect to: 1) The names and semantics of parameters describing which algorithms,=20 key formats, etc are used in the OSCORE group to discover. 2) Supporting the discovery of OSCORE groups that can use the group mode = only, or the pairwise mode only, or both modes. All examples throughout the document have been also updated accordingly. Comments are very welcome! Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-tiloca-core-oscore-discovery-09.txt Date: Mon, 12 Jul 2021 09:46:55 -0700 From: internet-drafts@ietf.org To: Christian Amsuess , Marco Tiloca=20 , Peter van der Stok A new version of I-D, draft-tiloca-core-oscore-discovery-09.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-oscore-discovery Revision: 09 Title: Discovery of OSCORE Groups with the CoRE Resource Directory Document date: 2021-07-12 Group: Individual Submission Pages: 36 URL:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-discovery-09.txt&da= ta=3D04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%7C= 5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C1000&sdata=3DLoEBCBf5Z0ExTRtrbDnA8hMuX%2FUf45R%2BXdpSnf%2F3h= J4%3D&reserved=3D0 Status:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&sdata=3DwquNTGqX1J2E9cOyQtEforDS2J1klU%2B0MdNtJR4tZbs%3D&= ;reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-discovery&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&sdata=3DgWYAj9AKhNEFE1a4ktCiLKdAgiXX94SEEj2daNUaNwM%3D&a= mp;reserved=3D0 Diff:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-oscore-discovery-09&data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&sdata=3D4yOBJP8UeUznI0ojg1hGZY9rUKiEtAlqa%2B0IzjaJ53o%3D&= amp;reserved=3D0 Abstract: Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. The IETF Secretariat --------------326D9E9B35B0E2994AD1A39E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an updated version of draft-tiloca-core-oscore-discovery

https://datatracker.ietf.o= rg/doc/html/draft-tiloca-core-oscore-discovery-09


The document describes how to use the CoRE Resource Directory for discovering OSCORE groups and retrieving information to join them through their Group Manager.

This update is especially about aligning with the latest version -12 of draft-ietf-core-oscore-groupcomm , with respect to:

1) The names and semantics of parameters describing which algorithms, key formats, etc are used in the OSCORE group to discover.

2) Supporting the discovery of OSCORE groups that can use the group mode only, or the pairwise mode only, or both modes.

All examples throughout the document have been also updated accordingly.

Comments are very welcome!

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-oscore-discovery-09.txt
Dat= e: Mon, 12 Jul 2021 09:46:55 -0700
Fro= m: internet-drafts@ietf.org
To:= Christian Amsuess <christian@amsuess.com>, Marc= o Tiloca <marco.tiloca@ri.se>, Peter van der Stok <consultancy@vanderstok.org>



A new version of I-D, draft-tiloca-core-oscore-discovery-09.txt
= has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-oscore-discovery
Revision: 09
Title: Discovery of OSCORE Groups with the CoRE Resource Directory<= br> Document date: 2021-07-12
Group: Individual Submission
Pages: 36
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-discovery-09.txt&= amp;amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94= 554a976%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7= CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW= wiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DLoEBCBf5Z0ExTRtrbDnA8hMuX%2FUf45R= %2BXdpSnf%2F3hJ4%3D&amp;reserved=3D0
Status: htt= ps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatrac= ker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&amp;data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&amp;sdata=3DwquNTGqX1J2E9cOyQtEforDS2J1klU%2B0MdNtJR4tZbs%3D= &amp;reserved=3D0
Htmlized: h= ttps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr= acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-discovery&amp;= data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C1000&amp;sdata=3DgWYAj9AKhNEFE1a4ktCiLKdAgiXX94SEEj2daNUaN= wM%3D&amp;reserved=3D0
Diff: ht= tps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-oscore-discovery-09&amp;da= ta=3D04%7C01%7Cmarco.tiloca%40ri.se%7C82b0200f3de54991995b08d94554a976%7C= 5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617052207498325%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C1000&amp;sdata=3D4yOBJP8UeUznI0ojg1hGZY9rUKiEtAlqa%2B0IzjaJ5= 3o%3D&amp;reserved=3D0

Abstract:
Group communication over the Constrained Application Protocol (CoAP)
can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may
not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining
process. This document describes how a CoAP endpoint can use
descriptions and links of resources registered at the CoRE Resource
Directory to discover security groups and to acquire information for
joining them through the respective Group Manager. A given security
group may protect multiple application groups, which are separately
announced in the Resource Directory as sets of endpoints sharing a<= br> pool of resources. This approach is consistent with, but not limited
to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments.



The IETF Secretariat


--------------326D9E9B35B0E2994AD1A39E-- --VNl9AXeBPWCu4g2CSJMYli6aZYSeD1LdV-- --7LriaLgmBlMXTBCvvjhW4GuHw2oUPLOly Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDxe+EFAwAAAAAACgkQ7iZktA5Y2kPs 0Af+OobSceUGq128PNpw5aLiljVaQbP49Zsuyc9G8moh2xmfpat99u3/39Y4ut0k8ueT/4Mo0aj9 zeUX8+uLtZlLmkENjNcFQ9Bf4GL/Vg4kM2x8EEj+9HReVRprx8+Kx9Z7lEUFlhdAoEONmx5AeMJK eXKEN+7oFMtWFsNpctPv6sTqT71ABxds2yZ73ILU8g4WVQ/AJ+I+8JfV4DDQ4IFgsmKD7kBx6VOG THsv7y0Nz1fwxo1WmnohxzXSLry0sr3/jNU97R8hgUgxCvlJdRMm9Hxi8CgFWgv/luBtVEuurz75 OGjQa9VZ+NRoXJEG8C1/cQklDKFp0PUYflcDUO5WCA== =acpl -----END PGP SIGNATURE----- --7LriaLgmBlMXTBCvvjhW4GuHw2oUPLOly-- From nobody Fri Jul 16 05:34:54 2021 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 72F723A3524 for ; Fri, 16 Jul 2021 05:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 2SEN-ZK2SkEV for ; Fri, 16 Jul 2021 05:34:47 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40058.outbound.protection.outlook.com [40.107.4.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 48A553A3523 for ; Fri, 16 Jul 2021 05:34:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QeIoLST3qr1qe/4UYP2Zt14Yp4yG8eL271qgz+Ha5flh0szzqftDJQ4T28XdgU6BCq4hjR1x6ooA9qL1Rt1FuR/rYx/xLOqHAaGxbQiJuKsVcxuVGjad/aJEfvmlLgSZ3BRz9l+lTYOgFPGLBzl4GvUiMfkWmS9KurbeYWNxaPOo3wY9ex4xGUDRFN/ToyGzo0K3A1rO8x9SuWaJloj4rK1X7LQmOONh+MmqKQ3EIJLMpngDjMVIENChwR6bU14Zt4uhK+HMolL2PLzcRMLeWV52HgNt1LSPU2m1mAZGEb/0zlwXlhHUNWfrhZIeTDEEnYPPUGM6KXToFuCugTal9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WI8qqwhnLXgvJYdTz5dwHJiDXH2W2Lo5Lyc1ThL130U=; b=DmmIocIuB2vL2k0xa83EKiSCso0UnkIL12o4jiinUNvPZvbYc6PgOP05g2bw7oTgWsh+G+0HHlhNk13tIkWgiHCvdV3ZujbCF58sSGfm6tvwIJXrXQ3E5KVB/w3eXFR8oynV7m1J6KWbINOyljtacQ3zKuHKWzWptcdA1Dwqv6GUaqYQa73ysCG4zAnSoxZPOFdCRph8XlUy0ymiRAFgJm5gvqGZS7P8B+nZEmYLu4RqFi/rNEdzaGjJhAFS1oNRrcFpYhSVzvJ2p1Lf054OjEkgHhiCpuQlqAk7ethS+y8hAcyOdRq0562sq5nlslknXER1Og6ZaoM7kY/TSprczg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WI8qqwhnLXgvJYdTz5dwHJiDXH2W2Lo5Lyc1ThL130U=; b=QBntT1/rNk2TRnujoF64d7z7D5TyOq7tk4DATRSHuVgC9cHYjvXuEt0syYT6/AC9eqoJQecpUc7ZemwPdsYa6peRAxb09aY+S6jbUhs1gIEraxewQWvg2ETvKjwIcHbXt7JnlGMdehVkmKWUUZ2DrXs2zYHSEqpacQ8qysDYAP0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1724.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a0::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Fri, 16 Jul 2021 12:34:44 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4308.027; Fri, 16 Jul 2021 12:34:44 +0000 References: <162611057083.29535.4596010198406896116@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <162611057083.29535.4596010198406896116@ietfa.amsl.com> Message-ID: Date: Fri, 16 Jul 2021 14:34:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <162611057083.29535.4596010198406896116@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CnFQBWYK6mLLRr6VuY0YfEHWjrmsbfZdw" X-ClientProxiedBy: HE1PR0202CA0011.eurprd02.prod.outlook.com (2603:10a6:3:8c::21) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.3] (185.219.140.159) by HE1PR0202CA0011.eurprd02.prod.outlook.com (2603:10a6:3:8c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21 via Frontend Transport; Fri, 16 Jul 2021 12:34:43 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3c3a0e43-0e94-4a2c-3ea0-08d9485616eb X-MS-TrafficTypeDiagnostic: DB9P189MB1724: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qow89gzM7qdQPXK68chUv554OslBoK/vaCrdWrzabNo2YZFOiUtnZ4gspGND2obG758YlyrbF3H3/h8o7fePfiKdNdVgEW0WtJ/6YwVwh1fGbyUxvEyZv3+eOxvFwhYmfCaYQbYf5ArhLcKUQtjxDdndTPILOLqzXFXnEWqFRIUvA/W0gVA41rlfWEMeIVngn8K5DFPvdj758em6OHgbMkusEp8P8E8NcN56+Uz7AqKLwppt9BEhDKrIIGMiXI83YdqIfzCg9cqTCy8csJEMOSqclPo24P/YN1ucUKiu8F1xOz1PlfuX6hzoc5Edx8PkptrL850tBDdURi7FovYyEuZI3vb4GDHV3g+C7Aa9CCYLy66allljnI7niiyWNeUo4fSAtFaQFgKDfXMkRBsPOwwR88z+0KQJdVpJh61JJB1okx3YI9OVyYMu21qj2nKKsNmMUJr+Vkuc70dOY/xfaeY+La67WW9tuiBt1k+PZwd8w6VU2B0xPGizYK8blKug1BLc+WiePuHzyC+Fl/PeoS2q8vsvsHNwBcjf2WDhu6p6iG/2/7Ky8T5Bpm2B/ivRS5p/MamfL6UNm/x3+uwsZwG7IuhCOYoYHYHqEr+bvW10Pj23TpqiqmsSLzJ5OOjSqeWXuFZFOzsNgwzo42BXuQgg/3g6WZEH0Tl04n+U/kHlVBJ5opPs2NuehtHRt5UDCWeWesiC4lk/o27xMDAEqdaCQVEx1FodDbIJ22rtkLntm1CQeX+Yd5BSdvL6p0TBolIyVZdG/VEHhXLW/WHG7EMPjlLl9hCdZTkCb2neJ4wG1ZXBU+JqM0HjF1kGvqJG X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(2906002)(38100700002)(31686004)(8676002)(235185007)(26005)(956004)(8936002)(186003)(31696002)(6486002)(21480400003)(316002)(966005)(6916009)(86362001)(83380400001)(66574015)(166002)(66556008)(36756003)(2616005)(45080400002)(66946007)(16576012)(508600001)(33964004)(66476007)(44832011)(15650500001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QWRpR3BqYW9lSzZhV1JreDAzRWhRQ1BzTGtLeHdNbWFubTI5ZWZMN3dXT0h3?= =?utf-8?B?Q2FRKzgweUMxeW13cVVOZUZja3BKdkx6c1lLaVVMZ0pjNUpVVnBFTVhjWFZZ?= =?utf-8?B?UjBDY0FxOHMvbUhyajFlWjBKQ21Hby9ieXVJTEo5V3lYK1lRVnE5N0cyd3dR?= =?utf-8?B?TkZPZFlXK1czWEkxS1k5QlB4aEpkR0sxakhpR0pqdzhuOWd2TlFrMkFLYnZw?= =?utf-8?B?cDdETyt4UmpTWFB6MUJQS3NDNGE2MDdmVHpHNTlHSDRNVVQ1Ykp3ZzhVV25J?= =?utf-8?B?N0lWc3pWR2M4R0VSMkI2SVdLa2lxTVF3SHJUY0ZRY2w1ZDhQWTVvZ0xzMmVD?= =?utf-8?B?YTlXNXBwaGpvQjVnbGhXa1hqLzQyblM5U3U2Um1hRWJrK0F6OEhrT3o1V2tk?= =?utf-8?B?ekc1Mjl1YWFGbnJpb2pLakxMaG5OTkM5TmVQcVZxUHJxUy9iRXdHTmtzeTJE?= =?utf-8?B?Y0NzS3hrR0xBbFBadjBtOVhKUENNcVFrOUI2RUVmcEx6ZmRxancwZVp4cjBr?= =?utf-8?B?K0xuR051aHhnbXBOclBMTTFkOHJOQ1VCNkRFL2pDSE9pMDRmdkJ3OVFPeDNH?= =?utf-8?B?YTRyeHhLd1BrTlBFaS9SZmhOT0JlcnFuc2FyckE3UCs4WGNud1hvT09Candx?= =?utf-8?B?VjNBd05pTEdZTFY3d1d1MkJveVpKMFN6ajdyRXZmeEkzbU5oejVrZGRmcGdy?= =?utf-8?B?Q0VOVTVEVEJHK2txc0ZFakV6WktNL2pBUHU3a0ludmd5YlpyM0hQM2dIdElj?= =?utf-8?B?TDlaWlBGVGVlM28wekRXb1ZRbUhyRlV4eXlkZDl3cENHdWdjK3hpZldkbTRS?= =?utf-8?B?L2xXakhQbzVzY0pRSTRmNlNSblV2QzA1b213U01meEd3c1Q3SEZ3QVIzWUdN?= =?utf-8?B?NU9rTnRoRWJLZlBuSmd1QjRrWUlYSnFUalZoeGZKRzFtVitMdUhhZkZ4NGZx?= =?utf-8?B?UmdEUm1SbngzNVptRkE5L1gwTGVmck40Mm9zK3pWTllUY1dsNzIyYkZ1TUtv?= =?utf-8?B?WkVqdm1XZUNPU21ha2Y5R2pIQlJBYzRvUm1SQldZY1Z6TU9aREp6enQ0VVhv?= =?utf-8?B?Snp1TjRkazQ1NDJiUlRsczFhRHdFTlVjYlVqV0xzeDhhQXFEWUtlYXhmZENR?= =?utf-8?B?M0ZVYlhSNU9PK1hWSmtsQWc5YllaMWJHWDYyWDFtWllPZFEyeEZiL3VYcURE?= =?utf-8?B?ZnpOR0pSNlU2ZEk2RjZtWWcvZzlIUW9DdlRmWk00R0lEV3MyWlM3VENtaEZq?= =?utf-8?B?SzVsYlMyVDJ0WmppY0luSVYwUC8raC9wY2hkWEFqUlJxMEZrSTBFSFo1eGk1?= =?utf-8?B?STBmYTRPRHZ3OUN0YUh5bGcwUTRGR0xocGhkRDB6S3J1TTNLNDExcU5xQ3U3?= =?utf-8?B?cFZqZXRsN1R0YVNmWmpFVDZGWmpXejNvdkhYMVk1TzZDdU85MUdkSDRPMzlr?= =?utf-8?B?ajRqSU5KVWl4UXdMR3VPM3hia3lzZG01TktRWlY5dUlZRnFNb09MQnFhd0Uw?= =?utf-8?B?VytzMU1OOC9PZThWTWMwekd3YXd3UG43WkJjNlo0emJpZ254QnFsdmpKdElo?= =?utf-8?B?d0NGN05kSmp3UTZ0Q3pLS0pWTys1Ym16Q1lmd01XcmVlaWhUdVBuYlM1bW9D?= =?utf-8?B?dkJVbkhld0pkS0lkRytva3NvbGVZLzNtSVp4THljK0lnQjJLMW5lL0xvcnJC?= =?utf-8?B?Zlp2UE1uOXZ2RDgyRTgrWjJvM3Q2WVJVZG5jUjVnclBWSjVSVUlKR0dsa2Vh?= =?utf-8?Q?guWRKhR6Rg3Hytj3AIeeCyEFlgyefXJi3HVWTJm?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 3c3a0e43-0e94-4a2c-3ea0-08d9485616eb X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2021 12:34:44.0121 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FcUu5uWMRWXnMDPpLq481O70sU07+8KbUmYJlluoMe19M2bEGQaEVfOr2wcvtcBGbfOsSIvB17cLz7Y395QNfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1724 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-groupcomm-proxy-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 12:34:53 -0000 --CnFQBWYK6mLLRr6VuY0YfEHWjrmsbfZdw Content-Type: multipart/mixed; boundary="jYML4LZoYshZlcZJaA0s1vcqsZy1I1RjF"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Fwd: New Version Notification for draft-tiloca-core-groupcomm-proxy-04.txt References: <162611057083.29535.4596010198406896116@ietfa.amsl.com> In-Reply-To: <162611057083.29535.4596010198406896116@ietfa.amsl.com> --jYML4LZoYshZlcZJaA0s1vcqsZy1I1RjF Content-Type: multipart/alternative; boundary="------------7C0C9A30A94AFA628CC4B599" Content-Language: en-US This is a multi-part message in MIME format. --------------7C0C9A30A94AFA628CC4B599 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an update for the draft "Proxy Operations for = CoAP Group Communication". https://datatracker.ietf.org/doc/html/draft-tiloca-core-groupcomm-proxy-0= 4 The document details the operations of proxies supporting CoAP group=20 communication and addresses the issues identified in [1]. In particular, a client can send a unicast CoAP group request to the=20 proxy including a new Option to indicate to the proxy the time period to = collect responses. Also a new Option is included in the servers'=20 responses, to enable the client to separate and identify the multiple=20 responses it receives via the proxy. Following what discussed during the CoRE interim at [2], this update=20 covers especially the following points. 1) The caching model at the proxy is now fully defined in this document=20 (see Section 7). This has built on preliminary content originally in=20 draft-ietf-core-groupcomm-bis and now moved here, with additional=20 improvements and clarifications as suggested especially by Christian Ams=C3= =BCss. 2) Added further clarifications on how the proxy forwards back responses = to the client "as they come", handling also possible multiple responses=20 to a same group request from a same server in the group. 3) The appendix "Using OSCORE Between Client and Proxy" has been=20 removed. At IETF 110 [3], it was agreed to have such an item separately=20 and better defined in a separate draft, which is now available at [4]=20 and is referred by this document. Comments are very welcome! Best, /Marco [1]=20 https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-04#se= ction-3.5 [2] https://datatracker.ietf.org/meeting/interim-2021-core-07/session/cor= e [3] https://datatracker.ietf.org/doc/minutes-110-core-202103081700/ [4]=20 https://datatracker.ietf.org/doc/draft-tiloca-core-oscore-capable-proxies= / -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-tiloca-core-groupcomm-proxy-04.txt Date: Mon, 12 Jul 2021 10:22:50 -0700 From: internet-drafts@ietf.org To: Esko Dijk , Marco Tiloca=20 A new version of I-D, draft-tiloca-core-groupcomm-proxy-04.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-groupcomm-proxy Revision: 04 Title: Proxy Operations for CoAP Group Communication Document date: 2021-07-12 Group: Individual Submission Pages: 43 URL:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-groupcomm-proxy-04.txt&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&sdata=3DcJiLDyxA2IiiGKQwuQZnu4TuEBXirOUudVHPQlbhVhw%3D&a= mp;reserved=3D0 Status:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-groupcomm-proxy%2F&data=3D0= 4%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C1000&sdata=3DkCBttuHyNrb%2BMrboJ4bFw24EduBR4ql1g7m6gtquj6Q%3D&= reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy&data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&sdata=3DyFYFinBvVXZ0bKByNlQIMOFFGowp9wZA44kHpJQmQvk%3D&am= p;reserved=3D0 Diff:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-groupcomm-proxy-04&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&sdata=3DMQ8OiHeF7JDvFM8Gq8nSxlBuupjcV991F2%2FtCWdKW%2BA%3D&a= mp;reserved=3D0 Abstract: This document specifies the operations performed by a forward-proxy or reverse-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such CoAP proxy processes a single request, sent by a CoAP client over unicast, and distributes the request over IP multicast to a group of CoAP servers. It then collects the individual responses from these CoAP servers and sends these responses to the CoAP client, in a way that allows the client to distinguish the responses and their origin servers through addressing information. This document updates RFC7252. The IETF Secretariat --------------7C0C9A30A94AFA628CC4B599 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an update for the draft "Proxy Operations for CoAP Group Communication".

https://datatracker.ietf.or= g/doc/html/draft-tiloca-core-groupcomm-proxy-04

The document details the operations of proxies supporting CoAP group communication and addresses the issues identified in [1].

In particular, a client can send a unicast CoAP group request to the proxy including a new Option to indicate to the proxy the time period to collect responses. Also a new Option is included in the servers' responses, to enable the client to separate and identify the multiple responses it receives via the proxy.

Following what discussed during the CoRE interim at [2], this update covers especially the following points.

1) The caching model at the proxy is now fully defined in this document (see Section 7). This has built on preliminary content originally in draft-ietf-core-groupcomm-bis and now moved here, with additional improvements and clarifications as suggested especially by Christian Ams=C3=BCss.

2) Added further clarifications on how the proxy forwards back responses to the client "as they come", handling also possible multiple responses to a same group request from a same server in the group.

3) The appendix "Using OSCORE Between Client and Proxy" has been removed. At IETF 110 [3], it was agreed to have such an item separately and better defined in a separate draft, which is now available at [4] and is referred by this document.


Comments are very welcome!

Best,
/Marco

[1] https://datatracker= =2Eietf.org/doc/html/draft-ietf-core-groupcomm-bis-04#section-3.5
=
[2] https://datatracker.ietf.or= g/meeting/interim-2021-core-07/session/core

[3] https://datatracker.ietf.org/d= oc/minutes-110-core-202103081700/

[4] https://datatracker.ietf.or= g/doc/draft-tiloca-core-oscore-capable-proxies/


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-groupcomm-proxy-04.txt
Dat= e: Mon, 12 Jul 2021 10:22:50 -0700
Fro= m: internet-drafts@ietf.org
To:= Esko Dijk <esko.dijk@iotconsultancy.nl>, = Marco Tiloca <marco.tiloca@ri.se>



A new version of I-D, draft-tiloca-core-groupcomm-proxy-04.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-groupcomm-proxy
Revision: 04
Title: Proxy Operations for CoAP Group Communication
Document date: 2021-07-12
Group: Individual Submission
Pages: 43
URL: h= ttps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Farchive%2Fid%2Fdraft-tiloca-core-groupcomm-proxy-04.txt&amp;= data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C1000&amp;sdata=3DcJiLDyxA2IiiGKQwuQZnu4TuEBXirOUudVHPQlbhV= hw%3D&amp;reserved=3D0
Status: ht= tps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-tiloca-core-groupcomm-proxy%2F&amp;data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C1000&amp;sdata=3DkCBttuHyNrb%2BMrboJ4bFw24EduBR4ql1g7m6gtquj6Q%3D= &amp;reserved=3D0
Htmlized: http= s://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatrack= er.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy&amp;data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&amp;sdata=3DyFYFinBvVXZ0bKByNlQIMOFFGowp9wZA44kHpJQmQvk%3= D&amp;reserved=3D0
Diff: = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-groupcomm-proxy-04&amp;d= ata=3D04%7C01%7Cmarco.tiloca%40ri.se%7C556178caf1954687c92008d94559ae8e%7= C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637617073767977550%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI= 6Mn0%3D%7C1000&amp;sdata=3DMQ8OiHeF7JDvFM8Gq8nSxlBuupjcV991F2%2FtCWdK= W%2BA%3D&amp;reserved=3D0

Abstract:
This document specifies the operations performed by a forward-proxy
or reverse-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such CoAP proxy processes a
single request, sent by a CoAP client over unicast, and distributes
the request over IP multicast to a group of CoAP servers. It then collects the individual responses from these CoAP servers and sends
these responses to the CoAP client, in a way that allows the client
to distinguish the responses and their origin servers through
addressing information. This document updates RFC7252.



The IETF Secretariat


--------------7C0C9A30A94AFA628CC4B599-- --jYML4LZoYshZlcZJaA0s1vcqsZy1I1RjF-- --CnFQBWYK6mLLRr6VuY0YfEHWjrmsbfZdw Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDxfOEFAwAAAAAACgkQ7iZktA5Y2kNN AQf/Y3UmxLpsygZAA00j8fRmvWPCuV5OWe4nU3cNpkqh+XrkbJ3fJig3le8BN9u8ds3UBpstA6Vp 0fmLp7oT2rMNIsaXR8KaRu0HzAVyxjR5YUP+PPjLlOho2RutpMhfkKhNFTGI7jL7ze+SRMMz2b/x VQvbRuQ48MlXPbOLhtImEnYrB3zrny2vNISIZnzOckwS4WgNqyHNMuzI2Af5V33pjExpyOwhGvR9 Ueb4AWr9IQR2d59/Db7WUNnEph1A2ZO5L+tkZ4BBxf1Vbp+kMOZWQbV2zIInHoFGda+06H2t2jNr LUNNXmyoCEEaCn80ntJnqDXQiwNJcV3xNu7TeubQww== =r7Q4 -----END PGP SIGNATURE----- --CnFQBWYK6mLLRr6VuY0YfEHWjrmsbfZdw-- From nobody Fri Jul 16 05:38:53 2021 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 8F4053A356A for ; Fri, 16 Jul 2021 05:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 1Qsr_lw0mRh2 for ; Fri, 16 Jul 2021 05:38:47 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30089.outbound.protection.outlook.com [40.107.3.89]) (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 0ABAA3A3564 for ; Fri, 16 Jul 2021 05:38:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=flOQo9fC3TlMm8+Hy4SXdZdsB+pDTULSgkdSH/o2OEvDn3Vj4nd9HJf82J0JJYxUPkHXk74pQqeng18cLWrobljloGGY0mp0n7Mr3Q9ld64TRpcGw2X7fGU2nguafBQCbNwk3U1WRsaCyqCxYu2/LYAWwHpDtX3erloTpF1BW/q3nrD6b4N/WpzeI8+IODJP73v7bc+L+pCQLhDjzM3YZaJpmE5QfKz3FN7m+8OPHw6HYLizffyg7LpK/YDX2uCfWl2dzREiw+8c8a5Actyamp3s5CgbEeEiqubKhU4wq5bIyKjYW5uIvzEtJpGY+3DCQQuRpqpNVnu7y7SzS4/4TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p1SZ4b274ChTLoV1sgx49ASjj+U8MTIqQLoEzxrt3v4=; b=BGfe380oQJw9/FXoXROlDenQ6cWOP2vnX5jJ9z+Nreah8Qtkbljj3Mx78jquMbeBuDvfaDy0W3igfUmV4vWpvU+vLXzddbQvE9jUWAFmEMUfTZDdqMVMyXUQHivcNGnVqRVQdMiM/tM5ZjDorJXdMbeqWqF32n54huMh8FKzA9tWh2QemGiewMhTuoPajDK2dVZsmlvb/8x6PxoW9xdfInpu0S106ruOFa+sUPN4lD/dpuVv8HOCfoD9j+NALUM4oY0T0sAIBIpH7+72zqFqiFYUkf6IAk4VfiSxqgGM+VbzhT/wz7MhmK6pUNIvx25etlKvZyNsAjCmufzIubaNPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p1SZ4b274ChTLoV1sgx49ASjj+U8MTIqQLoEzxrt3v4=; b=CGzGwBA2VehTra+BzphCyJAIhdm/ZZ53GQ9XtfAG4e4qJJoBOLFk7MHuGIzTZ8oGxlSvKSJ8QGgkDv60Ybwuz7hsJO9wSbUok/TkZbVDPgzAkhpOBMFuiYeHSlKFHXczMt2KN3b8pHmfR1fmdhOVHBuZSKpow86ev+H0ctOCwMA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1737.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Fri, 16 Jul 2021 12:38:41 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4308.027; Fri, 16 Jul 2021 12:38:41 +0000 References: <162608926127.7035.16952220356882707107@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <162608926127.7035.16952220356882707107@ietfa.amsl.com> Message-ID: <44d44200-0993-687c-cfa0-91d9182424e6@ri.se> Date: Fri, 16 Jul 2021 14:38:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <162608926127.7035.16952220356882707107@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tsTajDj6nByeRy4AmJhtxfSXjWAT4yylB" X-ClientProxiedBy: HE1PR08CA0043.eurprd08.prod.outlook.com (2603:10a6:7:2a::14) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.3] (185.219.140.159) by HE1PR08CA0043.eurprd08.prod.outlook.com (2603:10a6:7:2a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23 via Frontend Transport; Fri, 16 Jul 2021 12:38:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ad8cd41d-35b1-48dd-d5d8-08d94856a441 X-MS-TrafficTypeDiagnostic: DB9P189MB1737: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZkyPY4SMHoz5AkEIvHXZiJ+CimLiVM1Dm1IFFL0zhtMPcYAQ5OJM1Vj9J+wmefHIns1dGFXgB8gi7tN+72+uTv+9c5c+v5NhWHnEGdWfRp/ughbErBsg1HzxN3oxKP1zGao2iCGIJmIZwzu232XRfb8sQ8kkt4SfyvTb07/JMOvO1ELxBgrGR1P/z9mPOTQVK9QhfDBpV+xlr366RJm/A8ZUWKYpYriXRF263krbVr6bJm74nJXlBzYSL0IHWuBazbTovjWWmTpQqz9wsoeMxrzz83avBRrQVBdQrOlzE+TPsafix+8szKQrg71eFZW9JN9un1PVMxrbDugQQVCF0jkVl4XWSWvCIQ2fb+elbRP+DlxCtYbuiBV1sL+2VYkWtC9SssVBm67aXWgM0vdyoRjb4Viid/HfEqwcMy4pYhrpXxTiJxq0w84+qZknDSVgoxkKup1/npHvp5xEIC0ZHKZk7iXlvXf7r+PhPttQkTOjNv+LA5mm9N+GPSR3sjm8KuVmoBsQdQOL4m2FFSsqUPQYs3j0LbcgVRDmMCu/7q3L7bOkU1NoLlcelJOzIGCp/LBNGgnoWAF5eXcZ8L6dx5LgbaMSedXOUnJhBhIp5Fxy4s9EYDyIoemYm9xLlVXBnH+/wrtxslbcDoHBR/hO3d2jqDgROks+TH4z1YXvu6x3n7wEzfvOtOHqsOrzvgdBrzkRlkyR0oEK81MdrVK6WEFR1sV3KWPc1LyFWUkpQvZhBK+SJIyvgxm8WSJgNyVfPg4TIKsgIWFGYeEIPge/ivuInI2f2hSOwkz0zi2KpecNimN7jz6DczL3YylLz+MF X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(346002)(366004)(136003)(396003)(66476007)(45080400002)(86362001)(966005)(15650500001)(6486002)(478600001)(186003)(66946007)(31686004)(33964004)(38100700002)(26005)(66556008)(44832011)(2906002)(66574015)(235185007)(956004)(16576012)(316002)(8936002)(5660300002)(166002)(8676002)(21480400003)(2616005)(6916009)(36756003)(83380400001)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bjY5VlM3ZU1nZTh0TnRnUjQvRXNiUmovUFdYZVYvWnBaTGU5ZDRYL1Q5Ly9V?= =?utf-8?B?T21aNE5VeS9wdVQxbDRqOWMwcXFib0g0RGpDaTAzbVhvSi9Fa3RhVWFYbjIz?= =?utf-8?B?SDVmbFlFd0dDeDF6U2NZVlc1d3Y2Yzhaa1VibU1xa1ZvanZQTE9nZkpYQjlx?= =?utf-8?B?aGN2SlIvQ0FpL2JsK1FtcGdqcEpYbnF6MktXNlRjckcySWp5d2FOU3lrRDdz?= =?utf-8?B?MHk4K3RGOEJkY2o5aitlRFE3eHc1VERyaU95SE1TazFBclJqS2ladGZnc1Jt?= =?utf-8?B?bEY0WkZpdjVETUszYWh0N08vVVRsUGF6eDRhWmJETi9FYWFWa2hIcWx1Rnhv?= =?utf-8?B?MERxdXY2WjhhK3A0cDBmbis2ekx3c3MySzNRZ2RlekRweUhNNm9sby9iZUtD?= =?utf-8?B?Y2RXcnA3TXBIOVJ0dmZDNlFGRys5dVVlc0lrRDErOEErY1dQbnQ0bVJ3d2xO?= =?utf-8?B?VldRTHdsMytPQVhTekZQUzhwcnNtUHAwOTljY1ZsR1dMa09sUW1CVE9ZaEI1?= =?utf-8?B?VGpYVW9jcFBiTWpqNGFWaFViZkZyaGdLYlpoZVdsWC9tU0JQTGVSWUY0cWpw?= =?utf-8?B?U29FVjJaeFZLZVFuaVVaZXdJUEdQQm1iM2R2VnUzUXcvL1dJek5xQXdHUzlI?= =?utf-8?B?cG45Q3VCeGRMMlFqSmZFbmxnR0VXbnRnODdocStVMlF3K3hLamhvSXpRMnl4?= =?utf-8?B?cThKSDZRSkswSHZZcmFSREV5OXg2UmpuYVFUam9YSzBJbVB5WTgwb0RXbUYz?= =?utf-8?B?WDRuTCtHRXorVmZnbGdNK081UHJKME5iZy9MWHR5Y2FJcTY3ajFDdkZza2ty?= =?utf-8?B?VCtSdkZDYWR1bUFRUkFZTFFnbjhuNFpBZDNzOWdYM1pPRk9lT2h3ZFRMNTlV?= =?utf-8?B?WEt1K0dRMEpJMlBURW5GYXc5K0tySUREK1o4ZWJFUlpWb1hQRUpQWGxaYjRn?= =?utf-8?B?MnVrZGt4SVJ4RGpXMnV0a0w4SXE4VHQrU0tjRjh6MWtVZUJUZmZOWGFMa3Ev?= =?utf-8?B?VTNBcUU4YkQ4bXQ1Sm10YmU5TkFscnFOTjU1citqbGpHR0xROEMzTTVpL0tj?= =?utf-8?B?Q0w1MklxSHp5aDVINGl6WTJWcGFuQXgzN2pzdldoQzM4S3pLOS9YWmJTd1I5?= =?utf-8?B?cDF5Vi9GK2lhYVI2aHFWR1R1UmZ3dXNES3hrNFhkN091aVNKcXNVdm5EY1Jo?= =?utf-8?B?RjJnMHl3UGVPRkdPNEFMSW9yZkF4bGNMTTFucEdCYWxxdlFOTWNHM2liQ3FW?= =?utf-8?B?clk5a3kycURNbUF5RG55Um1wZEU5VGQ2aGZCY3Zob0VRQU5IQTFUVWhvSW1s?= =?utf-8?B?QmJiNE9KUzJ2eCtYSldvaklzMGprQUNnTlRqVTJTbWxGa1BjREdDVERGYXZm?= =?utf-8?B?RVcyUVRrMnI2RllWb25yaFpXc24wUHlnaFcwb2o1dkcxZTNLalExREE2L2dr?= =?utf-8?B?aFRSZDFQUVBlT2JQaWE2Q1hVVEhWM2I0N3o0NmxyT2QrMmhkNi9qZkRuaFdP?= =?utf-8?B?MUNFMHQ3ZUoyWUdDWVNBS2FNK3NUSmR3bWlUc2k5aEdySGc5Ylk4dkhGc1ho?= =?utf-8?B?bFRGZkZGdW5lSGx6R2Q2UVY3aVhBVmFZWGVDcG1vK3ZoQmhjckVKRVJuc3ZU?= =?utf-8?B?WVFqYVUxL3RZcXBSL1ZsZWwwczlUZUhmZklNRTZjRTZ3TC8velozemU2NTdL?= =?utf-8?B?dTNtYml0TnlRLzM1TDVqOE16ZHJ4U1pDNzA2RXlYZytEWE54UUVod040a3pa?= =?utf-8?Q?uw78L99HultrrvlZ7fqpisblmYbzDgWQXLyMZBL?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: ad8cd41d-35b1-48dd-d5d8-08d94856a441 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2021 12:38:41.1274 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vWCqRcXVcfKSksYuAuIg26Gv3oEybLUCGt5ctNhZuOiEQdHsmoqhV2A6y6213BU4jsMVX8EsrQ3w8pyD9fTSOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1737 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-oscore-capable-proxies-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 12:38:52 -0000 --tsTajDj6nByeRy4AmJhtxfSXjWAT4yylB Content-Type: multipart/mixed; boundary="2j5NnGeGczQb4ab2f4p8zDAtDnXKMVLBL"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <44d44200-0993-687c-cfa0-91d9182424e6@ri.se> Subject: Fwd: New Version Notification for draft-tiloca-core-oscore-capable-proxies-00.txt References: <162608926127.7035.16952220356882707107@ietfa.amsl.com> In-Reply-To: <162608926127.7035.16952220356882707107@ietfa.amsl.com> --2j5NnGeGczQb4ab2f4p8zDAtDnXKMVLBL Content-Type: multipart/alternative; boundary="------------BB90B161C3B43969AE32C57E" Content-Language: en-US This is a multi-part message in MIME format. --------------BB90B161C3B43969AE32C57E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello CoRE, Following what was discussed during IETF 110 [1] and the CoRE interim at = [2], we have recently submitted a new draft "OSCORE-capable Proxies". https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-capable-pr= oxies-00 The document defines how OSCORE is used to protect CoAP messages also=20 between an origin application endpoint and an intermediary, e.g., a=20 client and a proxy. Besides, it defines how a CoAP message can be=20 double-protected through "OSCORE-in-OSCORE", e.g., protected both=20 end-to-end between the origin client and origin server, as well as also=20 over the leg between the client and the proxy acting as next hop towards = the server. Seminal content about this was originally an appendix in [3], where such = functionality looked convenient to define. Besides that, more use cases=20 are mentioned in the present document. Finally, based on recent=20 discussions [4], this functionality might help also for the security=20 aspects of transport indication [5], when a proxy wants an additional=20 security context on its own. Comments are very welcome! Best, /Marco [1] https://datatracker.ietf.org/doc/minutes-110-core-202103081700/ [2] https://datatracker.ietf.org/meeting/interim-2021-core-07/session/cor= e [3] https://datatracker.ietf.org/doc/draft-tiloca-core-groupcomm-proxy/ [4] https://mailarchive.ietf.org/arch/msg/core/RZH8pgyksEwtMYVE1MrPkj9opy= g/ [5]=20 https://datatracker.ietf.org/doc/draft-amsuess-core-transport-indication/= -------- Forwarded Message -------- Subject: New Version Notification for=20 draft-tiloca-core-oscore-capable-proxies-00.txt Date: Mon, 12 Jul 2021 04:27:41 -0700 From: internet-drafts@ietf.org To: Marco Tiloca , Rikard Hoeglund=20 A new version of I-D, draft-tiloca-core-oscore-capable-proxies-00.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-oscore-capable-proxies Revision: 00 Title: OSCORE-capable Proxies Document date: 2021-07-12 Group: Individual Submission Pages: 23 URL:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-capable-proxies-00.txt&= amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cd8a0bf9ad78a4ab81e6c08d945281= 0af%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616860649838401%7CUnk= nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C1000&sdata=3DPrtejNXjt3PAD120Pg7T7OoocUl1IEPraHk64ETCz= bo%3D&reserved=3D0 Status:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-capable-proxies%2F&d= ata=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cd8a0bf9ad78a4ab81e6c08d9452810af%7= C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616860649848362%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI= 6Mn0%3D%7C1000&sdata=3DNBVAvs5rK0x3VqDhCpkT0%2B6oL8fEyMf3%2FBJVO09hSg= k%3D&reserved=3D0 Htmlized:=20 https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-capable-proxies&a= mp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cd8a0bf9ad78a4ab81e6c08d9452810= af%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616860649848362%7CUnkn= own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0%3D%7C1000&sdata=3DUPReEFc5zcw9hAo%2FqzDXQYN7HVibWYkd6wFSW%2B= uCf3w%3D&reserved=3D0 Abstract: Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how OSCORE is used to protect CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Besides, it defines how a CoAP message can be double-protected through "OSCORE-in-OSCORE", i.e., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach applies to Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used. The IETF Secretariat --------------BB90B161C3B43969AE32C57E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

Following what was discussed during IETF 110 [1] and the CoRE interim at [2], we have recently submitted a new draft "OSCORE-capable Proxies".

https://datatracker.= ietf.org/doc/html/draft-tiloca-core-oscore-capable-proxies-00


The document defines how OSCORE is used to protect CoAP messages also between an origin application endpoint and an intermediary, e.g., a client and a proxy. Besides, it defines how a CoAP message can be double-protected through "OSCORE-in-OSCORE", e.g., protected both end-to-end between the origin client and origin server, as well as also over the leg between the client and the proxy acting as next hop towards the server.

Seminal content about this was originally an appendix in [3], where such functionality looked convenient to define. Besides that, more use cases are mentioned in the present document. Finally, based on recent discussions [4], this functionality might help also for the security aspects of transport indication [5], when a proxy wants an additional security context on its own.


Comments are very welcome!

Best,
/Marco


[1] https://datatracker.ietf.org/d= oc/minutes-110-core-202103081700/

[2] https://datatracker.ietf.or= g/meeting/interim-2021-core-07/session/core

[3] https://datatracker.ietf.org/d= oc/draft-tiloca-core-groupcomm-proxy/

[4] https://mailarchive.ietf.o= rg/arch/msg/core/RZH8pgyksEwtMYVE1MrPkj9opyg/

[5] https://datatracker.ietf.org= /doc/draft-amsuess-core-transport-indication/


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-oscore-capable-proxies-00.txt
Dat= e: Mon, 12 Jul 2021 04:27:41 -0700
Fro= m: internet-drafts@ietf.org
To:= Marco Tiloca <marco.tiloca@ri.se>, Rikard Hoeglund= <rikard.hoglund@ri.se>



A new version of I-D, draft-tiloca-core-oscore-capable-proxies-00.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-oscore-capable-proxies
Revision: 00
Title: OSCORE-capable Proxies
Document date: 2021-07-12
Group: Individual Submission
Pages: 23
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-capable-proxies= -00.txt&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cd8a0bf9ad78a4ab81= e6c08d9452810af%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616860649= 838401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi= I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DPrtejNXjt3PAD120Pg7T7Oooc= Ul1IEPraHk64ETCzbo%3D&amp;reserved=3D0
Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-capable-proxies%2F&am= p;amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cd8a0bf9ad78a4ab81e6c08d9452= 810af%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616860649848362%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi= LCJXVCI6Mn0%3D%7C1000&amp;sdata=3DNBVAvs5rK0x3VqDhCpkT0%2B6oL8fEyMf3%= 2FBJVO09hSgk%3D&amp;reserved=3D0
Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-capable-= proxies&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cd8a0bf9ad78a4ab81= e6c08d9452810af%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637616860649= 848362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi= I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DUPReEFc5zcw9hAo%2FqzDXQYN= 7HVibWYkd6wFSW%2BuCf3w%3D&amp;reserved=3D0


Abstract:
Object Security for Constrained RESTful Environments (OSCORE) can be
used to protect CoAP messages end-to-end between two endpoints at the
application layer, also in the presence of intermediaries such as proxies. This document defines how OSCORE is used to protect CoAP messages also between an origin application endpoint and an
intermediary, or between two intermediaries. Besides, it defines how
a CoAP message can be double-protected through "OSCORE-in-OSCORE",<= br> i.e., both end-to-end between origin application endpoints, as well
as between an application endpoint and an intermediary or between two
intermediaries. Thus, this document updates RFC 8613. The same
approach applies to Group OSCORE, for protecting CoAP messages when
group communication with intermediaries is used.



The IETF Secretariat


--------------BB90B161C3B43969AE32C57E-- --2j5NnGeGczQb4ab2f4p8zDAtDnXKMVLBL-- --tsTajDj6nByeRy4AmJhtxfSXjWAT4yylB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDxfc8FAwAAAAAACgkQ7iZktA5Y2kP3 +Af/dbHNbvH/g8B1l2sa25ohkaIi39jhW62i5FhRV7cfGwhXouMsLhqzTDq6uBcswKcOlB0N3Z2L 1I8wjxqsqVsXpOAnNR8bXJY0Jvse+WbSkcVaOCIrHQHPZMC/0z1oeWozc0mIL/9haeSLSxb+NLeb SPvrn8eYQYjCcrp2TIy2+wPfDmY3cY4YLbLRnjoBwLIKxSiotP3MY5ORVdNYr2iP/mY0b7+I5vXF f5ebmg9qptVCb7+hazU17DeLvVQZQx3uxl3OGWGt/pIdggzvT5QokX9pbLMyOjoaUv9m74nzsDaI xo8AK2CH646PnfL/peW8S7OBj6qVYKRn0M9IBL59Wg== =7dsA -----END PGP SIGNATURE----- --tsTajDj6nByeRy4AmJhtxfSXjWAT4yylB-- From nobody Fri Jul 16 07:51:41 2021 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 0176D3A39F2 for ; Fri, 16 Jul 2021 07:51:40 -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, SPF_HELO_NONE=0.001, 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 6CeGSbQeXHOj for ; Fri, 16 Jul 2021 07:51:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEC73A39EC for ; Fri, 16 Jul 2021 07:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8305738A67; Fri, 16 Jul 2021 10:54:37 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fRPUyI-B_i2t; Fri, 16 Jul 2021 10:54:33 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2F31238A5F; Fri, 16 Jul 2021 10:54:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EA4BA2DD; Fri, 16 Jul 2021 10:51:27 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FRikard=5FH=3DF6glund=3F=3D?= cc: "core\@ietf.org" In-Reply-To: References: <162610065278.15528.15134519536449122090@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] New Version Notification for draft-hoeglund-core-oscore-key-limits-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 14:51:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rikard H=C3=B6glund wrote: > This document considers the CFRG draft at [1], and accordingly defines > how two peers using OSCORE must take limits of the used AEAD algorithm > into account, Good. > and what steps to take in order to preserve the security > of their communications, e.g., performing a rekeying. Also, this > document specifies a lightweight method that two peers can use to > update their keying material and establish a new OSCORE Security > Context. I'm concerned that this part will need significantly far more review, and should be split off into a new document. Maybe even, punt it into LAKE. but, in the meantime, can you ask the authors of cfrg-aead-limits to review? > 1) The proposed key limits have been revised, mostly based on input > from John Mattsson as per slide 11 of [3]. > 2) As reflected by the title change, the document scope has been > broadened to include also a key update method, that the two peers can > use to update their OSCORE Security Context. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDxnO8ACgkQgItw+93Q 3WXXkggAne6+mwCwVIMrhXNtVgObHt0KF43voLg1ioUUwHJ0Oxstntt7oQNXvQKc 1/bQ8k585DTYupfcSlTEroQTrBTekP2r86jfuYQjlE0RPQr9Om+kbOedrH5QLMeL GyJT12TfbbwzPLvfFVRR0bEJ982K/vmNXozeWObjRlF0av9PLgdAHpV5mw3nWKP+ oTHY7AbA3VnTKr7Nf7U5+oHfP/Q6BrSHxoEbTuhdOOTkAhmqTlOd/xyUxClOVDW/ ov7Epy0LS9dnhhsw0TZb5qxfrFG07HxtRvVhrdswmIlnTou1UEWQrE08+e3ERYe1 WrTWuHc5dIclxyn1lRCjAhfADM/+yA== =MQbQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 18 12:27:15 2021 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 7E0BC3A18BA; Sun, 18 Jul 2021 12:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 rOXRVXDtyakb; Sun, 18 Jul 2021 12:27:04 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0853A18B6; Sun, 18 Jul 2021 12:27:04 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GSZjd0rHYz2xK2; Sun, 18 Jul 2021 21:27:00 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 648329219.727559-39446c62e69487bb1faad1a080ed13c9 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sun, 18 Jul 2021 21:26:59 +0200 Message-Id: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> To: t2trg@irtf.org, asdf@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Monday 19th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 19:27:10 -0000 For the IETF 111 hackathon, we are planning some activities that relate = to T2TRG (and its WISHI activity), ASDF, and CoRE. We are cognizant = that many will be on vacation that week, but we still want to get some = work done ahead of the IETF111 happening the following week. We=E2=80=99ll run a kickoff at 1400Z on this Monday (today/tomorrow = depending on your timezone: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hackat= hon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210719T14&ah=3D1 ). The main purpose is to see who is planning to do what and to set up = collaboration points. We also want to agree on a time (approximately, but not necessarily = exactly 1400Z again) where we have a day sync call Tue to Fri; we=E2=80=99= ll announce this here, so if Monday doesn=E2=80=99t work for you, you = can chime in later. You may want to pre-fill below=E2=80=99s CodiMD with any additional = information that might be useful for the kickoff (or during the week). = You may also want to register for the hackathon at = https://registration.ietf.org/111/new/hackathon/ . Gr=C3=BC=C3=9Fe, Carsten # T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111 Kickoff: Monday, 2021-07-19, 1400Z (60 min max) Notes: https://codimd.ietf.org/hackathon-2021-t2trg-111-monday Meetecho: = https://meetings.conf.meetecho.com/interim/?short=3D5903310f-3a8d-4f3a-93c= 4-5dbb1c9cb768 Note that we will use meetecho for this meeting. Please check whether your datatracker account works; if it doesn=E2=80=99t= , reset its password or get a new one at: https://datatracker.ietf.org/accounts/create/ (It is worth doing this ahead of time as there may need to be an = interaction with the IETF secretariat.) ## Areas of work ### SDF related * tools (e.g., sdf compact) * definition(s) of equivalence * converters (translations) from SDF to X, from X to SDF * YANG (sdf-yang-converter.org) (*) * WoT (sdf-wot-converter.org) * IPSO/LwM2M (https://github.com/EricssonResearch/ipso-odm) * OCF? * Azure DTDL (*) * curl --data-urlencode sdf@test-sdf-file.sdf.json = http://wishi.nomadiclab.com:8083/odm2dtdl * CI pipeline to keep translations up to date? ### CoRE related * CoRE resource directory? (*) * CoRAL, particularly -href (CRIs) (*) ### Others? From nobody Sun Jul 18 13:18:31 2021 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 7AEB23A08E6; Sun, 18 Jul 2021 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUREeT0cXhiO; Sun, 18 Jul 2021 13:18:24 -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 6969C3A08E4; Sun, 18 Jul 2021 13:18:24 -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 87BF94010C; Sun, 18 Jul 2021 22:18:21 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 61242D0; Sun, 18 Jul 2021 22:18:20 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0784D148; Sun, 18 Jul 2021 22:18:19 +0200 (CEST) Received: (nullmailer pid 2667521 invoked by uid 1000); Sun, 18 Jul 2021 20:18:19 -0000 Date: Sun, 18 Jul 2021 22:18:19 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org Message-ID: References: <162613081317.26331.17084230218140543874@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ASfgTvVcotsh3GMW" Content-Disposition: inline In-Reply-To: <162613081317.26331.17084230218140543874@ietfa.amsl.com> Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-echo-request-tag-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 20:18:30 -0000 --ASfgTvVcotsh3GMW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE and all involved in "CoAP: Echo, Request-Tag, and Token Processing", with the submitted -13 version, G=F6ran, John and I think that all pending comments are addressed, and that the document should be ready to proceed. Thanks to all who provided comments, they were useful throughout and helped improve the document. We've found a few issues even with the published document (one of them being that I neglected to express the above sentiment in the acknowledgements section; another that the title may need some work to make a useful abbreviation, the rest editorial trivialities) -- however, we are confident that they are fixable in parallel to further processing at the RFC editor. In addition to the diffs available in the usual locations[1], there is now full list of changes between versions 12 and 13 at the end of the mail. (The list was just not ready in time for the cut-off...). Point to point responses are being sent to the latest round of reviewers and all reference this mail for introductions. As several points culminated in the addition of the new "Characterization of Echo Applications", a common answer referred to by the label GENERIC-SHORT-ECHO is provided at the end of this mail. Hoping that this at last ends the five and half years of MISSREF in C280 Christian [1]: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-echo-request-tag-13 ## GENERIC-SHORT-ECHO The explanations as to the required properties of Echo values were inconsistent: Section 2.3 "Echo Processing" required that the server MUST be able to verify that the Echo value is genuine, but at the same time the permitted minimal length and the example in Appendix A item 3 indicated that this would not always be the case. In parallel, Ben Kaduk's review asked for elaboration on the spectrum of requirements -- of which some extremes call for verifiable Echo values, and others not. Consequently, a section "Characterization of Echo Applications" was added t= hat discusses three aspects: "authority over synchronized property", "Time vs. Events" and "applicable security protocools". In the former, we derive when using guessable Echo values is OK, and when not. In the remaining texts, the ambiguous points were clarified (often pointing= at the new distinctions). In particular, the security considerations used to conflate the topic of "authority over synchronized property" with the Count= er implementation -- while these generally do coincide, the new text is more precise and refers back to the new section. ## Change log from -12 to -13 * Add subsection "Characterization of Echo Applications". * Changes in applications and appendices to use the newly introduced terms. * In particular, some of the legitimization for using short Echo values was drawn from the applications being event based; the concept of the client being the "Authority over [the] Used Information" now legitimizes these more precisely. * Add subsection "Updated Amplification Mitigation Requirements for Servers". It contains the normative text updating RFC 7252 w/rt recommended mitigation methods, which previously happened in passing. * Amplification mitigation: * Increase precision: Reachability check is performed once per endpoint (was: peer). * State that amplification factor applies to the sum of all (previously: "the size of the", implicitly, single) returned packets. * Fix odd wording around how the Echo value would "contain" the claimed address: was meant to contain in a cryptographic sense, now clarified in that a MAC is recommended * Define "preemptive Echo value" that was previously used without definition; another occurrence of the concept was simplified using the term. * Add considerations for the use of DTLS without replay protection. * Privacy considerations: Address concerns raised in various numeric-ids documents. * Explicitly state expected security modes for Echo applications and examples. * Fix of requirements for H-C proxies: They *MUST NOT* relay unsafe requests. (Previously, it only said that they SHOULD use a particular method, but not clearly that some method is mandated.) * Clarify that state synchonization is an application of the freshness results in combination with some transported application data, and not an immediate result of using Echo alone. * Add text to tie together applications and suggested mechanisms * Restrict C-C proxy allowed behavior: Only safe requests (incorrectly said "idempotent") may be used to proactively populate the proxy's cache. * Justify some "SHOULD"s by outlining justification for different behavior. * Normatively require H-C proxies to process Echo if they're justified to do so, as no alternatives are available. * Reference updates: * QUIC is now RFC9000; precise section given as amplification reference. * Add note for RFC editor that RFC6347 can be upgraded to DTLS 1.3 if C321 overtakes C280 * Follow the core-coap-actuators to core-coap-attacks update * RFC8470 reference is now normative (as using what's defined there has been RECOMMENDED already) * Editorial fixes * Rewording of confusing sentences in amplification mitigation and inner-/outer Echo values * Replace "blacklist" terminology with "deny-list" where left after other changes * Removed sloppy use of Echo as a verb * Minor clarifications * Remove duplicate statements * Typography and spelling fixes * Fixes that are not editorial but minor * Freshness is about time, of which round-trip time (specialization now removed) is only a part. * Reference how HTTP *1.1* does it when explaining token requirements, as that's an easily and widely understood baseline. --=20 A beginning is the time for taking the most delicate care that the balances are correct. -- Princess Irulan, Manual of Muad'Dib --ASfgTvVcotsh3GMW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD0jIcACgkQOY0REtOk veETRg//YPuJjmj65/5oXUxgnizSc1/Omr13ppOkp+5EyfoUFz1jjIieSfybRxNW PwvoXlshiYMCSfc3XWQgzhf87aUA6ZlXIxnPDUN9GuhFiyZW8ZVbRIisrS8lzuLz czyUTbuCsqosYSUbsgEPjY6ywpERBG1NlZEgx7fqdRZJuPQQZFCdjSvBBfYhi7lD dQxlysujzJjOKThy4AsxcG2dI54m+cKr1G8ZG7QkLMBepnFXrmNPnXZRqymCZAdN jVzQ9p1VgcH+oVNd++Jho5hh40iqmjXkKpHUxpp6Irv3AmMtlJ90y3G0pllBVzLn TVXi0qKtEr3oiRrTIiKwhH1C7sltCDITKAfCKhYZNlOFjfRI71oBC6GTZm+3AZ5K CXHg0W7HPDrJd6V1GAheXAPu/3UYUXvc4SgIDCyy6JTBS9HOcVfxJ/M51udEgoMs DQ1eFcrcm3ic+zucSuSzi66H7oVu5UQEqUCYGasVVNNG35rSx4CqDcgnG9LeK2xv 4cl/4SmyI01998t2PD3Ub4mDybt7M5rSde/x2ZkLE0rvD6ZzQbUMBz3Y+gtR1Pit h77BriI3oklCQLZbYQX6bZAoW8DmpVPOEWnkDWfmNoSZoSrghnSki8yVrIkOlzdB BYeOTwzD1oM5oG58vjcnBtz1J7IbQIvKqtVJOdI7DOs3uAjjmNQ= =Niqn -----END PGP SIGNATURE----- --ASfgTvVcotsh3GMW-- From nobody Sun Jul 18 13:25:35 2021 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 9571D3A0953; Sun, 18 Jul 2021 13:25:33 -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, SPF_HELO_NONE=0.001, 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 LTb6wQpDBm-j; Sun, 18 Jul 2021 13:25:29 -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 9E1D03A094E; Sun, 18 Jul 2021 13:25:23 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6FCDA4010C; Sun, 18 Jul 2021 22:25:20 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6C4ECD0; Sun, 18 Jul 2021 22:25:19 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DB533148; Sun, 18 Jul 2021 22:25:18 +0200 (CEST) Received: (nullmailer pid 2667889 invoked by uid 1000); Sun, 18 Jul 2021 20:25:17 -0000 Date: Sun, 18 Jul 2021 22:25:17 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Roman Danyliw Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, core@ietf.org Message-ID: References: <161359527152.11372.63177839446582675@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rWKSF1toZf7YgVp6" Content-Disposition: inline In-Reply-To: <161359527152.11372.63177839446582675@ietfa.amsl.com> Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 20:25:34 -0000 --rWKSF1toZf7YgVp6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Roman, thanks for your input on echo-request-tag, and apologies for the delay in processing them to completion. Please see [1] for a few general comments; here are individual responses to your comments: > ** Section 5. Per =E2=80=9CAs each pseudorandom number most only be used= once =E2=80=A6=E2=80=9D, how will that be possible when echo values as sma= ll are 1-byte are possible? Not all applications of Echo depend on pseudorandom numbers. Where they do not, their construction can ensure that only unique 1-byte values are used.until these are exhausted. See also GENERIC-SHORT-ECHO[1]. > ** Section 5. > However, this may not be an issue if the > communication is integrity protected against third parties and the > client is trusted not misusing this capability. =20 >=20 > -- Why is the use of integrity presented as only a possibility here? Did= n=E2=80=99t Section 2.3 require it when assuring the freshness requirement = =E2=80=93 =E2=80=9CWhen used to serve freshness requirements including clie= nt aliveness and state synchronizing), the Echo option value MUST be integr= ity protected between the intended endpoints ...=E2=80=9D > -- Would it be clearer here to say that this is mitigation against an on-= path attacker, not against rogue/compromised clients? In the course of the GENERIC-SHORT-ECHO changes, this has been made more precise using the concept of "authority over synchronized property" introduced there. > ** Appendix A helpfully tries to lay out recommendations. A few comments: >=20 > -- all of the recommendations here have option values much larger than th= e permitted minimum of 1-byte. In addition to the recommendations, could t= he circumstances of the lower bound also be discussed Item 3 of appendix A can be as short as 1 byte (until it overflows to 2), with a concrete example linked, and includes a requirement for its applicability. > -- it would be helpful to explicitly state which methods apply to the spe= cific use cases (client aliveness, request freshness, state synchronization= , network address reachability). For example, method 3 (persistent counte= r) notes that it can be used for state synchronization but not client alive= ness These are now tied together by the Characterization chapter introduced in GENERIC-SHORT-ECHO. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4 --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --rWKSF1toZf7YgVp6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD0ji0ACgkQOY0REtOk veHEJg/+P5XrWd2BZ6PnYOouoTg4O5uS5FahscmGGAgXG+Fg0PNDSMmuRBmc/LhU QduQ1WLELGdBLQqMN34Zgb4/5xNFQ6R0OqySFIGx3jaCYoujrUFKxGJaqVzVijay srI3i7xA5RX0RmClGzbyPYHzHIzRGuG8NjwYKj40Kkdg/d2AG7vak3sCWN6kAt76 j2LbhCyfHlYyXxCyKxt+A2k303Uwq5O6j4Ba2BzDHxDK6gWRaIF+0K197dEM7yp3 3aeOnwILQNiXA5N0y8bzAo3vXvRZDe09PtO6sEoJvL5y6imASQfR8doJahpey40O 63U2K5sXbWD7tb3bLpcZrm4lTOXSm2NFQU9wy9Pk4Hw+hl1g3qR4Q89IBAhAbT2e AxfFlvrV4Io3gkH5FvgldrJTgHDoRQ8AhXZqklEugnhVQrmuujb3hKxDz9cDiecb Ed/fJ4CcA4fX1BsAxy7Xxf+3nSJNwvNhLAGsrOT95EcnxkSouCJEJXCmWp9LWA0u npxOkF28DUzFumVJR9gG2Ao4OgoVcoJRj+b3HJiPLzWhnGcOH/ErxHi43zXLY8pI CyP3/9zGmr4fmVaYjpYg/cdvIigbC7wtXXxL48pE//LjA3qBkreYjI6pf2O0HpYD WNiD0xvpQnGDUoMi0KzV23AsXdkWOSNFemKYjFQbEwR4qZGAgSQ= =ezfI -----END PGP SIGNATURE----- --rWKSF1toZf7YgVp6-- From nobody Sun Jul 18 13:27:18 2021 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 282AA3A0976; Sun, 18 Jul 2021 13:27: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, SPF_HELO_NONE=0.001, 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 WV1qEsqoEOYp; Sun, 18 Jul 2021 13:27:11 -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 5C7D43A096D; Sun, 18 Jul 2021 13:27:11 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CC0804018E; Sun, 18 Jul 2021 22:27:08 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 24387D0; Sun, 18 Jul 2021 22:27:08 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BBA42148; Sun, 18 Jul 2021 22:27:07 +0200 (CEST) Received: (nullmailer pid 2668000 invoked by uid 1000); Sun, 18 Jul 2021 20:27:07 -0000 Date: Sun, 18 Jul 2021 22:27:07 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Martin Duke Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, core@ietf.org Message-ID: References: <161256869105.2187.18183319486008145082@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/qfUSLcTAeRhbV5w" Content-Disposition: inline In-Reply-To: <161256869105.2187.18183319486008145082@ietfa.amsl.com> Archived-At: Subject: Re: [core] Martin Duke's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 20:27:16 -0000 --/qfUSLcTAeRhbV5w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Martin, thanks for your input on echo-request-tag, and apologies for the delay in processing them to completion. Please see [1] for a few general comments; here are individual responses to your comments: > 5.1 This is optional, but please replace "blacklisted" with "deny-listed". Changed in -13. > 6. What is a "preemptive" echo value? They are Echo values sent with successful responses. The term is defined now at first use, and one more place where it could have been used added now that it's introduced properly. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4 --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --/qfUSLcTAeRhbV5w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD0jpoACgkQOY0REtOk veGf0g//UQYGciYanOObLEha5PWruSsDD0VV6GzSpjstAREUaJFY3uyANfhsNK1j 6KH6H9FfPbmNNu/8izOWDbuwDCxBjNa14oriQ8JIkWs3NmFWDniPgM8psNTpoU40 V7RrXA24ehav3/Ugjtp9rhVVL0MZlriNtvWkQbl4kYRghkR6KDm4CLvNPg7X13bl 72jrHUzVLp+VSpRo5mBWkT68edRZZlUniFXO4eTW+uP/BcQt8gbr2JcV0tW0K9zE 6Q7cnpvINEILs1Ec7MBR41liAEFkkiYYb2AjzRtkS88mR+lrzFLqN78cB6v1lzls lJV+UNAgB7jqsp3cxWKzYgrkb9aDmhNo+d65dKWmxT+bIMD3/Y8RobCVyHhytHWP qSEaJT5RTel/H1eBRIcaWBYZcZ5PG19Vq5gL/dFAD1+eM3tAB/KoC863HTg9aDGn hgKOW4NA7oRm9K9dzTA6+59k6NCZ43qVsPV5yUQv6Nks6k3fQ2Hw/bFAtQuGvZfr kPCpVoBf+PAslr0sbstotiQOg12Oc/Mm1mGde3mI24QUDy+NMumKLgRCqLbFTNRj VIItq6bnKF8QqbEeK8WwSoepYmhgA2ef+9hM1+J7OU2eqjHTGcbhW3QDDLgeTTX5 +YHtDStSU9o/sqfAqG3tPkqMFwAbMfSnNepGExDIb7H7geZ0VkE= =rNdA -----END PGP SIGNATURE----- --/qfUSLcTAeRhbV5w-- From nobody Sun Jul 18 13:38:36 2021 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 4EF1F3A0A33; Sun, 18 Jul 2021 13:38:29 -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, SPF_HELO_NONE=0.001, 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 5qskCuKYV-Is; Sun, 18 Jul 2021 13:38:24 -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 3CFC23A0A31; Sun, 18 Jul 2021 13:38:23 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 916174018E; Sun, 18 Jul 2021 22:38:21 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BBE53D0; Sun, 18 Jul 2021 22:38:18 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2B151148; Sun, 18 Jul 2021 22:38:18 +0200 (CEST) Received: (nullmailer pid 2668423 invoked by uid 1000); Sun, 18 Jul 2021 20:38:17 -0000 Date: Sun, 18 Jul 2021 22:38:17 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Benjamin Kaduk Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, core@ietf.org Message-ID: References: <161362172020.28530.15247844895355003249@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ffyqXju6tB2qsDXA" Content-Disposition: inline In-Reply-To: <161362172020.28530.15247844895355003249@ietfa.amsl.com> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 20:38:30 -0000 --ffyqXju6tB2qsDXA Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ben, thanks for your input on echo-request-tag, and apologies for the delay in processing them to completion -- I should have taken your note on "fairly substantive comments that might result in significant text changes" more seriously. Please see [1] for a few general comments; here are individual responses to your comments (with suggested terms / phrases that were accepted and similar small items removed from the list): > Thank you for working on this document; these mechanisms are important > and will help fill some long-standing gaps in CoAP operation. That > said, I do have some fairly substantive comments that might result in > significant text changes. >=20 > While I recognize that there is going to be a spectrum of requirements > for determining freshness, I would have expected the far extreme of that > spectrum to include a strongly time-limited single-use cryptographic > nonce (akin to what the ACME protocol of RFC 8555 uses but with time > limit), as well as discussion of some points on the spectrum and which > ones might be more or less appropriate in various cases. I do see some > discussion of different use cases, but not much about the tradeoffs > along the spectrum, and no discussion at all about the strongest > properties that it is possible to obtain with this mechanism. This spectrum, with the axes kind-of-freshness and authority-over-synchronized-property, is now described in a new Characterization of Echo Applications subsection, which includes limited-time-single-use as a combined form of kind-of-freshness. Particularly the part that deals with unique-but-predictable Echo values is frequently referenced later, and also mentioned in [1] as GENERIC-SHORT-ECHO. (It also addresses Roman's "helpful to explicitly state".) > In several places we mention that the Echo option enables a server to > "synchronize state", which to me is a confusing or misleading > characterization -- as I understand it, both additional (application) > protocol mechanism and constraints are required in order for state > synchronization to occur. Specifically, the client has to be the > authority for the state in question, and the application protocol needs > to specifically indicate under what conditions and which state is to be > synchronized. In essence, the Echo option provides a mechanism for > ensuring request freshness, and that mechanism is leveraged by the > application protocol to make a synchronzed transfer of state from client > to server. But AFAICT it is not a generic state synchronization > mechanism, the state to be synchronized is not conveyed in the option > body, etc. My preference would be to take "synchronize state" out of > the primary list of what is possible and mention it in a separate > sentence as something that can be constructed using the functionality > that the Echo option provides. State synchronization is indeed something that can be done with freshness; text was tweaked to make that more visible. It's still mentioned often together with freshness, as it is a very important class of use cases. That the state is not carried inside the Echo option is now emphasised in the applications list. On the topic of authority, this is now covered in the characterization of Echo applications (see also GENERIC-SHORT-ECHO). > There are a couple places where we recommend (implicitly or explicitly) > a sequential counter in contexts that might otherwise use a randomized > value. I think I mention them all in my section-by-section comments, > but in general the sequential counter might be placing too strong a > requirement on the value, and the considerations of > draft-gont-numeric-ids-sec-considerations seem relevant. Under the threat model of pearg-numeric-ids-generation, relevant identifiers are outer Request-Tag and outer Echo values of OSCORE (as inner and DTLS protected ones are protected by message integrity, and Token rules are only updated for DTLS where it is protected as well). For the remaining cases, a paragraph has been added to the privacy considerations section. > I think it would also be enlightening to have a comparison between the > anti-replay/freshness properties provided by the optional DTLS replay > protection mechanism and the Echo option. I know they have differences, > but I think there is also some commonality, and giving readers guidance > on whether one vs the other suffices or both are needed could be useful. Such a comparison was attempted, but found to be tied too deeply into core-coap-attacks; an issue has been opened at https://github.com/EricssonResearch/coap-actuators/issues/8. That comment did inspire a paragraph on the relationship between Request-Tag and replay protection, which did get more interesting when the document was adapted in awareness of DTLS's option to not use replay protection at all. > Section 2.3 >=20 > Upon receiving a 4.01 Unauthorized response with the Echo option, the > client SHOULD resend the original request with the addition of an > Echo option with the received Echo option value. [...] >=20 > [just noting that IIUC the revised requirements on token generation made > later in this document are needed in order for this "resend the original > request" to be safe" ... I am not sure if it needs to be called out here > specifically, though.] If the client does not increment the token, it would be susceptible to the 4.01 response being reinjected, so it may try again -- but as it is not incrementing tokens, the server processes the request only once anyway (but the client is left ignorant of its success). So yes there are some light implications (and more severe ones in corner cases), but the trouble from token reuse is so much bigger than this one case that pointing it out specifically would probably distract more than help. > I don't think the example of this in Figure 3 meets the requirements, > though, since the echo option value is just a counter that is easily > spoofable. It does meet the particular requirement of the above paragraph ("different except with negligible probability") as it is just counting up (where after 255 events it'd overflow to two bytes and further). For the general requirements, these should now be clearer (see GENERIC-SHORT-ECHO). > [...] When used to demonstrate > reachability at a claimed network address, the Echo option SHOULD > contain the client's network address, but MAY be unprotected. >=20 > What does "contain" mean, here? Plaintext? That seems potentially > problematic; using it as an input to the MAC that is not transmitted (as > I mention later) is more conventional, in my understanding. That's what it should have said in the first place; fixed. > The CoAP client side of HTTP-to-CoAP > proxies SHOULD respond to Echo challenges themselves if they know > from the recent establishing of the connection that the HTTP request > is fresh. Otherwise, they SHOULD respond with 503 Service > Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive > connection. If the HTTP request arrived in Early Data, the proxy > SHOULD use a 425 Too Early response instead (see [RFC8470]). They > MAY also use other mechanisms to establish freshness of the HTTP > request that are not specified here. >=20 > Where is the MUST-level requirement to actually ensure freshness (by > whatever mechanism is available/appropriate)? That was indeed missing; the "they SHOULD respond with" was intended to leave room for other methods of obtaining freshness, not to just ignore the issue and respond to the Echo challenge unchecked. A "MUST NOT repeat an unsafe request and [SHOULD]" was added. (The exception for safe methods allows filling caches, similar to how item 3.1 of the Applications of the Echo Option section describes CoAP-CoAP proxies that forward to their client interface though they reject on their server interface). > * If a server reboots during operation it may need to > synchronize state or time before continuing the interaction. > For example, with OSCORE it is possible to reuse a partly > persistently stored security context by synchronizing the > Partial IV (sequence number) using the Echo option, see > Section 7.5 of [RFC8613]. >=20 > In light of my toplevel comment, I'd suggest rewording this to clarify > that the protocol specified in RFC 8613 includes a mechanism for > resynchronizing the partial IV state, that uses the Echo option in a > specific controlled protocol interaction. > > (A similar consideration would apply to the group communication example, > though it might be a little harder to write clearly.) The "authority over synchronized property" concept intoduced in response to the toplevel comment (GENERIC-SHORT-ECHO) covers most of this. Thus, also the time synchronization given can be valid here -- provided the client is a recognize authority for it. Which, in a group case, it will likely not be; thus, removing the example from there. (Also upgrading the "see" to an "as specified" to softly indicate that this is not done easily). > 3. A server that sends large responses to unauthenticated peers > SHOULD mitigate amplification attacks such as described in > Section 11.3 of [RFC7252] (where an attacker would put a victim's > address in the source address of a CoAP request). The > RECOMMENDED way to do this is to ask a client to Echo its request > to verify its source address. [...] >=20 > (editorial) this usage of "ask a client to Echo its request" seems > rather divorced from the actual mechanicis of the Echo option...in the > rest of the document (bar one other instance noted below) we restrain > ourselves to saying that the Echo option is what is echoed, divorced > from the containing request/response. It kind of makes sense, but (with the current terminology) would really need terminology introduction. This particular occurrence has been cleared up in unrelated edits already; the later is changed. > This needs to be done only once > per peer [...] >=20 > How is the "peer" identified in this case? Is it tied to a single > (security) association, or the identity (if any) associated with that > security association, or IP address (and port?), or something else? > How long can/should the reachability information be cached for? Different strategies are valid here, and to be honest it may need some additional deployment experience to give hard and fast criteria here. The distinction only starts to matter when an attacker finds a potential amplification helper that already is in legitimate contact with its victim. Picking "the endpoint" as peer definition (which is host and port on both sides, plus the security association), as that curbs the attack at least in the case in which the amplification-helper-to-be does the OSCORE itself, and will then be suspicious of unprotected requests for large responses from the attacker. There is some wiggle room in the interpretation of endpoint, especially in layered setups (I like to think of a CoAP library as a proxy that translates CoAP-over-API to CoAP-over-transport), and some room for optimization (if the unsecured endpoint is good, no need to check for reachability of the secured equivalent), but that at last *will* need the deployment experience to be gathered over the next months and years to see what is practical. > Section 3.1 >=20 > In order for a security > protocol to support CoAP operations over unreliable transports, it > must allow out-of-order delivery of messages using e.g. a sliding > replay window such as described in Section 4.1.2.6 of DTLS > ([RFC6347]). >=20 > My understanding is that the requirement is only to allow out-of-order > delivery of messages (not necessarily including replay detection), so > the clause about the sliding window is not needed. here. Indeed. Realizing that DTLS can be used with replay protection off made this half-sentence go away and caused some follow-up adaptions. > Section 3.2 >=20 > In essence, it is an implementation of the "proxy-safe elective > option" used just to "vary the cache key" as suggested in [RFC7959] > Section 2.4. >=20 > The referenced section of RFC 7959 covers Block2 operation, but my > understanding is that the Block1 operation (covered in Section 2.5 of > that same document) would be a more applicable reference. Section 2.4 is where the cited suggestion is made. This is the relevant reference because there it is made clear that "the resource" to which block operations are keyed is the cache key and not the URI. Section 2.5 explains the general Block1 phase behavior. Its last paragraph is on concurrent transfers, but does not add anything to the understanding of Request-Tag, whereas the 2.4 statements contain the justification for why this can work that way (which applies to Block1 and Block2 alike). > Section 3.3 >=20 > Also, a client that lost > interest in an old operation but wants to start over can overwrite > the server's old state with a new initial (num=3D0) Block1 request and > the same Request-Tag under some circumstances. Likewise, that > results in the new message not being part of the old operation. >=20 > Where are those "some circumstances" enumerated? This could precisely this could say "if the client can recycle the request tag" -- but that has not been introduced at this point, and more importantly the paragraph is about server behavior (examplifying how "equal request tags" doesn't necessarily mean "same operation"). > * The client MUST NOT regard a block-wise request operation as > concluded unless all of the messages the client previously sent in > the operation have been confirmed by the message integrity > protection mechanism, [...] >=20 > nit: confirmed as what? Delivered? With the DTLS replay window realization, this would have become unwieldly, and thus was simplified to the "when the client knows the server won't accept it" that was already there. What that means in practice is spelled out for OSCORE and DTLS in the following paragraphs anyway. > In DTLS, this can only be confirmed if the request message was not > retransmitted, and was responded to. >=20 > Similarly, this would be "When security services are provided by DTLS" > -- DTLS does include a native retransmission layer, but only for DTLS > handshake messages, so this phrasing is needlessly ambiguous as to > whether it is the CoAP request that got retransmitted. The point about retransmission is on CoAP here; made more explicit in the rephrasing. The line was also changed to include the necessity for the server to perform replay protection (which until the RD review I was unaware was even optional). The over-all statement (which leaves the door open for request tag recycling in DTLS) is left open, even though this new constraint is making it *even* harder to be sure -- but the situations in which that could previously done were already pretty niche, and in a setup where the application can alreay know what got ACKed and what got retransmitted, it is not out of the question that it knows the server well enough to assert that it has replay protection active as well. > Authors of other documents (e.g. applications of [RFC8613]) are > invited to mandate this behavior for clients that execute block-wise > interactions over secured transports. In this way, the server can > rely on a conforming client to set the Request-Tag option when > required, and thereby conclude on the integrity of the assembled > body. >=20 > Could you clarify which client behavior would be mandated? The overall > "body integrity based on payload integrity" procedures, or the specific > "typically, in OSCORE" behavior? The behavior is the whole subsection's. (Many such specifications WOULD PROBABLY also mandate a particular security mechanism, narrowing it down to one of the cases, but the intention is to use the abstract behavior) Now clarified. > Section 3.6 >=20 > The Request-Tag option is repeatable because this easily allows > several cascaded stateless proxies to each put in an origin address. > They can perform the steps of Section 3.5.3 without the need to > create an option value that is the concatenation of the received > option and their own value, and can simply add a new Request-Tag > option unconditionally. >=20 > Thanks for including this! However, it wasn't clear to me from reading > https://tools.ietf.org/html/rfc7252#section-5.4.5 and this document > whether the order of repeated Request-Tag options was significant. > Some clarification might be helpful. The order of CoAP options is significant in the information model (and if any doubt on this arises, core-corr-clar would be the place to to dispell them). As Request-Tag has no own semantics, intermediaries can put theirs in the front or back (or not use repeatability at all), but as implementers can pick any, I don't see much to point out. > Section 3.7 >=20 > That approach would have been difficult to roll out reliably on DTLS > where many implementations do not expose sequence numbers, and would > still not prevent attacks like in [I-D.mattsson-core-coap-actuators] > Section 2.5.2. >=20 > (I agree that DTLS implementations largely don't expose sequence numbers > and that is unlikely to change. But) I am not sure I fully understand > the scenario referenced in draft-mattsson-core-coap-actuators =A72.5.2. > Perhaps it is not what was intended to be conveyed, but it seems like in > a setup that is tracking both sequence and fragment numbers, it would be > pretty easy to enforce that a fragment-0 block will only start a new > request if the sequence number is larger than the sequence number of the > current/previous blockwise request. IIUC that would reject the > "withheld first block" as being too old. Enforcing that means that not only state about ongoing block-wise operations is kept (which is about as much state as can be tolerated), but that in addition also state about block-wise transfers that are not pursued any more would need to be kept -- and that's too much to ask (as it'd be per-client times per-resource information). > Section 3.8 >=20 > and MUST NOT use the same ETag value for different > representations of a resource. >=20 > (side note) I was a little surprised that this was not already a > requirement, but I couldn't find an equivalent statement in a quick > review of RFC 7252. (It's definitely correct that this is required > behavior to get the protection in question.) Neither was any found in RFC 7959. > Section 4.1 >=20 > In HTTPS, this type of binding is always assured by the ordered and > reliable delivery as well as mandating that the server sends > responses in the same order that the requests were received. [...] >=20 > I believe this description applies to HTTP/1.1 over TLS, but not to > HTTP/2 or HTTP/3 (both of which provide other mechanisms for reliably > binding requests and responses in the form of stream IDs). Changed to refer to HTTP/1.1. Covering what /2 and /3 do might be interesting comparison material, but given we're just tweaking the Token mechanism here (and not introducing it anew, which would warrant the detailed related-work comparison over the setting-the-mental-frame reference to HTTP/1.1), that should suffice. > Section 4.2 >=20 > One easy way to accomplish this is to implement the Token (or part of > the Token) as a sequence number starting at zero for each new or > rekeyed secure connection. This approach SHOULD be followed. >=20 > I note that sequential assignment often has some additional undesirable > properties, as discussed in draft-gont-numeric-ids-sec-considerations. > Would a different method (e.g., one listed in > draft-irtf-pearg-numeric-ids-generation) provide the needed properties > with fewer side effects? > In particular, sequential increment is at odds with the "nontrivial, > randomized token" recommended for clients not using TLS (that is > intended to guard against spoofing of responses). > ("use of a sequence number" and "a sequence number approach" also appear > in =A75.1, if this is changed.) These recommendations are for secured transports without request-response binding, i.e. DTLS. As the identifiers are protected by the DTLS integrity protection, they are outside the scope of the threat model described in numeric-ids-generation. (On the other hand, the nontrivial, randomized token recommended for non-TLS cases, and this document makes no updates for them.) The concepts of numeric-ids did result in additions to the privacy considerations for outer Echo and Request-Tag values. > For the purpose of generating timestamps for Echo a server MAY set a > timer at reboot and use the time since reboot, in a unit such that > different requests arrive at different times. [...] >=20 > Something about this sentence confuses me, possibly around "in a unit". "choosing the granularity such that". (Which may not be necessary for all applications, but is convenient when using both time and events). > Section 5.1 >=20 > Tokens that cannot be reused need to be handled appropriately. This > could be solved by increasing the Token as soon as the currently used > Token cannot be reused, or by keeping a list of all blacklisted > Tokens. >=20 > editorial: perhaps "unsafe to reuse" is more clear than "blacklisted"? Changed simillarly ("keeling a list of all Tokens unsuitable for reuse"). > Section 6 >=20 > This seems to be the first (and only) place where we use the term > "preemptive Echo values"; it might be worth a bit more exposition that > these are ones piggybacked on non-4.01 responses (assuming that's > correct, of course). It is, and now properly introduced. > Section 8.1 >=20 > I note that DTLS 1.3 is in IETF Last Call. I did not notice anything in > this document that's specific to a DTLS version, which suggests that it > woudl be safe to change the reference according to relative publication > order of these documents. It would be good for the authors to confirm > that at their leisure, so as to not be rushed into a decision if/when > the RFC Editor asks during their processing. DTLS 1.3. works just as fine, a note to the editor has been added. > Section 8.2 >=20 > I note that draft-mattsson-core-coap-actuators is referenced from > several locations (for useful additional discussion, to be clear), but > it is only an individual draft that expired almost two years ago. Is > there any likelihood that it will ever progress to an RFC? Work on the document has been taken up again as draft-mattsson-core-coap-attacks-00, the references are updated. > One might argue that "SHOULD use a 425 Too Early response" is enough to > promote RFC 8470 to being a normative reference (see > https://www.ietf.org/about/groups/iesg/statements/normative-informative-r= eferences/). Given there is no way to indicate modularity here, yes, that's what the rules say; changed. > Section A >=20 > 2. Integrity Protected Timestamp. The Echo option value is an > integrity protected timestamp. The timestamp can have different > resolution and range. A 32-bit timestamp can e.g. give a resolution > of 1 second with a range of 136 years. The (pseudo-)random secret > key is generated by the server and not shared with any other party. > The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit > timestamp and a 64-bit MAC, the size of the Echo option value is 12 > bytes and the Server state is small and constant. The security > against an attacker guessing echo values is given by the MAC length. > If the server loses time continuity, e.g. due to reboot, the old key > MUST be deleted and replaced by a new random secret key. Note that > the privacy considerations in Section 6 may apply to the timestamp. > Therefore, it might be important to encrypt it. Depending on the > choice of encryption algorithms, this may require a nonce to be > included in the Echo option value. >=20 > I note that a MAC construction allows additional information to be > covered under the MAC that is not sent alongside it, e.g., identity > information about the client to which the Echo option value is being > associated. Are there common situations in which including such > additional contextual information under the MAC would be valuable (to > prevent an echo option value received on one connection from being > usable on a different one)? There is one -- demonstrating network reachability. It's not a common case (often the large responses are from GETs that don't need freshness anyway), but educational in the sense that it helps fill the continuum between MAC-the-address (RECOMMENDED for reachability) and time-and-MAC-of-time (RECOMMENDED for freshness) to guide the reader towards understanding the whole and not just coding down the recipes. Added. > 3. Persistent Counter. This is an event-based freshness method > usable for state synchronization (for example after volatile state > has been lost), and cannot be used for client aliveness. It requires > that the client can be trusted to not spuriously produce Echo values. >=20 > I have severe qualms about specifying a protocol mechcanism that relies > on trusting a client to this extent. It seems to expose a lot of latent > risk; even if we think there should be mechanisms in place to protect > against that risk, they might fail, or the mechanism might get used > outside its intended context, etc.; if there are other mechanisms > available for similar cost that provide the needed properties it seems > more robust to suggest their use in place of the persistent counter. The additions of GENERIC-SHORT-ECHO, especially on "authority over synchronized property", should help in describing this and limiting any ill-effects. If the client is *not* trusted, we're fast into the order of magnitude of 64-bit MACs; anything less might just give a false sense of security. Where these are transported regularly (as in [RD]), that quickly adds up in total bytes on the air. Thes cases *do* need good analysis, and it is hoped that with the new text the tools for this are there, but when the result is that trusting the client on this freshness is fine, then a counter should be too and has the least cost. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4 [RD]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28= =2Ehtml#name-request-freshness --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --ffyqXju6tB2qsDXA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD0kTYACgkQOY0REtOk veHP0A/+PdpHr9Nr2lrqAm70/6rkY7XH+3qb+/PuuQKWkwK/C+4Ej3UndKX/Umqf uGS261ZwjJg3AUT+dsJxEEsTjRk//6tCtAZAD4cywZrQf8baVbKWBkM+V5TFaH1j w09bh4G5KvECqbutBxV7sjKDzIvYJzCxN36xqgILcCuvGqpr6E0gz/hAAcvYfnBN i8YYLBtv/PCni7g9d9qfUT0MzbNR9t4cxlUnqgza5ryiEqA9GgJrjA6yXXiJO6mo 4nw62yCCH2OBwCabxsKPIgNiSmwx3Ivs8WIqLJrlWOJYTZlSrjdp2hs7/R1JZhn2 DaFFx7fgzY3tnXv/x1lepez5MHnRBlwR+eTywJpzSifuZYsAlwtqzfLMgA8hMCtI 0DwbM7sRCbPmOJqxTxhwcVPSkxlC/RWI6ShjOAQnxco/+zURVW8HmD4CpvYkn0Kn 85C5xkN92U3XY0DvYi/etVhEdTeYZOYZPuVbGV38tUE+gwX1VrWy9v/ARz9BmcgT PPAeAN4GkGFJpWMJNoh9IwZmqk35JXmeW/dgpWJQOaCycK9HqLzm6c0e4Kub0Z/9 OUDSTN1DFtR6Xo/JzEXxB5ORn4uZOir07Onrf7s4xD8WlsKJgMWu28mZzDbx7WvC BGtu5J1PAjAzYky4+n2PFcJ5ZynbLl8T0xucxYC4qNjzjVfsPsQ= =XZej -----END PGP SIGNATURE----- --ffyqXju6tB2qsDXA-- From nobody Sun Jul 18 13:42:00 2021 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 75C443A0A71; Sun, 18 Jul 2021 13:41:58 -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, SPF_HELO_NONE=0.001, 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 9B-Pku-vjBja; Sun, 18 Jul 2021 13:41:54 -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 9E51B3A0A66; Sun, 18 Jul 2021 13:41:48 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 13D104018E; Sun, 18 Jul 2021 22:41:46 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4F491D0; Sun, 18 Jul 2021 22:41:45 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [188.20.219.122]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D2749148; Sun, 18 Jul 2021 22:41:44 +0200 (CEST) Received: (nullmailer pid 2669061 invoked by uid 1000); Sun, 18 Jul 2021 20:41:44 -0000 Date: Sun, 18 Jul 2021 22:41:44 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Murray Kucherawy Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, core@ietf.org Message-ID: References: <161363758006.28269.10539291789085222217@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="USuXXIKuxDd/z2nJ" Content-Disposition: inline In-Reply-To: <161363758006.28269.10539291789085222217@ietfa.amsl.com> Archived-At: Subject: Re: [core] Murray Kucherawy's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 20:41:59 -0000 --USuXXIKuxDd/z2nJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Murray, thanks for your input on echo-request-tag, and apologies for the delay in processing them to completion. Please see [1] for a few general comments; here's the response to your particular comments: > There are several SHOULDs (e.g., near the top of page 8, and again at > the end of Section 2.3) that left me wondering why an implementer > would do something other than what it says. Since SHOULD offers a > choice, some advice would be helpful here. Otherwise, maybe those > ought to be MUSTs. I suggest giving them all a once-over to see if > any such advice would be helpful to include. Some categories of SHOULDs were identified that did not warrant any additions: * "You can do it differently and it wouldn't be wrong just weird (but maybe you have good reasons we don't understand)": eg. 'MUST NOT process [...] further and SHOULD send a 4.01 Unauthorized'. If the application has a successful code in a content format that indicates "try again with whatever I'm providing you here", that's technically fine and won't break things (which'd justify a MUST). But it's not like we can give good reasons to do that other than "someone decided to do it differently in that API", so there's nothing good to say. * "If you have anything better, be my guest": In some places, there is no current alternative but no reason to rule them out either. It's unlikely there'll be an "Echo 2.0" that does the same just different, but a more complex mechanism that provides freshness as bycatch would be a viable option in some places. For others (eg. SHOULD use preemptive values, pointing to privacy considerations), options were given; one SHOULD is indeed a MUST (HTTP-to-CoAP proxies) as there's no other viable option. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4 --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --USuXXIKuxDd/z2nJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD0kgcACgkQOY0REtOk veEB5A//X1n5o18R+p46a9jPlPmfGh4xVb8A4VQ+ja6aZBjmlwmrl++gXwM8tv+h HPGF0y6ANZxU733tNOzm9GRC/NtgST9BtEDlnBQHF7b9oHXbcEXCzz4k6pR1KjUJ Sxc9bxbQKWxyJzD1dskODZpZiE2Q8tIj3fP9I2qd0X4GovejYqVwBTSZzvUDRT8k 0cJ3SUBzI8tA6QqWMkUCX5qus1iKcP5+9YpCsq/WhBLF5/ZGfeOBWy2+P5kVqWVl CwDsF8As4wXqk6vr3dhB1e7jnEImoNV2sz9Mz/Oxz05rOvML5Ue59s4oQ1rBWs4/ 6pb4JqQYoLa/cNpdFRsEqvmRA4xkJRezIT9w2+1NPyvi1CTM093Jnz2IjWWW3KXM FsUKohj8QkRb2haNKqevdI7GIg+8Ck43Pj2jvcamyuLeyfUi9TITlu4ESVfm9pV7 3z+nibho+NUXsps3qI5PPlwK7pnCe4+rb7sJUTAwJH+rxHdR9XjHkM0EhL/JURiQ yLYapZn1UPo8EAUz3El/oUwxNwIw366A4Tvt+K/GycdfuEHpfFbUetbJBG0rrADG BOay6drmeCYALLqPVLUj3de16Ej5eTeSwRaUKz1iRe8TGaNiUIBVhp6b2MQF8izC oNWBU8RwgOPu/x8ocEJkA63c1kTBvDdlTUkm7qUHIAvU0zb2G5M= =sOpS -----END PGP SIGNATURE----- --USuXXIKuxDd/z2nJ-- From nobody Mon Jul 19 07:12:21 2021 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 DC40E3A3507; Mon, 19 Jul 2021 07:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHL0-fXJYFXV; Mon, 19 Jul 2021 07:12:10 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 982C93A3502; Mon, 19 Jul 2021 07:12:09 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id l5so20119110iok.7; Mon, 19 Jul 2021 07:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=47mXhDHYn/HXitO+eGI8Xa76UNNGqggxMnGJ3pxJICY=; b=cu4JfCNwDiyjXa65R9j2kiIujxQUetQmwKKDJVJ3U9OsOXBwhzj7+A7UqMvc9lH/cY 4cKjWV8gEG8r5UDS2OwEdi2BEDPQh3+8BTXAazeSllNPfApv/wBuY9yArElDHDwdthPd hrhLURs2nG5KXoCrjHOmfRLrgYu4BP5COpQzp6vWYIPV1Oi3qgsWEWAKUC9E8Hcihaqg fPm4y5N4yXahPMOpsrFT1ji6RL43a0xv6I4ZI9XQHZ4w1dW3X6mbQAAKA807z3Trqrl3 /c5Ddt6us4G9LyCkwnjsjtzJMwSJ0RmtXhEIDltXD0JApTtLz+No4CfAHnYE1JAKe0QN S4Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=47mXhDHYn/HXitO+eGI8Xa76UNNGqggxMnGJ3pxJICY=; b=MxG1uIvyfxhgWH4zC3RwypT9RFdFZN/NgZn4tfU2WEWOpk4YeXAUhegFtHbo8iAvFM zvSI9aoOE4G9Pu+Y/OXBHmb8xv2kEaCETj4wFwO94pQ/1t18eGGrNf4lSt/R23d1o/BN uf9agOSomMbv0hcBqvbiEXjDu5IXif1bBecfRUbP+bvsyRdNQJQ0Ny6bQgYXncxiyB0v VE+V74KL7tTNVAnT0gfftkobMnYFLRJ17w3FY5eznT6WgIMdYjc94iA3X7wSdajqeyhI mKeleVMCXkJg9V1iT7tML3VabwGg9ltAdBAJfGK8xv7/oeur7KlLp346juOWYbYzaExk /vFA== X-Gm-Message-State: AOAM531rXiaiyD29GERbnddlJ9fXYbfMOX5nKHtRzGQPdDFY7BgbhwEd WRCxSg0ww5gOCitLXDCvfotslETg2bfseU1VD6LmzGH+ X-Google-Smtp-Source: ABdhPJxvU19xo2E9HSUF8zt+yAvUD3fash3BrT/7um4RF0avoeBYzhpMIYzliCwvGxosFnKFJdqgdag7HCMDOvQFgTA= X-Received: by 2002:a5e:c70d:: with SMTP id f13mr18817980iop.95.1626703928016; Mon, 19 Jul 2021 07:12:08 -0700 (PDT) MIME-Version: 1.0 References: <161256869105.2187.18183319486008145082@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Mon, 19 Jul 2021 07:11:56 -0700 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-echo-request-tag@ietf.org, "core@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000c8c34905c77a8536" Archived-At: Subject: Re: [core] Martin Duke's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 14:12:15 -0000 --000000000000c8c34905c77a8536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, LGTM On Sun, Jul 18, 2021 at 1:27 PM Christian Ams=C3=BCss wrote: > Hello Martin, > > thanks for your input on echo-request-tag, and apologies for the delay > in processing them to completion. > > Please see [1] for a few general comments; here are individual responses > to your comments: > > > 5.1 This is optional, but please replace "blacklisted" with > "deny-listed". > > Changed in -13. > > > 6. What is a "preemptive" echo value? > > They are Echo values sent with successful responses. The term is defined > now at first use, and one more place where it could have been used added > now that it's introduced properly. > > > Best regards > Christian > > [1]: > https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4 > > -- > This may seem a bit weird, but that's okay, because it is weird. > -- perldata(1) about perl variables > --000000000000c8c34905c77a8536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, LGTM

On Sun, Jul 18, 2021 at 1:27 PM Christian = Ams=C3=BCss <christian@amsuess.= com> wrote:
Hello Martin,

thanks for your input on echo-request-tag, and apologies for the delay
in processing them to completion.

Please see [1] for a few general comments; here are individual responses to your comments:

> 5.1 This is optional, but please replace "blacklisted" with = "deny-listed".

Changed in -13.

> 6. What is a "preemptive" echo value?

They are Echo values sent with successful responses. The term is defined now at first use, and one more place where it could have been used added now that it's introduced properly.


Best regards
Christian

[1]: https://mailarchive.ietf.= org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4

--
This may seem a bit weird, but that's okay, because it is weird.
=C2=A0 -- perldata(1) about perl variables
--000000000000c8c34905c77a8536-- From nobody Mon Jul 19 07:28:30 2021 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 B8E493A35B8; Mon, 19 Jul 2021 07:28:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162670490870.27176.12225448623972952380@ietfa.amsl.com> Date: Mon, 19 Jul 2021 07:28:28 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-09-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 14:28:29 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-09-15 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=086b9da2-6dc7-4de8-8969-ef42503ad5cc From nobody Mon Jul 19 07:29:59 2021 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 8ECD53A365E; Mon, 19 Jul 2021 07:29:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162670498954.30354.2351582764735537308@ietfa.amsl.com> Date: Mon, 19 Jul 2021 07:29:49 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-09-29 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 14:29:58 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-09-29 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=60e19424-f37d-4715-b45b-8bb74ef6aea5 From nobody Mon Jul 19 07:30:15 2021 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 6EF893A364C; Mon, 19 Jul 2021 07:30:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162670500743.8960.8108216276391533493@ietfa.amsl.com> Date: Mon, 19 Jul 2021 07:30:07 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-10-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 14:30:14 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-10-13 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=3cedb9b5-b3ec-4685-ab43-5bff97c4b642 From nobody Mon Jul 19 07:30:43 2021 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 6868F3A3626; Mon, 19 Jul 2021 07:30:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162670502638.22430.15111340347557677949@ietfa.amsl.com> Date: Mon, 19 Jul 2021 07:30:26 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2021-10-27 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 14:30:38 -0000 The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2021-10-27 from 16:00 to 17:30 Europe/Stockholm (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=4b108e95-9886-4b1f-94dc-aee7b0a004ce From nobody Mon Jul 19 09:40:14 2021 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 AAD183A0833; Mon, 19 Jul 2021 09:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=unavailable 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 HWCuqpDenWVh; Mon, 19 Jul 2021 09:39:59 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2363A0832; Mon, 19 Jul 2021 09:39:59 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GT6yM0dfvz2xJr; Mon, 19 Jul 2021 18:39:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> Date: Mon, 19 Jul 2021 18:39:54 +0200 X-Mao-Original-Outgoing-Id: 648405594.701068-a20b94b44d3cb8574a2012b6ec68db95 Content-Transfer-Encoding: quoted-printable Message-Id: References: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> To: t2trg@irtf.org, asdf@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [T2TRG] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Tuesday 20th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 16:40:06 -0000 Today, we scheduled the next daily meeting for https://codimd.ietf.org/hackathon-2021-t2trg-111-tuesday start time: 2021-07-20 14:00:00 UTC max duration: 60 (We needed 45 min today.) = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hackat= hon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210720T14&ah=3D1 = https://meetings.conf.meetecho.com/interim/?short=3Dd49f0f3b-52d5-4a30-8a7= 5-e2f2effec8b0 Notes from today=E2=80=99s meeting are at = https://codimd.ietf.org/hackathon-2021-t2trg-111-monday Gr=C3=BC=C3=9Fe, Carsten > On 2021-07-18, at 21:26, Carsten Bormann wrote: >=20 > For the IETF 111 hackathon, we are planning some activities that = relate to T2TRG (and its WISHI activity), ASDF, and CoRE. We are = cognizant that many will be on vacation that week, but we still want to = get some work done ahead of the IETF111 happening the following week. >=20 > We=E2=80=99ll run a kickoff at 1400Z on this Monday (today/tomorrow = depending on your timezone: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hackat= hon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210719T14&ah=3D1 ). >=20 > The main purpose is to see who is planning to do what and to set up = collaboration points. > We also want to agree on a time (approximately, but not necessarily = exactly 1400Z again) where we have a day sync call Tue to Fri; we=E2=80=99= ll announce this here, so if Monday doesn=E2=80=99t work for you, you = can chime in later. >=20 > You may want to pre-fill below=E2=80=99s CodiMD with any additional = information that might be useful for the kickoff (or during the week). = You may also want to register for the hackathon at = https://registration.ietf.org/111/new/hackathon/ . >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > # T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111 >=20 > Kickoff: Monday, 2021-07-19, 1400Z (60 min max) >=20 > Notes: https://codimd.ietf.org/hackathon-2021-t2trg-111-monday >=20 > Meetecho: = https://meetings.conf.meetecho.com/interim/?short=3D5903310f-3a8d-4f3a-93c= 4-5dbb1c9cb768 >=20 > Note that we will use meetecho for this meeting. > Please check whether your datatracker account works; if it doesn=E2=80=99= t, reset its password or get a new one at: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > (It is worth doing this ahead of time as there may need to be an = interaction with the IETF secretariat.) >=20 > ## Areas of work >=20 > ### SDF related >=20 > * tools (e.g., sdf compact) > * definition(s) of equivalence > * converters (translations) from SDF to X, from X to SDF > * YANG (sdf-yang-converter.org) (*) > * WoT (sdf-wot-converter.org) > * IPSO/LwM2M (https://github.com/EricssonResearch/ipso-odm) > * OCF? > * Azure DTDL (*) > * curl --data-urlencode sdf@test-sdf-file.sdf.json = http://wishi.nomadiclab.com:8083/odm2dtdl > * CI pipeline to keep translations up to date? >=20 > ### CoRE related >=20 > * CoRE resource directory? (*) > * CoRAL, particularly -href (CRIs) (*) >=20 > ### Others? >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg From nobody Mon Jul 19 09:49:53 2021 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 5B3D33A09A1; Mon, 19 Jul 2021 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 eJqjl5RxSSgv; Mon, 19 Jul 2021 09:49:42 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B354F3A09D1; Mon, 19 Jul 2021 09:49:42 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GT79c3ncdz2xJr; Mon, 19 Jul 2021 18:49:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <013301d77cbd$7d165e00$77431a00$@gmail.com> Date: Mon, 19 Jul 2021 18:49:38 +0200 Cc: t2trg@irtf.org, asdf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 648406178.817611-6b08af98af5e5393165bab9ec070fd52 Content-Transfer-Encoding: quoted-printable Message-Id: <0CF8AD43-67C0-4368-A600-C568A15ECBA7@tzi.org> References: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> <013301d77cbd$7d165e00$77431a00$@gmail.com> To: Wouter van der Beek X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Asdf] [T2TRG] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Tuesday 20th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 16:49:48 -0000 On 2021-07-19, at 18:45, wavdb66@gmail.com wrote: >=20 > Hi Carsten, >=20 > OCF converters are available: > https://github.com/openconnectivityfoundation/SDFtooling Thanks! I put that into today=E2=80=99s notes: https://codimd.ietf.org/hackathon-2021-t2trg-111-monday?edit Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 19 10:01:07 2021 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 6A8983A08B0; Mon, 19 Jul 2021 09:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtI3tYI0apT4; Mon, 19 Jul 2021 09:45:36 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 EE2CE3A08C5; Mon, 19 Jul 2021 09:45:35 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id d12so22808139wre.13; Mon, 19 Jul 2021 09:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=egGkLb9RrdNidFiBHF+Q4nKuvhsfoE5jlaGQxZjsEYM=; b=Uu1g9SScRKMHes7zJfx3pe6kDaFCEJQu7Sl67CXW2y4U0IgZu6Oi/JNuw6FiEvRdPj xtZWpyGeIqpwofJwCI+E2nSJ6Zg/w4YmBHSvqM7sOI4XATf650/u3bFixLyvLLEy1TC0 CZ5L9HwqG51AQ6A96lvCWWYxU+RxZiPQQ1ab5shb3tHDtehNezi8roIIMoGCswZBaHf0 T682d2sAOtMrtDLppxryTqHXf4dWjj0Dac2CQFy6vqCugZnYbmeoX6acPo9z8It3SqjA 6zlIJHoICuaf+cRU+brqJp9LTVL4fVCWEem1uMamcGbUPlJ1NQTsK3iyQtwRleIcgc/2 ELCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=egGkLb9RrdNidFiBHF+Q4nKuvhsfoE5jlaGQxZjsEYM=; b=pTu/iaShbFpVq7vkDRuwf/QebiE2fiWZO5LXvzgRPYLgrGvoUQhLrkecZC6mRpk4CD TvSvPBFi1QRooPw5wtcYi1j2pr0ZfZ64mxNxI2UEivuoQk+5upnGHb2o2cIt25FnvlAu AR/L+GSSNf088BJMcWkuumiCGB+NEf49idoKa/5AYQIlWLkA3/g9P31S/h/48SBp3je5 9S9OS/nY5roAVTdmJMorlBqZX+75vRKOXmdRUMaMjkr6HZOO6jlMnKA1XQmWFxcjT6cV 4YMF22IP4ioqnNJYti2Re4RXJqX0srpD6R2GIE3+s83JLbSvZtf9JNbXAHYtCA4HLDli TXYQ== X-Gm-Message-State: AOAM530aLlmPu64VbMCvffxAl7DiVm6eegS/OzMXmWXKsODMbFD02NT+ vKnXI0IXWy1vS7twqwENDHt0SfnBlb0= X-Google-Smtp-Source: ABdhPJxIrjDteFtZ+JveMn5yC10ZB9xLUeXQEdGzbBCjru6TlA/tKPI2pdewNztHotTnGgL3bP3T/g== X-Received: by 2002:a5d:6804:: with SMTP id w4mr30383247wru.417.1626713132729; Mon, 19 Jul 2021 09:45:32 -0700 (PDT) Received: from LAPTOPL39HIA21 ([212.129.72.197]) by smtp.gmail.com with ESMTPSA id d18sm16392311wmp.46.2021.07.19.09.45.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jul 2021 09:45:32 -0700 (PDT) From: To: "'Carsten Bormann'" , , , References: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> In-Reply-To: Date: Mon, 19 Jul 2021 17:45:30 +0100 Message-ID: <013301d77cbd$7d165e00$77431a00$@gmail.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: AQHtOduIJAdSFXJu279NI1mCuPMZawFZIsMQqxQ9lzA= Content-Language: en-ie Archived-At: X-Mailman-Approved-At: Mon, 19 Jul 2021 10:01:06 -0700 Subject: Re: [core] [Asdf] [T2TRG] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Tuesday 20th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 16:45:42 -0000 Hi Carsten, OCF converters are available: https://github.com/openconnectivityfoundation/SDFtooling Kind Regards, Wouter -----Original Message----- From: ASDF On Behalf Of Carsten Bormann Sent: Monday 19 July 2021 17:40 To: t2trg@irtf.org; asdf@ietf.org; core@ietf.org Subject: Re: [Asdf] [T2TRG] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: = Tuesday 20th 1400Z Today, we scheduled the next daily meeting for https://codimd.ietf.org/hackathon-2021-t2trg-111-tuesday start time: 2021-07-20 14:00:00 UTC max duration: 60 (We needed 45 min = today.) https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hacka= thon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210720T14&ah=3D1 https://meetings.conf.meetecho.com/interim/?short=3Dd49f0f3b-52d5-4a30-8a= 75-e2f2effec8b0 Notes from today=E2=80=99s meeting are at = https://codimd.ietf.org/hackathon-2021-t2trg-111-monday Gr=C3=BC=C3=9Fe, Carsten > On 2021-07-18, at 21:26, Carsten Bormann wrote: >=20 > For the IETF 111 hackathon, we are planning some activities that = relate to T2TRG (and its WISHI activity), ASDF, and CoRE. We are = cognizant that many will be on vacation that week, but we still want to = get some work done ahead of the IETF111 happening the following week. >=20 > We=E2=80=99ll run a kickoff at 1400Z on this Monday (today/tomorrow = depending on your timezone: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hacka= thon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210719T14&ah=3D1 ). >=20 > The main purpose is to see who is planning to do what and to set up = collaboration points. > We also want to agree on a time (approximately, but not necessarily = exactly 1400Z again) where we have a day sync call Tue to Fri; = we=E2=80=99ll announce this here, so if Monday doesn=E2=80=99t work for = you, you can chime in later. >=20 > You may want to pre-fill below=E2=80=99s CodiMD with any additional = information that might be useful for the kickoff (or during the week). = You may also want to register for the hackathon at = https://registration.ietf.org/111/new/hackathon/ . >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > # T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111 >=20 > Kickoff: Monday, 2021-07-19, 1400Z (60 min max) >=20 > Notes: https://codimd.ietf.org/hackathon-2021-t2trg-111-monday >=20 > Meetecho:=20 > = https://meetings.conf.meetecho.com/interim/?short=3D5903310f-3a8d-4f3a-9 > 3c4-5dbb1c9cb768 >=20 > Note that we will use meetecho for this meeting. > Please check whether your datatracker account works; if it = doesn=E2=80=99t, reset its password or get a new one at: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > (It is worth doing this ahead of time as there may need to be an=20 > interaction with the IETF secretariat.) >=20 > ## Areas of work >=20 > ### SDF related >=20 > * tools (e.g., sdf compact) > * definition(s) of equivalence > * converters (translations) from SDF to X, from X to SDF > * YANG (sdf-yang-converter.org) (*) > * WoT (sdf-wot-converter.org) > * IPSO/LwM2M (https://github.com/EricssonResearch/ipso-odm) > * OCF? > * Azure DTDL (*) > * curl --data-urlencode sdf@test-sdf-file.sdf.json=20 > http://wishi.nomadiclab.com:8083/odm2dtdl > * CI pipeline to keep translations up to date? >=20 > ### CoRE related >=20 > * CoRE resource directory? (*) > * CoRAL, particularly -href (CRIs) (*) >=20 > ### Others? >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg -- ASDF mailing list ASDF@ietf.org https://www.ietf.org/mailman/listinfo/asdf From nobody Mon Jul 19 19:06:05 2021 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 403D93A005C; Mon, 19 Jul 2021 19:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 3Ic1sZL7t6m9; Mon, 19 Jul 2021 19:05:53 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70072.outbound.protection.outlook.com [40.107.7.72]) (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 744A23A005B; Mon, 19 Jul 2021 19:05:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oeGXSAojM9TRxBIQe325Sd4ZPYkZVgS2kuo9VS4KzMcU+8GXJ+0ENRk9z97q/x4CprLL8rMkeeFw1jAHZRpwIwUcPFzIlLEUGL/OWbSGv2bVeKl8LitdY8QVv6xxRMukx+PFzHTEgHKFf0FO6i7CRej+qmGFb8nDm2edAE6cciMX9OKn0iDnQrWE+u+0B5TV3fPkxaU/NP7sZiJmP6bv9q9esHZbw6XXrjhOtE6DZsvtlwsRQC8q5f/rY/ASqdudImqdR5cJoOwCFKu0I9KAYRPPsyMza89taf1D3gKHpuRxZpmqwTok9OLCaluI3oXc8llExHc+RO+Fc5JlHsuPpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w07mILlPfniI4zSkBdYmLUKcovS/4IAajVatCdc9wXs=; b=LD6Z04jCDHQqPNVbuXrHxmKYypM3bbbOfy64cnTcAsWSDso6niLioUMazYe2dXtwHQeYvVVYlQaUppiSThIp2ezmshukJB6cZRzUjeq0q7VqKqvHXvDOOUHdQ36QjwqpKb6/1hsZy4LJZucLBcYHdS0RX+SyYxWfZJfw/eK2KHNCZp9VoO1kdvJHLndZrZSQmK9rD/AM2EMoS5fiHv3wnC47gxHE8QMq507vOWmebTmiE9VQ9Dn/xHtfiGtAWGbYjxDNppn3cIH9bdSogYbMFF5m4Bs8ZI/I0vRj42n/YiEKZ+WVChPFeqnpaKO/SA9E+eerEpC74l8bOBULXEFk8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w07mILlPfniI4zSkBdYmLUKcovS/4IAajVatCdc9wXs=; b=X21kvLmliWHl1Y6/rpwRJTxzbBP6bCWwFM15MGW1pZicvQZSqUt+pax5hx0XBTZmlXINNwg95e4eA62wI1ScgY+C6nBxAupNWwRyg8Y5lt8dX3a8mA8Qfz8v9x50b25zVGUZ+pTQN7oLrZWYmzlLkjPjJerc/UVnv5S2l2yI9JM= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR07MB3241.eurprd07.prod.outlook.com (2603:10a6:7:34::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.19; Tue, 20 Jul 2021 02:05:44 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::158:faff:a530:9dcd]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::158:faff:a530:9dcd%6]) with mapi id 15.20.4352.021; Tue, 20 Jul 2021 02:05:44 +0000 From: Zaheduzzaman Sarker To: Michael Richardson CC: The IESG , "draft-ietf-core-sid@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) Thread-Index: AQHXeVvjUF8GoC5m/Ei0K30WppPo/qtEUYgAgAc30QA= Date: Tue, 20 Jul 2021 02:05:43 +0000 Message-ID: References: <162634134491.20957.9891384677904460366@ietfa.amsl.com> <2247.1626371526@localhost> In-Reply-To: <2247.1626371526@localhost> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4554b2a1-3559-4612-60db-08d94b22e1f4 x-ms-traffictypediagnostic: HE1PR07MB3241: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AtHZ1PaSsFQAtSaePPzVJMxWqzDPtsvXcFODvrNkAl+NfmJNpqneQ9k6SabCTZTS733gXN9iM18IVvDqaYe3myNyBf2EIxYE2t58h48cMi1EA+6bTfy94r9zJMH8clTmEuArJnkb7L0hxipsfgiKmhLioTpejXOaA58oZjxdTVpLcjYJ9HzLczhWuHm3OYNVWTRMqJbIKVD2dQVo604DP6LlHXZlBFhoQrUDI1UgP1YMDsR5O6+Goh9IRZEeOCv6OLofrmRpxI2JHTVnrfuZ9z7bLi5/UfoUEI+trZ8rsUhc+unG+Gv+yR8poC/bTKZf+phwQShrqyootnRnoiadNwmkx13yAmJ+N92G3o3mSr0FxpVj+gtc+VdE/Gnl6tanjLx6yO+nxmqxLzKRvl0R280r8AVosHzQwWOvs8NQZ+CYRI9Cnk/xHpmLNEq+MNF/wSsZ2P04HYBgVw1W12/YJqwGMtAmeuZDc30SIQRQHHely/w8gOjNQLL2Q0d+TN+bT5jlMzOxvpYj0EeBGmrQkWVv4KmSQxM9ou7QJy3gy0kIzd3H0i19oVtXYs6DzfYXGsaJ7atwFfyeIjUFQtJfjdSRXTId0/mt+6jiXJ4MjrcvWXUjRZ5LoEV6DUva1/Br7Hqczk6UcbJOkWinlNh6loAIi+hOH9O5Hbw+U8hWN7xXTCBfI2JHLB04qyrbkn9CKM+k1JVfX5ekHq+29umhyQTeXwktLreIzsnfjwLhf3G+bvwVtvc/wWPZ4mLnj1R4 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(396003)(376002)(346002)(136003)(6486002)(44832011)(76116006)(66946007)(4326008)(91956017)(66476007)(38100700002)(122000001)(2616005)(66446008)(64756008)(66556008)(316002)(5660300002)(8676002)(54906003)(8936002)(186003)(26005)(71200400001)(36756003)(33656002)(86362001)(83380400001)(478600001)(6506007)(2906002)(6512007)(45980500001)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VGlCNUwvdHVVVDhYMUhVam0ydEQ0VlRVdkRBUms4NVF1ZlBOKy9EOFppRVYz?= =?utf-8?B?N20xM3hUWXJhZ0FnRUVSYzdGcXZjNlVtbUtFK0RjbmsyNUU1Y1g0SzFFd0ph?= =?utf-8?B?MnB4eGtnN1hvUVdWOWhhaWFwdHlGenpuOVhiV3J3M0UxY3Vla09BcXh5QVFu?= =?utf-8?B?UGFlOTM4NjEwcysyU09mT3VzaXdib0VGTjJRcXdOL2hoeXNXR3hFOUdZVDJ5?= =?utf-8?B?dlpwVUEyeWNiTU1uYnNKQVIzeUY0OHFCdVZoRE51NkFKVkUrcTM1bE9PYWRs?= =?utf-8?B?Z0xodklvVG9GQWovMnNwTWRtbzZwY0tSV3VmSHFUdVFVQVVTenYva1daaWxm?= =?utf-8?B?K3Z1MnpWUytPZVI0dTVKRXRRWGU0YmlXd0tYVkJEcVlpam8wUlY1dW5xaHNh?= =?utf-8?B?Z0k0ci9UVkFhNkRGZzJzWHB2NmZJcUdKVEFDVlFmbmg0dEp1K2h6b0hZVGI5?= =?utf-8?B?MC9mbHpvRCt4RHVIb2x4eXJ6Rk5YQVZ0K1NGQm5WRlArRnJYamNzMEZYM1lX?= =?utf-8?B?dGttRy85aHp1eEVrNnM5RkhkYzVNMERLMWZvQ05jcWFZdVE5VnZMMmphaWtR?= =?utf-8?B?QzV6b1ZCdnFJUmxOMTljK0RyWFpUNi9GZytFNERRYXZENHlUeTNBRmM2S0p5?= =?utf-8?B?LzhnNXgwVndjTWhjUThOdmcrRmEycTg5UkFYYlk5M0V0RlVCQnpUNzZEUWlp?= =?utf-8?B?Z3kyaktGVE1jOUpsb0NxL2poMXhvTUpGMXBoQkZORy9XOFhvTVRZMnIveWUr?= =?utf-8?B?cU9OWHNJWVNBU0FHTGZpbkdEWXcyalFla3d5RlRHRmVFbFlOMG5HWmFaaGZG?= =?utf-8?B?VVM2elFXYVI0eFRZOTZaT2x0Z3p1N1BvMWNEQkptaWxZcjFrdVJjTFZJL2pw?= =?utf-8?B?OWUrRXVEOFhaQTQxYXFOb1daUWJVTUVBK2MrcTdsblF5MjJ5U2d5Z3E5ZWhV?= =?utf-8?B?dGx4dTZyVmVGQ04wekhnVTFQdUdtMmFNaThUQ2EwQkYxa2grbFNQV3BvMStG?= =?utf-8?B?VitFNmxOSG1YcW9JWjR1QnNpUmFPbGM5WU4wNldTRHdpdVdFbjc5ejlvaXJy?= =?utf-8?B?QkdrTTJWeWxXOURNdTNtU0FHZldGT1g2NjIwcVk4ai9mN2UwUmc3aTZUREM4?= =?utf-8?B?Smkwc3hRbEtyZGc2bEFYTWJJdXFnYStGSVpDN3U1Wk44VGgyNHh1WSs2NzVi?= =?utf-8?B?eHN3RUplNFl3OHdVUHRaTFhrU1hkaHNRMzcvK1BpblkyekZVNnp2UFA4eGFu?= =?utf-8?B?aWFPK1FtaGF1Z0pYemJnTTZqdWhkbkEvWStkZ1p5ZmpCOWZqa1MycVJwMTJZ?= =?utf-8?B?MlVLYmthMzREWGtGbkF6N2FZQTc4UDlDMTRFSUh0eGNMZjRPdzlyWTlrV21k?= =?utf-8?B?NkMwV3JPRUxHQjVZNXJCV09kNmF6cE8rSnNkTEJEbjQyeUFDYitvK0s4SVEx?= =?utf-8?B?Nkdhbmhzc1JQZ05JR2ZMcnM0Mys2d0NaYnBtL0pDNjA5cnRJL2JmZ213ckJK?= =?utf-8?B?WkpmWFRvNkM5alpEUVNUc1JmcjUyaGlQZzUrbUhTbk1BTzdiMVNuSjFjSlVI?= =?utf-8?B?NGFlWk5RNW1rQVpXcHYyMjhYNmdZVGFnMFRobUpCa1A5MThlbUR6c0Mydloy?= =?utf-8?B?SlRUZCtHenJkSkc0SlNLalVzMjA4dXpoM1A2SlRTQTRmUVpiaTJ6OGUzZTJB?= =?utf-8?B?Q2R3Z0Y2VEI0Tmtoaks0bnFScHBmS25DdGxLSC85NWhkd3Z3QSszeFJHbkM1?= =?utf-8?B?S3NOd2dXd3MvYkdYbWYrOWt3TXVnQks4aFd1WjVaZzA5N21nc1JxVmcwZmc0?= =?utf-8?B?TFhEa0plRTFOeFRiOHA1Zz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4554b2a1-3559-4612-60db-08d94b22e1f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2021 02:05:44.0257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aHMV93xXnRZhuTAoibj/RnRmrCO1vVVZS4b6a+xXvDvv9tI31zDnavZpncgoeUUfBw3NKCcuMEzK0PlMTkEKRgSFQS7dSqXBoCNAimBSdIOhiQxtgK0/D/D5eCsEtkjn X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3241 Archived-At: Subject: Re: [core] Zaheduzzaman Sarker's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 02:06:00 -0000 DQoNCu+7v09uIDIwMjEtMDctMTUsIDIzOjUyLCAiTWljaGFlbCBSaWNoYXJkc29uIiA8bWNyK2ll dGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCg0KICAgIFphaGVkdXp6YW1hbiBTYXJrZXIgdmlhIERh dGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCiAgICAgICAgPiAqU2VjdGlvbiAz IDogc2F5cyAtDQoNCiAgICAgICAgPiAiVGhlIGNyZWF0aW9uIG9mIHRoaXMgbmV3IHZlcnNpb24g b2YgdGhlICIuc2lkIiBmaWxlDQogICAgICAgID4gU0hPVUxEIGJlIHBlcmZvcm1lZCB1c2luZyBh biBhdXRvbWF0ZWQgdG9vbCINCg0KICAgICAgICA+IElmIHRoaXMgaXMgc3VwcG9zZWQgdG8gYmUg dGhlIGF1dG9tYXRpb24gcHJvY2VzcyB3cml0dGVuIGluIGFwcGVuZGl4IEIgdGhlbg0KICAgICAg ICA+IHB1dHRpbmcgYSByZWZlcmVuY2UgaGVyZSBtYWtlcyBzZW5zZS4gSWYgbm90LCB0aGVuIGFz IHRoaXMgaXMgdmVyeSBpbXBvcnRhbnQNCiAgICAgICAgPiB0b29sLCBtb3JlIGluZm9ybWF0aW9u IG5lZWQgdG8gYmUgYWRkZWQgaGVyZSBpbiB0aGlzIHNwZWNpZmljYXRpb24gKGxpa2UsDQogICAg ICAgID4gd2hlcmUgdG8gZmluZCBpdCwgd2hvIGNyZWF0ZSBhbmQgbWFpbnRhaW5zIGl0LCBhbnkg cmVmZXJlbmNlIHRvIHN1Y2ggYW4NCiAgICAgICAgPiBleGlzdGluZyB0b29scykuIEFsc28gSSBh bSBtaXNzaW5nIHdoYXQgY29uc2VxdWVuY2VzIG9uZSBuZWVkIHRvIGNvbnNpZGVyIGlmDQogICAg ICAgID4gdGhlIHByb2Nlc3MgaXMgbm90IGF1dG9tYXRlZC4gSWYgdGhpcyBpcyBzYW1lIGFzIHdy aXR0ZW4gaW4gdGhlDQogICAgICAgID4gaW50cm9kdWN0aW9uIC0NCg0KICAgIGl0J3MgaW4gcHlh bmcgMi4xIHNpbmNlIGxhdGUgMjAxOS4NCiAgICBJIGRvbid0IGtub3cgd2hhdCB0aGUgY3VycmVu dCBwcmFjdGljZSB0b3dhcmRzIHJlZmVyZW5jaW5nIHB5YW5nLg0KDQpJIHRoaW5rIGEgc2hvcnQg ZGVzY3JpcHRpb24gb2YgdGhlIHRvb2wgIChtYXkgYmUgc2hvdWxkIGdvIGluIGFzIGFuIGFwcGVu ZGl4IGluIHRoZSBkb2MgKSBhbmQgYSB1cmwgcmVmZXJlbmNlIHRvIHB5YW5nMi4xIHdpbGwgZG8g dGhlIGpvYiBoZXJlLg0KDQogICAgICAgID4gIkFzc2lnbm1lbnQgb2YgU0lEcyB0byBZQU5HIGl0 ZW1zIGNhbiBiZSBhdXRvbWF0ZWQuICBGb3IgbW9yZSBkZXRhaWxzDQogICAgICAgID4gaG93IHRo aXMgY2FuIGJlIGFjaGlldmVkLCBwbGVhc2UgY29uc3VsdCBBcHBlbmRpeCBCLiINCg0KICAgICAg ICA+IFRoZW4gd2UgaGF2ZSB0d28ga2luZCBvZiBpbnN0cnVjdGlvbnMgZm9yIHRoZSBzYW1lIHRo aW5nIC0gImNhbiBiZSIgYW5kIGENCiAgICAgICAgPiBub3JtYXRpdmUgIlNIT1VMRCIuIEhlbmNl IGl0IG5lZWQgdG8gYmUgY2xhcmlmaWVkIHdoaWNoIG9uZSBzaG91bGQgcHJldmFpbC4NCg0KICAg IEdvb2QgcG9pbnQuDQoNCiAgICAgICAgPj4gbWF4aW11bSBTSUQgcmFuZ2Ugc2l6ZSBpcyAxMDAw LiAgQSBsYXJnZXIgc2l6ZSBtYXkgYmUgcmVxdWVzdGVkIGJ5DQogICAgICAgID4+IHRoZSBhdXRo b3JzIGlmIHRoaXMgcmVjb21tZW5kYXRpb24gaXMgY29uc2lkZXJlZCBpbnN1ZmZpY2llbnQuICBJ dCBpcw0KICAgICAgICA+PiBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGFuIGFkZGl0aW9uYWwgU0lE IHJhbmdlIGNhbiBiZSBhbGxvY2F0ZWQgdG8gYW4NCiAgICAgICAgPj4gZXhpc3RpbmcgWUFORyBt b2R1bGUgaWYgdGhlIGluaXRpYWwgcmFuZ2UgaXMgZXhoYXVzdGVkLiINCg0KICAgICAgICA+IEkg aGF2ZSBoYXJkIHRpbWUgdW5kZXJzdGFuZGluZyB0aGUgbWVudGlvbmluZyBvZiB0aGUgbWF4aW11 bSBTSUQgcmFuZ2UgaGVyZS4NCiAgICAgICAgPiBkb2VzIHRoaXMgbWVhbiB0aGlzIGRvY3VtZW50 IHNldHMgdGhlIG1heGltdW0gcmFuZ2UgdG8gMTAwMCBidXQgb3RoZXJzIGNhbg0KICAgICAgICA+ IGhhdmUgbW9yZT8gcGxlYXNlIGNsYXJpZnkuDQoNCiAgICBFYWNoIG9mIG15IEFOSU1BIG1vZHVs ZXMgdXNlcyBhcm91bmQgMTUgU0lEIHZhbHVlcyBmcm9tIGEgcmFuZ2Ugb2YgNTAuDQogICAgKHRo YXQncyBkcmFmdC1pZXRmLWFuaW1hLWNvbnN0cmFpbmVkLXZvdWNoZXIsIHdoaWNoIGlzIGFtb25n IHRoZSBmaXJzdCB1c2VycykNCg0KICAgIEkgdGhpbmsgdGhhdCBpZiB5b3Ugd3JpdGUgYSBtb2R1 bGUgdGhhdCByZXF1aXJlcyBtb3JlIHRoYW4gMTAwMCBTSUQgdmFsdWVzDQogICAgdGhhdCB5b3Ug bWlnaHQgYmUgZG9pbmcgc29tZXRoaW5nIHdyb25nLCBhbmQgc28gbW9yZSBjb25zdWx0YXRpb24g aXMNCiAgICB3YXJyYW50ZWQuDQoNCldlbGwgSSBkb24ndCBnZXQgdGhlIHdhcnJhbnRlZCBpbiB0 aGUgZG9jdW1lbnQgYXMgY2xlYXIgYXMgeW91IHdyb3RlIGhlcmUuICBXb3VsZCBiZSBnb29kIHRv IG1ha2UgaXQgY2xlYXIgaW4gdGhlIGRvY3VtZW50Lg0KDQpCUg0KDQpaYWhlZA0KDQo= From nobody Tue Jul 20 06:39:26 2021 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 1E0743A230F; Tue, 20 Jul 2021 06:39:21 -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, SPF_HELO_NONE=0.001, 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 f7MMQZcPX3qq; Tue, 20 Jul 2021 06:39:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7463A230D; Tue, 20 Jul 2021 06:39:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AFE938991; Tue, 20 Jul 2021 09:42:32 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TOQj9yZuOTym; Tue, 20 Jul 2021 09:42:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 474643899E; Tue, 20 Jul 2021 09:42:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 89A201F1; Tue, 20 Jul 2021 09:39:09 -0400 (EDT) From: Michael Richardson To: anima@ietf.org CC: core@ietf.org In-Reply-To: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 13:39:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It was said in a private exchange: > There is no CoAP resource at the root / hence the 4.04. (Only the > MASA has a test HTTP resource at / ) I thought, what we need is a CoAP Ping/echo. And I remembered: https://www.ietf.org/archive/id/draft-ietf-core-echo-request-tag-13.html#= section-2.2 but, this is for the server to validate that the client is really there. Should we recommend that Registrar put something at / that produces a 2.00? (lowercase recommend) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD20f0ACgkQgItw+93Q 3WVuMwgAqJpSFem1+mskrIlNGu2KXT2UZp+nVmsSrc8ZrXPh2akJVcSPXar0K0xB YFJPHMQcSW2mbafBT7ZftvwTNUgZ2bFpNnzeJtoYOCJj9+59slD1BCqsJj4IBpVs UsEZnHbXgFHvTQV+RQbAA63V6FQfR5YOkn7tFBaDJ/Ta+2ujbQdu/A1q4hp4dsIH mEjOhWfrwuVrq40GVyDW1EsNS6jsTKkpGxbKBoAo/wzdnaGOIj/upeV1JmglorBG Zqq2NUsPiFa5N1L4JwF/II6MMxQLwqWYKrzCopk7fr1XddqJjijCPkBQ001QkVQS FzU5qw9G4opjLyK7cGvP92Vz6dsKDQ== =Ndj6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 21 00:48:38 2021 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 C67B43A0878; Wed, 21 Jul 2021 00:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=iotconsultancy.nl 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 Su0Y9tVKeEXt; Wed, 21 Jul 2021 00:48:28 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20097.outbound.protection.outlook.com [40.107.2.97]) (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 8BE2D3A0875; Wed, 21 Jul 2021 00:48:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f+q/QnswvDyWAeVGcKohK0BJgL7f6kqDSSb3iYa9oie3E0GApmDAIFma2Gw3J89CnF0PaG/gYpEWLggZi2KfKop/gmMw23LFk2j9k7MGusXXH3KJ2hH70/Rk6o2FL1UqSsof3CYLMS3u3Av26Tp29h1x+gR2Q8qy6evLAGv8t0TzVjxTMWc5S7yDbhYgHqABUYyyffax4FcquWQ3Ng/KWlA+6DCYNnukXl5C+xczbG87gkLTjIe1wMQutIHulCzZXARjmiNWSvEYkg3IuqxaSUxpCDmyD7gcPDga0+J7PssrrrPGGNo++Li02DoJ2S0LGs54+J5bF8t1PYF+AT+fLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BLDVFUEst6UlTFlbvaTD6iGfDsyMJ1asy9hSkQLCKzU=; b=D/yTA4tn40HXpM+OvBfDP/JU9dR4kxSTZpMHtK7/c3Cyt5ST07uQ3fJcEqy+9G7oaTF2+p5X4TbJdIvfzYTTAEyIjC6bvD/Zh5e9soY1ADm1iqidnFIK7EKR1NNTOWJ0GzkSFsvxXkxVa7PqvoK+cc85vdDReUJX/tfT8NktkDxBj/c5fyTXRwpyxmAY0CGqLCe8a7N6sSzXCgBoSqxHVvS1g2Sgvc0O8vq1qsJCKpP+XVIhGinRcJFPxxkktLxV5CHbmQG6Tt6XTVxp/kMHphBnJJ+GMA2P0k5fWv0qN2aVnIkO1JdujeWhe7Z4CPe/cg0yEji1cVrF1GJlAZG0Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BLDVFUEst6UlTFlbvaTD6iGfDsyMJ1asy9hSkQLCKzU=; b=hQiim8/w5LgE2ENDqn7gCshK3LlDpfpQYTTbpllzItugFmCN/fBD4ab1/y+/4gNH5x4a1wS4bovmff8M1WXHvymMfzMHM5xp/plY99BQt5jCgYIkeyzmJV8k6bopOVRFnpsJscSrbS4+vxdf5wTLHw7xhQqDXmvjdRijf932Rnc= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1028.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:268::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.25; Wed, 21 Jul 2021 07:48:24 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::adb7:fe6:5106:a8b9]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::adb7:fe6:5106:a8b9%9]) with mapi id 15.20.4331.034; Wed, 21 Jul 2021 07:48:24 +0000 From: Esko Dijk To: Michael Richardson , "anima@ietf.org" CC: "core@ietf.org" Thread-Topic: [Anima] constrained resources at root for debugging connectivity Thread-Index: AQHXfWyxp2MaVB//mEmr+125ENTtbKtNDUMw Date: Wed, 21 Jul 2021 07:48:24 +0000 Message-ID: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> In-Reply-To: <18975.1626788349@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d417a481-9db4-4ce0-80b2-08d94c1beb68 x-ms-traffictypediagnostic: AM9P190MB1028: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: saBwCFXKnORqwbKN7TmWnT0RodzQ5MEOVL4c2RzScsnWeXR5O27WyI66SZpBoGMDegjvZGz8AyU/hsupPtVkXjId/HbYlVGBKwcyb8UfurNEK5NCsZ4ymfewwU0KP8tKnBafD+g47zkPiriwgucBbG3WJ+EWu5wZyqeCqHpkKt7iP2t2LYzs+kiKMZTCinoLtcgCtBAK6gLnW3lNbJRtwAlAEyhNnHtMlHtKSi9/YqTLvmU3ypTTxA+ON2fnN/6NLSHa7i/yWrilc0vevxTtUrjtAHQAoLg0AooXaXK+Z8kFMz5giRhQ/23iw83s9Wyzox9+FhU0lbi39y7VSnsAM2S9LE+mvKSLFb75DrBNyj4Q4zG6arEtnZKZ/Fn8JVQlmPWRQlhZe9IogOcs4GaAFV3wjOfxRA7GJMElq4svcs0ScoHNL2XFiznr7sjss6jL3LFQNj/mbHnp0ZCMBSBvyY49b3K5/mwkwCUpJXzecCMzzn20+R4Qqr8dYASccL5LNekKR2X/GakdSilGJcNL33D7lF12UYUB1Y4dmMRtXjABSkTh/nPvJxfkw+JLfDG2GkRJhzBineOEan1vzdZ3uv9G+f39HeMm3l9UTt1bgxt5cj5VrpembyPCy3PXv2njFzFbcUjaf6xJQVtDQCAHZBSpPCan5hc3YSq4cE4f0zBmpwrT0meX6FkllgnI034PlsSBwYYvGEYJQOiP/x84nGBNsJVZwW0KcOZckVh9B9IST6TWCEL6aPJsmA65rGVgEeqdg8B1eoEya7bHkV0LK5FmZKc51A3vzsaePq8Ks9c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(376002)(39830400003)(136003)(66446008)(5660300002)(76116006)(86362001)(8936002)(66476007)(38100700002)(6506007)(122000001)(66946007)(966005)(52536014)(66574015)(4326008)(66556008)(64756008)(71200400001)(53546011)(7696005)(44832011)(8676002)(33656002)(2906002)(83380400001)(55016002)(186003)(110136005)(9686003)(478600001)(316002)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?THJmbm9kQ1VXcm1NVmJQTU1JMmcyYlRPNGhCSFZ6V25CYVpIY2JialFPenky?= =?utf-8?B?K1pRdEZ3eHdob0tJTGRldUNNb0tSRUZWWHBUa1h4UnJXZXd3cXNlR0xuMXQz?= =?utf-8?B?RkJhM1lzUzdJVTE4d3dCSDNOT0FlTEhEc2ovUENwNUV4VGdXbkliZWhtc0Nl?= =?utf-8?B?L0xmbGlZSnJUbWttWkVTWUhvZVc5OUxEWGhMUXpHNjJ6RVVQNE5YQnFUb2pr?= =?utf-8?B?dGNnZFhmcHBDWTlmN2ZKK0ZpODRKcGFHMmtMeHRqWnRaRURSZUVtekJReU1q?= =?utf-8?B?ZGw3blJMbyt1c1l6MGxLQVQyd0pnY2xTYnZLeDVwbllsSThSYmhEM0tqditB?= =?utf-8?B?R0M1M0o3Wk1TK2hHTTVFems4VDFGaUJHZHA4aVIrNEVCQzRJZWRMb0V0cThK?= =?utf-8?B?ZVlxUW0vZlo5MkV0MzB1UXl3LzFydGdVd2JzUytoK0F4OHJEa3Q5anRubjlq?= =?utf-8?B?cnNaMU12amZLZU1vU0tDMWx2dEN1T0lnSzdBc2lFMFpPdUVwTUdUMXp4aWlK?= =?utf-8?B?ZEthKzVpQThOOVlLSXZMdmVlWnJZcjRacGJFcWJ2TGdhamlBQTVadEM4Sm5X?= =?utf-8?B?ZVgvcHluQlJGY08xZHRMQnUvN1Rxc1pMS3pjQU4vY29xUlRBWEQ1Z1M0Qi8x?= =?utf-8?B?R1I0NkVxbFFEQ1p6blI3K2NLUmxVano3WldMeWZTQUJiaVZicnNKQnlNQTZG?= =?utf-8?B?YVFRZVZveDNqdkFPRk82ZERqeDJaeGFYL2xiREFycFBlRnVTWXJ4Q1ZUWC9H?= =?utf-8?B?VUpkeVU1YUxjWWdaRU5LbVpaY0J5Q20zUWdDY0JzUkdkdHN5Zm8xNzRuSDB6?= =?utf-8?B?MFNzSjZRcWFaV3lMWXhNR3Z5KzROZG1yYndVOVdnVURjYW1OYXpmekxxemZh?= =?utf-8?B?b29nTEtxSGtPTlRBR09IdDNKZWtzTVZGT2J3bDFCSXM4a0dna3M1aDBLNlNo?= =?utf-8?B?THY1QTU4M25Ib0xSWnhhRlNiZTFqYjN2K0kyMzhldlN4cE5nRERLb3NkS3Bx?= =?utf-8?B?M3R4eHBsL2QvTEIxQUVRWUpyQ1hTaHp3WEp4QTV3NjB1WVBJeHFkNzZMWXhP?= =?utf-8?B?UTk5MDU1dDdyT2hseHA1TlJnZkV3OERRQVlabVpsMXlFZ243bmhyaCt3TVg4?= =?utf-8?B?Y0N3T2RXaUFkVjNBVTdRQjV6bzFOOWpNQ01xMGZudm00NkhHU0oxSEJMV0NJ?= =?utf-8?B?STY1bkpmSjMyNnFlanJqYVAwVS85anlucG5Kc3FIWDRjUDc5Z1UrSEZzVXZv?= =?utf-8?B?Y3crQzRLbTZoOHNZellTNnRiQlJlYmxySlI3UldyeCtBNnRWVERONWE2eVRm?= =?utf-8?B?ODVoWU5rcnNzT2RCOStlMFZHQ0tOTElaWkdqS0hZSC9Hb2ZXYkpzSWk3ei9Q?= =?utf-8?B?SDQ1LzM1d01Ja2l1Wnl0ZGt3cHJMa2RrOFFqekF4djhoaEVaN1N0R3RRdkZy?= =?utf-8?B?WG5tc0JyRUVSYnViZDhaOHppM0FlSG5WaWRwdmVFTDl2THJ2cDRHRXlBbGxv?= =?utf-8?B?anRtTGJRYVo3VTlES1BWRzIzcFFqRWRkdkdZY0srWDF3UnVYNFJpV1gvL2ww?= =?utf-8?B?QXpNdm1SQ3Z4eWQ1NFlxdG1POGFTNGVOQzJaQ0NYMGNya1RQV29TQ3c1ZEVm?= =?utf-8?B?cnJ0VDZkRHl4MEI4OFVBWkd0RCtwT0pCMHVYYkFqZ3FnZlN4NVBSQkdhd20v?= =?utf-8?B?b2RZUjViWmtpYVc2WkRiOHVrcGluZ0treGR4OTBNWHpaTVBVUVFxUkRwNW9T?= =?utf-8?B?WG1Wc25TcXVWZ2R0b0xlcGRNbkVoMCtMeUJ5WWx5a3cxV3JFTGRWSlFWaHM0?= =?utf-8?B?d282d1VJdERyZnNwTDd3eXZ0REgrZ2R5R1k4VnptUDBVUjdOT1c5T3A0Mjlo?= =?utf-8?Q?z3V7m+JP9r/ao?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d417a481-9db4-4ce0-80b2-08d94c1beb68 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 07:48:24.6221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SR8Uxko+cjV+CU9sObUVDuIdsXnT0gSuHkabQT/qAky/5M57pl6E/eLTJCmP+YAXPpThtUdRJ2IQDEuTH6rTxZgmqC0KdmCpXc4TkvTeHwI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1028 Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 07:48:34 -0000 SGksDQoNClRoZXJlIGlzIGFscmVhZHkgYSAiQ29BUCBwaW5nIiBkZXNjcmliZWQgaW4gUkZDIDcy NTIgdGhhdCBjYW4gYmUgdXNlZC4gSXQgZG9lcyBub3QgYWNjZXNzIGFueSByZXNvdXJjZSwganVz dCB0aGUgQ29BUCBzZXJ2ZXIgZW5kcG9pbnQgYXQgQ29BUCBtZXNzYWdlIGxheWVyLiBBcyBhIHNp ZGUgZWZmZWN0IG9mIHRoaXMgcGluZyB5b3VyIERUTFMgc3RhY2sgd2lsbCBzZXQgdXAgdGhlIGNv bm5lY3Rpb24gd2hpY2ggaXMgaGFuZHkuDQoNClNvIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBhIHJl c291cmNlIGF0IC8gdGhhdCBwcm9kdWNlcyAyLjA1ICwgdGhpcyBpcyBmb3IgdGhlIG1haW50YWlu ZXIgb2YgdGhlIHNlcnZlciB0byBkZWNpZGUgaG93IHRvIGFsbG9jYXRlIHRoYXQgcmVzb3VyY2Ug c3BhY2UuDQpCZXNpZGVzIHdlIGhhdmUgYWxyZWFkeSBkZWZpbmVkIHNvbWUgd2VsbC1rbm93biBy ZXNvdXJjZXMgYWNjZXNzaWJsZSB3aXRoIEdFVCAoIGluIGNvcmUvZXN0L2Jyc2tpKSB0aGF0IHRo ZSBjbGllbnQgY291bGQgbWFrZSB1c2Ugb2YgdG8gdGVzdCBjb25uZWN0aXZpdHkuDQoNCkV2ZW4g YSBub24tZXhpc3RpbmcgcmVzb3VyY2UgaW4gdGhlIC8ud2VsbC1rbm93bi9YIHNwYWNlIGNvdWxk IGJlIHVzZWQganVzdCB0byBnZXQgYSA0LjA0IHdoaWNoIGNvbmZpcm1zIHRoZSBzZXJ2ZXIgaXMg d29ya2luZyBwcm9wZXJseS4gVGhpcyBpcyBldmVuIGJldHRlciB0aGF0IHRyeWluZyB0byBHRVQg YSByZXNvdXJjZSBvZiB3aG8ga25vd3MgaG93IGxhcmdlIHNpemUuDQoNCkVza28NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFuaW1hIDxhbmltYS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiBUdWVzZGF5LCBKdWx5IDIw LCAyMDIxIDE1OjM5DQpUbzogYW5pbWFAaWV0Zi5vcmcNCkNjOiBjb3JlQGlldGYub3JnDQpTdWJq ZWN0OiBbQW5pbWFdIGNvbnN0cmFpbmVkIHJlc291cmNlcyBhdCByb290IGZvciBkZWJ1Z2dpbmcg Y29ubmVjdGl2aXR5DQoNCg0KSXQgd2FzIHNhaWQgaW4gYSBwcml2YXRlIGV4Y2hhbmdlOg0KICAg ID4gVGhlcmUgaXMgbm8gQ29BUCByZXNvdXJjZSBhdCB0aGUgcm9vdCAvICBoZW5jZSB0aGUgNC4w NC4gIChPbmx5IHRoZQ0KICAgID4gTUFTQSBoYXMgYSB0ZXN0IEhUVFAgcmVzb3VyY2UgYXQgLyAp DQoNCkkgdGhvdWdodCwgd2hhdCB3ZSBuZWVkIGlzIGEgQ29BUCBQaW5nL2VjaG8uDQpBbmQgSSBy ZW1lbWJlcmVkOg0KICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYt Y29yZS1lY2hvLXJlcXVlc3QtdGFnLTEzLmh0bWwjc2VjdGlvbi0yLjINCg0KYnV0LCB0aGlzIGlz IGZvciB0aGUgc2VydmVyIHRvIHZhbGlkYXRlIHRoYXQgdGhlIGNsaWVudCBpcyByZWFsbHkgdGhl cmUuDQoNClNob3VsZCB3ZSByZWNvbW1lbmQgdGhhdCBSZWdpc3RyYXIgcHV0IHNvbWV0aGluZyBh dCAvIHRoYXQgcHJvZHVjZXMgYSAyLjAwPw0KKGxvd2VyY2FzZSByZWNvbW1lbmQpDQoNCi0tDQpN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4gICAuIG8gTyAoIElQdjYg ScO4VCBjb25zdWx0aW5nICkNCiAgICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIElu YywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCg0KDQoNCg0K From nobody Wed Jul 21 05:34:15 2021 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 81CD63A1441; Wed, 21 Jul 2021 05:34:09 -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, SPF_HELO_NONE=0.001, 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 2QqToFAbjJpH; Wed, 21 Jul 2021 05:34:06 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCE03A143E; Wed, 21 Jul 2021 05:34:06 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVFPm01p0z31MN; Wed, 21 Jul 2021 14:34:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 21 Jul 2021 14:34:03 +0200 X-Mao-Original-Outgoing-Id: 648563643.663488-ec9dc16847dadf16225f0ec6858d5dc3 Content-Transfer-Encoding: quoted-printable Message-Id: <074D2AD7-BA13-41ED-8C9C-2145036C89CF@tzi.org> References: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> To: t2trg@irtf.org, asdf@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Asdf] [T2TRG] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Tuesday 20th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 12:34:10 -0000 =E2=80=A6 and today=E2=80=99s meeting is at https://codimd.ietf.org/hackathon-2021-t2trg-111-wednesday start time: 2021-07-21 14:00:00 UTC max duration: 60 = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hackat= hon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210721T14&ah=3D1 = https://meetings.conf.meetecho.com/interim/?short=3D757a6832-77c3-43e6-8d0= 6-a980949ea7dd Notes from yesterday=E2=80=99s meeting are at = https://codimd.ietf.org/hackathon-2021-t2trg-111-tuesday See you in 90 min... Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 21 12:36:39 2021 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 013013A2694; Wed, 21 Jul 2021 12:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 amvgCUy8WEzw; Wed, 21 Jul 2021 12:36:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158013A2692; Wed, 21 Jul 2021 12:36:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 87BFE389FC; Wed, 21 Jul 2021 15:39:47 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9h8GnRfpkx2u; Wed, 21 Jul 2021 15:39:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF8A7389FB; Wed, 21 Jul 2021 15:39:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9049154A; Wed, 21 Jul 2021 15:36:18 -0400 (EDT) From: Michael Richardson To: Esko Dijk , "anima\@ietf.org" , "core\@ietf.org" In-Reply-To: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 19:36:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Esko Dijk wrote: > There is already a "CoAP ping" described in RFC 7252 that can be > used. It does not access any resource, just the CoAP server endpoint = at > CoAP message layer. As a side effect of this ping your DTLS stack will > set up the connection which is handy. I recalled that later in the day that CoAP "ping" is not connected to CoAP "echo" :-) I think that there is also potentially a need for a way to debug possible M= TU issues. Is there a way to use Olaf's "coap-client" to do the ping? I don't see an option, and it also doesn't seem to be commonly built with D= TLS. We also have the issue of CCM8 vs OpenSSL that I thought got solved, but it appears that it has not been, so one needs a tool built with mbedtls or wol= fSSL. > So I don't think we need a resource at / that produces 2.05 , this is > for the maintainer of the server to decide how to allocate that > resource space. > Besides we have already defined some well-known resources accessible > with GET ( in core/est/brski) that the client could make use of to te= st > connectivity. > Even a non-existing resource in the /.well-known/X space could be used > just to get a 4.04 which confirms the server is working properly. This > is even better that trying to GET a resource of who knows how large > size. BTW, I've changed my /version.json so that it now looks for and returns the client certificate that it saw: curl --cert spec/files/product/00-D0-E5-02-00-2E/device.crt --key spec/files/product/00-D0-E5-02-00-2E/key.pem https://masa.honeydukes.sandelman.ca/version.json =2D> {"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453d7784d3","H= ostname":"masa.honeydukes.sandelman.ca","client_certificate":"-----BEGIN CE= RTIFICATE-----\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZP= yLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry\ndW= 5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\nMBwxGjAYBgN= VBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEey+I0TtI= hm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjkiPVnhoCosUB= pTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0TBAIwADArBg= NVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkrBgEEAYLuUgI= EHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpADBmAjEAuEwT= KPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/AjEAnRjH2R0T\= n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-----END CERTIFI= CATE-----\n"} =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD4dzIACgkQgItw+93Q 3WXSBAf+P/9qV2cPQneWrUA3ic+WLvWk6B9kyyBnyxpJp68+w3rGk6H9DmF9tSOQ SxPOy6ZNHxWvqqeqGc2EcSPZoc+kRjbAO+5G/kwhZL80bMu1msAZwAPQcRs0j0eS O7fjcFXD2ATpfdLLDhDjRJHizBhN2YymC6YYBixGcrE2bjFNnnHxCitzfkxD391W gz4dkxC/qMM+QbUrGd+rXGEG3Ae55ZNIHBAmVCL/uBVZiG6XEw7JJ8RkndfSxb0+ kkv9PgemCXrumNNGpNEopwKc5v652+32xoTyFzFFfgkLlkzZlFhEg3mQhvhJwKVh Vv9eYDcgIELehh2n3D/DlbOdu1///g== =jisa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 21 23:56:09 2021 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 B88883A3B3A; Wed, 21 Jul 2021 23:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=bbhmail.nl 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 jwKue5GPyDWa; Wed, 21 Jul 2021 23:55:58 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0A23A3B36; Wed, 21 Jul 2021 23:55:57 -0700 (PDT) Received: from omf06.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id ED987100E7B49; Thu, 22 Jul 2021 06:55:55 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA id 9631C2448BC; Thu, 22 Jul 2021 06:55:55 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 22 Jul 2021 08:55:55 +0200 From: Peter van der Stok To: Michael Richardson Cc: Esko Dijk , anima@ietf.org, core@ietf.org Reply-To: stokcons@bbhmail.nl In-Reply-To: <25674.1626896178@localhost> References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_31766e53aceb2e8260c9d0050e54d310" X-Rspamd-Server: rspamout04 X-Rspamd-Queue-Id: 9631C2448BC X-Stat-Signature: s47kt4u4icw57dk6g4rqm5wuougs79tt X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX18uT3dgqVi8mx+HNBWRnfSrWmx9arg1dnU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=gldsS7ap+HlHmaWWs1mXHAWfxt/WimEvxfKtaiVW1sw=; b=KPZT+IUoSOcwGgqx1exBscq09Tm2gGnlsTvc3TcJr+pdrpYUSxtGI9Q9/n17JDvvcs0ZPGNEUTKbqyW/4TuCaQBwgcKKbQ92Qe0pc8RC0I0JyVsuoSpUf56KaBh787/HUTmZYEjpOwKwDTeiuMFdP+YocDYM+DgQOFr3odXRAiI= X-HE-Tag: 1626936955-288880 Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 06:56:04 -0000 --=_31766e53aceb2e8260c9d0050e54d310 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Is there a way to use Olaf's "coap-client" to do the ping? I don't see an option, and it also doesn't seem to be commonly built with DTLS. No, I have a three lines of code for doing a ping, from pledge; not from coap_client Peter Michael Richardson schreef op 2021-07-21 21:36: > Esko Dijk wrote: >> There is already a "CoAP ping" described in RFC 7252 that can be >> used. It does not access any resource, just the CoAP server endpoint >> at >> CoAP message layer. As a side effect of this ping your DTLS stack will >> set up the connection which is handy. > > I recalled that later in the day that CoAP "ping" is not connected to > CoAP > "echo" :-) > I think that there is also potentially a need for a way to debug > possible MTU > issues. > Is there a way to use Olaf's "coap-client" to do the ping? > I don't see an option, and it also doesn't seem to be commonly built > with DTLS. > We also have the issue of CCM8 vs OpenSSL that I thought got solved, > but it > appears that it has not been, so one needs a tool built with mbedtls or > wolfSSL. > >> So I don't think we need a resource at / that produces 2.05 , this is >> for the maintainer of the server to decide how to allocate that >> resource space. > >> Besides we have already defined some well-known resources accessible >> with GET ( in core/est/brski) that the client could make use of to >> test >> connectivity. > >> Even a non-existing resource in the /.well-known/X space could be used >> just to get a 4.04 which confirms the server is working properly. This >> is even better that trying to GET a resource of who knows how large >> size. > > BTW, I've changed my /version.json so that it now looks for and returns > the > client certificate that it saw: > > curl > --cert spec/files/product/00-D0-E5-02-00-2E/device.crt > --key spec/files/product/00-D0-E5-02-00-2E/key.pem > https://masa.honeydukes.sandelman.ca/version.json > > -> > > {"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453d7784d3","Hostname":"masa.honeydukes.sandelman.ca","client_certificate":"-----BEGIN > CERTIFICATE-----\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry\ndW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\nMBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEey+I0TtIhm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjkiPVnhoCosUBpTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpADBmAjEAuEwTKPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/AjEAnRjH2R0T\n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-----END > CERTIFICATE-----\n"} > > -- > Michael Richardson . o O ( IPv6 IøT > consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --=_31766e53aceb2e8260c9d0050e54d310 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Is there a way to use Olaf's "coap-client" to do the ping?
I don't see= an option, and it also doesn't seem to be commonly built with DTLS.
<= br />No, I have a three lines of code for doing a ping, from pledge; not fr= om coap_client

Peter

Michael Richardson schreef op 2021-07-21 21:36:

=
Esko Dijk <esko.dij= k@iotconsultancy.nl> wrote:
    > There = is already a "CoAP ping" described in RFC 7252 that can be
  = ;  > used. It does not access any resource, just the CoAP serv= er endpoint at
    > CoAP message layer. As a s= ide effect of this ping your DTLS stack will
    &= gt; set up the connection which is handy.

I recalled that later = in the day that CoAP "ping" is not connected to CoAP
"echo" :-)
I= think that there is also potentially a need for a way to debug possible MT= U
issues.
Is there a way to use Olaf's "coap-client" to do the pi= ng?
I don't see an option, and it also doesn't seem to be commonly bui= lt with DTLS.
We also have the issue of CCM8 vs OpenSSL that I thought= got solved, but it
appears that it has not been, so one needs a tool = built with mbedtls or wolfSSL.

    > So I= don't think we need a resource at / that produces 2.05 , this is
&nbs= p;   > for the maintainer of the server to decide how to = allocate that
    > resource space.

=     > Besides we have already defined some well-know= n resources accessible
    > with GET ( in core= /est/brski) that the client could make use of to test
  &nbs= p; > connectivity.

    > Even a n= on-existing resource in the /.well-known/X space could be used
 &= nbsp;  > just to get a 4.04 which confirms the server is worki= ng properly. This
    > is even better that try= ing to GET a resource of who knows how large
    &= gt; size.

BTW, I've changed my /version.json so that it now look= s for and returns the
client certificate that it saw:

curl<= br />        --cert spec/files/prod= uct/00-D0-E5-02-00-2E/device.crt
      &= nbsp; --key  spec/files/product/00-D0-E5-02-00-2E/key.pem
&n= bsp;       https://masa.honeydukes.sandelman.ca/version.json

-><= br />
{"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453= d7784d3","Hostname":"masa.honeydukes.sandelman.ca","client_certificate":"--= ---BEGIN CERTIFICATE-----\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIw= EAYKCZImiZPyLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME= 1Vuc3Ry\ndW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\n= MBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQ= gAEey+I0TtIhm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjk= iPVnhoCosUBpTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0= TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkr= BgEEAYLuUgIEHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpA= DBmAjEAuEwTKPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/Aj= EAnRjH2R0T\n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-----= END CERTIFICATE-----\n"}

--
Michael Richardson <mcr+IETF@sandelman.ca>   = ;. o O ( IPv6 IøT consulting )
     &n= bsp;     Sandelman Software Works Inc, Ottawa and = Worldwide





= _______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--=_31766e53aceb2e8260c9d0050e54d310-- From nobody Thu Jul 22 00:46:04 2021 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 E0B9A3A3CA5; Thu, 22 Jul 2021 00:45:58 -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, SPF_HELO_NONE=0.001, 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 piZ58WwhIl0Y; Thu, 22 Jul 2021 00:45:54 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6759F3A3CA2; Thu, 22 Jul 2021 00:45:54 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVkyl21JXz31Lh; Thu, 22 Jul 2021 09:45:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2021 09:45:50 +0200 Cc: Michael Richardson , core@ietf.org, anima@ietf.org X-Mao-Original-Outgoing-Id: 648632750.91115-1c2e064ed73c411aec71dec7f85a426a Content-Transfer-Encoding: quoted-printable Message-Id: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> To: stokcons@bbhmail.nl X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 07:45:59 -0000 Time for me to update the coaping gem=E2=80=A6 Well, yeah, the warning message. Gr=C3=BC=C3=9Fe, Carsten $ gem install coaping Fetching coaping-0.0.1.gem Successfully installed coaping-0.0.1 $ coaping coap.me Trying 20 times with coap.me at port 5683, waiting 1.0 second max: = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 0 28.0 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 1 23.2 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 2 22.1 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 3 22.0 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 4 22.7 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 5 28.0 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 6 33.6 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 7 23.4 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 8 35.1 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 9 39.2 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 10 28.7 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 11 29.2 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 12 32.4 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 13 24.2 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 14 25.9 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 15 23.0 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 16 36.1 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 17 24.4 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 18 27.7 ms 134.102.218.18 = /Volumes/nar/Users/cabo-rescue/lib/ruby/gems/3.0.0/gems/coaping-0.0.1/bin/= coaping:36: warning: Object#timeout is deprecated, use Timeout.timeout = instead. 19 27.0 ms 134.102.218.18= From nobody Thu Jul 22 00:50:37 2021 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 A455C3A3CC7; Thu, 22 Jul 2021 00:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 smEEN6bqZe_q; Thu, 22 Jul 2021 00:50:30 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1652D3A3CC0; Thu, 22 Jul 2021 00:50:30 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVl432Crzz31Md; Thu, 22 Jul 2021 09:50:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Thu, 22 Jul 2021 09:50:26 +0200 Cc: Michael Richardson , core@ietf.org, anima@ietf.org X-Mao-Original-Outgoing-Id: 648633025.5225559-e4e3ec6bac7fb18a277419465ca51bb6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> To: stokcons@bbhmail.nl X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 07:50:35 -0000 On 2021-07-22, at 09:45, Carsten Bormann wrote: >=20 > Time for me to update the coaping gem=E2=80=A6 Done: VERSIONS: =E2=80=A2 0.0.2 - July 22, 2021 (5 KB) =E2=80=A2 0.0.1 - November 19, 2012 (4.5 KB) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 22 01:05:12 2021 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 BF0043A3D22; Thu, 22 Jul 2021 01:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 Rcbexu8b3nGP; Thu, 22 Jul 2021 01:04:59 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2086.outbound.protection.outlook.com [40.107.22.86]) (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 0C01A3A3D21; Thu, 22 Jul 2021 01:04:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c2t3E2vjJA2UZrkeim3kfvSJha7EnRRlkNkP2/4xgr4OeZxT5VG6w6SUbO/K5EZpVj4iEVj8lyHyWx55aA5WV7TLMDq+YEPPmHJ+516EpN5/zQbEUb4tPoh2CZ7UEwSgGFpY6s8xQOVUUcio+LT4chJsxS/U99hOx6XZJXvD9IGxm+A49yI78j+gE91818B/QQcpgP4Ge601rhvOaa2KUeKCUWWAM/0Ju0caZaSiedPfWS4/hur9Ly3R89bzuf5ILxHhL6f7wWCVJIi/EqxcdGxHpOLYM9oSX2PGMWwz7xlEaI6Q39Wdu2d5U5kknaQ6NSoDVTcLhsf2jX/48fHuog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EZDBeWpDSN6TcPTBdOGrbZRYqYhOoiaE1UqFguvFGjk=; b=eRZKnaqnW4RHfJzpIw9HfoTkxrcxGOHSkmMhw52HPyL3Hxz8/liGmxDw79b/vdIsu2CIDYZ7i+p9aaY0/EEcdoDVzT9OE5QhG3VAPjeWSyVNE5/LZoCekxzRp6lDOEBaaiTF23V/qmqNTVHhIZXVfJxO8XrENu6q+rS3r57em+LtBA9EQfRx7OuTvvtm5Jkgh+8b3DjilA6Yurc8PKMTGki2x5ziy2r203hxVyEflrKvilMwHCGiII7wfeyQRiORKZZ9l2HT+ep+8lR7zvrfgN6R40xeXceDBWR5e+hoZCc93NVE0QERL6+Xt88PKxzPj7fHvcBBZbIxUGIbRAY4yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EZDBeWpDSN6TcPTBdOGrbZRYqYhOoiaE1UqFguvFGjk=; b=iUrnF1tGbVZBAnNmJbW8EvNcRbiUleebJfZcfzQa6xpjCtyIruCzyYLIN58EhXqz2c7QGyl5NszjAlQKn5/3NKmB/g6CiNdU0RqDzyLNiOFQB0UFmH5Kzwv5ey6a4OvBwRAISUNfjhwrQVRxMj1uT3jMaGO6ZQYlcGdHD8GNFs8= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB4218.eurprd07.prod.outlook.com (2603:10a6:7:a1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.17; Thu, 22 Jul 2021 08:04:56 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::8cb8:b3b2:b265:d65f]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::8cb8:b3b2:b265:d65f%5]) with mapi id 15.20.4352.024; Thu, 22 Jul 2021 08:04:56 +0000 From: Christer Holmberg To: Carsten Bormann , "stokcons@bbhmail.nl" CC: "anima@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Anima] constrained resources at root for debugging connectivity Thread-Index: AQHXfWyxp2MaVB//mEmr+125ENTtbKtNDUMwgADHPQCAAL3igIAADfIAgAABSQCAAAN40A== Date: Thu, 22 Jul 2021 08:04:56 +0000 Message-ID: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90031ecc-32b3-49e6-61a3-08d94ce764e9 x-ms-traffictypediagnostic: HE1PR07MB4218: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eF27WFmfAVcMSjI5ASjRGCZ25yGvDv/Z1n1cYknzs+mhrB1hbHOkG2vJku5JC5uS/Pap84b5bryX52HPwDfCWz5NmaWbjSubBwXslOEe7M+ch8hhjyXbzUhLkPGBg+MDodg2GINtlxo/q2Abth/q3H2OschCqKdtl5lvfHI6GG0hEuAc9HESQf1TReA3OwWJVzsulxCdQ9FVEPr9mvXBty5QRxD2UzoS9Z2+h8ZG57yJLLlVsTKsCs/SKTXjvCsMXI3mdWrV4vNMAhsDcPJYwlfyd4KcmhBth7g8FYPL8tHnk8sL4KJtr8nYunXq9pYdhboR+G5sUMDrk/UWzajI3VqADoxYAUsLfztqrYG0YNU8xmyU5L2wg6aj3lZtdCK/Rw9L9H+jqCoiU8yPT0DSQYTVER7SQXk604zFpwkoSA15QWk/OTg6KX85xDG36NCqHq5ViiajhPFfntLcmQd1s7cTBM3tZ54ho6PQ5QMEpPo5i/hw8K7pZAglO9EA3ibM8YzcsqMs669eV8IaDxK6AYndhhExrW2j5YcfQ5RZyBUEYSQ1imk+9ZRrm4SAmnvZai9FX+XqNyD+gkFHXLxAlk+ZyKfYGUzu1pdUrL3D/4nFbBPeRjhGVHHSTlWHT3K1d+Eo0Xblx1RPQhZ6ePj86RYDDKVlOiXeP/p2LqPV5EIA8Pv7mP8qcVr2kNbq4ZehGlwQ8rML2HGk8D3+F0D23wHoyitCl3EYb4Hhv/PK87SdG9iQ4FdfVmCXYOk1XBGqGav/Xkzd6roSOEiurEWxF58ZwoYQIMQTIMpYi85s75+B7wG2XDM1/rI6hRjWn/ewtCXYqfPPi/51UDZKyatW3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(76116006)(86362001)(4326008)(44832011)(8936002)(110136005)(316002)(2906002)(8676002)(66946007)(38100700002)(122000001)(66476007)(54906003)(186003)(66574015)(53546011)(6506007)(4744005)(55016002)(508600001)(5660300002)(83380400001)(52536014)(66446008)(66556008)(26005)(9686003)(64756008)(7696005)(71200400001)(966005)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eHcxYTVJZ21QSTc0Tk41UGpDZHR6QVgxSVZzendWWkRQeGN1UXZtbUI5U0FU?= =?utf-8?B?MzBvTG92ejN1aHJxWm1kVVRXdjZVTmpoc3dXOGU5eDdrbTMwRFdJeUZYRVZL?= =?utf-8?B?WHRxSlJSdjlpdHJjWENnaVRMK2lQNlEzL21DMnNmRzU5VjJsZldXQ0JocHA5?= =?utf-8?B?S0dXSzdGaEt2MDZLWHFCREtuV1MxWXJNSC9JUzNOeXZZcXdBQ3JEaXphdnJz?= =?utf-8?B?SnRsTGpRbUYwT3dmVGoxYzhQaC9BMFlIOEwwdWV1cW1nN3VJaEFpRFlpSVp5?= =?utf-8?B?QjA2VnNrQzNmbFhFVFkraHlOU25jVm1ERFcreEQyeVBORmt6dVVoazlWZmNu?= =?utf-8?B?NlJoSjd2cUZXNituMTNzSktvelZ5UXFFRmhhaDlQOEZQL3BTbHlBYkZBMDIy?= =?utf-8?B?bkp6aUk3UTM4eTN6UHN6dUI0RE5FbjBiK3ArTmE1eUhScVlGOCt1bU1lNGlW?= =?utf-8?B?d2Y0M2Y2dEdYY3NUZTRoaWFxZ1N3dmdqL01JY2RIV1lreHhTeWJOeVhOTU9G?= =?utf-8?B?eFVVUGVoWFJWaGhnSmVXajBWbDlIL0NuM3F3R21zYzJIMzFHczVlcGcxUUpv?= =?utf-8?B?bkJvM1oxeVdkT0Z3bkMwVmVZV1lWcDZOOENidjJvd01RTGJMQTJRdVVmOUEv?= =?utf-8?B?STJQVFo1WnkzYjF1b2dwQ0Jqb3VEMWZ5Nld3TW1pRm9sUG5SOW1VdWdKRnhx?= =?utf-8?B?c1hUVjlYdzhZSThGN1FSbS9FSmcwdkNIZjhPOTFJYXpDakJEdEhQbUNUMmg5?= =?utf-8?B?Z2gvL1I1MzQya05WU1BEVm9IcVFPdXVOVEdrZ2xPa2tjYzhCSHdaWDBFaFcy?= =?utf-8?B?RHB4S1NPeUc1Z0w3U094dkVhd1dsS2tubHNZblROVXpSZDRWVnhRa05WQXVU?= =?utf-8?B?NkFkMDVpbWdnNlpWUWxBdGpDeGEwSGltcU1pOFRWdk13RXdaUHdwQi9xY0xi?= =?utf-8?B?RnBPRkh3S2UrRmJzcGR3ZlZPWVF3TWRteEhZL0VkWkdsTnh6Z0JybjdXL3hs?= =?utf-8?B?M05wUGxBT0dCWVhuQ1FLQ1JPWStFZXo0aFZIcEQ1NUZGQVp5enZENEFMZ25L?= =?utf-8?B?R3BNTW9aNWJxTy80ZEV3NU9PQXNJYVl0VXhXYXBHa2E4cXdGQlo1U1U3VWVx?= =?utf-8?B?aWF2OVpyRjZyQzd5TGczWGE5SDh4bCtpZDR1NE9FM0tGLzMvaFNiMDkwSXVE?= =?utf-8?B?bDRCTEYxcFdsTVhiRUFUaFcvVVFQOHJoTTdBNldWZjM1MUhPelFHbzF2cDJk?= =?utf-8?B?dEZ5UVBwbG4zSkF0cTNmNDNlZ0k5cHQySFdMeFJQcXJMWVMwaVZwWWJtZFpK?= =?utf-8?B?MW8wbWh4WWMwTnlXa0Z3QXpIOER6MWVLMGdzZ1IwdUZOTWsxSW1YN0VyVVVV?= =?utf-8?B?bjNXTnlaNm1LS3gwanlZcC9ERUNhM2ZBZFYrKzVUNEVTNWpxVWIyYkJFbFBK?= =?utf-8?B?cW80TmFMbkU1SXlXS1ZnM0VTVm9KaStmTTNteXcyVW1KOWVsVjNoRXhjNTlP?= =?utf-8?B?c2R5TW11TkZ4WHY5TkFnRW9EcXJMWTlVd0xmYkNzNEE0UzBiRUdoVGx3bkNI?= =?utf-8?B?dDVvWXRiQ3Y3cEEwTDlrN015NEFIdmZtLzVyTXV3UEJEb3BTb0laOGdDUk93?= =?utf-8?B?T3hzcW5rTVJocm5MNTRwRFZ4eCtza2lscVhjQ2w0WjVub0xCRzdGNzdkZ3ZM?= =?utf-8?B?S1llMTVCVnYrTE5GQkJjbjM1eDc3S0MvS3ZsYzQ3YXNnUXFIc1ZFMUl4MGZa?= =?utf-8?Q?hj2Vy5RFUFX9c2tDB/4snXI08c2Yf+mPmTrAauF?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90031ecc-32b3-49e6-61a3-08d94ce764e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2021 08:04:56.2029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: clTYvu7P+x7518ZGqbd+PO2oJx5+TPnCqlQdGyajHndJCv00gCy8MuCvEfmoes37voHqsbmUiSbEbtpJDZme4ZpuqRnKm8FSfri+EyEd1zE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4218 Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 08:05:05 -0000 SGksDQoNCk1heWJlIG5vdCBleGFjdGx5IHdoYXQgcGVvcGxlIGFyZSBsb29raW5nIGZvciwgYnV0 IGJlbG93IGlzIGEgbGluayB0byB0aGUgdGhpbi1JQ0UgcHJlc2VudGF0aW9uIGZyb20gdGhlIFQy VFJHIDIwMTkgc2Vzc2lvbiBpbiBTaW5nYXBvcmUuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS90MnRy Zy8yMDE5LTExLXNpbmdhcG9yZS9ibG9iL21hc3Rlci9zbGlkZXMvNDQtdGhpbi1JQ0UtMTUxMTE5 LVNpbmdhcG9yZS5wZGYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IHRvcnN0YWkgMjIuIGhlaW7DpGt1dXRhIDIw MjEgMTAuNTANClRvOiBzdG9rY29uc0BiYmhtYWlsLm5sDQpDYzogYW5pbWFAaWV0Zi5vcmc7IGNv cmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gW0FuaW1hXSBjb25zdHJhaW5lZCByZXNv dXJjZXMgYXQgcm9vdCBmb3IgZGVidWdnaW5nIGNvbm5lY3Rpdml0eQ0KDQpPbiAyMDIxLTA3LTIy LCBhdCAwOTo0NSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KPiANCj4g VGltZSBmb3IgbWUgdG8gdXBkYXRlIHRoZSBjb2FwaW5nIGdlbeKApg0KDQpEb25lOg0KDQpWRVJT SU9OUzoNCgnigKIgMC4wLjIgLSBKdWx5IDIyLCAyMDIxICg1IEtCKQ0KCeKAoiAwLjAuMSAtIE5v dmVtYmVyIDE5LCAyMDEyICg0LjUgS0IpDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0 DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUNCg== From nobody Thu Jul 22 01:44:01 2021 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 3B0823A3E63; Thu, 22 Jul 2021 01:43:46 -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, SPF_HELO_NONE=0.001, 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 QOn6IR7GOCZP; Thu, 22 Jul 2021 01:43:40 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87363A3E58; Thu, 22 Jul 2021 01:43:34 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVmFK1YFKz31Lw; Thu, 22 Jul 2021 10:43:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <25674.1626896178@localhost> Date: Thu, 22 Jul 2021 10:43:32 +0200 Cc: Esko Dijk , "anima@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 648636212.862666-8d6445ef3d0b09f09ae679c47ceaf0d6 Content-Transfer-Encoding: quoted-printable Message-Id: <7C073EC6-1335-454F-9E34-C60DD8E94167@tzi.org> References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 08:43:56 -0000 > On 2021-07-21, at 21:36, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Esko Dijk wrote: >> There is already a "CoAP ping" described in RFC 7252 that can be >> used. It does not access any resource, just the CoAP server endpoint = at >> CoAP message layer. As a side effect of this ping your DTLS stack = will >> set up the connection which is handy. >=20 > I recalled that later in the day that CoAP "ping" is not connected to = CoAP > "echo" :-) The Echo option is not an echo in the sense of an ICMP echo. (Maybe we should fix the name to =E2=80=9Ccookie=E2=80=9D.) > I think that there is also potentially a need for a way to debug = possible MTU > issues. Good point, CoAP Ping (empty CON messages) cannot do that. Actually, the fact that it was possible to set up DTLS should give one = considerable confidence; the CoAP Ping is not needed to verify pure = presence. Verifying that that server actually speaks a specific = protocol would need to be part of that protocol though. Also, cough, cough, https://datatracker.ietf.org/doc/html/rfc6520 gives = you a nice way to ping a DTLS server with different MTU sizes. (Ignoring the fact that an incorrect implementation led to the biggest = TLS, er, =E2=80=9Cevent=E2=80=9D we ever had.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 22 02:53:34 2021 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 60D4F3A4018; Thu, 22 Jul 2021 02:53:28 -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, SPF_HELO_NONE=0.001, 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 OWerFAeAK0qz; Thu, 22 Jul 2021 02:53:20 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39CB3A4016; Thu, 22 Jul 2021 02:53:20 -0700 (PDT) Received: from wangari.tzi.org (p5b36fb81.dip0.t-ipconnect.de [91.54.251.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVnnj0W4qz2xFx; Thu, 22 Jul 2021 11:53:13 +0200 (CEST) From: Olaf Bergmann To: Michael Richardson Cc: Esko Dijk , "anima@ietf.org" , "core@ietf.org" References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> Date: Thu, 22 Jul 2021 11:53:07 +0200 In-Reply-To: <25674.1626896178@localhost> (Michael Richardson's message of "Wed, 21 Jul 2021 15:36:18 -0400") Message-ID: <87h7gm65fg.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 09:53:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael, On 2021-07-21, Michael Richardson wrote: > Esko Dijk wrote: > > There is already a "CoAP ping" described in RFC 7252 that can be > > used. It does not access any resource, just the CoAP server endpoin= t at > > CoAP message layer. As a side effect of this ping your DTLS stack w= ill > > set up the connection which is handy. > > I recalled that later in the day that CoAP "ping" is not connected to CoAP > "echo" :-) > I think that there is also potentially a need for a way to debug possible= MTU > issues. > Is there a way to use Olaf's "coap-client" to do the ping? =2DK does that, see man coap-client (https://libcoap.net/doc/reference/deve= lop/man_coap-client.html): -K interval Send a ping after interval seconds of inactivity. If not specified (or 0), keep-alive is disabled (default). It would be not difficult to create a dedicated coap-ping, though. > I don't see an option, and it also doesn't seem to be commonly built > with DTLS. It is automatically built with DTLS if you have either GnuTLS, OpenSSL, Mbed TLS with headers installed (--enable-dtls is default). Gr=C3=BC=C3=9Fe Olaf --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJFBAEBCgAvFiEEmSguCDxS9rZidVh3o7Urr5IZivoFAmD5QAMRHGJlcmdtYW5u QHR6aS5vcmcACgkQo7Urr5IZivrnsxAAkeWuIWWq+Xa62l3sQAe57hww0mP/cS8c PX/9551sTe8LOzcm6vECdFcfE9vMFwwWv7v9dsBazD539uEdeveu7fiDprs+2sH8 pV8sbvf2oR25cOKIshICrH4+uw4I6FI6irpFqB2nAmxLmfB/Npou6pB7aBWbsDfw fefoj9mWy88U54/86i10fo+VxXwJKqsO6/vLEy6nNinaET0vXsq94xhj0iV5umzY Z/NV8NIZ/bK+Vx0JdDPDJW++jGcChxNDn/7ALg06jqufhFRL+2I3fMmdyfnEO+W6 RoanoNgTLD1rb6r0MI6Rb1zKd/zm/tb1iz6I8frnuejbxoJKKbDlN8xSCsjVnLOi bjHpl3a9+/vVcuQ9/YKYdD18SpzvHS3z6lW3BMtwyWuQ+c+3hB8CIGZlVun+Y4jj m5UzRtdsbXhjqGUj2qynTy1hAqh6IUS4lwZXPHRu0rB7Rk2eTl4hOMsKbgBQex3O VKEwuyV0pp8xuk60Z8sobsqt9/NUhmhHOeSwKnjX1Y1ND/R/ETqrr4eZCU6WFRSG vDDj2mZENamd3oEPANKW0veXri1mpvMNVWQVQ2d5rO7cLvF8rnu7XKShNKHiz5dK DpFEi9tlTrqEpC/yknU0Xvk+jbf+nchTBfDYtPlsgKSmveT0N7U+adorT/XkeYLX d74bPT1SiSU= =BGFT -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 22 06:19:47 2021 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 3E9373A4636; Thu, 22 Jul 2021 06:19:41 -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, SPF_HELO_NONE=0.001, 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 HCUpwNYfpGO6; Thu, 22 Jul 2021 06:19:37 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DC33A463D; Thu, 22 Jul 2021 06:19:36 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVtMj1Grlz31Mm; Thu, 22 Jul 2021 15:19:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <074D2AD7-BA13-41ED-8C9C-2145036C89CF@tzi.org> Date: Thu, 22 Jul 2021 15:19:28 +0200 X-Mao-Original-Outgoing-Id: 648652768.647468-3a36965c9137958c2ce742a8888c55cb Content-Transfer-Encoding: quoted-printable Message-Id: References: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> <074D2AD7-BA13-41ED-8C9C-2145036C89CF@tzi.org> To: t2trg@irtf.org, asdf@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] [Asdf] [T2TRG] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Thursday 20th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 13:19:42 -0000 =E2=80=A6 and today=E2=80=99s meeting is at https://codimd.ietf.org/hackathon-2021-t2trg-111-thursday start time: 2021-07-22 14:00:00 UTC duration: 60 = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hackat= hon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210722T14&ah=3D1 = https://meetings.conf.meetecho.com/interim/?short=3Df993baa2-1946-4ee9-ba9= 2-1f5b9a107329 We=E2=80=99ll mostly focus on CI work for getting converter outputs = disseminated. Notes from yesterday=E2=80=99s meeting are at = https://codimd.ietf.org/hackathon-2021-t2trg-111-wednesday See you in 40 min... Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 22 17:45:28 2021 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 BAF4F3A14DA; Thu, 22 Jul 2021 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s3wriqPNcn1; Thu, 22 Jul 2021 17:45:20 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 89B083A14D1; Thu, 22 Jul 2021 17:45:19 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id o5so1314505ejy.2; Thu, 22 Jul 2021 17:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=546Be0lS7gjvICuqHMsR4i+Twkf4/IF/cTQMtrSRlUM=; b=pJXeMUKEv/hDgXdDZzHaqlwZmKwj0UZXpxO/Ec7OKpYaUPjtjW6sy2AxsJ+f1C5+1j HOUYKWSLIONWfRYjiUQa5/yybyDbDzwxX8Ms8BDXMGVH+8e6GLeP/2r4kyH5uifD45LT KfVmaEGXZcuyKTnMPO8xYwiWW1dvs296cZuFwK64AAVBNXVsp2S5LqR62p0zZYXxWdQF zsG8XdiVU4i7OemoSCLiWdLylfGx6xII0hVAEzqQbJGI6gSrJvZmEcZfEy2Mj3ZqxPlf BJQxWDtUDAUhYT+SfQxcIaIjuWdSEEYu1dVUqjHkrUAaFMkE4xgg9hOPPwVQizaGYtjg UZCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=546Be0lS7gjvICuqHMsR4i+Twkf4/IF/cTQMtrSRlUM=; b=TA49ka6oGvouE/OnGEX4Liwq7zuVAemkOJdLboESkB7h9iJTeuLUbAh1ioNg40u6bV fylXDv74IrwDKKUReC39zKif4NizwKYq/AIB7vbdx1RxEfdnAlsUu8jCCeeAijUVM3WG xtk4gp7b+9D1pabakEVr2vIGDIM+X/jKJaJJYsDWoeoY61rEZ826aFLq4A7bWw0rA5bC iMcrHEENK3ZR1VR9q9cNUDcsnGZjkxlLS8Wczx36EP3e4NAo5YYVx6P0o+NNGGq0q61W tvME7pv64HkPLz5ZV7DB0O3gDaBvegqfm8+w8CItuthAsJsxHIjm40JpZ2xkjGwu6yLd oqEA== X-Gm-Message-State: AOAM531btw3m75NOPXIJf9zZG/GAWj0LXEZF83WXgtoX1xtuZ1kezIu9 1N0P3Xpry2PccVnDFZQ9X3vnURrK+WsPJOn4grc= X-Google-Smtp-Source: ABdhPJyrA+v2KBc6Q9oSi8c0kkqiqiNVh7yF9KJ0g1eDav8L2rjEtgyVNkPMHVwSNLwEXqcJLREKn3CvARn67+j+m5M= X-Received: by 2002:a17:906:a391:: with SMTP id k17mr2379577ejz.516.1627001117096; Thu, 22 Jul 2021 17:45:17 -0700 (PDT) MIME-Version: 1.0 References: <161671562340.18744.12200188901217754567@ietfa.amsl.com> In-Reply-To: From: Xufeng Liu Date: Thu, 22 Jul 2021 20:45:05 -0400 Message-ID: To: Ivaylo Petrov Cc: yang-doctors@ietf.org, core , draft-ietf-core-sid.all@ietf.org, Last Call Content-Type: multipart/alternative; boundary="000000000000a23bda05c7bfb776" Archived-At: Subject: Re: [core] Yangdoctors last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 00:45:27 -0000 --000000000000a23bda05c7bfb776 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ivaylo, Thanks for addressing the comments. One more minor comment on item 1. Best regards, - Xufeng On Sun, Jun 13, 2021 at 5:52 PM Ivaylo Petrov wrote: > Hello Xufeng, > > Thank you for your review and apologies for the delay! Please find our > answers to your questions below. The diff with -15 is available here > [1]. The updated version is available as txt [2] and as html [3]. > > Thanks, > Ivaylo > > [1]: > https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet= f-core-sid-15.txt&url2=3Dhttps://core-wg.github.io/yang-cbor/draft-ietf-cor= e-sid-latest.txt > [2]: https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt > [3]: https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.html > > On Fri, Mar 26, 2021 at 12:40 AM Xufeng Liu via Datatracker > wrote: > > > > Reviewer: Xufeng Liu > > Review result: Ready with Nits > > > > This is a review of the YANG module in draft-ietf-core-sid-15. > > > > Minor Issues, Nits, and Questions: > > > > 1) This module uses the yang-data extension in RFC8040, which was the > best > > choice a few years ago when this draft started. However, RFC8791 has be= en > > published so that the YANG structure extension is available now. Has th= e > YANG > > structure extension been considered to replace the yang-data extension? > > > > [IP]: Thank you for providing this pointer! We would really prefer not > to change this given the mature state of this document, unless there > are some really important advantages of using YANG structure > extension. Quickly looking at the document I did not find compelling > reasons to do the change, but please do let us know if you believe > there are such reasons. > [Xufeng]: If yang-data is kept, Sec 2 of RFC8340 specifies the format for the tree diagram for yang-data. In this case "yang-data" is used, so the tree would be: module: ietf-sid-file yang-data sid-file: +-- sid-file +-- module-name? yang:yang-identifier > > 2) The container sid-file is missing in the tree diagram in Section 4. > RFC8340 > > specifies the tree format to represent such a yang-data definition. If > the YANG > > structure extension in RFC8791 is used, RFC8791 describes how the tree > diagram > > looks like for such a YANG structure. Also, the top container would not > be > > needed, because a YANG structure is encoded as a 'container'. > > > > [IP]: I fixed the tree diagram. About adding the sid-file container, > it was suggested in the following email: > https://mailarchive.ietf.org/arch/msg/core/-1YKD5X75p9CeTIm1yt0BM3KtOg/. > We can discuss with Andy, but from the email I am under the impression > that he believed the container is needed. > [Xufeng] You are right the the container is needed for yang-data. If the YANG structure extension in RFC8791 were used, the container would not be needed. > > > 3) In the container sid-file, the leaf module-name is optional. What is > the > > assumption when it is not specified? It would be beneficial to clarify > in the > > description statement. > > [IP]: I could not remember why that was made optional. I will have to > check with my co-authors and come back to you. > > > 4) In the container sid-file, the leaf sid-file-version is optional. Th= e > > description says that this number starts at zero. Let=E2=80=99s say tha= t there > are two > > .sid files, one of which does not have the version number and the other > one has > > version number 0. Are they the same? If so, would it be better to have = a > > default statement with a default value of 0? > > [IP]: Fixed. > > > 5) For =E2=80=9Clist dependency-revision=E2=80=9D, the key is module-na= me. The > =E2=80=9Cmandatory > > true=E2=80=9D statement is not necessary for this leaf because it is a = key. > > [IP]: Fixed. > > > 6) Under the =E2=80=9Clist dependency-revision=E2=80=9D, the leaf revis= ion-identifier is > > specified as =E2=80=9Cmandatory=E2=80=9D. What would this leaf be speci= fied when a > dependent > > module does not have a revision? > > [IP]: Is it possible to make two different versions of a YANG module > without revisions in practice? If the answer is no, then I believe we > can make that optional. My understanding is that the answer would be > maybe and then I do not think we can support this as it will add non > determinism in the SID allocation, which we can not allow. > > > 7) =E2=80=9Clist assigment-ranges=E2=80=9D should be =E2=80=9Clist assi= gnment-ranges=E2=80=9D. A letter > =E2=80=98n=E2=80=99 is > > missing in the current YANG module because of a typo. > > > > 8) For =E2=80=9Clist assignment-ranges=E2=80=9D, the key is entry-point= . The =E2=80=9Cmandatory > true=E2=80=9D > > statement is not necessary for this leaf because it is a key. > > [IP]: Fixed. > > > 9) As a convention, the node names of =E2=80=9Clist assignment-ranges= =E2=80=9D and =E2=80=9Clist > items=E2=80=9D > > should be in the singular form, the same way as =E2=80=9Clist > dependency-revision=E2=80=9D, so > > that they would be =E2=80=9Clist assignment-range=E2=80=9D and =E2=80= =9Clist item=E2=80=9D. > > [IP]: Fixed. > > > 10) Since a YANG SID value is globally unique, would it be beneficial t= o > have a > > statement in the YANG file to describe the requirement formally? This > can be > > easily done by adding the following statement under =E2=80=9Clist items= =E2=80=9D: > > unique "sid"; > > [IP]: Added. > > > 11) The format of the YANG file needs to be adjusted. Some of the lines > in the > > .yang file are longer than 69 characters. For example, at line 108 is: > > o Any subsequent schema node name is in the namespace-qualified > form > > To examine, the command =E2=80=9Cpyang --ietf --max-line-length 69 FILE= =E2=80=9D can be > used. > > Before publishing, an RFC editor would normalize the format by using th= e > > command =E2=80=9Cpyang -f yang --keep-comments --yang-line-length 69 FI= LE=E2=80=9D. It > would be > > helpful to run this command now since it may change the lines to be > longer than > > the limit of 69 characters. > > [IP]: Fixed. > > > 12) In the example in Appendix A, the four "module-revision" statements > contain > > =E2=80=9C.yang=E2=80=9D after the date, not following the pattern rule = of the > > revision-identifier. It seems that the sid generation tool did not take > out the > > extension =E2=80=9C.yang=E2=80=9D. > > [IP]: Removed those and made a note to check the tool. > > > 13) In Appendix A, the 5th item is: > > o iana-crypt-hash@2014-04-04.yang (defined in [RFC7317]) > > but in RFC7317, the revision of iana-crypt-hash is 2014-08-06 > > [IP]: I believe I manually downloaded or created that file when I last > generated this and probably I have mistakenly put an incorrect > revision. Now it's fixed. > > > 14) The following is a thought that may have been discussed before and > decided > > by the WG, but I=E2=80=99d mention it here anyway just in case: Since t= he scope > of a > > .sid file is for a single YANG file (module), many of the data nodes > start with > > the namespace of this particular module. The =E2=80=9Cschema-node-path= =E2=80=9D currently > > requires an identifier string to always start with a namespace. Because > of this > > requirement, there are many repeated namespace strings in the > identifiers of > > the items. If we assume that the default starting namespace is the modu= le > > associated with the .sid file, we may shorten the .sid file? > > [IP]: On the constraint devices or over the network the SID file will > not be present at all, therefore having some possibly redundant data > is not a big issue and my concern is can we introduce possible > ambiguity because of an attempt to save a few bytes where they were > not creating an issue. If you feel strongly about this, we will bring > it to the WG to discuss. > > > - Xufeng > > > > > > > --000000000000a23bda05c7bfb776 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ivaylo,

Thanks for addres= sing the comments. One more minor comment on item 1.

Best regards,
- Xufeng

On Sun, Jun 13, 2021 at 5:52 PM Ivay= lo Petrov <ivaylo@ackl.io> wrot= e:
Hello Xufeng,=

Thank you for your review and apologies for the delay! Please find our
answers to your questions below. The diff with -15 is available here
[1]. The updated version is available as txt [2] and as html [3].

Thanks,
Ivaylo

[1]: ht= tps://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf-co= re-sid-15.txt&url2=3Dhttps://core-wg.github.io/yang-cbor/draft-ietf-cor= e-sid-latest.txt
[2]: https://core-wg.github.io/yan= g-cbor/draft-ietf-core-sid-latest.txt
[3]:=C2=A0 https://core-wg.github= .io/yang-cbor/draft-ietf-core-sid-latest.html

On Fri, Mar 26, 2021 at 12:40 AM Xufeng Liu via Datatracker
<noreply@ietf.org<= /a>> wrote:
>
> Reviewer: Xufeng Liu
> Review result: Ready with Nits
>
> This is a review of the YANG module in draft-ietf-core-sid-15.
>
> Minor Issues, Nits, and Questions:
>
> 1) This module uses the yang-data extension in RFC8040, which was the = best
> choice a few years ago when this draft started. However, RFC8791 has b= een
> published so that the YANG structure extension is available now. Has t= he YANG
> structure extension been considered to replace the yang-data extension= ?
>

[IP]: Thank you for providing this pointer! We would really prefer not
to change this given the mature state of this document, unless there
are some really important advantages of using YANG structure
extension. Quickly looking at the document I did not find compelling
reasons to do the change, but please do let us know if you believe
there are such reasons.



> 2) The container sid-file is missing in the tree diagram in Section 4.= RFC8340
> specifies the tree format to represent such a yang-data definition. If= the YANG
> structure extension in RFC8791 is used, RFC8791 describes how the tree= diagram
> looks like for such a YANG structure. Also, the top container would no= t be
> needed, because a YANG structure is encoded as a 'container'.<= br> >

[IP]: I fixed the tree diagram. About adding the sid-file container,
it was suggested in the following email:
https://mailarchive.ietf.org/= arch/msg/core/-1YKD5X75p9CeTIm1yt0BM3KtOg/.
We can discuss with Andy, but from the email I am under the impression
that he believed the container is needed.
[Xufeng] You= are right the the container is needed for yang-data. If the YANG structure= extension in RFC8791 were used, the container would not be needed.

> 3) In the container sid-file, the leaf module-name is optional. What i= s the
> assumption when it is not specified? It would be beneficial to clarify= in the
> description statement.

[IP]: I could not remember why that was made optional. I will have to
check with my co-authors and come back to you.

> 4) In the container sid-file, the leaf sid-file-version is optional. T= he
> description says that this number starts at zero. Let=E2=80=99s say th= at there are two
> .sid files, one of which does not have the version number and the othe= r one has
> version number 0. Are they the same? If so, would it be better to have= a
> default statement with a default value of 0?

[IP]: Fixed.

> 5) For =E2=80=9Clist dependency-revision=E2=80=9D, the key is module-n= ame. The=C2=A0 =E2=80=9Cmandatory
> true=E2=80=9D statement is not necessary for this leaf because it is a= key.

[IP]: Fixed.

> 6) Under the =E2=80=9Clist dependency-revision=E2=80=9D, the leaf revi= sion-identifier is
> specified as =E2=80=9Cmandatory=E2=80=9D. What would this leaf be spec= ified when a dependent
> module does not have a revision?

[IP]: Is it possible to make two different versions of a YANG module
without revisions in practice? If the answer is no, then I believe we
can make that optional. My understanding is that the answer would be
maybe and then I do not think we can support this as it will add non
determinism in the SID allocation, which we can not allow.

> 7) =E2=80=9Clist assigment-ranges=E2=80=9D should be =E2=80=9Clist ass= ignment-ranges=E2=80=9D. A letter =E2=80=98n=E2=80=99 is
> missing in the current YANG module because of a typo.
>
> 8) For =E2=80=9Clist assignment-ranges=E2=80=9D, the key is entry-poin= t. The=C2=A0 =E2=80=9Cmandatory true=E2=80=9D
> statement is not necessary for this leaf because it is a key.

[IP]: Fixed.

> 9) As a convention, the node names of =E2=80=9Clist assignment-ranges= =E2=80=9D and =E2=80=9Clist items=E2=80=9D
> should be in the singular form, the same way as =E2=80=9Clist dependen= cy-revision=E2=80=9D, so
> that they would be =E2=80=9Clist assignment-range=E2=80=9D and =E2=80= =9Clist item=E2=80=9D.

[IP]: Fixed.

> 10) Since a YANG SID value is globally unique, would it be beneficial = to have a
> statement in the YANG file to describe the requirement formally? This = can be
> easily done by adding the following statement under =E2=80=9Clist item= s=E2=80=9D:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unique "sid";

[IP]: Added.

> 11) The format of the YANG file needs to be adjusted. Some of the line= s in the
> .yang file are longer than 69 characters. For example, at line 108 is:=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Any subsequent schema node name is = in the namespace-qualified form
> To examine, the command =E2=80=9Cpyang --ietf --max-line-length 69 FIL= E=E2=80=9D can be used.
> Before publishing, an RFC editor would normalize the format by using t= he
> command =E2=80=9Cpyang -f yang --keep-comments --yang-line-length 69 F= ILE=E2=80=9D. It would be
> helpful to run this command now since it may change the lines to be lo= nger than
> the limit of 69 characters.

[IP]: Fixed.

> 12) In the example in Appendix A, the four "module-revision"= statements contain
> =E2=80=9C.yang=E2=80=9D after the date, not following the pattern rule= of the
> revision-identifier. It seems that the sid generation tool did not tak= e out the
> extension =E2=80=9C.yang=E2=80=9D.

[IP]: Removed those and made a note to check the tool.

> 13) In Appendix A, the 5th item is:
>=C2=A0 o=C2=A0 iana-crypt-hash@2014-04-04.yang (defined in [RFC7317]) > but in=C2=A0 RFC7317, the revision of=C2=A0 iana-crypt-hash is 2014-08= -06

[IP]: I believe I manually downloaded or created that file when I last
generated this and probably I have mistakenly put an incorrect
revision. Now it's fixed.

> 14) The following is a thought that may have been discussed before and= decided
> by the WG, but I=E2=80=99d mention it here anyway just in case: Since = the scope of a
> .sid file is for a single YANG file (module), many of the data nodes s= tart with
> the namespace of this particular module. The =E2=80=9Cschema-node-path= =E2=80=9D currently
> requires an identifier string to always start with a namespace. Becaus= e of this
> requirement, there are many repeated namespace strings in the identifi= ers of
> the items. If we assume that the default starting namespace is the mod= ule
> associated with the .sid file, we may shorten the .sid file?

[IP]: On the constraint devices or over the network the SID file will
not be present at all, therefore having some possibly redundant data
is not a big issue and my concern is can we introduce possible
ambiguity because of an attempt to save a few bytes where they were
not creating an issue. If you feel strongly about this, we will bring
it to the WG to discuss.

> - Xufeng
>
>
>
--000000000000a23bda05c7bfb776-- From nobody Fri Jul 23 03:44:36 2021 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 B14FF3A1240 for ; Fri, 23 Jul 2021 03:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 7S-Qel6q9NLQ for ; Fri, 23 Jul 2021 03:44:28 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150071.outbound.protection.outlook.com [40.107.15.71]) (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 2B3813A1236 for ; Fri, 23 Jul 2021 03:44:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LmANXbl+DJcQSrD/NCb2k8qP6ggw9p7wzo1cwXaT8liOFP4H3UjdQoUagfg+PAgRs5LnKsw0ssp1RdADHwpNOR1ka77NVkq+XvTur7wXe9lwIBwKvjUWbO65slZd20ku/KXZv0dZLc0+zCceL+aZUJCrFBDu3uRBu59yl0709FqxTqAPkw60EymuXj+fh+3harX/6fn7zvI48+g4XGa3N+ECOkrUEkrRmZqwR97sz0wbtmB1a4ykWgxPniJ3JGGHNM/METuaHC5qMCkP2e02lxD96v50JyvYd7VPkLoFAT+O6YQ3TgUeSREFEw0WbFlZ56RXmcBIcx+CmBEw/ugCaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ij9MJtE63R1j9srHp/9ym3blIfDq2Z9DlgegTEu124M=; b=mHjBo0MI49pALWDzYGngAak2RBjFqaAmDYC/IE0L+8MWnXMeNex81uLVI8rESGdpMUnfPiNXL1w3ZIrQ22oWcYSs4menqKlouIXJqO0MMB0B/FWU9dPmLhOCkpssfr2PjPO5CbNOK4luAaHssb60XDEGWEDwngqWrzcOfuNJLa3pD2kX3NnDQfBKR+GcFKoHVOr389/TMh5CDJumcG4eJhAelJB8WiRPsVptYw0TiWqjvj7pZ3mNTb9LKWXv8UdsRpUhJi+4xjbeKTAzsqlo8N7fT5KPRLZ6u+4buHW7Q061BjaA85fhU/DeZCj6MzFkpimhYsyiasO2lAbZh2IAxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ij9MJtE63R1j9srHp/9ym3blIfDq2Z9DlgegTEu124M=; b=VlHxPdUDSzLtNGGS3FiCB8cxVZ7FeUjBxUOFYPxMg8newdO+CmoslHNt/s/3U8UjMmCv+Fr+sw/W3dfxADFuUAEqSwM5JuYK0E3dm0xbX6RgHgoEYfA2Nz08ezkAQQaBCPerjZooTvJO4+hAj8Uqaa/98PtnkJlzHJ0W15bT5cA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0102.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.28; Fri, 23 Jul 2021 10:44:25 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%5]) with mapi id 15.20.4352.029; Fri, 23 Jul 2021 10:44:25 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Message-ID: <5c62b88f-1d64-19a4-e9bf-ad319bffc4f4@ri.se> Date: Fri, 23 Jul 2021 12:44:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TN5RaVEKkYGJAPNztMGCEIxCv4UExMvcK" X-ClientProxiedBy: HE1PR1001CA0017.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::27) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.2] (185.236.42.21) by HE1PR1001CA0017.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.24 via Frontend Transport; Fri, 23 Jul 2021 10:44:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 46a430fe-c20c-4cbd-eccf-08d94dc6d6db X-MS-TrafficTypeDiagnostic: DB6P18901MB0102: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mU41xDrMyXK+p7zlFv1E0Fqhtki9Q3ppJQ7kCeDOw4kGHbxijeYZGVshSHuJff2Jr+l/3LVr+stU8AhXsEjQ+RL4Km2GMiuxed1ZUe/uMRqBUU3slpDdaoU073Sx75YrL5iLynP2YplsLm0WHM7w1iHyscxrUZ1zdZ5CDLh9K0Lba3QTVbpqzlyUe75MzklDBb9ooo/Cha2D33tJdvFGxPNicnaJ6DUeCsex+40xRrCvg5Qc8hOKsJMz7V0GVN/3ayadyfyrmmf+PQbgvkuBOfqkVV9PHUKotpiotlja2z6ionKiD3vvuZkZet9WUeRB/iNVmNL8CrkMYbbtW1ADTCJ4lWADj0yTGGPJGP4kmS5hzhjou1LfqWFtNsQsG163hE4HD6PsUeVyRHvvFo/zSL6+wuVzVboig7gekjFGIN9nyJYDXq6QlqR64utdjTtvHzYpAqdFRqyrmlyIL8nlWRNYH8uPE9OKA4kYmToV96EEG0KhE79dfNBR7Yvd+x/nkIwlgP3R2DWQRktNdRfzqPDeNfrYm1mUqD/NjdD5CuithbXtUPTXIG/4b5bQk2e+LUunnrBFhXKEGvgx2Au9eVD8vRu2qRr6dlXc5kp4ZgzKRy1OznD2gZcI8vfcPdWvt+LqBuP5ZL3CK1xWrl8NSANWz5E3xpnz4Bt61+BMDTmMdJDcja2FAQL8I/PjwbTlnZNn6G6eZl9j1+GI5ZPz8mR/rz+qzjH9//j6KnbaQ5Xkzp4RaVEmDEP17j4LwZetbxCXEfPtYRCwV4JPm//83fiTT3U/xZ0qxkmxgc2hMokWikKkjo8fE52c0u5WFTz5 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(136003)(396003)(376002)(39850400004)(36756003)(2906002)(38100700002)(44832011)(66556008)(33964004)(26005)(6486002)(31686004)(86362001)(186003)(66946007)(2616005)(6916009)(5660300002)(956004)(66574015)(8676002)(21480400003)(31696002)(66476007)(83380400001)(66616009)(8936002)(16576012)(478600001)(235185007)(966005)(53546011)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QU5zdkx6SUpLOHJuUElGNS94U0ZVV3NseC9iUVhuSnp4b0R1L3UwRlZOaVJR?= =?utf-8?B?bW1zRm9YUVc1QTdLOFV3RG1acm1kQ1k2UHlRSFZqWm5oNk05c2hLUzJVRnVz?= =?utf-8?B?NWJOaEdpOStmdXhuTVVuNFFjRGhuRzlHTDd1OWo0YmtTbDdZcDc2VUp6U0h3?= =?utf-8?B?NERnaS8xWHJaQmJsdWRaVkR5dEVoT0Q4dWd6UzQrdWpLdUJxbW5SMk1JTUJF?= =?utf-8?B?TEZldzVwek5nKzRncm5uWkYzaVlsVlFaMGt5UDNaTjB0Y0pnRXlYRzdvZmRM?= =?utf-8?B?WEdMNjZPejlvUGpGdWNpdDg1ZFlSNzNrS2czaE9kZ0hSb1pISEpQaHJoSnR3?= =?utf-8?B?VU5VN21EamY2TjlyMFk4TnE1bXpGZFZia3lqald6Qndjdm5SZGdoUGkyTVA1?= =?utf-8?B?SG9XNG91U1dwYkg4cnBVVU92OVFkL0FHZnlQOHJTanIwREplbVVWR3BUUm02?= =?utf-8?B?Nzg0MFh4a2VmMjZZa0JqZlVNcko5NkZtZmVmY1ZXMGc1NG5IL3ZCdTVOakxT?= =?utf-8?B?SnFKT1lYQml3dzFlbXhqSnV6ZlN6UlA1OTNQNDNaOXg3U1BMKzVlMmFBMkJQ?= =?utf-8?B?TFRUTDlldW91emNZTTVxRGZ2RGdvQVQ3VEVMTTU5S1Q3V01KRElKYTI3TTFq?= =?utf-8?B?SG42ajRPWW5vZCtoWG43dTBNWEZQLzhFc3VnWDVucks2UkgzcEEyYW1jbHRT?= =?utf-8?B?S2lTK2tLNUZqSVBGR2NhNDE0aXhrSGVxb0JxQ0lFSVlUN29MZ3U5THFsakc2?= =?utf-8?B?bGQ5LzB1YjdqUGUrUi9WMWV2MEgxbFo3VWFmN2I5YXlGRDEvMXpGRFN0Z1Bn?= =?utf-8?B?OWpocVNSNDV1aW1SdEFpYnZ6MUdNYno0Q0pUN1A1T0hqS1JQWU5Od0VtSnY4?= =?utf-8?B?UDNmdnBuKzVSWkdkWVNSeHlrNmo1OEFXMUk2L21TbEJ2anVYOE5KQ29YME4z?= =?utf-8?B?b0dhRjRiOWNHYjRRTVRueDNSRytNVEF5QWhrRVhKWGtGUkxEZ1JEa1lOWkRY?= =?utf-8?B?eHdYbGE1dW9hT0lNOGova1R1V0U5MzZZb29VZ1NNZFdOTVhQUS9mYlk1M0Zs?= =?utf-8?B?OUw1eXh0Zjl4cWxDQ1NVMlVxb2RYUFBUM0Y2TnBmd2N4NlZLbTRBblhPMWRj?= =?utf-8?B?ZTVmbGh3cVFhTUdOaEwybTMyUU0vUzc1Q3JDbUpXZzBacEpmU1I0WVB6eXEx?= =?utf-8?B?MmhRc0I1TDV3TXJpQ29qSmROSHhGWUZlZ3dWRGZZVTkxdnYxL0cxVVZaQjlW?= =?utf-8?B?eDgxS2JoL2YvTzFyYUU1U0luOGFWdEloaVNadkhOaTRqa1kyejlKdjBWZTFy?= =?utf-8?B?WUxoaHlQOTF1bFpVSzFIdU5mcHIyNnJnQnRrUWJEUnhjcU4yUWNGQ1Blbk9L?= =?utf-8?B?bGxERnJGUzRacFB4eXQ3N0ZmYTJiU041b25VU0NFN2RwYTJPRnE3WjNGTzJC?= =?utf-8?B?V1FIVkE0bUdqYlJKVkxCeWVEZUFwVThCOFhIMUFKYnFpVDRpT1lZeGlsRWRW?= =?utf-8?B?UUxSeWFhSmV5ZWhyYlZTdTFJU2NXcXRzM3drNzN3Vm5KM2xiSFVpbXpZREQy?= =?utf-8?B?MnozS2V4ek1RTmFBZURvSzU0bWUvNHhKN1hYNGt0N0dnU1J3WHpoZW41NjBM?= =?utf-8?B?K2pEclJSODU3anM0V3hvTkwvcCtkRFZsSjdGMmpZeHpSZVU1YlNFOWxaWkRT?= =?utf-8?B?TWQwb0hUM3FBVE5xSU5xUTJIcmM0NmZsY3NCa1ZXaDUrTkhZVlF5Tk5jRkVV?= =?utf-8?Q?cn7FWRzYcbpkQ8RQ1FE520ax+zs3TNyTKkz1jkw?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 46a430fe-c20c-4cbd-eccf-08d94dc6d6db X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2021 10:44:25.5775 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MqTlrpIWBeCSICKQcHvri3XCQWVY1OHyqDZ1u25O9oiKg1riKFu9YhsV8UndH+5q5UNGbbR/LG6VssJsGjXNrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0102 Archived-At: Subject: Re: [core] CoRE Agenda for IETF 111 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 10:44:34 -0000 --TN5RaVEKkYGJAPNztMGCEIxCv4UExMvcK Content-Type: multipart/mixed; boundary="99IxePsOY8n03iWzApcXXe3e2IVQnBWKh"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <5c62b88f-1d64-19a4-e9bf-ad319bffc4f4@ri.se> Subject: Re: [core] CoRE Agenda for IETF 111 References: In-Reply-To: --99IxePsOY8n03iWzApcXXe3e2IVQnBWKh Content-Type: multipart/mixed; boundary="------------64BE69BA735C38946F100E92" Content-Language: en-US This is a multi-part message in MIME format. --------------64BE69BA735C38946F100E92 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, Just a kind reminder to the presenters of our session on Wednesday. Please, upload your presentations as a PDF on the Datatracker [1], no=20 later than Tuesday, the 27th of July, at 14:00 UTC. Thanks to those who have already uploaded their slides! Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/111/session/core On 2021-07-14 19:21, Marco Tiloca wrote: > Dear all, > > An agenda based on what has been submitted and on recently ongoing=20 > activities is now available at: > > https://datatracker.ietf.org/doc/agenda-111-core/ > > > Those who want to run a slot, please: > > - check the person suggested to run the slot and possibly provide an=20 > alternative; > - check that the estimated time for the slot is ok > > > Please, send a mail with this information or other comments to=20 > core-chairs@ietf.org > > > Best, > Marco and Jaime > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --------------64BE69BA735C38946F100E92 Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Za= RDP C4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt0G4Ck= Unq 5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6= NHf EWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QO= XrX MGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpb= G9j YSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLB= BYC AwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JNWDTX6h1MUsgejwj4R= Xs6 UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s86ncVygiDUh9fbSDTcuzOp2qgu9nsc= 8sE sYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4M= xMh mi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0K= nXl AczWxCD3J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZs= zJe TvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZkt= A5Y 2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFboHwJaeKZ6s3dCGpzDlV6bLrRM= 9LN /sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4LK4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgS= E/F 26QK2VL9Y/ur5BHgUI34mUar4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgi= YgG QeDvlisWb9NtsxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxz= s6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFCzwWDB4Yfg= AAK CRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod5Njc1jlXqItPKDXzvmTJA= Cy7 JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF9tNL38mzm8emh5vV3XDy8arElEP7bE9Jf= gm2 3Lm9OEwubbtjLYf0z7poncThsYUuaEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+l= alf GS+9OSv9nJD9mdoTNk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXAC= iGG 0zpK666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVSnWWQF= v/9 2zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As1S6e/OC5Mdo5jQhe0= Ozj u5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgtdoCsRRQQxWME8+V95FqsleNd1QfEU= /jM +HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG= 8x2 rFxUOQ7B2DqmxBrRX3GLokNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ= 84o zNX5q52bRceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUCV= I16 cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggAhFyfi+VlqgIj5= a54 npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35HBXZvuFGn5DHBUYhqBFWTx+H5= zHg GBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47OyDDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+= BF9 wtDs6M6YAs9GdHIDhvUJWGDhOZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmt= JXP +QtZRfSaabFxCVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1v= gai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFufWd/D/9PO= 2eZ HdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1Uxu3gbtJoQ4PbT9rJan4Oe= m7/ NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDzALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6= gEq /+3+KROA0ZKEDWcE2rVEzw4UEv37BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5Z= kaS LN6kFoZPZFhrf0fhlLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4= G4D vUAYt5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13YYlqw= g9A yIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw9EpnqLWkWgm5KbT+J= 9h/ tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPzCf3do08MiLWTRVcrY6pXVTGAF/c41= uC6 520+RFm4ytAfrefNac1+5eZBG5k84sTdV9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKX= XPF djMJtVRWSZ/gzaBE7cbELu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02T= WFy Y28gVGlsb2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3B= BMB CAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQOWNpDAS8IAIko8= kg8 YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLfzZ7gNtprJatBEV6fRotIW7NtT= gFf g79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZ= lfh EOO7LALzyLVXELAxYZplGVSs9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8R= e05 8j1ncd6p4jw6QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC= 6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6ZhVzbaLJW= oAR ebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZYi61xhUK32J6iS6W2Siv0E= GhB U+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0mdRsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRo= SgO yqwZWNnAKF84yDk7IWb3RCOkjDybS4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSd= HYs OHVKEPb0VasVlI1VUJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O= 08z UMLCCCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi8uYfJ= xWw VdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HUR4DxiPdo7PQ1tTJ/k= Zb6 Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6I8qLaN7H41Wh2GM5UZfDwSFgaR5ku= /Kc cRuiIszhNvI9tVH0ex1WooZVMPEpITedqajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2n= Nou 6GZ+clFzXYfk1VkRmYT8SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy= 04S XLkLo0K7Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------64BE69BA735C38946F100E92-- --99IxePsOY8n03iWzApcXXe3e2IVQnBWKh-- --TN5RaVEKkYGJAPNztMGCEIxCv4UExMvcK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmD6nYcFAwAAAAAACgkQ7iZktA5Y2kMD rwgAo5AUhnJULLuZloF8l/gD7/D3NVJSEdkSwZO8X+n+ONRPcNDtOw/r3+OaUyOEl78mJtr4Hed4 7FwdNSI9TqiHvr3onj8nowZSCtjYtD1fZcBNKYSXl329d0IzdX0xYdOjY33Uz/o1+6szETMw5Sha oTYKxRWZyZw6h2YChJrkoLGKGeORoJVXiaXkSp0LK1ARq5Ttw8A7N1yIPEfyfnwD5/AnnJaNHbHQ QhIqdeVnEFoQRxl6TDhRv26qgCD2Q9jtZgQImAiPJQt2pNv2GLLYcUTRDfG3CoacGCyUnqlxmbAe jf5zo0xL7gK9HZejJCfi5vv/b6XpeZjNAXYAOLwNyg== =o8Xe -----END PGP SIGNATURE----- --TN5RaVEKkYGJAPNztMGCEIxCv4UExMvcK-- From nobody Fri Jul 23 06:51:58 2021 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 A8F473A07E2; Fri, 23 Jul 2021 06:51:53 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 axfzLdzk8B_4; Fri, 23 Jul 2021 06:51:48 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D81E3A09F7; Fri, 23 Jul 2021 06:49:21 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GWVzf05cMz31R1; Fri, 23 Jul 2021 15:49:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Fri, 23 Jul 2021 15:49:17 +0200 X-Mao-Original-Outgoing-Id: 648740957.587602-e33cb6a4aea9502c016b0a802ba892f4 Content-Transfer-Encoding: quoted-printable Message-Id: <2CC42F46-8FB8-4083-956B-6267DF04DB61@tzi.org> References: <985EBCFE-9783-4C7C-BEA7-D7F975AED7A5@tzi.org> <074D2AD7-BA13-41ED-8C9C-2145036C89CF@tzi.org> To: t2trg@irtf.org, asdf@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [T2TRG] [Asdf] T2TRG/WISHI/ASDF/CoRE hackathon @ IETF111: Thursday 20th 1400Z X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 13:51:54 -0000 =E2=80=A6 and the last one for this hackathon week: https://codimd.ietf.org/hackathon-2021-t2trg-111-friday start time: 2021-07-23 14:00:00 UTC duration: 60 = https://meetings.conf.meetecho.com/interim/?short=3D199772c0-3880-461b-993= b-94828a1239dd = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DIETF111+hackat= hon+T2TRG-WISHI-ASDF-CoRE&iso=3D20210723T14&ah=3D1 We=E2=80=99ll mostly focus on wrapping up and presenting results in the = evenening hackathon finale. Notes from yesterday=E2=80=99s meeting are at = https://codimd.ietf.org/hackathon-2021-t2trg-111-thursday See you in 10 min... Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 24 16:13:16 2021 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 CA4D43A0A19; Sat, 24 Jul 2021 16:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 bntofcYhPoIH; Sat, 24 Jul 2021 16:13:06 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6673A0A16; Sat, 24 Jul 2021 16:13:06 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GXMRf1JKcz2xJx; Sun, 25 Jul 2021 01:13:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Sun, 25 Jul 2021 01:13:01 +0200 Cc: cbor@ietf.org, 6MAN <6man@ietf.org>, core@ietf.org X-Mao-Original-Outgoing-Id: 648861181.448921-0dec9112deba25bccb8959bcc45025f9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> To: Erik Kline X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Interface names (Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2021 23:13:11 -0000 > On 2021-07-25, at 00:42, Erik Kline wrote: >=20 > Michael, >=20 > Thanks for the update. >=20 > Was there any interest in figuring out a representation for link-local = addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included = either an interface name or index as part of a structured unit? Perhaps = some generic {address_info, interface_info} pairing that could be used = the same way? Interesting. We just discussed this in the design team for = draft-ietf-core-href, which is maybe the more likely case where an IP = address is paired with an interface name. This can be added, but we = didn=E2=80=99t quite see such a strong use case. Interface names are = local, so it doesn=E2=80=99t make a lot of sense to carry them around = between systems, which is where CBOR is mostly used these days. > Obviously, it's possible to pair what you've described here together = with extra interface information separately on an ad hoc basis. Yes, but somehow, this question has come up often enough now that I=E2=80=99= ll add a design to draft-ietf-core-href-06. We can always delete that = feature again later. Gr=C3=BC=C3=9Fe, Carsten >=20 > Curious, > -ek >=20 > On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson = wrote: >=20 > internet-drafts@ietf.org wrote: > > Title : CBOR tags for IPv4 and IPv6 addresses and = prefixes > > Authors : Michael Richardson Carsten Bormann > > draft-ietf-cbor-network-addresses-05.txt Pages : 8 Date : = 2021-07-12 >=20 > > Abstract: This document describes two CBOR Tags to be used with = IPv4 > > and IPv6 addresses and prefixes. >=20 > > The IETF datatracker status page for this draft is: > > = https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/ >=20 > > There is also an HTML version available at: > > = https://www.ietf.org/archive/id/draft-ietf-cbor-network-addresses-05.html >=20 > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-network-addresses-05 >=20 > The major differences since -04 is that we now have three forms: >=20 > 1) IPv4 or IPv6 address. > 2) IPv4-prefix/len or IPv6-prefix/len > new: 3) IPv4-addr/len or IPv6-addr/len >=20 > The difference between (2) and (3) is that (2) is just the prefix, and = the > bits to the right MUST be zero, and MAY be omitted. (A bit win for = IPv6/32 or > Ipv6/48s..). > In the case of (3), this is more of an interface definition, like: > 2001:db8::1234/64 the "::1234" is to the right of the /64. > 192.0.1.4/24 ".4" is to the right of the /24, and is the = interface definition. >=20 > Cases (2) and (3) are distinguished by order of data vs prefix. > (2) is: [64, h'20010db8'] > (3) is: [h'20010db8_00000000_00000000_00001234', 64] > We can do this in CBOR, because it is self-describing. > Note that (2) is much shorter than (3), because trailing zeroes are = omitted. > (3) is always 18 or 19 bytes long. (1 byte for CBOR array prefix) >=20 > Prefix longer than 24 require two bytes to encode the integer. > (I guess we could have made the prefixlen be length-24, and then up to = /48 > would fit into a single byte integer. We could also have made the = negative > integers represent multiples of -4 perhaps) >=20 > I don't personally have a use case today for (3), but there were not = many > objections to including it. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sat Jul 24 16:36:48 2021 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 693AB3A0B21; Sat, 24 Jul 2021 16:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPs7qjqEYuzi; Sat, 24 Jul 2021 16:36:36 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 9E8053A0B1F; Sat, 24 Jul 2021 16:36:36 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id z26so6423375oih.10; Sat, 24 Jul 2021 16:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EZgTWwv1bnlNwmAMcLVGlZiCBkCRb5jFSMWTlzPml30=; b=fRgQVY6m0dF6Xl5uTul3dFf+HPDK87FgFZmA9yTGPCKao6e1V6MHvfKmey/wyOYI1X p+zxS86VtDbUbirjESV5qIgvPO1aA96+kwXG1pCyw0d9/ydywFKTgBcUFrw2RFffUeUG t0oAM7WSPw6aRZBTkTujcIgyDnCrvkmrr6RduSpElaAqrNAdwvoXh50aZo3EGGUJdlls Mg0PAvBcnqvBPWPT9i8RmidbKuEQRkPu5s9wCaXGAy4L4eUOk4sVM5qPkUjR5CbZ1fiw oNC9IVGvTaOYPJpW3mjLjCNTWkIRcB/Z/y8N+faH8UYO4Ujc3ZiGoodaWVl199rM70PK vDMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EZgTWwv1bnlNwmAMcLVGlZiCBkCRb5jFSMWTlzPml30=; b=NYzS5DvkBQMXpw7v8INL/Ul+LxbWo25jCqdrVg5LID+QiTheZG0qDdHssCMqcyz30E jzG0J6bTlEA0HopY7M2cPsjdNYG8y/y4pR9jCy/jnRN6fZVABh6Mj6JbSarZFPFldWxm KAGNHXYGQ85PB6rs1xTiIQMDaku60O+D/pwm/Ol8/rK4X/XlLbibpBYK7cHmhqIYTzKo M5Jymo1bSkoR+YL+Gqc6AZtv/RHQopk9LzipabXtFE+h3/9dqVMKGexIbyacXGkUJOxp aZZwYwyJViabWseWAFi5sLbHFF4sDsWZWqH4p0e82ZykLfpYaQ/B65+y4ULpaFKPN5Cw 23dA== X-Gm-Message-State: AOAM531Q1FQNSBB7niSEs5EdA3TR7jCGMR29RPwDAQsiDceupCnvAv7Q kL5s91QyGvUYPnNR528SPvdz5tqgssXaWvh4V/o= X-Google-Smtp-Source: ABdhPJy0RqWV8kptk+eGwVMpmnT1p/S+GOVaeutkZw2Ghb8+lZ4ysiOkr6UlMInMZhro8C5cSL0TixtICV+ZLEGWNlY= X-Received: by 2002:aca:2b07:: with SMTP id i7mr13207449oik.97.1627169795194; Sat, 24 Jul 2021 16:36:35 -0700 (PDT) MIME-Version: 1.0 References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> In-Reply-To: From: Erik Kline Date: Sat, 24 Jul 2021 16:36:24 -0700 Message-ID: To: Carsten Bormann Cc: cbor@ietf.org, 6MAN <6man@ietf.org>, core WG Content-Type: multipart/alternative; boundary="000000000000a1c1c805c7e6fd38" Archived-At: Subject: Re: [core] Interface names (Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2021 23:36:43 -0000 --000000000000a1c1c805c7e6fd38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, your point about interchange between systems seems important. Following YAGNI , maybe this is not necessary until there's a use case for something within a node (some CBOR-encoded communication among processes on the same box, perhaps). If it keeps coming up though, maybe it's just worth a sentence to say why it's left for some other time/document (confession: I haven't read -05). Thanks though! On Sat, Jul 24, 2021 at 4:13 PM Carsten Bormann wrote: > > > > On 2021-07-25, at 00:42, Erik Kline wrote: > > > > Michael, > > > > Thanks for the update. > > > > Was there any interest in figuring out a representation for link-local > addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included > either an interface name or index as part of a structured unit? Perhaps > some generic {address_info, interface_info} pairing that could be used th= e > same way? > > Interesting. We just discussed this in the design team for > draft-ietf-core-href, which is maybe the more likely case where an IP > address is paired with an interface name. This can be added, but we didn= =E2=80=99t > quite see such a strong use case. Interface names are local, so it doesn= =E2=80=99t > make a lot of sense to carry them around between systems, which is where > CBOR is mostly used these days. > > > Obviously, it's possible to pair what you've described here together > with extra interface information separately on an ad hoc basis. > > Yes, but somehow, this question has come up often enough now that I=E2=80= =99ll add > a design to draft-ietf-core-href-06. We can always delete that feature > again later. > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > Curious, > > -ek > > > > On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson < > mcr+ietf@sandelman.ca> wrote: > > > > internet-drafts@ietf.org wrote: > > > Title : CBOR tags for IPv4 and IPv6 addresses and prefixe= s > > > Authors : Michael Richardson Carsten Bormann > > > draft-ietf-cbor-network-addresses-05.txt Pages : 8 Date : > 2021-07-12 > > > > > Abstract: This document describes two CBOR Tags to be used with > IPv4 > > > and IPv6 addresses and prefixes. > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/ > > > > > There is also an HTML version available at: > > > > https://www.ietf.org/archive/id/draft-ietf-cbor-network-addresses-05.html > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-network-addresses-05 > > > > The major differences since -04 is that we now have three forms: > > > > 1) IPv4 or IPv6 address. > > 2) IPv4-prefix/len or IPv6-prefix/len > > new: 3) IPv4-addr/len or IPv6-addr/len > > > > The difference between (2) and (3) is that (2) is just the prefix, and > the > > bits to the right MUST be zero, and MAY be omitted. (A bit win for > IPv6/32 or > > Ipv6/48s..). > > In the case of (3), this is more of an interface definition, like: > > 2001:db8::1234/64 the "::1234" is to the right of the /64. > > 192.0.1.4/24 ".4" is to the right of the /24, and is the > interface definition. > > > > Cases (2) and (3) are distinguished by order of data vs prefix. > > (2) is: [64, h'20010db8'] > > (3) is: [h'20010db8_00000000_00000000_00001234', 64] > > We can do this in CBOR, because it is self-describing. > > Note that (2) is much shorter than (3), because trailing zeroes are > omitted. > > (3) is always 18 or 19 bytes long. (1 byte for CBOR array prefix) > > > > Prefix longer than 24 require two bytes to encode the integer. > > (I guess we could have made the prefixlen be length-24, and then up to > /48 > > would fit into a single byte integer. We could also have made the > negative > > integers represent multiples of -4 perhaps) > > > > I don't personally have a use case today for (3), but there were not ma= ny > > objections to including it. > > > > -- > > Michael Richardson . o O ( IPv6 I=C3=B8T > consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > --000000000000a1c1c805c7e6fd38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, your point about interchange between systems seems imp= ortant.=C2=A0 Following YAGNI,=C2=A0maybe this is not necessary until there&#= 39;s a use case for something within a node (some CBOR-encoded communicatio= n among processes on the same box, perhaps).

If it keeps= coming up though, maybe it's just worth a sentence to say why it's= left for some other time/document (confession: I haven't read -05).

Thanks though!

On Sat, Jul 24, 2021 at 4:13 PM = Carsten Bormann <cabo@tzi.org> wr= ote:


> On 2021-07-25, at 00:42, Erik Kline <ek.ietf@gmail.com> wrote:
>
> Michael,
>
> Thanks for the update.
>
> Was there any interest in figuring out a representation for link-local= addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included eith= er an interface name or index as part of a structured unit?=C2=A0 Perhaps s= ome generic {address_info, interface_info} pairing that could be used the s= ame way?

Interesting.=C2=A0 We just discussed this in the design team for draft-ietf= -core-href, which is maybe the more likely case where an IP address is pair= ed with an interface name.=C2=A0 This can be added, but we didn=E2=80=99t q= uite see such a strong use case.=C2=A0 Interface names are local, so it doe= sn=E2=80=99t make a lot of sense to carry them around between systems, whic= h is where CBOR is mostly used these days.

> Obviously, it's possible to pair what you've described here to= gether with extra interface information separately on an ad hoc basis.

Yes, but somehow, this question has come up often enough now that I=E2=80= =99ll add a design to draft-ietf-core-href-06.=C2=A0 We can always delete t= hat feature again later.

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


>
> Curious,
> -ek
>
> On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson <mcr+ietf@sandelman.ca>= wrote:
>
> internet= -drafts@ietf.org wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title : CBOR = tags for IPv4 and IPv6 addresses and prefixes
>=C2=A0 =C2=A0 =C2=A0> Authors : Michael Richardson Carsten Bormann >=C2=A0 =C2=A0 =C2=A0> draft-ietf-cbor-network-addresses-05.txt Pages= : 8 Date : 2021-07-12
>
>=C2=A0 =C2=A0 =C2=A0> Abstract: This document describes two CBOR Tag= s to be used with IPv4
>=C2=A0 =C2=A0 =C2=A0> and IPv6 addresses and prefixes.
>
>=C2=A0 =C2=A0 =C2=A0> The IETF datatracker status page for this draf= t is:
>=C2=A0 =C2=A0 =C2=A0> http= s://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/
>
>=C2=A0 =C2=A0 =C2=A0> There is also an HTML version available at: >=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/archive/id/draft-ietf-cbor-network-addresses-05.html=
>
>=C2=A0 =C2=A0 =C2=A0> A diff from the previous version is available = at:
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-network-addresses-05=
>
> The major differences since -04 is that we now have three forms:
>
> 1) IPv4 or IPv6 address.
> 2) IPv4-prefix/len or IPv6-prefix/len
> new: 3) IPv4-addr/len or IPv6-addr/len
>
> The difference between (2) and (3) is that (2) is just the prefix, and= the
> bits to the right MUST be zero, and MAY be omitted. (A bit win for IPv= 6/32 or
> Ipv6/48s..).
> In the case of (3), this is more of an interface definition, like:
>=C2=A0 =C2=A0 2001:db8::1234/64=C2=A0 the "::1234" is to the = right of the /64.
>=C2=A0 =C2=A0 192.0.1.4/24=C2=A0 =C2=A0 =C2=A0".4" is to the ri= ght of the /24, and is the interface definition.
>
> Cases (2) and (3) are distinguished by order of data vs prefix.
> (2) is:=C2=A0 =C2=A0[64, h'20010db8']
> (3) is:=C2=A0 =C2=A0[h'20010db8_00000000_00000000_00001234', 6= 4]
> We can do this in CBOR, because it is self-describing.
> Note that (2) is much shorter than (3), because trailing zeroes are om= itted.
> (3) is always 18 or 19 bytes long. (1 byte for CBOR array prefix)
>
> Prefix longer than 24 require two bytes to encode the integer.
> (I guess we could have made the prefixlen be length-24, and then up to= /48
> would fit into a single byte integer.=C2=A0 We could also have made th= e negative
> integers represent multiples of -4 perhaps)
>
> I don't personally have a use case today for (3), but there were n= ot many
> objections to including it.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3= =B8T consulting )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sandelman Software Works Inc,= Ottawa and Worldwide
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- > _______________________________________________
> CBOR mailing list
> CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor

--000000000000a1c1c805c7e6fd38-- From nobody Sat Jul 24 19:03:36 2021 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 746B53A0DE9; Sat, 24 Jul 2021 19:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 besExOd9C1-t; Sat, 24 Jul 2021 19:03:28 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4363A0DE8; Sat, 24 Jul 2021 19:03:27 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GXRDD6416z2xKs; Sun, 25 Jul 2021 04:03:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann Date: Sun, 25 Jul 2021 04:03:24 +0200 Cc: draft-ietf-core-href@ietf.org X-Mao-Original-Outgoing-Id: 648871404.302268-602d3c9bc187d0cae4b9245d8eacb579 Content-Transfer-Encoding: quoted-printable Message-Id: <5FAAEE85-669A-450D-9C96-AF675599E4B1@tzi.org> To: core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] draft-ietf-core-href (CRIs) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 02:03:34 -0000 I have updated draft-ietf-core-href with all the results of the latest = discussions. The last major change was: +* rework authority: + * split reg-names at dots; + * add optional zone identifiers {{-zone}} to IP addresses I can=E2=80=99t submit this as an I-D for another 5 hours, but a diff is = at=20 = https://tools.ietf.org/rfcdiff?url1=3Dhttps://core-wg.github.io/href/draft= -ietf-core-href.txt&url2=3Dhttps://core-wg.github.io/href/ietf111/draft-ie= tf-core-href.txt and the full version is at: https://core-wg.github.io/href/ietf111/draft-ietf-core-href.html We need to discuss whether the latest changes were desirable, and when = we have reached diminishing returns. If you have any comments, please send them here (or to the authors in = CC, or as issues or PRs). Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 25 04:27:15 2021 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 80B8A3A263C; Sun, 25 Jul 2021 04:27:13 -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: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162721243346.15633.14948192852821317741@ietfa.amsl.com> Date: Sun, 25 Jul 2021 04:27:13 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-href-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 11:27:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Resource Identifiers Authors : Carsten Bormann Henk Birkholz Filename : draft-ietf-core-href-06.txt Pages : 19 Date : 2021-07-25 Abstract: The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-href-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-href-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 25 04:30:55 2021 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 360903A2654; Sun, 25 Jul 2021 04:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 sPwUPaXFSMxl; Sun, 25 Jul 2021 04:30:49 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBF63A2652; Sun, 25 Jul 2021 04:30:48 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GXgpt17Bsz2xL6; Sun, 25 Jul 2021 13:30:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <5FAAEE85-669A-450D-9C96-AF675599E4B1@tzi.org> Date: Sun, 25 Jul 2021 13:30:45 +0200 Cc: draft-ietf-core-href@ietf.org X-Mao-Original-Outgoing-Id: 648905445.767141-eed56f59eb4b9536b0551803e10a23a7 Content-Transfer-Encoding: quoted-printable Message-Id: <8CB32133-0B07-4F06-9F26-1E02C9A55857@tzi.org> References: <5FAAEE85-669A-450D-9C96-AF675599E4B1@tzi.org> To: core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] draft-ietf-core-href (CRIs) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 11:30:53 -0000 =E2=80=A6 and, after a quick comment from Brian Carpenter (thank you!), = this is now in draft-ietf-core-href-06. We won=E2=80=99t have much time in Wednesday=E2=80=99s CoRE meeting to = discuss this, so please do send input to the list first. Gr=C3=BC=C3=9Fe, Carsten The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-href-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-href-06 > On 2021-07-25, at 04:03, Carsten Bormann wrote: >=20 > I have updated draft-ietf-core-href with all the results of the latest = discussions. The last major change was: >=20 > +* rework authority: > + * split reg-names at dots; > + * add optional zone identifiers {{-zone}} to IP addresses >=20 > I can=E2=80=99t submit this as an I-D for another 5 hours, but a diff = is at=20 >=20 > = https://tools.ietf.org/rfcdiff?url1=3Dhttps://core-wg.github.io/href/draft= -ietf-core-href.txt&url2=3Dhttps://core-wg.github.io/href/ietf111/draft-ie= tf-core-href.txt >=20 > and the full version is at: >=20 > https://core-wg.github.io/href/ietf111/draft-ietf-core-href.html >=20 > We need to discuss whether the latest changes were desirable, and when = we have reached diminishing returns. >=20 > If you have any comments, please send them here (or to the authors in = CC, or as issues or PRs). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Jul 25 09:46:29 2021 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 B628A3A316A; Sun, 25 Jul 2021 09:46:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Kg50lN0gugLG; Sun, 25 Jul 2021 09:46:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C003A316E; Sun, 25 Jul 2021 09:46:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 379CA389B5; Sun, 25 Jul 2021 12:49:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O4nGW4VbU-l4; Sun, 25 Jul 2021 12:49:51 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 77916389B4; Sun, 25 Jul 2021 12:49:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B90741CB; Sun, 25 Jul 2021 12:46:12 -0400 (EDT) From: Michael Richardson To: Christer Holmberg cc: Carsten Bormann , "stokcons\@bbhmail.nl" , "core\@ietf.org" , "anima\@ietf.org" In-Reply-To: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 16:46:23 -0000 --=-=-= Content-Type: text/plain Christer Holmberg wrote: > Maybe not exactly what people are looking for, but below is a link to > the thin-ICE presentation from the T2TRG 2019 session in Singapore. No, not what we want. We just want to prove connectivity as part of debugging what's going on. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD9lVQACgkQgItw+93Q 3WVNDggArYbFmLi9BHj2xv2oDkDkWB3oesUHH0R0pqiLZ3olq5KotyNnQKCdDjoA ZC5Nty/z39xLe8sb4cwAUgz8EHzVS3Gc4bQHjhSDddYK3QrA9GSYdDcCMkDDY9cU BO/6TLxfah5YYNnA474iMPW5sB4WrupAg2lCFFnm+3MBjQ/6uuVGohDFR0eW835S RaWajDa20YA8BXNjk/7rRNPSAtzNcFfiuSwundZW9Uzc0KgeH9oXawJIUFn8zDdy LnUWp7BKQFr1CPw0autprAONWW4hpk5BJBUyI2mnwyMZPKwPwwied/vUvzP+5lRn JuXu1ZqInpXirL65vXFWlsYdJfPLGg== =yDYa -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 25 09:47:47 2021 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 ED1733A3177; Sun, 25 Jul 2021 09:47:45 -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, SPF_HELO_NONE=0.001, 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 rbSJJQkzPg6X; Sun, 25 Jul 2021 09:47:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEA23A3173; Sun, 25 Jul 2021 09:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D8B883898F; Sun, 25 Jul 2021 12:51:17 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LjCLTZD5L5ia; Sun, 25 Jul 2021 12:51:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B4AFB38988; Sun, 25 Jul 2021 12:51:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 993AE1CB; Sun, 25 Jul 2021 12:47:34 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: stokcons@bbhmail.nl, core@ietf.org, anima@ietf.org In-Reply-To: References: <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <18975.1626788349@localhost> <25674.1626896178@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: Re: [core] [Anima] constrained resources at root for debugging connectivity X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 16:47:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2021-07-22, at 09:45, Carsten Bormann wrote: >> >> Time for me to update the coaping gem=E2=80=A6 > Done: > VERSIONS: > =E2=80=A2 0.0.2 - July 22, 2021 (5 KB) Yes, but DTLS? I'll see about adding it in my copy, but my DTLS additions to coap gem are rough. I guess my changes to OpenSSL are only required by the server s= ide. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD9laYACgkQgItw+93Q 3WV+GQf/UUp0k+2aPkBxhAlDt8r0yst8sxrWsReYB/zwy60Uln7Nq9LGXs/P4UdI x+6NfmbUGEtSNYvUJHI/XOxSaTheubkIrq7yzxacoZvCWXX8M4JxS4cWTghjkRn1 4N4rEIBmU/ECAFIppG0A/kj+6xrvpIir3ouuQLgREk3/+OX+LY68ZItdxawx4DG0 oFIAW60dL7zEbuQEbOOeipFria3osM9Z1wOp+MOViE+lVcO3z0TQ3oN+82+50lcm qeRR8OHPxY9/KnGg+XaNR0p1D4r8FYkMj2FcX3HonqPShZnGnX20dj4WTifg/TG1 Weglv+WvY2o/W+BIExUNP5zRZ9cnIw== =XUul -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 26 02:07:32 2021 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 4DFFD3A21EF; Mon, 26 Jul 2021 02:07:31 -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_HELO_NONE=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 QrbNSK1ucNsw; Mon, 26 Jul 2021 02:07:28 -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 56E613A21EA; Mon, 26 Jul 2021 02:07:24 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B7E65401B5; Mon, 26 Jul 2021 11:07:21 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6DB83D0; Mon, 26 Jul 2021 11:07:20 +0200 (CEST) Received: from hephaistos.amsuess.com (77.119.209.226.wireless.dyn.drei.com [77.119.209.226]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 041BB46; Mon, 26 Jul 2021 11:07:19 +0200 (CEST) Received: (nullmailer pid 2919482 invoked by uid 1000); Mon, 26 Jul 2021 09:07:19 -0000 Date: Mon, 26 Jul 2021 11:07:19 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-dynlink@ietf.org, draft-ietf-core-dynlink.chairs@ietf.org Cc: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GJjHwlEUH2Vr1C1e" Content-Disposition: inline Archived-At: Subject: [core] IPR confusion between dynlink and conditional-attributes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 09:07:31 -0000 --GJjHwlEUH2Vr1C1e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello conditional-attributes and dynlink authors and chairs, the data tracker shows 3 IPR items on dynlink and none for conditional-attriutes. Judging from the statement titles on the former ("to govern measurement evaluation when in Power-Save-Mode"), I think it'd stand to reason to reassess their applicability, and probably move the statements over to conditional-attributes where they probably belong. BR c --=20 Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Terry Pratchett (attributed) --GJjHwlEUH2Vr1C1e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD+e0MACgkQOY0REtOk veGH1xAAzdbn3JZ9g0indZmyIqKadGizOdBgFzwfWuZ3rO35vb2ztgOChd1fasOu CEJIxZvE0PRMCHAQ6prRkD+qQ9cEt2xiqdunvntEgpQ0me65zX7AjdXimX7XTbvs MDuOyStZFHf5iR2Qt0iDhXx/JuiCc8vID5w/AHHcIu4NWwP0Hkt3xKeJ7FjCVeS4 YIB+mCFP6h7bd3x8pbqiISxbCMTF0I5m59QS7/iXFtCPvEBvXWPFqicDF2tBxWfA RIdwLsqZtezob7ZbmvUe0SIiv2IK17SbbhYQyuoGUHUcgqFhyg5V8qMkt89LKK21 LEnjsDogfLUzktWaTKo/5mVX8/A5N81XlM2vVM6zHvgwDGmUjhLKGwNrp7f8MGb6 e4M+um/Jmyv54C5m2+HQC8MmTSe6/1i/LN96alkb031gT6DcOsDDTGqD7SwIghyv jUzrhiu15pZT1/f2xKJTKgsrjqrwUiw+iEmGz2v1WyQ6PbGLPdjk7nRGmXoQVwTp DyMzF9kEoZY//W9CiH+C4vHGBrNUrSG+3NIY3bBuieZCO9wh9iWlc6QCfu7ViIDo +i8GUsZEbMIJEz8bOb2q8wB0RhoBbskRZqvMlGwqSDU9okI1dM9IeOdagUmBw1EY UdihjtUF8ODSGceWQs0gvvPfkPcBc+BWsO/dfDBQ8dHSsiFrVFU= =gtrR -----END PGP SIGNATURE----- --GJjHwlEUH2Vr1C1e-- From nobody Mon Jul 26 04:11:21 2021 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 236993A0BA4; Mon, 26 Jul 2021 04:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 B8xmV88rKwg0; Mon, 26 Jul 2021 04:11:15 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (mail.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691D93A0BA3; Mon, 26 Jul 2021 04:11:15 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYHKs5sjRz2xMN; Mon, 26 Jul 2021 13:11:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 26 Jul 2021 13:11:13 +0200 Cc: draft-ietf-core-dynlink@ietf.org, draft-ietf-core-dynlink.chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 648990673.415216-818e3b153f7fce3264ccf5723a531158 Content-Transfer-Encoding: quoted-printable Message-Id: <63965B25-F36E-4650-B7D0-885528B029F4@tzi.org> References: To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] IPR confusion between dynlink and conditional-attributes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 11:11:20 -0000 Not sure we can get the submitters of the notifications to update them = appropriately. This may be easier to engineer on our side. Mental note for WG chairs: When splitting the draft, don=E2=80=99t try to find good names for the = fragments, but make sure the patent claims get stuck on the right wall. = The names are going away when these become RFC anyway. I sure didn=E2=80=99t think of that! Gr=C3=BC=C3=9Fe, Carsten > On 2021-07-26, at 11:07, Christian Ams=C3=BCss = wrote: >=20 > Hello conditional-attributes and dynlink authors and chairs, >=20 > the data tracker shows 3 IPR items on dynlink and none for > conditional-attriutes. Judging from the statement titles on the former > ("to govern measurement evaluation when in Power-Save-Mode"), I think > it'd stand to reason to reassess their applicability, and probably = move > the statements over to conditional-attributes where they probably > belong. >=20 > BR > c >=20 > --=20 > Build a man a fire, and he'll be warm for a day. Set a man on fire, = and > he'll be warm for the rest of his life. > -- Terry Pratchett (attributed) From nobody Tue Jul 27 02:55:24 2021 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 080C83A1D92; Tue, 27 Jul 2021 02:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 C_XXdzZncamI; Tue, 27 Jul 2021 02:55: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 E9DE93A1D91; Tue, 27 Jul 2021 02:55:12 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E2E92401B5; Tue, 27 Jul 2021 11:55:08 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DE89ED0; Tue, 27 Jul 2021 11:55:06 +0200 (CEST) Received: from hephaistos.amsuess.com (178.115.45.57.wireless.dyn.drei.com [178.115.45.57]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 577B0101; Tue, 27 Jul 2021 11:55:06 +0200 (CEST) Received: (nullmailer pid 3010371 invoked by uid 1000); Tue, 27 Jul 2021 09:55:05 -0000 Date: Tue, 27 Jul 2021 11:55:05 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: Erik Kline , cbor@ietf.org, 6MAN <6man@ietf.org>, core@ietf.org Message-ID: References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D0qnWMT2l4O2k3sh" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] [Cbor] Interface names (Re: changes in draft-ietf-cbor-network-addresses-05.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 09:55:18 -0000 --D0qnWMT2l4O2k3sh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Carsten, groups, > Interface names are local, so it doesn=E2=80=99t make a lot of sense to c= arry > them around between systems, which is where CBOR is mostly used these > days. two applications come to mind: * RD introspection[1] uses zone identifiers in what may be described as debug output: Usually an RD won't show you a resource on a fe80:: address not on your link, but as an administrator you may need the birds-eye view. * Many network devices offer a remote way to run a ping; when the process is started via CBOR, it'd be useful to give an interface identifier. I'm not particularly advocating that we add zone identifiers to the new tags (as I can use URIs or even work around completely in the former, and don't have a pressing need for the latter) -- but with those examples, a statement like "we don't specify interface identifiers because they shouldn't be serialized anyway" would be overreaching. BR c [1]: https://www.ietf.org/archive/id/draft-amsuess-core-resource-directory-= extensions-05.html#name-zone-identifier-introspecti --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --D0qnWMT2l4O2k3sh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmD/1/IACgkQOY0REtOk veHHHBAAwWogF03FzT2380COBHrWEXew8JR/I7BMZLRDlTQvi7Mmgos0fNsLm12o uxC5cr04BkYXvT+7r+/O8/mv8bERGc3ZqUum/bIXsRh0YgD3q3dgTLcCRMqnkO3O 3gziI0yeiQztUlytY8WH3wmxoFsPI3aWqp7Er570qj54QKOvVCadWzQM+Q9KRwW1 dUlksFnsGIiz7EWDM+SidjJnBcoltVYpVx4uuDldqU3mQcGqLjFexjoqCtbmpVvb /gwb537VJ3nJI/kp5voa+5LfMvZgx7UgpyHBT6ADv0htPacPDEzXlOYk+DnL2QX4 sbf3HP7z5+ZAgF1FO4gVR5gx5k8js03UnJF6p5kfamjLRQuKekSj2zYJiLQFhoaW c6PgunbZj2n53z5tKf/myDUxVSEeUACl2vBXIMN0N6HDUSCTZVCEzQZG5wEna9Iy eRwMiG1UivhRbelw/YjY1Qdnma1zKaL40TOITVl7XvMCP1TXTlRl9pVEVoRqxXMo sQWO5z1Kd2MS1rFqNiGtbTJ+7U4PzvldiM7w0GiHsOM/eK1ZlMnrniUepBC43uEg YHNWR1ksQAj3OcLUf6XziTbYaEbKlB9TP7suzZHmrGAOrZR8h03gn0mueQ/qMd/e Q8dOJEbxSmCm0+hAQKHFv5O4dUJ6NPJ5y3S59H2zVf/xR6rqoHQ= =DNKH -----END PGP SIGNATURE----- --D0qnWMT2l4O2k3sh-- From nobody Tue Jul 27 05:22:07 2021 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 0194F3A2483 for ; Tue, 27 Jul 2021 05:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 K8PBxBkKOjXL for ; Tue, 27 Jul 2021 05:22:00 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140079.outbound.protection.outlook.com [40.107.14.79]) (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 7628E3A2481 for ; Tue, 27 Jul 2021 05:22:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dgd2iy1MLMZsqqj+CzMPqqZRXstF5ZaX1UKG9b+v22ta6U9tCcBvg6epyN1X49AvtR8iTMFsIk92KNMX9AzqApd3be4G4oHnCqg7MWr7dep+Y7OHfokpbNT9p4rSAJsO2n0Y/CT4x+Sh/f0Ppw7T+5i89w4fj2gZK3qtkjHYi7aFuIZne5TFjQU1H+/1lPE6/sMbEPUHiu66HTAJfZdbM3eoYz/BlJIA8lV2eSFqOh3wUe0STQIsllFrscxoLmf4ORGoIZjpBw/deC/0sRJds4PWjW+4u1N9rcwC/9Grlk2zQiba06X6j4zvscPPkE3Wco4CdItPivy0gwpMeY1c2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gYFbCTlUx3+MpSphCISD0er3cxi/SsZcYLkIOQXFN4E=; b=DcTW/DYoQyjXdWNmQoEWb/MR4xk7o+hZUQsVm82dnMtlN8Dy4gw/s+7g71wbCeiNp/bRvc6nFHVaGjhs7KRUVU9qz8g+knZQ/KV6/xaVGcCvQUu4kJ7ywzWjI+hFudeGXdhbMFiGeZ6jHi3hHInacTX9TijGWcp/BiMzTt9l1jero+96aU+4QnhvQ3mhP0a+XR6VJ6k+IgIGuTuhMTNgVSWDTNrKb0PBs/MX1/S6IpdsFIxzzFnvTy9OMGhD9bQ3/f4utKOsDhW+Di8dTycsqVZF4ErvHA2hIoinp48bSa4J3VaZNcH1UHK/vlWSWPAGKO/CnkKUwhEPZ3z+mzgyCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gYFbCTlUx3+MpSphCISD0er3cxi/SsZcYLkIOQXFN4E=; b=FOqIEM2ggt0xnqzBHWuP8Wk3S+NJZdSnQPDWPi1ajArZ+o0/sAouSNbQ6JVKQ7by8teJPt8qYKdU3np95L4vlX3BiAp0I0qnIWjnbaxmiGt7ElOGk2oFZeu80F7HcgbiQBCjqw4LTQ+j6TG+6ihcWU6dWkm077cDRJnKsAVFtKU= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2940.eurprd07.prod.outlook.com (2603:10a6:3:4c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.7; Tue, 27 Jul 2021 12:21:57 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b%5]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 12:21:57 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-core-coap-attacks-01.txt Thread-Index: AQHXguD62uN6MBVOcEuQQolQTbBzlqtWvKYy Date: Tue, 27 Jul 2021 12:21:57 +0000 Message-ID: References: <162738806996.26500.12234093828276493269@ietfa.amsl.com> In-Reply-To: <162738806996.26500.12234093828276493269@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 186bd5e5-2303-4173-9bac-08d950f920ce x-ms-traffictypediagnostic: HE1PR0701MB2940: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G5CxGcHESy8SzRw+Iyh0/zPwkCB+nvftlechcSBaa7vCw42tnZze0xe4AB4R4g2QWhbfYZm4ZxGh6rqxdKs7dr1aY0omE+mU4Etr8b59bSbHhfiPCdfDmuvCEHNZe+3AnU4MWYmlO3Sxy52CkLLN05tH+9eefBKb8/Xy/0pvBVNvyawab9PpGkNBISgL/55Xxv4t4Pr5n2vzZYKIt1bICN1CVivA6xW2QPzoJmfZaPgLoBhvwiUlOggk+98gjpkFql1MacUIyGisRn0BL0qagNggrp1SZclFi3Xo2L/OHfhz6LL1Ygd9jykFs4E3AZ8Hu7UI/15YdPbo31v0LmnzSIW0o2PdmoJ8ZUprlM/APetfLN6dfPznxwNok5XD2tZdYNTWGKdVEhzY87WUu9MkskjCbEIv4c0SAVMz4ETye+UM4c40hjDDNT/DDQRqLaszGexx5b5ZB4rRA8AlEYKo9A5MZXi7EWkCv7qgGtX1C2R1Wc1rS1IG0mCE5s2K1cZfOWGpQAGlVZnxYHnS4D/LbF1uN+UKw9IjXiKbRu+NvI4NtoDbEQUQMfakMVtkLfaPABUMkcsIywh7p1N1HmaiuOxufs38TvnXwNdOfwsQXK/Gux7snXrrExB/2rxOu3+DwnYdATtfx9/y78eURaVFW31SaTxDtUowAs4qpiNl3eUg0WI38p0DiuaktSaJiMpJx8FurNqsAgs9UTHZSnrrMSXKBu9cPRO5bB9NMFPmnhzL+xMnwGRAe7StPtP1BafNHG434PpAlOAIRFq3Yq/2tp7V1eg7JET2TuC9C8u5iLLqyAy5pmfAHMCyV4dsXi32 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(66446008)(66476007)(76116006)(66556008)(64756008)(166002)(6916009)(66946007)(966005)(122000001)(15650500001)(83380400001)(38100700002)(71200400001)(316002)(5660300002)(52536014)(44832011)(26005)(55016002)(6506007)(186003)(66574015)(508600001)(86362001)(33656002)(9686003)(7696005)(8936002)(53546011)(8676002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?vJg30WCxv92tCCzT/MMb6jkFdcWxxXtkVmWC6DeZICFdgFysQ9x27HasSN?= =?iso-8859-1?Q?R3gNj3lQ4qGnEmlexWL7LVT96HCaNv5sWdq1Q8G9xacljNikHMGf4FZC/T?= =?iso-8859-1?Q?/jpaZzWVnjfIqeNcyM0CBHIuScG9CqdbI6RLtx2ZfxV17k/OCbh1p5vz6J?= =?iso-8859-1?Q?VRcIxmLzZtS3An7VJ/3+YA/7ObV015JySEqhD4maOV3k2Y/cQWAsn6G7sf?= =?iso-8859-1?Q?XW1MKCPcz9YsY0H+rf/lP5cYmFMB4h30L6nNOmONceostYwgYhpkfz8uqU?= =?iso-8859-1?Q?OIutXAT+SMsqVueRUcgkjRyRYGVevg7Ry63F86HDxqVSjdYEXZaM0++WMS?= =?iso-8859-1?Q?jGKUqJB4P1rCtjk+TcZMY5BG9hwjB1RJinWZJtR3FTLCBwZs4VVcpG1wQv?= =?iso-8859-1?Q?Veen63LoxOgBFM/Y+PrdZ95ueVnDVzwGTzCWGncZiyqXMm2LqlwP/n4bmp?= =?iso-8859-1?Q?G06h95Nfl6MXKkjrL0Uy5EJMB147VChBht4wcdAh5ts8MotmYc7iW9lhtZ?= =?iso-8859-1?Q?Ask/yIAZjjgl6SBr8uMhJeZ0NOKXWl0CmnD5sOKGZBP3ckig0hENq8oCkt?= =?iso-8859-1?Q?B32w+AkzVlaWvb1fTwNE1w5cOETQ3PHz/o6WKRB71uG7rQeSZHQnUvrMEl?= =?iso-8859-1?Q?tMLwEpr1eD4+mOCasfmiNu0kOGqGEgK4CGvF3wqJC6HZiUpXTxHiJtvmYA?= =?iso-8859-1?Q?+kXIYDx6EupSTBf5jR5hqzdnm/J4MYbdBdMv2CUtRZepMFn0tnz1A4m1/O?= =?iso-8859-1?Q?HPNbDaOhbX008I1MlxbSsGh7tN0qiXByAKx51JXSOr8N9YfEhuzozOqtb6?= =?iso-8859-1?Q?DKeLyicVVyvRwpcWMnnrj+JhuDJM9F53KFuM7x7jRX7PMBwNFoOWZLCaGR?= =?iso-8859-1?Q?VSJv2aKkSWnoh0v5MkhqL0dsdbch06ldj7vfPCeNveJeIKoXkj0yVVbwWF?= =?iso-8859-1?Q?MVPocyEmrMntd/vTRG166cDqOXCLFL5q0PtHo0TErJRt6afIkVn/Cy9Y0M?= =?iso-8859-1?Q?EgSLK2tWB/omsfEfUR1/r3xSdh8qcr/rOJNOa9im+7sOTNw9C277QqSFAV?= =?iso-8859-1?Q?h6GYZTp7URdxP5mPZopLgxl7AIHM1rsTdYjgWNfaXY23eJNlkrFwdfkPHO?= =?iso-8859-1?Q?iQhwWHlbIoL5F3SzDirOgCWrJu/7E3pQm5imqjl1iWJdyTep0Qe/VMsagk?= =?iso-8859-1?Q?mM9CD4MhrmQgLuJmza8M60r2Og6slqo1e8HWQorRQq0yDvFy65K3KW1BzM?= =?iso-8859-1?Q?uRV3P+/N18XhcZzxjk76US0x/2GSY/YQs804yxWhqUsi3dI3/NfitiGtG5?= =?iso-8859-1?Q?nhkov8rfZi0HJKWXzQbOLHBxZjVwBbVND+WLwQgpehqa5OoWtHccIz8H+0?= =?iso-8859-1?Q?Xx0th/OzKl2ZPGQ1nGCspYNko9h18XFw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30501F88128EA96925703D8289E99HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 186bd5e5-2303-4173-9bac-08d950f920ce X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 12:21:57.5476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iqXXBNMy+FihEy86RRt+lFn/3RAPQtRSRkdRCXnnaWyETpBFxlqeOLCgS/2Bgi+zf3Ya36J/ohdiA8/kT8p9bx+i7rEFDv5CaJAx6dMsyh8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2940 Archived-At: Subject: [core] FW: New Version Notification for draft-mattsson-core-coap-attacks-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 12:22:06 -0000 --_000_HE1PR0701MB30501F88128EA96925703D8289E99HE1PR0701MB3050_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I tried to address all received comments on title, abstract, introduction, = and amplification attacks. Comments on Section 2 will be addressed in a future version: https://github.com/EricssonResearch/coap-actuators/issues. Section 3 on amplification attacks has been substantially expanded. Cheers, John From: internet-drafts@ietf.org Date: Tuesday, 27 July 2021 at 14:14 To: Christian Ams=FCss , G=F6ran Selander , John Mattsson , Ch= ristian Amsuess , Francesca Palombini , G=F6ran Selander , John Fornehed , John Mattsson Subject: New Version Notification for draft-mattsson-core-coap-attacks-01.t= xt A new version of I-D, draft-mattsson-core-coap-attacks-01.txt has been successfully submitted by John Preu=DF Mattsson and posted to the IETF repository. Name: draft-mattsson-core-coap-attacks Revision: 01 Title: CoAP Attacks Document date: 2021-07-27 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/archive/id/draft-mattsson-core-coap-at= tacks-01.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-core-coap-a= ttacks/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-core-c= oap-attacks Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mattsson-core-coa= p-attacks-01 Abstract: Being able to securely read information from sensors, to securely control actuators, and to not enable distributed denial-of-service attacks are essential in a world of connected and networking things interacting with the physical world. This document summarizes a number of known attacks on CoAP and show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not enough for secure operation. The document also summarizes different denial-of-service attacks using CoAP. The goal with this document is motivating generic and protocol-specific recommendations on the usage of CoAP. Several of the discussed attacks can be mitigated with the solutions in draft-ietf-core-echo-request-tag. The IETF Secretariat --_000_HE1PR0701MB30501F88128EA96925703D8289E99HE1PR0701MB3050_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I tried to address all received comments on title, abstract, introduc= tion, and amplification attacks.

 

Comments on Section 2 will be addressed in a future version:

https://github.com/EricssonResearch/coap-actuators/issues.<= /span>

 

Section 3 on amplification attacks has been substantially expanded.

 

Cheers,

John

&nbs= p;

From: internet-drafts@ietf.org <internet-dr= afts@ietf.org>
Date: Tuesday, 27 July 2021 at 14:14
To: Christian Ams=FCss <c.amsuess@energyharvesting.at>, G=F6ra= n Selander <goran.selander@ericsson.com>, John Mattsson <john.matt= sson@ericsson.com>, Christian Amsuess <c.amsuess@energyharvesting.at&= gt;, Francesca Palombini <francesca.palombini@ericsson.com>, G=F6ran Selander <goran.selander@ericsson.com>, John Fornehed <jo= hn.fornehed@ericsson.com>, John Mattsson <john.mattsson@ericsson.com&= gt;
Subject: New Version Notification for draft-mattsson-core-coap-attac= ks-01.txt


A new version of I-D, draft-mattsson-core-coap-attacks-01.txt
has been successfully submitted by John Preu=DF Mattsson and posted to the<= br> IETF repository.

Name:           draft-mat= tsson-core-coap-attacks
Revision:       01
Title:          CoAP Attacks Document date:  2021-07-27
Group:          Individual Sub= mission
Pages:          25
URL:            https://www.ietf.org/archive/id/draft-mattsson-core-coap-attacks-01.txt=
Status:         https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks<= br> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-mattsson-core-coap-attacks-01=

Abstract:
   Being able to securely read information from sensors, to secur= ely
   control actuators, and to not enable distributed denial-of-ser= vice
   attacks are essential in a world of connected and networking t= hings
   interacting with the physical world.  This document summa= rizes a
   number of known attacks on CoAP and show that just using CoAP = with a
   security protocol like DTLS, TLS, or OSCORE is not enough for = secure
   operation.  The document also summarizes different denial= -of-service
   attacks using CoAP.  The goal with this document is motiv= ating
   generic and protocol-specific recommendations on the usage of = CoAP.
   Several of the discussed attacks can be mitigated with the sol= utions
   in draft-ietf-core-echo-request-tag.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

--_000_HE1PR0701MB30501F88128EA96925703D8289E99HE1PR0701MB3050_-- From nobody Tue Jul 27 07:03:11 2021 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 2806F3A0B00; Tue, 27 Jul 2021 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=qti.qualcomm.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 M9CE2HDP9-Kg; Tue, 27 Jul 2021 07:03:05 -0700 (PDT) Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.140.77]) (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 B58D23A0AD3; Tue, 27 Jul 2021 07:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1627394584; x=1627999384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GMddKhNj+0NPjSLcwi3QuA4QFZoAbL7TU00ya7jXPt4=; b=Dt6vPgdHPLpRJCmqZnaOhCnp4+qGCHPD3GsgAQv3mspbItRvKVKgtAx9 seCNTXDuPQX8oui5r22oj3/pxlBOivbZRNYc0J0cNhUDD12Sb+/HuF8q4 kPMexqYmS7aTMtvVd+njYLRCJZCEuffGHEG3/BEm//TCRkyAuGMGZXkZh 0=; Received: from mail-bn8nam11lp2175.outbound.protection.outlook.com (HELO NAM11-BN8-obe.outbound.protection.outlook.com) ([104.47.58.175]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2021 14:03:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fd04Dn7iyT4xly+pqJJ9KQsoVYW6HXUkbCHbvvMFM+8NRfz78pf7aDAju4MT/DTaue4dNJU0VwLmaWMt5c3jRCjgGewCNHLYuaMklcwLP8oGXXXPZBxD77U6BLYv620XbzcqkGyFJR+GtTHefT8MDcr8kGEysjC1JPmobvVSzJlhLIILiDI9HXjQ3yECKtQON9Uckv8+uJFuoITgTLfS7iJqP/ZsqiSML/keVk+l6WXJLV2nfia6JhijYYcz/LD7Yp6Xw9vZhrxx56lFoylZIXXnKEFYgxGvLgFDIzt4xoACK9KmZfXh/HJdkSQKCw8mbHr1v07N4zl7ov13AhX7/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMddKhNj+0NPjSLcwi3QuA4QFZoAbL7TU00ya7jXPt4=; b=NRrMSQ1gVS1AM2cEfqM4kq3hYgEnkb1ohRCUOJx7/RGr/PAwxtjqxhqB0kuweXeoJBp70JMrtJFX3Q22U2YL4I4FUJ6PBHOaxrpTKVlldx3+LK2rkJNTJ5MBRu2EZMrbJcE7otofGqYp1bny9aY+6TFf3Sf86Z14f7saYGYu5J7AcSv2lutKONxAgN5xfFbIeeS6Y2qXDZbM3OK4SrZmtMjJ/5A+vEdAso5Fym3kH7EowTmalNP+jm0/sXuOIbBLxQOo64btQSdnUQ4d3+rfeMM7X6t1EqeBP0ABZOqd/fT0FSRWKrdy12eaI+rqFg27SWcZ8CYLV5+1kxHf4dpjqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none Received: from BL3PR02MB8019.namprd02.prod.outlook.com (2603:10b6:208:35a::18) by MN2PR02MB6158.namprd02.prod.outlook.com (2603:10b6:208:186::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.17; Tue, 27 Jul 2021 14:03:00 +0000 Received: from BL3PR02MB8019.namprd02.prod.outlook.com ([fe80::8cac:e323:5ae1:afa]) by BL3PR02MB8019.namprd02.prod.outlook.com ([fe80::8cac:e323:5ae1:afa%3]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 14:03:00 +0000 From: Alan Soloway To: Carsten Bormann , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "draft-ietf-core-dynlink@ietf.org" , "core@ietf.org" , "draft-ietf-core-dynlink.chairs@ietf.org" Thread-Topic: [core] IPR confusion between dynlink and conditional-attributes Thread-Index: AQHXgf3YbCdH/WgOk0GcScL1jMQuMatVGeiAgAHCLHA= Date: Tue, 27 Jul 2021 14:03:00 +0000 Message-ID: References: <63965B25-F36E-4650-B7D0-885528B029F4@tzi.org> In-Reply-To: <63965B25-F36E-4650-B7D0-885528B029F4@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=qti.qualcomm.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d83f7ede-a992-4572-5360-08d951073ea2 x-ms-traffictypediagnostic: MN2PR02MB6158: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HBFMVQqiXZUe7Y/FtggkBo6+vncn64UiUYo1R7bfJtIevbZqiusxrDVcBnhqfUBIN/R+OR1xLOiH5hqtm9DK/1KTWgcmETchpG3o65uhmK6TjvA+y69cKZvoDtNhifcNWGHLFFYXF0CiEnkfWTQHacVxlXRzSpxthvtkcrQGQMS3uKAOakrQrN0d4xMJTc6ht0YbfDVsSCsZ2Z5Q5DNunh4kUqNwm1dOJsiVocmRZXi2Kxt08khsSw6ShsInZk/wh00nDd2JM820uSDAfRJ91Ru9E31R5+HIyuzJGztWb6UCIGMXk+fCuoyROw6m1T/b9lp7BSa3tbdfOmaC6w8eo3MNR/JQoc463qTYCornQWJ213fabNO+3MfSiQs2HZWykQK05JV1wbARszrxpy+RvKXBxI2ING5DUd1+r/X8EbKcM1Pxsmy8t9HAQlOELueDQxLmjicGCzkYUitl0eMqrwdZsGsrNi9E0iN6G7G3n/WxMmXoQXsvDnbeNxZxFz2t41oN+0n6lZAjH0JjO1tOdF4yGlPxsDf7dCgRKfXf44Rq9wfvyn1KmW9G2mR46vLqZkXsZvfpBIGRokRSxlSDadLQ/T9DRIpUka3xnpZPtQtAd4ZzFCSFxp+frc5vy02uhobHyMoOi3igHWKGflMBQn0JL0WWOrJ5QXWKHwW3Ocl4Od2hRIbzQcSMLiNK1icVOYEPmO0a/JTWfZWo3hjHbDfapNb/ZO6XBsSIxzvwsctbxATyy/c/G9n+0J2X/3dALY6JU9DzsCscs/AwiqpZRmmleUzys+W4BWoSHbV61Vc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR02MB8019.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(396003)(376002)(366004)(39860400002)(52536014)(9686003)(86362001)(4326008)(55016002)(8676002)(33656002)(6506007)(38100700002)(122000001)(966005)(110136005)(2906002)(66476007)(66556008)(316002)(66946007)(71200400001)(478600001)(5660300002)(54906003)(64756008)(66446008)(8936002)(7696005)(83380400001)(66574015)(76116006)(186003)(53546011)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Z2IwR2ZLa2ROMGlCSjE5Mmgyb0c1ZVFWZk8wRHFlMnNrM2pobFZvOXppNHNz?= =?utf-8?B?WEcwN2dpY2lwM1M3bXJ2OGwvdExha3BnZVkweGM1RUVIT0xjcFErVGRyZUxP?= =?utf-8?B?ZStPMGtDQk5pdnhRTmFzTVJOMVRtQUh3UzJTVHdqYm1MNkZ6QVhaYnRGWnln?= =?utf-8?B?SCtuZlhhaG9CemhZcTB6bkY5NS8xcUxXM1ErMFQ1SjBlMDI5T3lIL05FbENm?= =?utf-8?B?T3J2UXpzWlhvQmJRSW5yYVVHb3dxcnh3azJydU1xSTVJZEVVUG96ZFR4MllF?= =?utf-8?B?a0xlZjJnT0pqOEZpdWQxMG5Rdm9oUkowaVl0SkUzV01PK0IxZGJBYnd1b3ds?= =?utf-8?B?NUN4N2Rqbk8vSEM4UEJsZWdhUEhuVUFGNHVzTStYemMwbkxGRXRDcm1RRzk1?= =?utf-8?B?K2VwNVdxZnFjcDRBbVpFZC92OTlhY2cwUVFGTm5yZG90UnBpRnQxeGJlaVM4?= =?utf-8?B?NGwvdUtueUtVR0lLc2VWbFhQM0F5THZCVTV2a3I4WDkyaG1pSE5CWmZ6Q0M2?= =?utf-8?B?V1lJVGZ0a3lJZlNtQmYxeUc5NjR0UDFKU3ZPdkhmNXRXMnR5dTRvalNzeHND?= =?utf-8?B?a01ZZjhRN3hUcDMxUWI0enhoV0x0aGFmTitjNjNkTlJON0NtNnNjT2dERjFE?= =?utf-8?B?RFZtT0F4c2E5Z3JER2dmNzJaeHFVNjcrZksyTXZnNGZvd2ovNmZ5TXkwb0Fh?= =?utf-8?B?TTZkY2svdXlYVXc3RjQ1dS90Nys0aUpZUHhXb0lmdmFjZ2N4aFVRSHl6bTR0?= =?utf-8?B?NWxiaWYrUzFxWHcrekoxN3d2cmgyWE9lUHAvekF0YmRpR01xS3FEM1dDUU5t?= =?utf-8?B?Vk9uUWpPNkFjOVEzTlpuajRTM0ZOZjVYZWNWVVBwN1ZocXAvNkxjWklaZElK?= =?utf-8?B?cnkzOXF3QzVHWHBocUVGd2NXRFVIZHgyeHlrVzFlenRtNFBaS3hXU21yNElU?= =?utf-8?B?bUUyTFBBRmdXaklvRnRDNmp3Zld1U2M2MUlzZ2MzWXZWKzh6Vkx1cThENDVK?= =?utf-8?B?KzNzUlhNWFErZ1dIeXN5K1gzVW1ra3pZRFNVMG5QbzBNUm5UY0VqYVd2OEgx?= =?utf-8?B?NmlVOU9LS0U2cUhpaUZ1U1pnSmdkb0xXOVFUeVU2dlhUWnRQcVIzYXVKYzBy?= =?utf-8?B?RjNYMVFyYlMrQmdSbDI4Tk92aVEwRVZsMkxtY3htTFh3bStEOW9NQzcvY3M3?= =?utf-8?B?ZTZBd08xa0hIVGhETml4OEdrVHpZZm1FVmk0M1BIdWtlUWtyTXZzOE4zdVpS?= =?utf-8?B?c0ZDN1NnUzBqZEpBTEh0UkFVNFpoWjlPa1cxaXBSQVlndlFmVmUzd1p5YkZS?= =?utf-8?B?ODg4QVNReWt6amVBdHBIVExpakpMdE1TdG5QMERheWI5eStiOGFuaWZCUit1?= =?utf-8?B?UHo3NDJWQ1gyK1Nud2szdkhLOVJRQUdwMlJDMi8wbGVFUVh0THp5eWNVRnZo?= =?utf-8?B?NVNqOHhJa2IzNDJpdTlWZTRCQjJxclRjUWc4YjRFSkVTdFlmeExnTHA0alNI?= =?utf-8?B?Wk9oNis5SVV6U3FRaUx1N0RiUlpmK2xQcUk3bzR6bkJ0UjZGcFd6NUhaK2xi?= =?utf-8?B?N1JydldROWQzcUkySHJKQ1hza2REUWZzL2xPOEUyQ0FUQ3VpQytTSFpScFRP?= =?utf-8?B?Y0lHdFVHNERVMjNaKy9aeUp3cTkwOW9jUUk5N2xwMEVPWjNybVFaWUF2c1RX?= =?utf-8?B?dUlmMXFrWGgwblVxVjlnRHdGM1dkSy91SnhJeVYvWGhoY1p3M1NpcEUwY0w2?= =?utf-8?B?STBiTlc2eFhWU3NEWll2RXZwN1hwSXNQWm84ME9JbHZqc2xZWnBOcXhPclMv?= =?utf-8?B?SFhjY3ZHbDYwOWo1NWVIK2JxRStWM2k2UFVneHlNN0krT2FHY0JuMmwvTFdB?= =?utf-8?Q?eq9XyUIbBY86Y?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: qti.qualcomm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR02MB8019.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d83f7ede-a992-4572-5360-08d951073ea2 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 14:03:00.5568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JUz4pICm8SkshzZMDELM8JadgXcCv2kPZkluz9COS9ZTcqXUCeicvcjheFrOrb6U2WaW3oRWnBEx9R5rB6+m/TJy0xa/GpiwZ8TWg+VeiCk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR02MB6158 Archived-At: Subject: Re: [core] IPR confusion between dynlink and conditional-attributes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 14:03:10 -0000 SXNuJ3QgdGhlcmUgYW55dGhpbmcgSSBjYW4gZG8gdG8gaGVscD8gSSB0aGluayB0aG9zZSB3ZXJl IG15IG5vdGlmaWNhdGlvbnMuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFu bg0KU2VudDogTW9uZGF5LCBKdWx5IDI2LCAyMDIxIDU6MTEgQU0NClRvOiBDaHJpc3RpYW4gQW1z w7xzcyA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPg0KQ2M6IGRyYWZ0LWlldGYtY29yZS1keW5saW5r QGlldGYub3JnOyBjb3JlQGlldGYub3JnOyBkcmFmdC1pZXRmLWNvcmUtZHlubGluay5jaGFpcnNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gSVBSIGNvbmZ1c2lvbiBiZXR3ZWVuIGR5bmxp bmsgYW5kIGNvbmRpdGlvbmFsLWF0dHJpYnV0ZXMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ0FVVElP TjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9u Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOb3Qgc3VyZSB3ZSBjYW4gZ2V0IHRoZSBzdWJtaXR0ZXJz IG9mIHRoZSBub3RpZmljYXRpb25zIHRvIHVwZGF0ZSB0aGVtIGFwcHJvcHJpYXRlbHkuICBUaGlz IG1heSBiZSBlYXNpZXIgdG8gZW5naW5lZXIgb24gb3VyIHNpZGUuDQoNCk1lbnRhbCBub3RlIGZv ciBXRyBjaGFpcnM6DQoNCldoZW4gc3BsaXR0aW5nIHRoZSBkcmFmdCwgZG9u4oCZdCB0cnkgdG8g ZmluZCBnb29kIG5hbWVzIGZvciB0aGUgZnJhZ21lbnRzLCBidXQgbWFrZSBzdXJlIHRoZSBwYXRl bnQgY2xhaW1zIGdldCBzdHVjayBvbiB0aGUgcmlnaHQgd2FsbC4gIFRoZSBuYW1lcyBhcmUgZ29p bmcgYXdheSB3aGVuIHRoZXNlIGJlY29tZSBSRkMgYW55d2F5Lg0KDQpJIHN1cmUgZGlkbuKAmXQg dGhpbmsgb2YgdGhhdCENCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCj4gT24gMjAyMS0wNy0yNiwg YXQgMTE6MDcsIENocmlzdGlhbiBBbXPDvHNzIDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+IHdyb3Rl Og0KPiANCj4gSGVsbG8gY29uZGl0aW9uYWwtYXR0cmlidXRlcyBhbmQgZHlubGluayBhdXRob3Jz IGFuZCBjaGFpcnMsDQo+IA0KPiB0aGUgZGF0YSB0cmFja2VyIHNob3dzIDMgSVBSIGl0ZW1zIG9u IGR5bmxpbmsgYW5kIG5vbmUgZm9yIA0KPiBjb25kaXRpb25hbC1hdHRyaXV0ZXMuIEp1ZGdpbmcg ZnJvbSB0aGUgc3RhdGVtZW50IHRpdGxlcyBvbiB0aGUgZm9ybWVyIA0KPiAoInRvIGdvdmVybiBt ZWFzdXJlbWVudCBldmFsdWF0aW9uIHdoZW4gaW4gUG93ZXItU2F2ZS1Nb2RlIiksIEkgdGhpbmsg DQo+IGl0J2Qgc3RhbmQgdG8gcmVhc29uIHRvIHJlYXNzZXNzIHRoZWlyIGFwcGxpY2FiaWxpdHks IGFuZCBwcm9iYWJseSANCj4gbW92ZSB0aGUgc3RhdGVtZW50cyBvdmVyIHRvIGNvbmRpdGlvbmFs LWF0dHJpYnV0ZXMgd2hlcmUgdGhleSBwcm9iYWJseSANCj4gYmVsb25nLg0KPiANCj4gQlINCj4g Yw0KPiANCj4gLS0NCj4gQnVpbGQgYSBtYW4gYSBmaXJlLCBhbmQgaGUnbGwgYmUgd2FybSBmb3Ig YSBkYXkuIFNldCBhIG1hbiBvbiBmaXJlLCANCj4gYW5kIGhlJ2xsIGJlIHdhcm0gZm9yIHRoZSBy ZXN0IG9mIGhpcyBsaWZlLg0KPiAgLS0gVGVycnkgUHJhdGNoZXR0IChhdHRyaWJ1dGVkKQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWls aW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZQ0K From nobody Tue Jul 27 07:12:24 2021 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 39D5B3A0BD7; Tue, 27 Jul 2021 07:12:14 -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, SPF_HELO_NONE=0.001, 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 FpvsmMZkoWI7; Tue, 27 Jul 2021 07:12:10 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC793A0B9D; Tue, 27 Jul 2021 07:12:09 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYzJ56CZXz31MY; Tue, 27 Jul 2021 16:12:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Tue, 27 Jul 2021 16:12:05 +0200 Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , "draft-ietf-core-dynlink@ietf.org" , "core@ietf.org" , "draft-ietf-core-dynlink.chairs@ietf.org" X-Mao-Original-Outgoing-Id: 649087925.476938-f7bdb2eb61bd97c007cec5208d915215 Content-Transfer-Encoding: quoted-printable Message-Id: <9DB60289-B540-4C27-8B3A-484FDC152C9B@tzi.org> References: <63965B25-F36E-4650-B7D0-885528B029F4@tzi.org> To: Alan Soloway X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] IPR confusion between dynlink and conditional-attributes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 14:12:22 -0000 On 2021-07-27, at 16:03, Alan Soloway wrote: >=20 > Isn't there anything I can do to help? I think those were my = notifications. Yes, please! Maybe the chairs can check with you what needs to be done. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 27 13:02:03 2021 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 6F4013A1038; Tue, 27 Jul 2021 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZDmTOcglqgO; Tue, 27 Jul 2021 13:01:49 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 83BF73A1031; Tue, 27 Jul 2021 13:01:49 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id n10so17593244plf.4; Tue, 27 Jul 2021 13:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Dxti4k821vv0/Ka70r4sapy64woJHN4/FMeckpz7It0=; b=qt/aY1BPraGLhxOxNUPptj61GXCSrgLJtBkcnLDeuA1LH7ysySrQt2ZTLPu4TjWTFd pAWgSLSZLgcW1A81shZGE9AGGKBIJBdsH0OdAjKxzgj9EBae5Ex4TL0ZnwVRq6HdMlKT 7xAgAAA/JziI2vJdhXtxj37epGjHxQF/jBbHHnxlUU28AtxIos/Rk0v0vZqjIMs157wF ijt/95Q5M5og2DJIrss1J0319d60pW7wIVUpMErqUR3GU3xGYEMRGtzy1OipXNk9lilC TIWkA8B2Db+dhBvPNBHXVu0INCnVF/Qgq3p5BAEmABcF7wlmLeOJFChSWdt8r3XZxIri fZBQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Dxti4k821vv0/Ka70r4sapy64woJHN4/FMeckpz7It0=; b=A8hzvBmDKAvJz6HAYRpYM52dJRnzTHm3seLsDfGEuVenAeB+0llvEKjCJuXA0PoCFu 6Msc9LBm40KUuZbUfkBAZPDzjD4r3OKP6qEPRQMBDAOxkxCUn1dOEpJV1eoKTKVjhZC5 M0Yaf5n1LL4kpwgW+3xMMuYYgphomCAvyJu2nG16YHdlFgdsLJTWXOFAuzTegGzmVKsJ j7aHx6gnbloWyuK3Nw9eT5B/rfZBrsqiyF9fS6YzkOM+n/bnYJOJJJYrC7PMX5k8cz1l YIHty9N3VRUAAQhwocheCw1sQqIKtkJ/pXVm2V7gJ0tF8sOy2GPFmkpBqqzoG1W8Yj0Y jYoA== X-Gm-Message-State: AOAM533fAKzQ1VWwSxLrOe6SeArcZXwMCwdcyfycFRg6q6/YCsbWm0fU b77rgyN6+QoWsug11h7+JOVDiSe5S1lC+w== X-Google-Smtp-Source: ABdhPJzVoTrUTe5gkeem/6nYmRH0Xc5ZNUB5bWOwiLk6Nnw8X/YBI7aJARkn3IFIywjUGQZXLnT48Q== X-Received: by 2002:a17:90a:ead4:: with SMTP id ev20mr5887771pjb.65.1627416106488; Tue, 27 Jul 2021 13:01:46 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id n11sm226604pfj.158.2021.07.27.13.01.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 13:01:46 -0700 (PDT) To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , Carsten Bormann Cc: Erik Kline , cbor@ietf.org, 6MAN <6man@ietf.org>, core@ietf.org References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> From: Brian E Carpenter Message-ID: Date: Wed, 28 Jul 2021 08:01:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] [Cbor] Interface names (Re: changes in draft-ietf-cbor-network-addresses-05.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:01:55 -0000 On 27-Jul-21 21:55, Christian Ams=C3=BCss wrote: > Hello Carsten, groups, >=20 >> Interface names are local, so it doesn=E2=80=99t make a lot of sense t= o carry >> them around between systems, which is where CBOR is mostly used these >> days. >=20 > two applications come to mind: >=20 > * RD introspection[1] uses zone identifiers in what may be described as= > debug output: Usually an RD won't show you a resource on a fe80:: > address not on your link, but as an administrator you may need the > birds-eye view. Yes, that is an operational use case, as also considered in RFC6874(bis) =20 > * Many network devices offer a remote way to run a ping; when the > process is started via CBOR, it'd be useful to give an interface > identifier. How does host A know the Zone IDs (interface names) used on host B? (Answer: only if B has previously told A. So the use case is quite complex.) =20 > I'm not particularly advocating that we add zone identifiers to the new= > tags (as I can use URIs or even work around completely in the former, > and don't have a pressing need for the latter) -- but with those > examples, a statement like "we don't specify interface identifiers > because they shouldn't be serialized anyway" would be overreaching. They shouldn't be on the wire except in rather special use cases. Brian >=20 > BR > c >=20 > [1]: https://www.ietf.org/archive/id/draft-amsuess-core-resource-direct= ory-extensions-05.html#name-zone-identifier-introspecti >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Fri Jul 30 06:54:35 2021 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 C3D043A2B09 for ; Fri, 30 Jul 2021 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=ri.se 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 0vQjQKpkDzit for ; Fri, 30 Jul 2021 06:54:28 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2063.outbound.protection.outlook.com [40.107.20.63]) (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 4FD873A2ACE for ; Fri, 30 Jul 2021 06:54:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aJ2bRWYweOwkciyifXPcW51JFYVgTCQtNYturNlxtC+niAvgSMoi+cmKfrf26o0nHhJKFeIOTiCernF/aB/psYCaUPlwURt799+whEd+1YdYbuUFM145yxk2THmF2tl0OCx0oseQLcA6j8teqj3dcRXPtoiaw54uqC9ifeAnjy/9lFAZoUj0nMyQBhnT+oMCVOO0KLkGwzzDOubSxhJNbfvl+jhQWz/gEhe2Yaq7jHtmS96+df+D1jvw3TX7pqXHo6Ep7Q0XjMj330l4WpetGwYDyNUHKlv5sRksr+NBiWQgArWxsEbz26wESNAkjnhUDNghEMvLtd/kI7+oQLVFCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2Txnz7Rn4eM6axEwlf9h0PIYZ6fuH5ZZMQm0geun3M=; b=oCdZ1eiPzaWEUfRNm0BSr9eFkg6raICBhE96i7poUsWFH0/bSgZ8NsW9n6Z4UNFtRIjYWe45eubxJOReSv05yuq4uMiOp35w2eooz5w6h9DalRTgHuihZ7nfqx5EjTMCnPC0MR39B5uYgnB8NfNDFtpAm69XW6UFyLxzU37ZqW9YzK9ZMU89VX+sLicXTKCei+M9b8dlGUO/gsNy8xStdDtieHwwHDn0QpW/o+abnnbjokxhE67IarnjspZI2Jc/7Hjk2CIxx9ORgmQVLhOErZFC+f3NGCO5N6Cd9cpH6QYZzH7JBA79UuRvNxW/RtBlrbW/u73SqGlP4pN1C9hlJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2Txnz7Rn4eM6axEwlf9h0PIYZ6fuH5ZZMQm0geun3M=; b=VYlh71uBUA7NOuUPKqL67nfs97SbUpMmDGtKj8ZD37IbjVqwmQuMkPQwogcLvDtmU0Gs4tSV4LKcIeE4KTi+iN31xzGPpFdZy0qnWIWTAn+o8i7Nc7MV3i67WIshRfyNuDaLH4WkhORlfWPquFT3qL6UFLHkOzMkW+6/c63GRAA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0839.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:148::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.21; Fri, 30 Jul 2021 13:54:25 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::4837:ae94:28a8:8014%4]) with mapi id 15.20.4373.025; Fri, 30 Jul 2021 13:54:24 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Fri, 30 Jul 2021 15:54:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qdojeZNjG9tZ8oxTl7bHOqfvIA8i4xTTi" X-ClientProxiedBy: HE1PR05CA0382.eurprd05.prod.outlook.com (2603:10a6:7:94::41) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.6] (45.12.220.236) by HE1PR05CA0382.eurprd05.prod.outlook.com (2603:10a6:7:94::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.17 via Frontend Transport; Fri, 30 Jul 2021 13:54:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 14535bb6-adf6-49a9-63ae-08d953618a45 X-MS-TrafficTypeDiagnostic: DB8P189MB0839: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: J2HWlFpu+JdZCYmslvv5gQQax1KOiYize6l89TpqfdPf3BhQpwu35lvq+MnWpe3bBpW9zykB8I8TWnb9KSuhoJO69ICjf9sQufxQNRqMTOtAnA0M/cgjL5GN6DDgDS0geT8VII2S28Cge1tMno93Be5LtJ9KU5mkmDFppszCmCD+/ps8yTPTSZhkkGt67pZl5WpMB0MxpoPdg2zqrXSHHAxIjotqix4fz2OU1cmWS4uzV3gn0I+00Shc0YlLb0aBTyVbmswvrWh7S3eZEFX86t/cEqkLMtzq7vahPPsfAWM7EEutQOl3Hcwc2y1oIipTLdHXfpMrXQzyIOw2oyn92z8uf100G825SuAYLh+22dUtdfir4L6S6ZD2yvHS5D3BqEFRzY47+ZiJxGiAd5raTFfL5YjJUHHzZ7lOHSh/S9mbIvwDrl+VMd7XdCkNp1zqxhY6uQkcIGB3NGRewsi7VlDph0SDY1f58UMHuGiTYBrRIppiaz1htPkBSu8rf5dyc470gaE4MqQE+jI1k04tyIzZBokUrNTfNw720e/HRdDXKfUwZqGAR0oYZ0SW+O64dxvtAJVYtYGdEn5z015f6ThxcclYgOP9uYVE2Zv6PgJs9q/4KnYvzhNAMZjTHBRzbN+sccBbw0kr3J0WPehpXr0G2xWUsu6t5q3U/TAHjMVrwA83mxnpmH2VYg/EusDyQNGOBaPrD8WtfX5BldqayltmOxy8NAc2/x8V6JuXLa8w5SiCLYpXHigYJGOGkfVbzARX+Aj0pVBskKHZvzQ2QzWvntvTU8bv6rsWLzs2HLpSShsPIBLAVAzrThtbzwdAnGD30USfEvb0pCz+1pTloH5MXdpbk/bomMs8uGOZj9Y= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39830400003)(136003)(396003)(376002)(6486002)(31686004)(235185007)(31696002)(5660300002)(966005)(66946007)(2616005)(66476007)(478600001)(66556008)(36756003)(956004)(38100700002)(8676002)(83380400001)(21480400003)(8936002)(6916009)(44832011)(16576012)(316002)(186003)(2906002)(26005)(33964004)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZkllaHBPQmhhM1A5NW9YLzArLzR3MllGYno3NHkzSUd6aDJSRkhnODY4MXhO?= =?utf-8?B?OGhNb1VJWnAxbmNhZEpJN2RqOTBPOHVLc09sbjliMFRNMWV4TXNrWEVTTmFl?= =?utf-8?B?VlZDWGpiK0JHdDVOQk1jUThKcm11Z0dLK216TnpuWHloVU54Qlc0NSsvMmVo?= =?utf-8?B?dCs5bWQ0SUZrNUNPMG9XbUxDc2ZPMnd0dGk1U3F0d3M3aDAvOUFkZDdqR3Rq?= =?utf-8?B?V2doUGx0dTYxNFF2Zlh3clg2ZEd4VnZDSXAraU0rRU00STl0UG1nOTJqVUdo?= =?utf-8?B?YzF3VXllMEJ0S01xUHFIQmpQa1hpa2UxR3VXMXFURHRyRFhISTVpNm0rZHNV?= =?utf-8?B?L1J3SnVEdWY1L1Y2bGs5K29HdWQ3TjY3eXdQWGtLc2t4YXpDTXJ5KytVNWJK?= =?utf-8?B?QnRDQUUwcEZrVmlzRFlIVUI2ZGdFSldBMGtMdk1oL1k2cE1NazJUUGdXaXk5?= =?utf-8?B?MTAzZFZaWlBGUWprSldOa0xhbG4vS3FGbDZOVnEzM3BBWTRUZTFNZWtZTDhY?= =?utf-8?B?aHVXRk5IYU4zanQxUnpFUUd1L2N0eDhUZDR4bktOZnhBM0x3SzBkQzMreXRB?= =?utf-8?B?ZEFxdVFxUmZMaWJRUmVFSVhIeW90NFBoUmtxc3o1Y21yTE0rNjVvTjBFSGdP?= =?utf-8?B?SU1MMUYxckFxTE9KVms1aGNjUmRkV3lpcTVGb3hTWDRkZGxaQ1FkNXByUjNu?= =?utf-8?B?bndiaEVhRnNSSGJvTUNGS1JHRFZydStWc0lQNXlGOTM0MXhUYXNGMW1JOTAr?= =?utf-8?B?YkpZeHBHR0RVNU9ramtaM05FT1lJSEtIYjJhNFB6YVI0YnVvTmVPY1B6ZjlZ?= =?utf-8?B?Wmh2SHFZNHdnbityaWRET2VxL3Rkek8wT0o2Y00zOTdsSUNVaXo4cVBPdGFr?= =?utf-8?B?bTZEZE1IaEh0VHo2T2JITWpOZE5XNEdCTCtoN1ZmRVVNT3ZmU1ZJd1RwODVz?= =?utf-8?B?V2RmRGhNWjI5bG1ycjVqcXBZYyszblU5T0tUV2FYY05abjluWXVhODdtd08w?= =?utf-8?B?V0NMSzMxV2pydmVFUzlXcjZlbHlWbnJaUUZWU2FjdjYvK0laTmFxWWNDcGk3?= =?utf-8?B?dGcvVzVkbjRtbWdLaHdxcHV5cDIzeEpRNkwzOU02MlJwNFJLVU95TWlCUGJ6?= =?utf-8?B?Z3RYNVZoWGlUOVBhbmpOWDJ5V0s1QVcwSTg4YzdGUGhCY3MrRzNHeTVVVkVF?= =?utf-8?B?SStobXlxdGhUY2hVT2pINms1QkNhdnZsczRPMDBqTnRleUI1VzFZZGpWSFZD?= =?utf-8?B?UjVuZGxKckpIZEo1YVlFa0p0MWR3TW53UXYvdWt4NFo2TGsrZnJRbllXRkNZ?= =?utf-8?B?eWtyZlVnQVpJMU1yK1lQTFpkYWJPb2xRdVEvVWZLd0oyLzVtL09tQyt0WTJs?= =?utf-8?B?VlpSSzBvZ01mcWl1d1hRQmJYb3NGK1lYTk5JekphTExuZ29FOU1xdnpvcjgx?= =?utf-8?B?YmI5N0ZLeUVKMW9ONFNXcXpkeWUzOVo5cmVjU0F4NHNLaVJrSDhtQTNOTjBz?= =?utf-8?B?b0lLWkFtOFBTMjlrUDBWRElTUmZOOW5kNTlaQnk5UVNjS1VMdm5JV2VHQ25s?= =?utf-8?B?ZTEyc3VkS2xPMGFMUnFMaDN0dVEyM3ZnTnBIVmNtck9PS2ZacE5uVHU2QlBN?= =?utf-8?B?REpjSUl3N1FqR0d4bWpTd3N2OXBxaXlIdk9VcU8va2hEMkRSVXR4NjlIZ0Fn?= =?utf-8?B?TXNzS1dkdHRic1BFK25ST3Fqbmg0NSt0YlBmT0d3aFMvOUowRHdzaS8raEhp?= =?utf-8?Q?44RT6ugPbw+LNbzUgqlFqiW0tQFpWu/t+/4jPLa?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 14535bb6-adf6-49a9-63ae-08d953618a45 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2021 13:54:24.7646 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RE/hmMhr5Vv/4OqNW92OzeBOV2QTFzkK4kQo19Sn1tCsrPWUzqBUMt+F6GrFSapr3viasvxjBKmNlk3y9hNLhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0839 Archived-At: Subject: [core] CoRE @ IETF 111 - Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 13:54:34 -0000 --qdojeZNjG9tZ8oxTl7bHOqfvIA8i4xTTi Content-Type: multipart/mixed; boundary="bPYILyCXSUXiKuPGustYXauWc3oEfemEg"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE @ IETF 111 - Minutes --bPYILyCXSUXiKuPGustYXauWc3oEfemEg Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, The minutes for the CoRE session are available at [1]. Thanks a lot to=20 the fantastic note takers Bill Silverajan, Christian Ams=C3=BCss and G=C3= =B6ran=20 Selander! Please, send possible fixes and updates to=C2=A0 core-chairs@ietf.org=C2=A0= or to=20 the mailing list, preferably within the next 7 days. The recording of the CoRE session is available at [2]. Thank you all for your participation and contribution! Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/111/session/core [2] https://www.youtube.com/watch?v=3DSQlyUdL1VEo&pp=3DsAQA --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --bPYILyCXSUXiKuPGustYXauWc3oEfemEg-- --qdojeZNjG9tZ8oxTl7bHOqfvIA8i4xTTi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmEEBI4FAwAAAAAACgkQ7iZktA5Y2kNi 3wf/aGM1wuddgqLHpB4Ffi6u0VMezKyUlOFGG54gJJuSFY2jV5oI2JwWDk5yi1Dl7s2iKpYfas2p E0kmc1pGw/YnIPqQIM/xdOr6YN+Op/lnmbEZiNizfca0RtEPJTyrIHxZ8KMuno2SnxjGKNuxrqpT yIk4tete/TAOS/ZSf0P0jalf/Lo5DYHae446VPu44ZXbJcCrqoc+rpTVw9I+gGJzsEKhxktlwc/t o6jl6t5Owg6ajY2Ut78cye5YnsFwvktXE0+DFOSh52+RqYmTMBw5e2Gcy0wO+ifsXB5r4Z/THrCk OGGutNZC622sFUHsZAFHt2V7ROpMMGIniMSSuEYEow== =uXk0 -----END PGP SIGNATURE----- --qdojeZNjG9tZ8oxTl7bHOqfvIA8i4xTTi-- From nobody Fri Jul 30 17:47:40 2021 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 23DF23A1AEC for ; Fri, 30 Jul 2021 17:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YgIChXs3clGx for ; Fri, 30 Jul 2021 17:47:23 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 D36B63A1AD3 for ; Fri, 30 Jul 2021 17:47:23 -0700 (PDT) Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id 9d9umBqMo31BX9d9umRF7r; Fri, 30 Jul 2021 17:47:23 -0700 X-CMAE-Analysis: v=2.4 cv=T49J89GQ c=1 sm=1 tr=0 ts=61049d9b a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=48vgC7mUAAAA:8 a=OfDViWQvA1O8X5BytuIA:9 a=QEXdDO2ut3YA:10 a=d2TqRZ6kbDWfyFeT:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAE8B98-6B98-486A-B213-7364565CBAF7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Fri, 30 Jul 2021 17:47:22 -0700 To: rats@ietf.org, core@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-CMAE-Envelope: MS4xfDADkh355glnxFI0tNgedkc4vxs9uJuNqK62WB/HTeBgrq+PCbY7aJiTTozJdxDf+8Gj8xAKYXdBYucOnxW5b24kNR1WC6J5GvSUGugLaKCEeJvrY2B0 HDFNJg4Ne9p+TkXkLbfoLcSjAmWVD4i6b83UKb/FOIhizG1uvq2hixiS+WKPcSVpohDKsZV4kC8Wl7vCmDxXYEn5/Hwh2CuAbWA= Archived-At: Subject: [core] UEID device identifier and RFC 9039 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 00:47:37 -0000 --Apple-Mail=_8FAE8B98-6B98-486A-B213-7364565CBAF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is to check-in with the WG that defined the RFC 9039 device = identifier URN and others on the UEID = = , a new device identifier proposed by EAT in the RATS WG. Wanted you to = know about UEID and see if you have any comments. RFC 9039 and UEIDs = seem largely complementary to me. I plan to add a registration for urn:dev:ueid:xxxxxxxx to the registry = established in 9039. LL Here=E2=80=99s some background that might be helpful. A UEID (Universal Entity ID) is intended to be universal in ways that an = EUI-64 / MAC and IMEI aren=E2=80=99t. When designing a new device or for some existing, it may be too = expensive, impractical or otherwise not possible to have and EUI-64 or = an IMEI. For example, the fees for these identifiers may be too high, or = the maker of the device may be politically not able to transact with the = IEEE or 3GPP. The UEID addresses this issue by allowing for the generation of an = identifier that is statistically unique, one that doesn=E2=80=99t = require any organization to track assignments. This is accomplished by = making sure there enough true random bits in the UEID that the = probability of collision is negligible. The statistical analysis for = this is here = Note that this is similar to using a UUID, however it is explicitly = not a UUID for reasons given here = . That is, a UEID is universal in that it can apply to more use cases than = EUI-64 and IMEI.=20 It is also universal in another way. The UEID can be the only device identifier that a back-end or service = decodes and tracks. For example, without something like a UEID, a = back-end that works with phones and laptops may need to track both by = IMEI and by EUI-64 / MAC. Its database has two fields for device = identifier, and may be more. It has to decode incoming messages for all = the different types of device identifiers it knows about. Some devices = have one, others the other, or maybe both. A system that uses a UEID only has to decode and track only the UEID and = is thus simpler. Here=E2=80=99s a little more detail for how UEIDs are designed. In = addition to the random bits and statistical uniqueness, a UEID may be = made out of an IMEI or an EUI-64. The UEID has minimal internal = structure to make sure there is no collision between the three types of = UEIDS (random/hash, EUI-64 and IMEI). See here = = for details. Note that the IMEI and EUI-64 have an advantage of being = shorter. --Apple-Mail=_8FAE8B98-6B98-486A-B213-7364565CBAF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This is to check-in with the WG that defined the RFC 9039 = device identifier URN and others on the UEID, a new device identifier = proposed by EAT in the RATS WG. Wanted you to know about UEID and see if = you have any comments. RFC 9039 and UEIDs seem largely complementary to = me.

I plan to = add a registration for urn:dev:ueid:xxxxxxxx to the registry established = in 9039.

LL


Here=E2=80=99s some = background that might be helpful.

A UEID (Universal Entity ID) is intended to be = universal in ways that an EUI-64 / MAC and IMEI aren=E2=80=99t.

When designing a new = device or for some existing, it may be too expensive, impractical or = otherwise not possible to have and EUI-64 or an IMEI. For example, the = fees for these identifiers may be too high, or the maker of the device = may be politically not able to transact with the IEEE or 3GPP.

The UEID addresses this = issue by allowing for the generation of an identifier that is = statistically unique, one that doesn=E2=80=99t require any organization = to track assignments. This is accomplished by making sure there enough = true random bits in the UEID that the probability of collision is = negligible. The statistical analysis for this is here  Note that this is similar to using a = UUID, however it is explicitly not a UUID for reasons given here.

That is, a UEID is universal in that it = can apply to more use cases than EUI-64 and IMEI. 

It is also universal in = another way.

The= UEID can be the only device identifier that a back-end or service = decodes and tracks.  For example, without something like a UEID, a = back-end that works with phones and laptops may need to track both by = IMEI and by EUI-64 / MAC. Its database has two fields for device = identifier, and may be more. It has to decode incoming messages for all = the different types of device identifiers it knows about. Some devices = have one, others the other, or maybe both.

A system that uses a UEID only has to = decode and track only the UEID and is thus simpler.

Here=E2=80=99s a little = more detail for how UEIDs are designed. In addition to the random bits = and statistical uniqueness, a UEID may be made out of an IMEI or an = EUI-64. The UEID has minimal internal structure to make sure there is no = collision between the three types of UEIDS (random/hash, EUI-64 and = IMEI). See here for details. Note that the IMEI and = EUI-64 have an advantage of being shorter.




= --Apple-Mail=_8FAE8B98-6B98-486A-B213-7364565CBAF7--