From nobody Sun Jul 1 10:47:42 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A548130E71; Sun, 1 Jul 2018 10:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG4tJh6ydfzO; Sun, 1 Jul 2018 10:47:25 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4220130E6D; Sun, 1 Jul 2018 10:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w61HlJED022461; Sun, 1 Jul 2018 19:47:19 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41JdBH3zGCzDXdR; Sun, 1 Jul 2018 19:47:19 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 552160036.771-3560f32e67c21b99b06b4537d19f474c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 1 Jul 2018 19:47:18 +0200 Message-Id: <19B520A9-2C13-44CA-AA76-AE8325320CBA@tzi.org> To: ace , Core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF102: FINAL AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:47:29 -0000 I forgot to send the update of my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF102. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The only change from the previous draft agenda (apart from different room assignments) seems to be the move of SECDISPATCH on top of the first CORE slot and of SUIT into what previously was the SECDISPATCH slot. The conflicts ACE vs. DISPATCH as well as CBOR vs. 6LO vs. TEEP remain. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Laurier INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Duluth ART *** core Constrained RESTful Environments WG Laurier INT intarea Internet Area Working Group WG Viger SEC secdispatch Security Dispatch WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Van Horne ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Duluth INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Laurier OPS v6ops IPv6 Operations WG Centre Ville RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Laurier IRTF*** t2trg Thing-to-Thing Viger OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Laurier SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Centre Ville IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Mon Jul 2 06:25:00 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9CD131152; Mon, 2 Jul 2018 06:24:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053788472.28231.15418514543666802135@ietfa.amsl.com> Date: Mon, 02 Jul 2018 06:24:44 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-too-many-reqs-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:24:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Too Many Requests Response Code for the Constrained Application Protocol Author : Ari Keranen Filename : draft-ietf-core-too-many-reqs-02.txt Pages : 5 Date : 2018-07-02 Abstract: A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 06:31:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC483130F47 for ; Mon, 2 Jul 2018 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gfzq-QALNiIO for ; Mon, 2 Jul 2018 06:31:06 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36014130F20 for ; Mon, 2 Jul 2018 06:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530538264; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/TMx/FSSdr+2l7TFCNgO/s4yiejYuyO0ajV9D6eLPSY=; b=Z0gxNmH9/W2sLtAVucsG/oMDq4AoPbhmvODJf9EaAwW5/jtDyLBEMIAQ6mP1yoRx 2sF4AduqpL9GF4ek/6+Hx8c8pdcCgOeqJ5Si2LSdKWcfRs7jv3L+WtGtu0Ehe1wl VzKSN++RlgQFOWrjg7xmlPnGVJz92HP1fliSrNkV6Dw=; X-AuditID: c1b4fb30-93dff70000000a77-13-5b3a2918ef5f Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id ED.91.02679.8192A3B5; Mon, 2 Jul 2018 15:31:04 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 2 Jul 2018 15:31:04 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 2 Jul 2018 15:31:03 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-02.txt Thread-Index: AQHUEggYx2Oy5phlb0+3ixllAEPeWqR7zECA Date: Mon, 2 Jul 2018 13:31:03 +0000 Message-ID: References: <153053788472.28231.15418514543666802135@ietfa.amsl.com> In-Reply-To: <153053788472.28231.15418514543666802135@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <460C835440355C47BDD0D42E91CC5EAF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbG9UldC0yraYP46aYt9b9czOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9/5NSwFN/grFt2cxtbAeIGni5GTQ0LARGJPz0SWLkYuDiGB o4wSzVeOsUI4XxklbjVcYYRwljJKTJywnAmkhU3AXmLymo+MILaIgIRE59f97CC2sICLxMfV a1kh4q4Sm2/tYoOwjSS2vbkGFmcRUJE4OO8kC4jNCzTn4cv7YHEhoN4X62aDzeEE6t3zagVY L6OAmMT3U2vA9jILiEvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUk9h67zgJRrydxY+oUNgjb WuLf883sELa2xLKFr5khbhCUODnzCcsERrFZSFbMQtI+C0n7LCTts5C0L2BkXcUoWpxanJSb bmSkl1qUmVxcnJ+nl5dasokRGEcHt/w22MH48rnjIUYBDkYlHt49fy2jhVgTy4orcw8xSnAw K4nwblO1ihbiTUmsrEotyo8vKs1JLT7EKM3BoiTOa+G3OUpIID2xJDU7NbUgtQgmy8TBKdXA yM1k6i17s7PXvMfbe9nnAL77MWYh03bdyixpU/6bsmP9icwkrqez8jizm5f9rJEzWyY2xzMw L6mwPiVRylNiW528yyTTFVmr95StkvaUcp7i+/vTn8rky6p6ejOZbk3eXS5qkHT51+x7xZXT j3FONJaor9niXjvldlvrxDXTJ8sE/ly0QPuvEktxRqKhFnNRcSIAJAIhDp8CAAA= Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:31:10 -0000 This version addresses the feedback about accommodating also for requests t= hat are not identical but similar, e.g., part of the same series [1].=20 Cheers, Ari [1] https://www.ietf.org/mail-archive/web/core/current/msg09685.html > On 2 Jul 2018, at 16.24, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > Title : Too Many Requests Response Code for the Constrai= ned Application Protocol > Author : Ari Keranen > Filename : draft-ietf-core-too-many-reqs-02.txt > Pages : 5 > Date : 2018-07-02 >=20 > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02 > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 2 06:48:36 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF62130E64; Mon, 2 Jul 2018 06:48:35 -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: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053931502.16078.9137162753361217458@ietfa.amsl.com> Date: Mon, 02 Jul 2018 06:48:35 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:48:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-14.txt Pages : 80 Date : 2018-07-02 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-14 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 06:52:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8466C130E79 for ; Mon, 2 Jul 2018 06:52:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ3GMwdQvGWe for ; Mon, 2 Jul 2018 06:52:03 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556AB1271FF for ; Mon, 2 Jul 2018 06:52:03 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 5ED2632206 for ; Mon, 2 Jul 2018 13:52:02 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:1:2:41:72:152:355:379:582:602:800:962:967:968:973:982:983:988:989:1049:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1433:1434:1436:1437:1516:1517:1518:1571:1575:1588:1589:1592:1594:1730:1776:1792:1801:2068:2069:2198:2199:2288:2525:2528:2553:2559:2568:2570:2633:2682:2685:2703:2731:2741:2771:2859:2892:2895:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4250:4321:4605:4860:5007:6117:6119:6261:6298:7464:7875:7903:8603:8985:9010:9025:9121:9177:10004:11658:12379:12740:13139:13161:13229:30056, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: back89_4bf7e32e4785e X-Filterd-Recvd-Size: 11761 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf08.hostedemail.com (Postfix) with ESMTPA for ; Mon, 2 Jul 2018 13:52:02 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7deae829afa634308ba0295768658be6" Date: Mon, 02 Jul 2018 15:52:01 +0200 From: Peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <153053931502.16078.9137162753361217458@ietfa.amsl.com> References: <153053931502.16078.9137162753361217458@ietfa.amsl.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [82.95.140.48] Archived-At: Subject: [core] Fwd: I-D Action: draft-ietf-core-resource-directory-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:52:07 -0000 --=_7deae829afa634308ba0295768658be6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 HI Core, We have the pleasure to submit a new version of the resource directory, Major changes with former version 13 are: o Rename "registration context" to "registration base URI" (and "con" to "base") and "domain" to "sector" (where the abbreviation "d" stays for compatibility reasons) o Introduced resource types core.rd-ep and core.rd-gp o Registration management moved to appendix A, including endpoint and group lookup o Minor editorial changes o Simple registration carries no error information and succeeds immediately (previously, sequence was unspecified) o Lookup: href are matched against resolved values (previously, this was unspecified) o Lookup: lt are not exposed any more o con/base: Paths are allowed o Registration resource locations can not have query or fragment parts o Default life time extended to 25 hours o clarified registration update rules o lt-value semantics for lookup clarified. o added template for simple registration Greetings, Peter -------- Oorspronkelijke bericht -------- ONDERWERP: [core] I-D Action: draft-ietf-core-resource-directory-14.txt DATUM: 2018-07-02 15:48 AFZENDER: internet-drafts@ietf.org ONTVANGER: KOPIE: 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 : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-14.txt Pages : 80 Date : 2018-07-02 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-14 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=_7deae829afa634308ba0295768658be6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Core,

We have the pleasure to submit a new version of the res= ource directory,

Major changes with former version 13 are:
=

o  Rename "registration context" to "registration base URI" (and       "con" to "base") and "domain" to "sector= " (where the abbreviation
      "d" stays fo= r compatibility reasons)

   o  Introduced resour= ce types core.rd-ep and core.rd-gp

   o  Regist= ration management moved to appendix A, including endpoint
  = ;    and group lookup

   o  Mino= r editorial changes

   o  Simple registration c= arries no error information and succeeds
    &nbs= p; immediately (previously, sequence was unspecified)

 &n= bsp; o  Lookup: href are matched against resolved values (previously, = this
      was unspecified)

&nb= sp;  o  Lookup: lt are not exposed any more

 &n= bsp; o  con/base: Paths are allowed

   o  = Registration resource locations can not have query or fragment
 =      parts

   o  Default li= fe time extended to 25 hours

   o  clarified re= gistration update rules

   o  lt-value semantic= s for lookup clarified.

   o  added template fo= r simple registration

Greetings,

Peter

-------- Oorspronkelijke bericht --------

Onderwerp: [core] I-D Action: draft-ietf-core-resource-directory-14.txt
Datum: 2018-07-02 15:48
Afzender: internet-drafts@ietf.org
Ontvanger: <i-d-announce@ietf.org>
Kopie: core@ietf.org

=
A New Internet-Draft is available from the on-line Internet-Drafts d= irectories.
This draft is a work item of the Constrained RESTful Envi= ronments WG of the IETF.

      &n= bsp; Title           = ;: CoRE Resource Directory
       =  Authors         : Zach Shelby=
           &n= bsp;            = ;  Michael Koster
       = ;            &n= bsp;      Carsten Bormann
  &= nbsp;           &nbs= p;           Peter v= an der Stok
         &nb= sp;            =     Christian Amsüss
    = ;Filename        : draft-ietf-core-resou= rce-directory-14.txt
    Pages    =        : 80
   &nbs= p;Date            : = 2018-07-02

Abstract:
   In many M2M applic= ations, direct discovery of resources is not
   practi= cal due to sleeping nodes, disperse networks, or networks where
 = ;  multicast traffic is inefficient.  These problems can be = solved by
   employing an entity called a Resource Dir= ectory (RD), which hosts
   descriptions of resources = held on other servers, allowing lookups to
   be perfo= rmed for those resources.  This document specifies the web
 = ;  interfaces that a Resource Directory supports in order for web=
   servers to discover the RD and to register, mainta= in, lookup and
   remove resource descriptions.  = Furthermore, new link attributes
   useful in conjunct= ion with an RD are defined.


The IETF datatracker status p= age for this draft is:
http= s://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/
<= br /> There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-resource= -directory-14
ht= tps://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-core-resource-directory-14


Please note= that it may take a couple of minutes from the time of submission
unt= il the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
f= tp://ftp.ietf.org/internet-drafts/

________________________= _______________________
core mailing list
core@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/core
--=_7deae829afa634308ba0295768658be6-- From nobody Mon Jul 2 06:54:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837EF130F70 for ; Mon, 2 Jul 2018 06:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGLkyDrbV11E for ; Mon, 2 Jul 2018 06:54:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37FB13115B for ; Mon, 2 Jul 2018 06:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w62DrwUx019856 for ; Mon, 2 Jul 2018 15:53:58 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41K7yZ0TdczDXp4; Mon, 2 Jul 2018 15:53:58 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 552232435.775463-e6ac4ab2bbc93d4938af51037289bfba Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 2 Jul 2018 15:53:57 +0200 Message-Id: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> To: Core X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 13:54:12 -0000 Dear CoRE WG, during the London IETF, we said we want to quickly finish the spec of = the response code 4.29 (too many requests). The author has now submitted a revised version dealing with the recent = comments and believes it is ready for Working Group last call. https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02 A diff from the previous version is available at: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-02 The WGLC will end in exactly 336 hours so we can discuss the outcome at = the CoRE WG meeting=20 Gr=C3=BC=C3=9Fe, Carsten PS.: A bonus for the first one who finds the one malformed sentence I = found during chair review:=20 You=E2=80=99ll get some Finnish Salmiakki at the Montreal meeting. From nobody Mon Jul 2 07:02:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA39131107 for ; Mon, 2 Jul 2018 07:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOx5RzuKuVja for ; Mon, 2 Jul 2018 07:02:14 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABC2130FB8 for ; Mon, 2 Jul 2018 07:02:13 -0700 (PDT) Received: from mail-io0-f172.google.com ([209.85.223.172]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fZzP8-0001Yi-NJ; Mon, 02 Jul 2018 16:02:10 +0200 Received: by mail-io0-f172.google.com with SMTP id p7-v6so2445807ioh.13 for ; Mon, 02 Jul 2018 07:02:10 -0700 (PDT) X-Gm-Message-State: APt69E2Mv9joR/0eXc1sEnqC5jRv2XbzLHkEqIPn6egPFzkbw9YNoMUi 7R7s89K+P1qx80WZapQXjx3+Sj2U4GpVnC6PBk4= X-Google-Smtp-Source: AAOMgpealqOF5aF9axVXfDAyRsyh0xBG62fUtqYZdX1d212/Ec0G9k6u+k7G30Btw0uuJaPTHM3D62qwViUHCBIC+ps= X-Received: by 2002:a6b:e403:: with SMTP id u3-v6mr20470368iog.131.1530540129462; Mon, 02 Jul 2018 07:02:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:a286:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 07:01:28 -0700 (PDT) In-Reply-To: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> From: Klaus Hartke Date: Mon, 2 Jul 2018 16:01:28 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Core Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1530540133; 6051750c; X-HE-SMSGID: 1fZzP8-0001Yi-NJ Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 14:02:20 -0000 > PS.: A bonus for the first one who finds the one malformed sentence I fou= nd during chair review: > You=E2=80=99ll get some Finnish Salmiakki at the Montreal meeting. This one? While a server may not be able to response to a one kind of request, it may be able to respond to a different request, even from the same client. :-) From nobody Mon Jul 2 07:14:36 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C22DB130EDC; Mon, 2 Jul 2018 07:14:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153054087376.16368.840019331143160223@ietfa.amsl.com> Date: Mon, 02 Jul 2018 07:14:33 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-multipart-ct-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 14:14:34 -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 : Multipart Content-Format for CoAP Authors : Thomas Fossati Klaus Hartke Carsten Bormann Filename : draft-ietf-core-multipart-ct-01.txt Pages : 8 Date : 2018-07-02 Abstract: This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of several different media types into a single CoAP message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-multipart-ct-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-multipart-ct-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-multipart-ct-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 10:14:16 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F9C127598; Mon, 2 Jul 2018 10:14:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153055164682.16295.9403417535721765062@ietfa.amsl.com> Date: Mon, 02 Jul 2018 10:14:06 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:14: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 : Uniform Resource Names for Device Identifiers Authors : Jari Arkko Cullen Jennings Zach Shelby Filename : draft-ietf-core-dev-urn-02.txt Pages : 14 Date : 2018-07-02 Abstract: This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dev-urn-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 16:29:01 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61592130DCB; Mon, 2 Jul 2018 16:28:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057413535.16276.13158075103448710867@ietfa.amsl.com> Date: Mon, 02 Jul 2018 16:28:55 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:28:56 -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 : Zach Shelby Michael Koster Christian Groves Jintao Zhu Bilhanan Silverajan Filename : draft-ietf-core-dynlink-06.txt Pages : 18 Date : 2018-07-02 Abstract: For CoAP (RFC7252), Dynamic linking of state updates between resources, either on an endpoint or between endpoints, is defined with the concept of Link Bindings. This specification defines conditional observation attributes that work with Link Bindings or with CoAP Observe (RFC7641). 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 16:35:28 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E84DD131428; Mon, 2 Jul 2018 16:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057451490.16091.5183197527066908672@ietfa.amsl.com> Date: Mon, 02 Jul 2018 16:35:14 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:35:22 -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 : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jimenez Filename : draft-ietf-core-coap-pubsub-05.txt Pages : 24 Date : 2018-07-02 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 16:53:09 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2F130E1B; Mon, 2 Jul 2018 16:53:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057558736.16480.7706309743616375172@ietfa.amsl.com> Date: Mon, 02 Jul 2018 16:53:07 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-rd-dns-sd-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:53:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoRE Resource Directory: DNS-SD mapping Authors : Kerry Lynn Peter van der Stok Michael Koster Christian Amsuess Filename : draft-ietf-core-rd-dns-sd-02.txt Pages : 12 Date : 2018-07-02 Abstract: Resource and service discovery are complimentary. Resource discovery provides fine-grained detail about the content of a server, while service discovery can provide a scalable method to locate servers in large networks. This document defines a method for mapping between CoRE Link Format attributes and DNS-Based Service Discovery fields to facilitate the use of either method to locate RESTful service interfaces (APIs) in heterogeneous HTTP/CoAP environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-rd-dns-sd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-rd-dns-sd-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-rd-dns-sd-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-rd-dns-sd-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 3 06:40:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE58130E0A for ; Tue, 3 Jul 2018 06:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRLPb9q0wSE7 for ; Tue, 3 Jul 2018 06:40:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CA9130DF7 for ; Tue, 3 Jul 2018 06:40:28 -0700 (PDT) Received: from Jude (12.171.40.194) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 3 Jul 2018 06:37:15 -0700 From: Jim Schaad To: References: <153055053574.16070.2582969990516455205.idtracker@ietfa.amsl.com> In-Reply-To: <153055053574.16070.2582969990516455205.idtracker@ietfa.amsl.com> Date: Tue, 3 Jul 2018 06:40:18 -0700 Message-ID: <044501d412d3$634fca80$29ef5f80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHrcjOgZeEDe6Jft6as1x5DGrbLiqROwjtg X-Originating-IP: [12.171.40.194] Archived-At: Subject: [core] FW: New Version Notification for draft-schaad-cose-x509-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 13:40:31 -0000 I have pulled this draft out of the dust bin and plan to try and get it = to move forward soon. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Monday, July 2, 2018 9:56 AM To: Jim Schaad Subject: New Version Notification for draft-schaad-cose-x509-02.txt A new version of I-D, draft-schaad-cose-x509-02.txt has been = successfully submitted by Jim Schaad and posted to the IETF repository. Name: draft-schaad-cose-x509 Revision: 02 Title: CBOR Object Signing and Encryption (COSE): Headers for carrying = and referencing X.509 certificates Document date: 2018-07-02 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-schaad-cose-x509-02.txt Status: https://datatracker.ietf.org/doc/draft-schaad-cose-x509/ Htmlized: https://tools.ietf.org/html/draft-schaad-cose-x509-02 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-cose-x509 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-x509-02 Abstract: This document defines a set of headers to identify and transport X.509 certificates in the CBOR Encoded Message (COSE) syntax. The document additionally defines a set of digest algorithms that are used in identifying certificates, as well as being available for other uses. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Tue Jul 3 07:39:31 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865FB130E04; Tue, 3 Jul 2018 07:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i94ohNuZIXww; Tue, 3 Jul 2018 07:39:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD23130DE1; Tue, 3 Jul 2018 07:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1530628767; x=1531838367; h=from:to:cc:subject:date:message-id:mime-version; bh=V0OzzG66ftkQ9wbDq5Vj3snmiqdoYIr2H3d+T3j0w8o=; b=CMJPnEvOnHMWjwenQ7wy7p6+x05EV0vhLPPE9CSVMpItiDT+s8Q0zlxy XdsOQeemS0JVJF7ELqEwGpMFMFSHm/S159Pgk15zLJEhF5cw9HmXCgIG8 qVRPyrfAj5uHnfYsxXqwmplqG+SpzLUy07gZi3iQNulruoCQCsL0+oJo0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AACCiTtb/5ldJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdmJ/MotzjECSIYUOFIFmCyOESYIaITQYAQIBAQIBAQJ?= =?us-ascii?q?tHAyFakcFEgEMdCYBBAENDYMZgRtkD6pviE+BNQWIbYFWP4EPgmGDRgEBA4E?= =?us-ascii?q?lhg4CjQyMPwkChgSJEYFIhAyIC4o1hy0CERMBgSQdOIFScBWDJYsThT6QG4E?= =?us-ascii?q?aAQE?= X-IronPort-AV: E=Sophos;i="5.51,303,1526342400"; d="scan'208,217";a="408338836" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 14:39:26 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w63EdQs5012986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jul 2018 14:39:26 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 3 Jul 2018 09:39:23 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 3 Jul 2018 09:39:23 -0500 From: "Pascal Thubert (pthubert)" To: lp-wan , "core@ietf.org" CC: Charlie Perkins , ivaylo petrov , sivasothy shanmugalingam , "sum@wi-sun.org" , =?iso-8859-1?Q?G=F6ran_Selander?= Thread-Topic: Pre WGLC reviews for SCHC compression for CoAP Thread-Index: AdQS2rEA/JeHkYUxSpakoJD3IUHErg== Date: Tue, 3 Jul 2018 14:39:01 +0000 Deferred-Delivery: Tue, 3 Jul 2018 14:38:46 +0000 Message-ID: <4fe2654111f54524bdf25791e9e13302@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.241.108] Content-Type: multipart/alternative; boundary="_000_4fe2654111f54524bdf25791e9e13302XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [core] Pre WGLC reviews for SCHC compression for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 14:39:30 -0000 --_000_4fe2654111f54524bdf25791e9e13302XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all : LPWAN is setting the stage for WGLC of the SCHC compression of CoAP, includ= ing OSCORE (https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-contex= t-hc-04). As usual we are looking for volunteers to perform an in-depth review prior = to WGLC, which we plan to start after the LPWAN session at IETF 102, if the= comments we get indicate that we have reached the expected level for the d= ocument. In this case, we think that we must look beyond the LPWAN WG and seek for h= elp from the CORE WG as well, with a particular interest on the OSCORE piec= e. If you are willing to help and review before Thursday July 19th please let = us know! Many thanks in advance, Pascal --_000_4fe2654111f54524bdf25791e9e13302XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all :<= /p>

 

LPWAN is setting the stage for WGLC of the SCHC comp= ression of CoAP, including OSCORE (https://tools.ietf.org/html/draf= t-ietf-lpwan-coap-static-context-hc-04).

As usual we are looking for volunteers to perform an= in-depth review prior to WGLC, which we plan to start after the LPWAN sess= ion at IETF 102, if the comments we get indicate that we have reached the e= xpected level for the document.

In this case, we think that we must look beyond the = LPWAN WG and seek for help from the CORE WG as well, with a particular inte= rest on the OSCORE piece.

 

If you are willing to help and review before Thursda= y July 19th please let us know!

 

Many  thanks in advance,

 

Pascal

--_000_4fe2654111f54524bdf25791e9e13302XCHRCD001ciscocom_-- From nobody Tue Jul 3 09:09:15 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C47671310CF; Tue, 3 Jul 2018 09:00:33 -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, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063363379.4893.9788695197482679611.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:33 -0700 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 102 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:46 -0000 Dear Carsten Bormann, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (1:30 requested) Monday, 16 July 2018, Afternoon Session II 1550-1750 Room Name: Duluth size: 150 --------------------------------------------- core Session 2 (1:30 requested) Thursday, 19 July 2018, Afternoon Session III 1810-1910 Room Name: Van Horne size: 130 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor httpbis artarea t2trg suit ace lpwan 6lo roll teep Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm emu Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Please also avoid any potentially IoT related BOFs that might come up (atick, amp). Prefer some time between the two meetings (48 h or more). --------------------------------------------------------- From nobody Thu Jul 5 06:15:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99F7130E3B for ; Thu, 5 Jul 2018 06:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no8DeKNpZsDO for ; Thu, 5 Jul 2018 06:15:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642DF130DC2 for ; Thu, 5 Jul 2018 06:15:47 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Jul 2018 06:12:33 -0700 From: Jim Schaad To: 'Core' References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> In-Reply-To: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> Date: Thu, 5 Jul 2018 06:15:36 -0700 Message-ID: <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJt7qfOLfP6zXhio7jvHWj1sBbapqNM5AQA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 13:15:50 -0000 The draft looks fine to me. The server gets to have a definition of what it means for something to = be "too similar" for a request and there is no way for this standard to = be communicated to the client. Thus the client's idea that similar = means 'the same payload' may not be the servers idea of 'any payload'. = I don't know how to fix this so I expect it to be ignored. The document appears to say that this response code is for dealing with = a single client. That is the traffic metric is calculated individually = for each client. The proxy for each client presumably being source IP, = port pair. If the traffic metric is calculated for everybody then it = should return 5.03. If that is not the intent then this needs to be = made clearer. Note that a client could get this as a response even on its first = request if the path to the server goes through a proxy agent. Jim > -----Original Message----- > From: core On Behalf Of Carsten Bormann > Sent: Monday, July 2, 2018 6:54 AM > To: Core > Subject: [core] =F0=9F=94=94 WGLC of draft-ietf-core-too-many-reqs-02 >=20 > Dear CoRE WG, >=20 > during the London IETF, we said we want to quickly finish the spec of = the > response code 4.29 (too many requests). > The author has now submitted a revised version dealing with the recent > comments and believes it is ready for Working Group last call. >=20 > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02 > A diff from the previous version is available at: > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-02 >=20 > The WGLC will end in exactly 336 hours so we can discuss the outcome = at the > CoRE WG meeting >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > PS.: A bonus for the first one who finds the one malformed sentence I = found > during chair review: > You=E2=80=99ll get some Finnish Salmiakki at the Montreal meeting. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 5 09:39:20 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6875130EC8 for ; Thu, 5 Jul 2018 09:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ycgi-O7Gs8xC for ; Thu, 5 Jul 2018 09:39:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC81512785F for ; Thu, 5 Jul 2018 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w65Gcipq028649; Thu, 5 Jul 2018 18:38:45 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41M3TJ2j9HzDX1B; Thu, 5 Jul 2018 18:38:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> Date: Thu, 5 Jul 2018 18:38:42 +0200 Cc: Core X-Mao-Original-Outgoing-Id: 552501520.872967-728a0e722f343dbe9dc52e6dd40fd8f1 Content-Transfer-Encoding: quoted-printable Message-Id: <573D4219-72C7-425F-A9FA-D2A8A4093310@tzi.org> References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 16:39:19 -0000 On Jul 5, 2018, at 15:15, Jim Schaad wrote: >=20 > Note that a client could get this as a response even on its first = request if the path to the server goes through a proxy agent. Which strikes me as moderately appropriate =E2=80=94 after all, the = client is =E2=80=9Cpart of the problem=E2=80=9D. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 5 09:48:51 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D231130E19 for ; Thu, 5 Jul 2018 09:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mT0kKPbeGvA for ; Thu, 5 Jul 2018 09:48:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C69130E6C for ; Thu, 5 Jul 2018 09:48:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Jul 2018 09:45:32 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: 'Core' References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> <573D4219-72C7-425F-A9FA-D2A8A4093310@tzi.org> In-Reply-To: <573D4219-72C7-425F-A9FA-D2A8A4093310@tzi.org> Date: Thu, 5 Jul 2018 09:48:38 -0700 Message-ID: <00a601d41480$074aa990$15dffcb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJt7qfOLfP6zXhio7jvHWj1sBbapgGLD0UXAccAZY+jMpIJUA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 16:48:49 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Thursday, July 5, 2018 9:39 AM > To: Jim Schaad > Cc: Core > Subject: Re: [core] =F0=9F=94=94 WGLC of = draft-ietf-core-too-many-reqs-02 >=20 > On Jul 5, 2018, at 15:15, Jim Schaad wrote: > > > > Note that a client could get this as a response even on its first = request if the > path to the server goes through a proxy agent. >=20 > Which strikes me as moderately appropriate =E2=80=94 after all, the = client is =E2=80=9Cpart of > the problem=E2=80=9D. I understand this, however it means that a client might get this = response even though it had never sent a message to the server before. = This might be considered to be unexpected behavior. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 6 02:52:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787DB130DF2 for ; Fri, 6 Jul 2018 02:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rdsV6vIzb5TK for ; Fri, 6 Jul 2018 02:52:10 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441A5130DD7 for ; Fri, 6 Jul 2018 02:52:10 -0700 (PDT) Received: from [192.168.1.109] (p54BDE38A.dip0.t-ipconnect.de [84.189.227.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id D092320504 for ; Fri, 6 Jul 2018 11:52:07 +0200 (CEST) From: Stefanie Gerdes To: core@ietf.org Message-ID: <3d39562b-5a57-6fd6-03f7-9d13d2c58ffd@tzi.de> Date: Fri, 6 Jul 2018 11:52:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [core] Resource Directory Authorization Problems X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jul 2018 09:52:13 -0000 Hi all, I just read through the security considerations of draft-ietf-core-resource-directory-14 and have some comments. I have some difficulties to understand the security considerations, in particular sections 8.1 and 9. Section 8.1: "An Endpoint is determined to be unique.." -> is supposed to be unique? should/must be unique? "Consider the following threat: two devices A and B are managed by a single server" I don't really understand the scenario, are A and B endpoints (btw, the definition of the term endpoint in the document is not really intuitive)? What kind of server do you refer to? The RD server? Do you describe registration, lookup, ..? "Then, it puts the endpoint name of device B." Where does it put that? If certain processes, e.g., the registration or the lookup, require authorization, it may be useful to mention clearly in the security considerations where authorization is or may be required and why. Section 9.: "An authorized registry request to the Resource Directory (RD) is accompanied by an Access Token that validates the access of the client to the RD." validates -> allows? In section 9.2 you define the new CWT fields rd_epn and rd_sct. I don't think new fields should be defined in the security considerations. Also, lookup and registration of RD entries do not seem to differ that much from the access to other resources. We may not want to define new CWT fields for every use case. That the subject of the access token is only allowed to register for the registree-ep given in rd_epn, sounds more like an access token scope to me. It might be a good idea to only point out the security problems concerning authorization in the security considerations and define the solution elsewhere. Viele Gruesse, Steffi From nobody Fri Jul 6 06:24:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5D130EF1 for ; Fri, 6 Jul 2018 06:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Rcha3UFixbt4 for ; Fri, 6 Jul 2018 06:24:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05091130E88 for ; Fri, 6 Jul 2018 06:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530883478; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SpuBeLw36IznsodEH8LKCIftHjp+9W+MQy2dMzkKM5o=; b=dp4cu4U8daRNxu+jcsxKu4dQsSlVC+mVLjzO68RYEYp/AVVKHDvN2DhhEi4hSs1X GvNe38ZLzE5cx5cAgDp709mPd8HHt8EKMaRqfhlKQtifvyaPvFeVFSkKiLjGgbl4 VOFfUUJ0fT6n8f8J+35BVAvgheiEVWoN1uMtc82Vwyk=; X-AuditID: c1b4fb30-93dff70000000a77-4b-5b3f6d96dafd Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.52.02679.69D6F3B5; Fri, 6 Jul 2018 15:24:38 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 6 Jul 2018 15:24:37 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Fri, 6 Jul 2018 15:24:37 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: New Version Notification for draft-keranen-core-senml-fetch-01.txt Thread-Index: AQHUEk5pC6RKf/h0xkmIkbrzjuoHUA== Date: Fri, 6 Jul 2018 13:24:37 +0000 Message-ID: References: <153056810732.16135.8525440067509626517.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <379A5FB419431341ACF08A90C863A766@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbG9SHdarn20wcfJfBb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsu2bUwFPYIVW5fOYmpgfM7bxcjJISFgIvFi3032LkYuDiGB o4wS8+feYYNwvjJK9G84CZVZyihxZW0jO0gLm4C9xOQ1HxlBbBEBCYnOr/vB4sICQRKr7v1j gogHSRzu6GKBsPUkTk2axgZiswioSDyes5sZxOYFmnN47gEwW0jAV6KrvRdsDqOAmMT3U2vA 5jALiEvcejKfCeJUAYkle84zQ9iiEi8f/2OFsJUk9h67zgJRrydxY+oUNgjbWuL3rlusELa2 xLKFr6H2CkqcnPmEZQKj6CwkK2YhaZ+FpH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpMLi7O z9PLSy3ZxAiMl4NbfhvsYHz53PEQowAHoxIPb0WOfbQQa2JZcWXuIUYJDmYlEd69gXbRQrwp iZVVqUX58UWlOanFhxilOViUxHkt/DZHCQmkJ5akZqemFqQWwWSZODilGhjrzMWM8nyYi5ii 2Vre+5h4b+f6xOlx2o7x347FNxczf3IO27PofHWZzbekgInbHA0Wilc6Hvy82o1fqL9u36w8 tkt9MxfOjHjy9dG0Tf/b9FKniGw+fYpBT3iRtI2J5q7TPC3phw2vPb3OwbVr++FYDyH/lTte efNGGJ+wWMDT5LmbZ/8EpyIlluKMREMt5qLiRACANh18kwIAAA== Archived-At: Subject: [core] Fwd: New Version Notification for draft-keranen-core-senml-fetch-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jul 2018 13:24:43 -0000 FYI; we submitted a new version of the SenML FETCH & PATCH draft. Main changes: * Removed the wild-card feature (based on London IETF feedback) * Removed the registration of media types. Those are not actually needed si= nce we can simply define semantics for SenML for the new methods. * Made iPATCH support and preference explicit * Added way to append and delete with iPATCH (inspired by RFC7396) * Added security considerations. Comments welcome! Cheers, Ari > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-keranen-core-senml-fetch-01.t= xt > Date: 3 July 2018 at 0.48.27 EEST >=20 >=20 > A new version of I-D, draft-keranen-core-senml-fetch-01.txt > has been successfully submitted by Ari Keranen and posted to the > IETF repository. >=20 > Name: draft-keranen-core-senml-fetch > Revision: 01 > Title: FETCH & PATCH with Sensor Measurement Lists (SenML) > Document date: 2018-07-03 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-keranen-core-s= enml-fetch-01.txt > Status: https://datatracker.ietf.org/doc/draft-keranen-core-senml= -fetch/ > Htmlized: https://tools.ietf.org/html/draft-keranen-core-senml-fetc= h-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-keranen-core-= senml-fetch > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-keranen-core-se= nml-fetch-01 >=20 > Abstract: > The Sensor Measurement Lists (SenML) media type and data model can be > used to send collections of resources, such as batches of sensor data > or configuration parameters. The CoAP iPATCH, PATCH, and FETCH > methods enable accessing and updating parts of a resource or multiple > resources with one request. This document defines semantics for the > CoAP iPATCH, and FETCH methods for resources represented with the > SenML data model. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Jul 6 06:28:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEE7130FF3 for ; Fri, 6 Jul 2018 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5AFPpNYSsa4 for ; Fri, 6 Jul 2018 06:28:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C78131012 for ; Fri, 6 Jul 2018 06:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w66DSIKL002664 for ; Fri, 6 Jul 2018 15:28:18 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41MbC64HSQzDXD4; Fri, 6 Jul 2018 15:28:18 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 552576496.218891-6471c14eb3a6688e7b9aa00c17cb7a9f Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 6 Jul 2018 15:28:17 +0200 Message-Id: <61A84924-A3D3-461F-9783-4644706A6F1A@tzi.org> To: Core X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] CoRE @ IETF102 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jul 2018 13:28:31 -0000 The chairs have uploaded a draft agenda to https://datatracker.ietf.org/doc/agenda-102-core/ Please have a look and check whether =E2=80=94 your slot request is in there =E2=80=94 the time allocated is appropriate There is zero flextime this time. We=E2=80=99ll need to reduce the time = on some items a bit so we have more flextime at the end, so please do = look if you can get useful work done in less time (or possibly need more = time=E2=80=A6). As usual, please also send the objectives you have for your slot to = core-chairs@ietf.org so we can include them in the next version of the = agenda. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 6 08:03:31 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2655130E5F for ; Fri, 6 Jul 2018 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v41rJZDNcDl2 for ; Fri, 6 Jul 2018 08:03:22 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40F8120049 for ; Fri, 6 Jul 2018 08:03:20 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id v25-v6so15231976wmc.0 for ; Fri, 06 Jul 2018 08:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=kxCyEWVk4VpjxprK3GjzdcN/ENtJD7Jz1zSY0aJQnVc=; b=jEwtLmtBhcvL9j4wSreZgQNuXFWFEWtl57DT62D3GJ1QX9WCw9zNxmsP3AbX5LmENs QC9ddN3sEAPRSSPIrywRXYuwc+IXNUmoXmHifxduYexAXgT5AlQYn8T+aHwJMGeE2TAH yUC/uPnwj7UFWGKDobpbvRiaURxCbi8TCBZyCkcB5ZNEFMC4LR6ZoSDRYqQrfbzbpzIj Xjd1zMEGwFa3CVEOTPvzF3pCN+uwB/jOKrXW37zpGGmb7SUIYozfYIKuz+FdDV1GR6UB 1AbXXaROqkmbno3bo3yR3ORHqDd9QMa5Z/yWWAAlEwmn1KUoU2XlElYyhpS932fNNKZg c/bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=kxCyEWVk4VpjxprK3GjzdcN/ENtJD7Jz1zSY0aJQnVc=; b=qL9lmWN1Vt1vrlsbBfNP7gXCvNWCttYodi6MaBgDCyvq3s3drXIJgFZApyeTT2BXPu zQlBxBLBrxSEk9OzTVpliKVOuBZzAXUB18jXbkBUYOYiMMn2vQMssex7O2h6fjciI/jo YPttg6D7HGkLdKOP1PcCbA0cOu+22mv5arrOckypLtII4BDaQVsl2IS9x0Me35YhoSJz mKQpo4kq6d7NedNRADPmtlPAwhf0ZngGbdQHJm8iQTZloTiNpegT7XGtnGBU0yLRSzL+ zNc5eUKn0Kmd3+ogwVBvcg5nR0/z7j8IYGaBvg+9n8lGO86VgBI4r7YghhGTRMCYrDir DJ5w== X-Gm-Message-State: APt69E0tAC9CsGjgc/CDBA4ZkcTqtn0ScUj6htac/ptOrCbVVLFgAnGj XCQjino/O/YN53GMjV6YkYnI95zYGA0= X-Google-Smtp-Source: AAOMgpcI0pt5ckJx9OfozcRy6p/yBNSPbwP3OkgKXDDOIsqZQY1oDaPXwpIMJY/SYKao1BNHa/hKTA== X-Received: by 2002:a1c:3b54:: with SMTP id i81-v6mr7041400wma.143.1530889398745; Fri, 06 Jul 2018 08:03:18 -0700 (PDT) Received: from [192.168.1.64] (204.137.207.77.rev.sfr.net. [77.207.137.204]) by smtp.gmail.com with ESMTPSA id t124-v6sm3367673wmf.37.2018.07.06.08.03.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 08:03:17 -0700 (PDT) From: Alexander Pelov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <042A223B-722C-43DD-9478-EC8D014133F4@ackl.io> Date: Fri, 6 Jul 2018 17:03:16 +0200 To: core@ietf.org, netmod@ietf.org, yot@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] Hackathon - open-source CoMI implementation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 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, 06 Jul 2018 15:03:24 -0000 Dear all, The way to use YANG for IoT - CoMI - has been stable for some time and = the missing piece as always has been.. running OPEN-SOURCE code! Montreal is the place to change that! Join us at the Hackathon in the = first structured effort to provide an open-source implementation of a = CoMI server and CoMI client. I personally will be coding in Python, but in case other folks want to = use something else - that's even better. See you on the Hackathon! Alexander PS. If people knowledgable in YDK want to join, that would be really = perfect! The description is here: https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon From nobody Mon Jul 9 00:53:43 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845E1277CC for ; Mon, 9 Jul 2018 00:53: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGv-9ui-NFwY for ; Mon, 9 Jul 2018 00:53:38 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224BE130E10 for ; Mon, 9 Jul 2018 00:53:36 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id D8A4F18024A68; Mon, 9 Jul 2018 07:53:34 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:41:72:152:355:371:372:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2559:2564:2682:2685:2692:2693:2859:2894:2901:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4120:4250:4321:4470:4860:5007:6117:6119:6261:6657:6659:6678:7875:7903:7904:8603:9010:9025:9177:10004:10848:11232:11657:11658:11914:12043:12291:12295:12296:12379:12438:12663:12683:12740:12895:13139:13141:13144:13230:13439:13846:13972:14093:14095:14096:14180:14181:14721:21060:21080:21324:21433:21451:21627:30029:30030:30054:30060:30076:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck: X-HE-Tag: snow00_76843b0968c5c X-Filterd-Recvd-Size: 9124 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Mon, 9 Jul 2018 07:53:34 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b505ce2498315dd4e6e85c0d04bf0907" Date: Mon, 09 Jul 2018 09:53:33 +0200 From: Peter van der Stok To: Stefanie Gerdes Cc: core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3d39562b-5a57-6fd6-03f7-9d13d2c58ffd@tzi.de> References: <3d39562b-5a57-6fd6-03f7-9d13d2c58ffd@tzi.de> Message-ID: <6a6095b3681e9d3da32eb98c14ec2239@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [82.95.140.48] Archived-At: Subject: Re: [core] Resource Directory Authorization Problems X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 07:53:42 -0000 --=_b505ce2498315dd4e6e85c0d04bf0907 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Steffi, Many thanks for reading and sharing your impressions from another background. I react below. Stefanie Gerdes schreef op 2018-07-06 11:52: > Hi all, > > I just read through the security considerations of > draft-ietf-core-resource-directory-14 and have some comments. > > I have some difficulties to understand the security considerations, in > particular sections 8.1 and 9. > > Section 8.1: > > "An Endpoint is determined to be unique.." -> is supposed to be unique? > should/must be unique? > > Correct; the (ep-name, sector-name) pair MUST be unique within the set of endpoints specified within the RD. > (will rephrase) > > > "Consider the following threat: two devices A and B are managed by a > single server" I don't really understand the scenario, are A and B > endpoints (btw, the definition of the term endpoint in the document is > not really intuitive)? What kind of server do you refer to? The RD > server? Do you describe registration, lookup, ..? > > thanks, it is RD server. will clarify. > (FYI: endpoint definition has taken some time to agree upon) > > > "Then, it puts the endpoint name of device B." Where does it put that? > > Yes, this is really opaque, probably something got lost over the versions. > > > If certain processes, e.g., the registration or the lookup, require > authorization, it may be useful to mention clearly in the security > considerations where authorization is or may be required and why. > > Authorization to specify endpoint names > > > Section 9.: > > "An authorized registry request to the Resource Directory (RD) is > accompanied by an Access Token that validates the access of the client > to the RD." validates -> allows? > > This is ACE terminology; I am just guessing: authorizes? > > > In section 9.2 you define the new CWT fields rd_epn and rd_sct. I don't > think new fields should be defined in the security considerations. > > We agree; that is not done; Section 9 is stand alone; Section 8 refers to it; that's all. > May be I misunderstand your concern here. > > Also, lookup and registration of RD entries do not seem to differ that > much from the access to other resources. We may not want to define new > CWT fields for every use case. That the subject of the access token is > only allowed to register for the registree-ep given in rd_epn, sounds > more like an access token scope to me. > > scope is from client to AS? > I did not discuss that part, but indeed the client first asks the AS permission to register an endpoint name into the RD. > The AS, when happy, creates an endpoint name, and authorizes the client to register the endpoint name by specifying its value with rd_epn. > Do you have an alternative to solve the problem. Can you modify the example? > > > The purpose is to authorize > > It might be a good idea to only point out the > security problems concerning authorization in the security > considerations and define the solution elsewhere. > > > I thougt, I did. > > > Viele Gruesse, > Steffi > > Many thanks. looking forward to your reaction. > > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=_b505ce2498315dd4e6e85c0d04bf0907 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Steffi,

Many thanks for reading and sharing your impressions = from another background.
I react below.

Stefanie Gerdes schreef op 2018-07-06 11:52:

= Hi all,

I just read through the security considerations of
draft-ietf-core-resource-directory-14 and have some comments.

= I have some difficulties to understand the security considerations, in
particular sections 8.1 and 9.

Section 8.1:

"An = Endpoint is determined to be unique.." -> is supposed to be unique?
should/must be unique?
<pvds>
Correct; the (ep-name, sect= or-name) pair MUST be unique within the set of endpoints specified within t= he RD.
(will rephrase)
</pvds>

"Consider the fo= llowing threat: two devices A and B are managed by a
single server" I= don't really understand the scenario, are A and B
endpoints (btw, th= e definition of the term endpoint in the document is
not really intui= tive)? What kind of server do you refer to? The RD
server? Do you des= cribe registration, lookup, ..?
<pvds>
thanks, it is RD ser= ver. will clarify.
(FYI: endpoint definition has taken some time to ag= ree upon)
</pvds>

"Then, it puts the endpoint name o= f device B." Where does it put that?
<pvds>
Yes, this is re= ally opaque, probably something got lost over the versions.
</pvds&= gt;

If certain processes, e.g., the registration or the lookup,= require
authorization, it may be useful to mention clearly in the se= curity
considerations where authorization is or may be required and w= hy.
<pvds>
Authorization to specify endpoint names
<= ;/pvds>

Section 9.:

"An authorized registry requ= est to the Resource Directory (RD) is
accompanied by an Access Token = that validates the access of the client
to the RD." validates -> a= llows?
<pvds>
This is ACE terminology; I am just guessing: = authorizes?
</pvds>

In section 9.2 you define the ne= w CWT fields rd_epn and rd_sct. I don't
think new fields should be de= fined in the security considerations.
<pvds>
We agree; that= is not done; Section 9 is stand alone; Section 8 refers to it; that's all= =2E
May be I misunderstand your concern here.
</pvds>
= Also, lookup and registration of RD entries do not seem to differ that
much from the access to other resources. We may not want to define new CWT fields for every use case. That the subject of the access token is=
only allowed to register for the registree-ep given in rd_epn, sound= s
more like an access token scope to me.
<pvds>
scope= is from client to AS?
I did not discuss that part, but indeed the cli= ent first asks the AS permission to register an endpoint name into the RD= =2E
The AS, when happy, creates an endpoint name, and authorizes the c= lient to register the endpoint name by specifying its value with rd_epn.Do you have an alternative to solve the problem. Can you modify the exam= ple?
</pvds>

The purpose is to authorize 
<= br /> It might be a good idea to only point out the
security problems= concerning authorization in the security
considerations and define t= he solution elsewhere.

<pvds>
I thougt, I did.
&= lt;/pvds>

Viele Gruesse,
Steffi

Many thanks= =2E looking forward to your reaction.

Peter
______________= _________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--=_b505ce2498315dd4e6e85c0d04bf0907-- From nobody Mon Jul 9 01:09:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AD6130E22 for ; Mon, 9 Jul 2018 01:09:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3bdPMjhwnsY for ; Mon, 9 Jul 2018 01:09:33 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9818D130E1D for ; Mon, 9 Jul 2018 01:09:33 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id BEE35837F24C for ; Mon, 9 Jul 2018 08:09:32 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:72:152:355:379:582:800:960:962:967:969:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1381:1431:1436:1437:1516:1517:1518:1534:1542:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2525:2527:2561:2564:2682:2685:2693:2829:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3586:3622:3740:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4659:5007:6261:6298:6659:6684:8603:9015:9025:9177:9388:10004:10400:10848:11232:11657:11658:11914:12043:12555:12679:12895:12986:13139:13161:13199:13229:13439:13846:14096:14181:14721:21063:21080:21324:21433:21451:21625:21691:30029:30041:30048:30054, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: bell52_706ba7aaf7d43 X-Filterd-Recvd-Size: 4561 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA for ; Mon, 9 Jul 2018 08:09:32 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_01684bb13c8aaf9b221295c5fcbf19e9" Date: Mon, 09 Jul 2018 10:09:32 +0200 From: Peter van der Stok To: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [82.95.140.48] Archived-At: Subject: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 08:09:36 -0000 --=_01684bb13c8aaf9b221295c5fcbf19e9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Dear CoRE, In the coaps-est draft presented in ACE, I ran into the following question: The coaps-est server uses a collection of resources: The collection resource has been assigned rt=ace.est It is not clear what the resource types of the underlying resources should be. Will they all have rt=ace.est as well or will each underlying resource need a separate resource type The choice for the est-coaps example is: REQ: GET /.well-known/core?rt=ace.est RES: 2.05 Content ; rt="ace.est" ;rt="ace.est" ;rt="ace.est" ;rt="ace.est" ;rt="ace.est" ;rt="ace.est" OR an example alternative: REQ: GET /.well-known/core?rt=ace.est.* RES: 2.05 Content ; rt="ace.est" ;rt="ace.est.crts" ;rt="ace.est.sen" ;rt="ace.est.sren" ;rt="ace.est.att" ;rt="ace.est.skg" Looking forward to your thoughts and ideas. A volunteer that writes a draft about the structure of the rt= name space would be welcome indeed. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_01684bb13c8aaf9b221295c5fcbf19e9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Dear CoRE,

In the coaps-est draft presented in ACE, I ran into t= he following question:
The coaps-est server uses a collection of resou= rces:
The collection resource has been assigned rt=3Dace.est
It i= s not clear what the resource types of the underlying resources should be= =2E 
Will they all have rt=3Dace.est as well
or will each un= derlying resource need a separate resource type

The choice for t= he est-coaps example is:

REQ: GET /.well-known/core?rt=3Dace.est=
RES: 2.05 Content
</est>; rt=3D"ace.est"
</est/crt= s>;rt=3D"ace.est"
</est/sen>;rt=3D"ace.est= "
</est/sren>;rt=3D"ace.est"
</est/a= tt>;rt=3D"ace.est"
</est/skg>;rt=3D"ace.es= t"


OR an example alternative:
REQ: GET /= =2Ewell-known/core?rt=3Dace.est.*
RES: 2.05 Content
</est>; rt=3D"ace.est"
</est/crts&g= t;;rt=3D"ace.est.crts"
</est/sen>;rt=3D"ace.est.sen"
</est/sren>;rt=3D"ace.est.sren"
</est/att>;rt=3D= "ace.est.att"
</est/skg>;rt=3D"ace.est= =2Eskg"

Looking forward to your thoughts and ideas.
=
A volunteer that writes a draft about the structure of the rt=3D name= space would be welcome indeed.

Peter
--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org
www: = = www.vanderstok.org
tel NL: +31(0)492474673    &nbs= p;F: +33(0)966015248
--=_01684bb13c8aaf9b221295c5fcbf19e9-- From nobody Mon Jul 9 03:48:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9D130F83; Mon, 9 Jul 2018 03:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfj5al-Kr7sj; Mon, 9 Jul 2018 03:48:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219A6130E62; Mon, 9 Jul 2018 03:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1598; q=dns/txt; s=iport; t=1531133299; x=1532342899; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=ILYlwdQ82g9tv3hMJWeay+NKZP3+kU3+uUpVCskpIdg=; b=JUcOQPdc+TT5JYYYRv0n2yTJJWR9NMH8OOl4JkmbNi1tzKjM3s3uHqiW KuAyyMvOdONPIEbjGSIjGZTYY3UKFLALOox0EJZ7+JmpGo1LrxQpNLRWx awEr1NSQnZCMPxcyvsvaxau+BqCxIlv87d6buVQm3S+mwAMDXWkx6m3Ps g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQBgPENb/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMfgXkShCKIY40ylVyBeguHUTYWAQIBAQIBAQJtKIVgDwE?= =?us-ascii?q?FdgImAmAMCAEBF4MFggCpA4IchFuDaoE6gQuJOT+BDyeCaId7glUCmU8JgUC?= =?us-ascii?q?HLIYyBoFChlQlhSKMPIVUgUgKJyaBLDMaCBsVO4JqgiMXegEOjQ8+jwEBAQ?= X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="scan'208";a="5002223" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 10:48:17 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w69AmGib005562; Mon, 9 Jul 2018 10:48:16 GMT To: core@ietf.org, draft-ietf-core-sid@ietf.org From: Robert Wilton Message-ID: Date: Mon, 9 Jul 2018 11:48:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [core] Review of draft-ietf-core-sid-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 10:48:22 -0000 Hi, I've read this draft.  I think that it is well written, and is fairly easy to follow, and I generally like the solution of SIDs. Some comments: 1) Section 1. I think that it may be better if SIDs are only allocated from the range 0 to int64 max (i.e. 2^63 - 1).  This would still seem to make huge numbers of SIDs available, but makes it easier to generate 64 bit SID deltas without having to worry about sign overflow. 2) In the YANG model .sid file format (section 4): (i) It might be nice if this could use YANG instance-data (draft-lengyel-netmod-yang-instance-data-02), although I don't think that it is worth waiting for. (ii) Rather than the enum of namespace types, and 2 key list, I would prefer that there are separate lists (each with a single key) for each namespace.  I think that this would probably make it slightly easier to process, since implementations could then easily choose which order to process the namespaces in.  It also avoids the need for the union type, and corresponding MUST statements. (iii) If you are going to use RFC 2119/8174 language in the YANG module, then I think that the module should include the boilerplate from RFC 8174. 3) Section 6.1: In the first sentence, I think that you should include "private enterprise" (or equivalent) in the list of examples. Section 6 isn't particularly clear about allocating blocks of SIDs to private enterprises or individuals.  I presume that this is allowed, and possibly it would help if the draft was a bit more explicit on this. Thanks, Rob From nobody Mon Jul 9 03:50:49 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212A7130F86 for ; Mon, 9 Jul 2018 03:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: invalid data)" header.d=kereval.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 mH9f7V0r5JBk for ; Mon, 9 Jul 2018 03:50:42 -0700 (PDT) Received: from ouessant.kereval.com (ouessant.kereval.com [95.128.151.250]) by ietfa.amsl.com (Postfix) with SMTP id 4185012D7F8 for ; Mon, 9 Jul 2018 03:50:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ouessant.kereval.com (Postfix) with ESMTP id 7BC84DE019F for ; Mon, 9 Jul 2018 12:50:39 +0200 (CEST) Received: from ouessant.kereval.com ([127.0.0.1]) by localhost (ouessant.kereval.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5FE1IuNglFJy for ; Mon, 9 Jul 2018 12:50:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ouessant.kereval.com (Postfix) with ESMTP id 735CCDE04B5 for ; Mon, 9 Jul 2018 12:50:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 ouessant.kereval.com 735CCDE04B5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kereval.com; s=3A785DCC-E244-11E6-867F-0A305E6AE5F1; t=1531133438; bh=ssF0FtAOcs4mQGs+A58nV51uCrzgNsMLcqgvPdr0FeY=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=U3CzfyaybTfaTgYcwW8fnt+uq/OP73HmEItffQMCtV5CirglkvL2vtvFTzdS2J+mZ +ZakEhQQixURP08XaJowHKgs4rpv7a9iHFjfiWAd2Pqcv2t96oeBq94rjWJCHixDoz BZmtgbcwxwYvuDpxI8zE0Cxv7axJwq3cHQSNG3t0= X-Virus-Scanned: amavisd-new at ouessant.kereval.com Received: from ouessant.kereval.com ([127.0.0.1]) by localhost (ouessant.kereval.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7xgH7VNCZexX for ; Mon, 9 Jul 2018 12:50:38 +0200 (CEST) Received: from PCART (unknown [192.168.10.153]) by ouessant.kereval.com (Postfix) with ESMTPSA id 475BDDE019F for ; Mon, 9 Jul 2018 12:50:38 +0200 (CEST) From: "Alain RIBAULT" To: Date: Mon, 9 Jul 2018 12:50:32 +0200 Message-ID: <060001d41772$a8938de0$f9baa9a0$@ribault@kereval.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0601_01D41783.6C1C5DE0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdQXcqhYJGyRt8/eTEWEiyiyDKHmvw== Content-Language: fr Importance: High Archived-At: Subject: [core] Surevy to prepare a CoAP remote plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 10:50:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0601_01D41783.6C1C5DE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0602_01D41783.6C1C5DE0" ------=_NextPart_001_0602_01D41783.6C1C5DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, KEREVAL is a french testing lab involved in the European open project F-interop (https://www.f-interop.eu/) which aim is to develop an interoperability testing platform for WPAN. In this project, there are tools to realize CoAP interoperability tests. The F-Interop platform has been presented during the last IETF meeting, = in London, and the IoT week. We intend to organize CoAP remote plugtests, using the F-Interop = platform and CoAP testing tools (https://youtu.be/_oZ08kp1hQk) , but before, we prepared a survey in order to gather your needs. Thus, please could you fill the survey ; it will take no more than 5 minutes. Thanks for your attention. Regards. =20 Alain. =20 Alain RIBAULT Directeur Technique/ CTO =20 image001 KEREVAL 4, rue H=E9l=E8ne Boucher Z.A. Bellevue 35235 Thorign=E9 Fouillard=20 Tel : +33 (0)2 23 20 36 64 Direct : +33 (0)2 23 20 41 88 Mobile : +33 (0)6 13 89 55 89 http://www.kereval.com =20 ------=_NextPart_001_0602_01D41783.6C1C5DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

KEREVAL is a french testing lab involved = in the European open project F-interop (https://www.f-interop.eu/) = =A0which aim is to develop an interoperability testing platform for = WPAN.
In this project, there are tools to realize CoAP = interoperability tests.
The F-Interop platform has been presented = during the last IETF meeting, in London, and the IoT week.

We = intend to organize CoAP remote plugtests, using the F-Interop platform = and CoAP testing tools (https://youtu.be/_oZ08kp1hQk) = , but before, we prepared a survey in order to gather your = needs.

Thus, please could you fill the survey   ; it will = take no more than 5 minutes.

Thanks for your = attention.

Regards.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Alain.

 

Alain RIBAULT
Directeur Technique/ CTO

 

3Dimage001

KEREVAL

4, rue H=E9l=E8ne Boucher

Z.A. Bellevue

35235 Thorign=E9 Fouillard

Tel : +33 (0)2 23 20 36 64

Direct : +33 (0)2 23 20 41 88

Mobile : +33 (0)6 13 89 55 89
http://www.kereval.com

 

------=_NextPart_001_0602_01D41783.6C1C5DE0-- ------=_NextPart_000_0601_01D41783.6C1C5DE0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhZAAwAPcAAAAAAEZGRkhHR0pJSUxKSk1MTE5OTlBOTl5ERVJRUVRTU1VUVFZWVllYWFxa WlxcXGBeXmJiYmRlZmVmaGdoaWloaGhpa2pqamlqbGtsbmxra21tbm5vcW9wcnFvb3FxcXN0dXRz c3V1dnV2eHd4en93d3h4eHh4ent6enp7fXx7e3x8fHx9fn5+fn5+gH+AgY42N4B/f5VoabZGR6d8 fcssLtMhI9QgItUiJNUkJtYmKNYoKtYqLNcsLtcvMdgwMtgzNdg0Ntk3Odk4Otk6PNo9P9o/QdtA QttCRNxGSNxJSt1LTd1NT95QUt9XWcB7e+BaXOBdXuBeYOFgYuFiY+FjZOJlZuJpauNqa+Ntb+Nu cORwceRzdOR0duV2d+V4eeV6e+Z6fOZ+f+Z/gIGBgYGChISDg4SEhIWFhoaGhoaGiIiHh4mIiIqK ioqLjI2NjY6Ojo6PkJaLi5GQkJCRkpKSkpKTlJWTk5SUlJSUlpWWlpaXmJmYmJuampyampycnJyd np2en6GgoKCgoqKioqKjpKOkpaWkpKWlpqampqinp6moqKmqqqusraysrK6urq6vsLGwsLOztLWz s7a0tLi3t7m4uLm5urq6ury7u728vL6+vs+srOeBgueCg+iFhuiHiOiIieiIiumKi+mLjOmNjumP kOqRkuuVluuXmOuYmeydnu2foO2hou2kpe6pqu+trvG0tfG4ufK9vvK+vsDAwMLCwsPDxMTDw8TE xMXGxsjHx8nIyMnJysrKys3MzM7OztDQ0NLS0tPT1NTU1NXV1tbW1tjX19jY2Nra2tvb3Nzb29zc 3N7e3uDf3/PDxPTFxfTHyPTJyvXNzfbP0PbQ0fbS0vfV1ffY2Pja2vjd3eHg4OLi4uTj4+Tk5Obm 5uno6Orq6uzr6+zs7O7u7u/v8Pni4vnj5Prl5frp6fvs7Pvu7vzv7/Dw8PLy8vfw8PT09PX19vb2 9vzx8fzx8vzy8v309P329vj4+Pr6+vv7/P34+P76+vz8/P7+/gAAACH5BAEAAP8ALAAAAABkADAA AAj/AP8JHEiwoMGDCBMqTNgvXDJiwYAJS7bt2zh4/hZq3Mixo8eB/rzZcvSIEqZNuYIha7aNmTFk 3/B9nEmz5sFmh/4cYkQJmDd3/Qr2c/ft2LegNpMqVTiO0Jo6fzBx06fRnztwMpdq1SpsxYo1irjN xJdvq1ma/RZVCGHGV0ahG90hO0t3Iz42ECq8GWdwnpdOV2hp5ParruGD+FAsgIAna0FQ1v7xi/JW Ia+5hzP3S0NgwR+kBq0MFHNOo7xJ4DIfFkSAwBvQBkFlEzjl3sZgmcqqPvurdQV5CtVpCfUlFkd3 lJbtNgvPAQEF3jba+6hLk+PlSfm0rnR4WaZt2JV6/ytAQETlgq9YDdRmCt1BadgOhsvkK3zSO62P IZx240Y9gU7cgIVB6ODgA2wC4ZNJLdcZpM95IAmlz4QTDpTPhRheiOA//fDjoYdIuZMAASUkpMUN TQiUTX85pFPQNf3tY5A/mtQSjkIiDFKQO3ZM0Ms/3+jBgQREFllGPoMUqaQEFujhzj/7mGIEDv1V 2YNgmLQ2w4b/sKPDDbAIJEaVp7wY40G11AJeQhLQQVAxIEgwgkVDSsDBnXjS0Q8LEnwAwp+ATiDB Hv+ceAMPPiSa6BHR/EMGAQjcMMtBq9zwg4z29GDpDUPwQxCMN8hoUJrJKNSmQPo4Iuge8PwTiQSJ tP96EAsnHNQOCBugc4MR1yDUzwIEwHBDFQclcQMoArlyQxDofCnLp2caVKMxproZThoSZHDLQIFI wBdCLKSAkB0SSHNDKQlt09oTN+DgHkH83WCOQErcMMo/WdwQBbShGqRgLcSY6oYuG0iARmoDASIB OQmFO265N5iSEC4EHPDODxEX1MUNUwgU77zQ9KfNQKCKShA5CwbMJpETPEIVQQpLcsvMNN/iy54j bDjOCBmYC8UrQAcNNDqOEODBP6Bw6qlA9exwg2D/bHGDFAL5c8QNn5AcLUHOLKjfyhIEcpDCSyoZ Dp8WYKD22kTaYW6VcPcnCiEEnPGPOVQ+m+wNRQT/pY6zA6ViqaglG/TLgs2YSsGqsiYsQR6FRC55 IY3ow2fZEmCQRzvmIgHG56CDEYY1fxBwh0BWTD3QEjeoIpDgQiz9Tzo5gClQ4QTlY8mC0bFJhzEi yImZQArfCG4HeRBZBjMaCmTuvQj5QUAfAj3T37zW3KDDOhwWcW5BWKB4+9YCdUPJgu1U+487yU8A CVLFNyxuMXxOYEjj5oqS0CIEzFE1EjcgxT/CcAMuCIQW7XrXQEJ2g17hbiC4OF8uuDSQUwlkExiQ gBpuxAgJSIKCDvuHPi5RsA/UIijauIESXHSQ3qxhIK1YVjo0RQ2BUGFYMwIgGP7xwH+EIxLno5b6 /wbijRdIYAPD8IYFMjcCEjjRiS5wRwgFUg6yueAb/wgQDoJAhC568RXwKIAKBlIPTQXhBkwQyDmo NCmDVIoH9TBHf6ZBkE0AMRMMU0gHxJY7REhAR8yIAwXKRoF26CEPBlFGGSRgiX/UwxMYi1vr/rGB BxBkDFV6hUBEcQMicGkeTmuFP864gy6gYhWcOAQQd6ERfHDJlQPpRztmSct4cIhL/UjGywQyj3T4 8pcZSQQBEPaPFN7AB7bZBxBuUCaEeOEGSfiHKeBWAzmokhJYtE9NxFGASBDkhvqbnfZYeJBr6MAH /tiH1G5gAxnMQZW5gJA2PWIGDVSGHrIwGSyesf+QasxGIOaQBQ1a8M5IfGueNNlGAQpjFl58oAVo mAMvEJodE5hlF30yAUHxAAyK1gQfG6jPUmzRgAh8QAIPaEEb8PAI4Hj0I98QQYM+0o9EJKCkHyDD TVdwBj3ooXcv7Yg3vFmTb3xgADeNwBnAYQwGLGAFZMADHOIZ1I64w3geIYceCCAApDbgDbJqRgMS oNE31OEQT6oqR8DhC90sxBt/MIAAAhCAASiAEbD5RgQMIIIWpEEPc2CGWtdKhjr4In0FkUcwCLEB ujo2ADEQi0HCcYECPDSqbcAEBQdbEF1IIAAN2IAJTHCBBjzWsQJQQTAUQo6jbqAFBJ3DH/LIWYV4 +EMYbWDAaR07gA0sIpsLcccKBFAB2LJBD21QWW0X4o9t5CISf/gDIzBBjJkuRB5nCEAEYEsGPaQh EtZdrmHwAYcApJQMhXVDIsQbnnzwYQAMWAF37cZe7PSDEEjVaAvgUN/w+MMRBShABTZQi/7apxYb EIEt/BEQADs= ------=_NextPart_000_0601_01D41783.6C1C5DE0-- From nobody Mon Jul 9 03:53:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9A7130F86 for ; Mon, 9 Jul 2018 03:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_GREY=0.424] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: invalid data)" header.d=kereval.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 Z8bpnz-NYOis for ; Mon, 9 Jul 2018 03:53:03 -0700 (PDT) Received: from ouessant.kereval.com (ouessant.kereval.com [95.128.151.250]) by ietfa.amsl.com (Postfix) with SMTP id A4594130E62 for ; Mon, 9 Jul 2018 03:53:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ouessant.kereval.com (Postfix) with ESMTP id DFAE1DE019F for ; Mon, 9 Jul 2018 12:53:01 +0200 (CEST) Received: from ouessant.kereval.com ([127.0.0.1]) by localhost (ouessant.kereval.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id M6TgZA1k_gi1 for ; Mon, 9 Jul 2018 12:53:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ouessant.kereval.com (Postfix) with ESMTP id 59E98DE04B5 for ; Mon, 9 Jul 2018 12:53:01 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 ouessant.kereval.com 59E98DE04B5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kereval.com; s=3A785DCC-E244-11E6-867F-0A305E6AE5F1; t=1531133581; bh=I3sOCX0FyD5MuTxViKWQPPAoViXiAykAP67YjxwGFTg=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=f1brZYXxb/1Lq5pwnrOeRs18Ja1HSy0s00DOHg21WrUaLqvlAXNhibOVOGXjQFe+B /k788hVk1OxRpe92fbatyUIXx7Q5B2Rv0LnllCvx6bxb4BdHxjzCtKNJnejDcr5fCV YOO1OBEkwO8ToXdpjJ9mxQEti/cBXq5XhMCyieVw= X-Virus-Scanned: amavisd-new at ouessant.kereval.com Received: from ouessant.kereval.com ([127.0.0.1]) by localhost (ouessant.kereval.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hkU-WtHFXy5b for ; Mon, 9 Jul 2018 12:53:01 +0200 (CEST) Received: from PCART (unknown [192.168.10.153]) by ouessant.kereval.com (Postfix) with ESMTPSA id 2AA51DE019F for ; Mon, 9 Jul 2018 12:53:01 +0200 (CEST) From: "Alain RIBAULT" To: References: In-Reply-To: Date: Mon, 9 Jul 2018 12:52:54 +0200 Message-ID: <060c01d41772$fdbd76f0$f93864d0$@ribault@kereval.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_060D_01D41783.C14646F0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdQXcqhYJGyRt8/eTEWEiyiyDKHmvwAAC0cA Content-Language: fr Importance: High Archived-At: Subject: Re: [core] Surevy to prepare a CoAP remote plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 10:53:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_060D_01D41783.C14646F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_060E_01D41783.C14646F0" ------=_NextPart_001_060E_01D41783.C14646F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I forgot the link to the CoAP remote plugtest survey: https://fr.surveymonkey.com/r/KNSH37Z. =20 Alain. =20 Alain RIBAULT Directeur Technique/ CTO =20 image001 KEREVAL 4, rue H=E9l=E8ne Boucher Z.A. Bellevue 35235 Thorign=E9 Fouillard=20 Tel : +33 (0)2 23 20 36 64 Direct : +33 (0)2 23 20 41 88 Mobile : +33 (0)6 13 89 55 89 http://www.kereval.com =20 De : Alain RIBAULT [mailto:alain.ribault@kereval.com]=20 Envoy=E9 : lundi 9 juillet 2018 12:51 =C0 : 'core@ietf.org' Objet : Surevy to prepare a CoAP remote plugtest Importance : Haute =20 Dear all, KEREVAL is a french testing lab involved in the European open project F-interop (https://www.f-interop.eu/) which aim is to develop an interoperability testing platform for WPAN. In this project, there are tools to realize CoAP interoperability tests. The F-Interop platform has been presented during the last IETF meeting, = in London, and the IoT week. We intend to organize CoAP remote plugtests, using the F-Interop = platform and CoAP testing tools (https://youtu.be/_oZ08kp1hQk) , but before, we prepared a survey in order to gather your needs. Thus, please could you fill the survey ; it will take no more than 5 minutes. Thanks for your attention. Regards. =20 Alain. =20 Alain RIBAULT Directeur Technique/ CTO =20 image001 KEREVAL 4, rue H=E9l=E8ne Boucher Z.A. Bellevue 35235 Thorign=E9 Fouillard=20 Tel : +33 (0)2 23 20 36 64 Direct : +33 (0)2 23 20 41 88 Mobile : +33 (0)6 13 89 55 89 http://www.kereval.com =20 ------=_NextPart_001_060E_01D41783.C14646F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I = forgot the link to the CoAP remote plugtest survey: https://fr.surveymonkey.com/r/KNSH37Z.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Alain.

 

Alain RIBAULT
Directeur Technique/ CTO

 

3Dimage001

KEREVAL

4, rue H=E9l=E8ne Boucher

Z.A. Bellevue

35235 Thorign=E9 Fouillard

Tel : +33 (0)2 23 20 36 64

Direct : +33 (0)2 23 20 41 88

Mobile : +33 (0)6 13 89 55 89
http://www.kereval.com

 

De : Alain = RIBAULT [mailto:alain.ribault@kereval.com]
Envoy=E9 : = lundi 9 juillet 2018 12:51
=C0 : = 'core@ietf.org'
Objet : Surevy to prepare a CoAP remote = plugtest
Importance : = Haute

 

Dear all,

KEREVAL is a french testing lab involved = in the European open project F-interop (https://www.f-interop.eu/) =  which aim is to develop an interoperability testing platform for = WPAN.
In this project, there are tools to realize CoAP = interoperability tests.
The F-Interop platform has been presented = during the last IETF meeting, in London, and the IoT week.

We = intend to organize CoAP remote plugtests, using the F-Interop platform = and CoAP testing tools (https://youtu.be/_oZ08kp1hQk) = , but before, we prepared a survey in order to gather your = needs.

Thus, please could you fill the survey   ; it will = take no more than 5 minutes.

Thanks for your = attention.

Regards.

 

          =       Alain.

 

Alain RIBAULT
Directeur Technique/ CTO

 

3Dimage001

KEREVAL

4, rue H=E9l=E8ne Boucher

Z.A. Bellevue

35235 Thorign=E9 Fouillard

Tel : +33 (0)2 23 20 36 64

Direct : +33 (0)2 23 20 41 88

Mobile : +33 (0)6 13 89 55 89
http://www.kereval.com

 

------=_NextPart_001_060E_01D41783.C14646F0-- ------=_NextPart_000_060D_01D41783.C14646F0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhZAAwAPcAAAAAAEZGRkhHR0pJSUxKSk1MTE5OTlBOTl5ERVJRUVRTU1VUVFZWVllYWFxa WlxcXGBeXmJiYmRlZmVmaGdoaWloaGhpa2pqamlqbGtsbmxra21tbm5vcW9wcnFvb3FxcXN0dXRz c3V1dnV2eHd4en93d3h4eHh4ent6enp7fXx7e3x8fHx9fn5+fn5+gH+AgY42N4B/f5VoabZGR6d8 fcssLtMhI9QgItUiJNUkJtYmKNYoKtYqLNcsLtcvMdgwMtgzNdg0Ntk3Odk4Otk6PNo9P9o/QdtA QttCRNxGSNxJSt1LTd1NT95QUt9XWcB7e+BaXOBdXuBeYOFgYuFiY+FjZOJlZuJpauNqa+Ntb+Nu cORwceRzdOR0duV2d+V4eeV6e+Z6fOZ+f+Z/gIGBgYGChISDg4SEhIWFhoaGhoaGiIiHh4mIiIqK ioqLjI2NjY6Ojo6PkJaLi5GQkJCRkpKSkpKTlJWTk5SUlJSUlpWWlpaXmJmYmJuampyampycnJyd np2en6GgoKCgoqKioqKjpKOkpaWkpKWlpqampqinp6moqKmqqqusraysrK6urq6vsLGwsLOztLWz s7a0tLi3t7m4uLm5urq6ury7u728vL6+vs+srOeBgueCg+iFhuiHiOiIieiIiumKi+mLjOmNjumP kOqRkuuVluuXmOuYmeydnu2foO2hou2kpe6pqu+trvG0tfG4ufK9vvK+vsDAwMLCwsPDxMTDw8TE xMXGxsjHx8nIyMnJysrKys3MzM7OztDQ0NLS0tPT1NTU1NXV1tbW1tjX19jY2Nra2tvb3Nzb29zc 3N7e3uDf3/PDxPTFxfTHyPTJyvXNzfbP0PbQ0fbS0vfV1ffY2Pja2vjd3eHg4OLi4uTj4+Tk5Obm 5uno6Orq6uzr6+zs7O7u7u/v8Pni4vnj5Prl5frp6fvs7Pvu7vzv7/Dw8PLy8vfw8PT09PX19vb2 9vzx8fzx8vzy8v309P329vj4+Pr6+vv7/P34+P76+vz8/P7+/gAAACH5BAEAAP8ALAAAAABkADAA AAj/AP8JHEiwoMGDCBMqTNgvXDJiwYAJS7bt2zh4/hZq3Mixo8eB/rzZcvSIEqZNuYIha7aNmTFk 3/B9nEmz5sFmh/4cYkQJmDd3/Qr2c/ft2LegNpMqVTiO0Jo6fzBx06fRnztwMpdq1SpsxYo1irjN xJdvq1ma/RZVCGHGV0ahG90hO0t3Iz42ECq8GWdwnpdOV2hp5ParruGD+FAsgIAna0FQ1v7xi/JW Ia+5hzP3S0NgwR+kBq0MFHNOo7xJ4DIfFkSAwBvQBkFlEzjl3sZgmcqqPvurdQV5CtVpCfUlFkd3 lJbtNgvPAQEF3jba+6hLk+PlSfm0rnR4WaZt2JV6/ytAQETlgq9YDdRmCt1BadgOhsvkK3zSO62P IZx240Y9gU7cgIVB6ODgA2wC4ZNJLdcZpM95IAmlz4QTDpTPhRheiOA//fDjoYdIuZMAASUkpMUN TQiUTX85pFPQNf3tY5A/mtQSjkIiDFKQO3ZM0Ms/3+jBgQREFllGPoMUqaQEFujhzj/7mGIEDv1V 2YNgmLQ2w4b/sKPDDbAIJEaVp7wY40G11AJeQhLQQVAxIEgwgkVDSsDBnXjS0Q8LEnwAwp+ATiDB Hv+ceAMPPiSa6BHR/EMGAQjcMMtBq9zwg4z29GDpDUPwQxCMN8hoUJrJKNSmQPo4Iuge8PwTiQSJ tP96EAsnHNQOCBugc4MR1yDUzwIEwHBDFQclcQMoArlyQxDofCnLp2caVKMxproZThoSZHDLQIFI wBdCLKSAkB0SSHNDKQlt09oTN+DgHkH83WCOQErcMMo/WdwQBbShGqRgLcSY6oYuG0iARmoDASIB OQmFO265N5iSEC4EHPDODxEX1MUNUwgU77zQ9KfNQKCKShA5CwbMJpETPEIVQQpLcsvMNN/iy54j bDjOCBmYC8UrQAcNNDqOEODBP6Bw6qlA9exwg2D/bHGDFAL5c8QNn5AcLUHOLKjfyhIEcpDCSyoZ Dp8WYKD22kTaYW6VcPcnCiEEnPGPOVQ+m+wNRQT/pY6zA6ViqaglG/TLgs2YSsGqsiYsQR6FRC55 IY3ow2fZEmCQRzvmIgHG56CDEYY1fxBwh0BWTD3QEjeoIpDgQiz9Tzo5gClQ4QTlY8mC0bFJhzEi yImZQArfCG4HeRBZBjMaCmTuvQj5QUAfAj3T37zW3KDDOhwWcW5BWKB4+9YCdUPJgu1U+487yU8A CVLFNyxuMXxOYEjj5oqS0CIEzFE1EjcgxT/CcAMuCIQW7XrXQEJ2g17hbiC4OF8uuDSQUwlkExiQ gBpuxAgJSIKCDvuHPi5RsA/UIijauIESXHSQ3qxhIK1YVjo0RQ2BUGFYMwIgGP7xwH+EIxLno5b6 /wbijRdIYAPD8IYFMjcCEjjRiS5wRwgFUg6yueAb/wgQDoJAhC568RXwKIAKBlIPTQXhBkwQyDmo NCmDVIoH9TBHf6ZBkE0AMRMMU0gHxJY7REhAR8yIAwXKRoF26CEPBlFGGSRgiX/UwxMYi1vr/rGB BxBkDFV6hUBEcQMicGkeTmuFP864gy6gYhWcOAQQd6ERfHDJlQPpRztmSct4cIhL/UjGywQyj3T4 8pcZSQQBEPaPFN7AB7bZBxBuUCaEeOEGSfiHKeBWAzmokhJYtE9NxFGASBDkhvqbnfZYeJBr6MAH /tiH1G5gAxnMQZW5gJA2PWIGDVSGHrIwGSyesf+QasxGIOaQBQ1a8M5IfGueNNlGAQpjFl58oAVo mAMvEJodE5hlF30yAUHxAAyK1gQfG6jPUmzRgAh8QAIPaEEb8PAI4Hj0I98QQYM+0o9EJKCkHyDD TVdwBj3ooXcv7Yg3vFmTb3xgADeNwBnAYQwGLGAFZMADHOIZ1I64w3geIYceCCAApDbgDbJqRgMS oNE31OEQT6oqR8DhC90sxBt/MIAAAhCAASiAEbD5RgQMIIIWpEEPc2CGWtdKhjr4In0FkUcwCLEB ujo2ADEQi0HCcYECPDSqbcAEBQdbEF1IIAAN2IAJTHCBBjzWsQJQQTAUQo6jbqAFBJ3DH/LIWYV4 +EMYbWDAaR07gA0sIpsLcccKBFAB2LJBD21QWW0X4o9t5CISf/gDIzBBjJkuRB5nCEAEYEsGPaQh EtZdrmHwAYcApJQMhXVDIsQbnnzwYQAMWAF37cZe7PSDEEjVaAvgUN/w+MMRBShABTZQi/7apxYb EIEt/BEQADs= ------=_NextPart_000_060D_01D41783.C14646F0-- From nobody Mon Jul 9 06:18:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C606B130FBF; Mon, 9 Jul 2018 06:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] 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 6fzg0hGDF-2A; Mon, 9 Jul 2018 06:18:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96EA130FBD; Mon, 9 Jul 2018 06:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w69DIckG009640; Mon, 9 Jul 2018 15:18:38 +0200 (CEST) Received: from [192.168.217.102] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41PQrZ1Cc1zDXfy; Mon, 9 Jul 2018 15:18:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 9 Jul 2018 15:18:37 +0200 Cc: core@ietf.org, draft-ietf-core-sid@ietf.org X-Mao-Original-Outgoing-Id: 552835115.6746809-12701e0902b7bd425f72ba675c2a5d6c Content-Transfer-Encoding: quoted-printable Message-Id: <4A6789B6-B09E-4A2B-9D54-BF34CDB03AA4@tzi.org> References: To: Robert Wilton X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] Review of draft-ietf-core-sid-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 13:18:45 -0000 On Jul 9, 2018, at 12:48, Robert Wilton = wrote: >=20 > 1) Section 1. I think that it may be better if SIDs are only allocated = from the range 0 to int64 max (i.e. 2^63 - 1). This would still seem to = make huge numbers of SIDs available, but makes it easier to generate 64 = bit SID deltas without having to worry about sign overflow. Good point. (Not an issue for the CBOR representation, but poses a trap = for overflow-naive host processing=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 9 08:00:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D86130E3D; Mon, 9 Jul 2018 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yylnuqfz-ln; Mon, 9 Jul 2018 08:00:31 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EED1130E23; Mon, 9 Jul 2018 08:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4179; q=dns/txt; s=iport; t=1531148430; x=1532358030; h=to:subject:from:message-id:date:mime-version; bh=jP4cPQrHt81d1XCZGMRiZGybzfl9ex34CpUh7GwwQWc=; b=IHACoISTJ2p4tCqf38zUHzQpso0+31mdOj3jMJxmtsh/PoOa26gxYz+5 Tjyr0iw3Gxq+gtR07L0d28DBA3STscuUva2HKH0jR1sBvY4ROd9cxo3+0 3zB5lrQxvOV0Xl0NSdfQXeSSpqRCtfXGc3kVlPcZ1UULQMSa65Wg5hpZ4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQATd0Nb/xbLJq1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTgleEIohjjTKQTocIC4dUOBQBAgEBAgEBAm0ohWB1PgJgDAg?= =?us-ascii?q?BAYMcggCqCoIcH4Q8g2qBOopEP4EPJ4pjglUCmU8JgUCNXgaBQoZUJYUijDy?= =?us-ascii?q?FVIFYISaBLDMaCBsVgyWCIxeOGD6PAQEB?= X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="scan'208,217";a="5006729" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 15:00:28 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w69F0Sk3006528; Mon, 9 Jul 2018 15:00:28 GMT To: draft-ietf-core-yang-cbor@ietf.org, core@ietf.org From: Robert Wilton Message-ID: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> Date: Mon, 9 Jul 2018 16:00:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------54F88AC65D1A669F69408B19" Content-Language: en-US Archived-At: Subject: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:00:34 -0000 This is a multi-part message in MIME format. --------------54F88AC65D1A669F69408B19 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I've read this draft, and think that it is well written. There is one area of the draft that is somewhat unclear to me when using SID encodings:  Is the root node(s) of a request or a response always an absolute SID value, or could it still be a delta? In particular: Sec 2.1 indicates that the translation to/from SID deltas is stateless, which implies to me that the root node(s) of a request/response would always be an absolute SID value. Sec 4.2.1 gives an example using a absolute SID for the top node.  It then has this text: " On the other hand, if the serializer is aware of the parent SID, 1716 in the case 'system-state' container, root data nodes are encoded using deltas. " I think that it is quite plausible that the serializer may know the SIDs for all nodes in the data tree, which the text implies it could then use a relative SID for the top node.  Particularly, if the top level node was explicit from the request. Hence, I think that this draft could probably benefit in being more explicit on exactly when a top level node uses an absolute SID, and in what scenarios it may end up using a a relative SID. If this distinction is down to the protocol being used, then perhaps that could be stated? One other nit: Section 4.4.1 says "delta encoding can be performed", but I think that this should probably be "delta encoding MUST be performed". Thanks, Rob --------------54F88AC65D1A669F69408B19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I've read this draft, and think that it is well written.

There is one area of the draft that is somewhat unclear to me when using SID encodings:  Is the root node(s) of a request or a response always an absolute SID value, or could it still be a delta?

In particular:

Sec 2.1 indicates that the translation to/from SID deltas is stateless, which implies to me that the root node(s) of a request/response would always be an absolute SID value.

Sec 4.2.1 gives an example using a absolute SID for the top node.  It then has this text: "

   On the other hand, if the serializer is aware of the parent SID, 1716
   in the case 'system-state' container, root data nodes are encoded
   using deltas.
"

I think that it is quite plausible that the serializer may know the SIDs for all nodes in the data tree, which the text implies it could then use a relative SID for the top node.  Particularly, if the top level node was explicit from the request.

Hence, I think that this draft could probably benefit in being more explicit on exactly when a top level node uses an absolute SID, and in what scenarios it may end up using a a relative SID.  If this distinction is down to the protocol being used, then perhaps that could be stated?

One other nit:

Section 4.4.1 says "delta encoding can be performed", but I think that this should probably be "delta encoding MUST be performed".

Thanks,
Rob



--------------54F88AC65D1A669F69408B19-- From nobody Mon Jul 9 08:18:17 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE0E130E23; Mon, 9 Jul 2018 08:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfqJJ_j_53DQ; Mon, 9 Jul 2018 08:18:10 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EF612F295; Mon, 9 Jul 2018 08:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q2AtKxiF+NuIqqNh8CJLXODTYo+YV7S833HqSRfk8Jc=; b=WrcY07v8lyUkgdhlw5yoAKtb3NQF4+FGcmgW/jTSqb69OA9VigH/HdZbfwOsbfQiYw1hsnutgJ4leTnl2gOgKqQEnbXSiJkRmYX0RzgKWgEvMDTo0qsz1DqYqJ4sUsJkMhArVMJbCCihHgIphuXTeZMPl35PmAVNN77hnHrlpEo= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2715.namprd06.prod.outlook.com (10.168.199.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Mon, 9 Jul 2018 15:18:09 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300%5]) with mapi id 15.20.0930.022; Mon, 9 Jul 2018 15:18:09 +0000 From: Michel Veillette To: Robert Wilton , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" Thread-Topic: Comments on draft-ietf-core-yang-cbor-06 Thread-Index: AQHUF5WX0PmR6lU92EO3Kbe/Vd91WaSG/U6Q Date: Mon, 9 Jul 2018 15:18:08 +0000 Message-ID: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> In-Reply-To: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB2715; 7:5HConIXh8pHll/AkUjn4hal6bAEshAyGxT7GgyIChBQrMpvWfwKBC4XAIilHU19tVVsWnYgJQSjybUnv8Wu1VX1IiBBUa84A4aXHuBehC9si7hI35qim6BRjc39fq0J2/QlxuuY+bGyJETPi5nRy/1rZC8yAXqkkhbQSJyn5iTDtLl9BwCtfp6hv+2gfuwcmemr+OBCBm6snKJAKIO8HdKBf52zLRNioOYEwihEC5o5qfYxDDz6zt+YNoUvh2gNr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5fafa327-df2e-446c-0b1d-08d5e5af2da2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2715; x-ms-traffictypediagnostic: DM5PR06MB2715: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB2715; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2715; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39850400004)(396003)(376002)(346002)(51444003)(199004)(189003)(99286004)(81156014)(476003)(110136005)(66066001)(6506007)(486006)(81166006)(14444005)(256004)(86362001)(3846002)(53546011)(6116002)(790700001)(8676002)(446003)(97736004)(8936002)(102836004)(26005)(2501003)(5250100002)(316002)(186003)(105586002)(11346002)(2201001)(7736002)(74316002)(25786009)(7696005)(478600001)(55016002)(72206003)(6306002)(5660300001)(9686003)(2906002)(68736007)(54896002)(14454004)(6436002)(106356001)(2900100001)(6246003)(76176011)(53936002)(229853002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2715; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: d5Pb4rWnL+c+HWwX4v0IE8Thzru1Wup8aTfwkU97lwvXLf6yNK17xUdYuNU8gdoxyY02b9tWnpnS+4XRvPYKq281UgemCqNXr35oXy+hJvoVdR6vd/SuIGZJ3JPx9cItoj7qzZjwxukavF9emmtIStmwJCODJ+cShfFzTblQlSYrn332drFzdUF/rZzmd/WstwO08yy99PJDwVnheEQ67jIcbtLjqQXT/CxlG7yJP2l4gfjWquA92Liy40kkSWCk+cwYhWgUGioYq1yfMoXoZRhYn7eLRHUOfodm1ZfAmrDyNTovvmRVDcBQmUKgyleb1N4cHcet7oKumpN1vQdGyAJ+xb9VIMMbEUXURotoAPM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR06MB2777C2ABB330D1054D2E1D8D9A440DM5PR06MB2777namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fafa327-df2e-446c-0b1d-08d5e5af2da2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 15:18:08.9175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2715 Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:18:15 -0000 --_000_DM5PR06MB2777C2ABB330D1054D2E1D8D9A440DM5PR06MB2777namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0DQoNCkFuZHkgYWxzbyBhc2tlZCBmb3IgYSBjbGFyaWZpY2F0aW9uIGFib3V0IHRo ZSBlbmNvZGluZyBvZiB0aGUgcm9vdCBkYXRhIG5vZGUgaWRlbnRpZmllciAoYWJzb2x1dGUgdnMu IGRlbHRhKS4NClNlY3Rpb24gNC40LjEuIGhhdmUgYSBzZW50ZW5jZSBhZGRyZXNzaW5nIHRoaXMg dG9waWMuDQogICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBwcm90b2NvbCBvciBt ZXRob2QNCiAgIHVzaW5nIHRoaXMgbWFwcGluZyBtYXkgY2FycnkgYSBwYXJlbnQgU0lEIG9yIG1h eSBoYXZlIHRoZSBrbm93bGVkZ2UNCiAgIG9mIHRoaXMgcGFyZW50IFNJRCBiYXNlZCBvbiBpdHMg Y29udGV4dC4gIEluIHRoZXNlIGNhc2VzLCBkZWx0YQ0KICAgZW5jb2RpbmcgY2FuIGJlIHBlcmZv cm1lZCBiYXNlZCBvbiB0aGlzIHBhcmVudCBTSUQgd2hpY2ggbWluaW1pemVzDQogICB0aGUgc2l6 ZSBvZiB0aGUgZW5jb2RlZCBkYXRhLg0KDQpBIHNpbWlsYXIgc2VudGVuY2UgbmVlZCB0byBiZSBh ZGRlZCB0byBzZWN0aW9uIDQuMi4xLg0KV2UgYWxzbyBuZWVkIHRvIGNsYXJpZnkgdGhhdCB0aGUg cHJvdG9jb2wgb3IgbWV0aG9kIHVzaW5nIHRoaXMgZW5jb2RpbmcgbXVzdCBtYW5kYXRlIHdoaWNo IGFwcHJvYWNoIGlzIGltcGxlbWVudGVkLCB0aGUgZGF0YSBzZXJpYWxpemVkIGRvbuKAmXQgY2Fy cnkgdGhpcyBpbmZvcm1hdGlvbi4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQpGcm9tOiBSb2JlcnQg V2lsdG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgOSwg MjAxOCAxMTowMCBBTQ0KVG86IGRyYWZ0LWlldGYtY29yZS15YW5nLWNib3JAaWV0Zi5vcmc7IGNv cmVAaWV0Zi5vcmcNClN1YmplY3Q6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY29yZS15YW5nLWNi b3ItMDYNCg0KDQpIaSwNCg0KSSd2ZSByZWFkIHRoaXMgZHJhZnQsIGFuZCB0aGluayB0aGF0IGl0 IGlzIHdlbGwgd3JpdHRlbi4NCg0KVGhlcmUgaXMgb25lIGFyZWEgb2YgdGhlIGRyYWZ0IHRoYXQg aXMgc29tZXdoYXQgdW5jbGVhciB0byBtZSB3aGVuIHVzaW5nIFNJRCBlbmNvZGluZ3M6ICBJcyB0 aGUgcm9vdCBub2RlKHMpIG9mIGEgcmVxdWVzdCBvciBhIHJlc3BvbnNlIGFsd2F5cyBhbiBhYnNv bHV0ZSBTSUQgdmFsdWUsIG9yIGNvdWxkIGl0IHN0aWxsIGJlIGEgZGVsdGE/DQoNCkluIHBhcnRp Y3VsYXI6DQoNClNlYyAyLjEgaW5kaWNhdGVzIHRoYXQgdGhlIHRyYW5zbGF0aW9uIHRvL2Zyb20g U0lEIGRlbHRhcyBpcyBzdGF0ZWxlc3MsIHdoaWNoIGltcGxpZXMgdG8gbWUgdGhhdCB0aGUgcm9v dCBub2RlKHMpIG9mIGEgcmVxdWVzdC9yZXNwb25zZSB3b3VsZCBhbHdheXMgYmUgYW4gYWJzb2x1 dGUgU0lEIHZhbHVlLg0KDQpTZWMgNC4yLjEgZ2l2ZXMgYW4gZXhhbXBsZSB1c2luZyBhIGFic29s dXRlIFNJRCBmb3IgdGhlIHRvcCBub2RlLiAgSXQgdGhlbiBoYXMgdGhpcyB0ZXh0OiAiDQoNCiAg IE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgc2VyaWFsaXplciBpcyBhd2FyZSBvZiB0aGUgcGFy ZW50IFNJRCwgMTcxNg0KDQogICBpbiB0aGUgY2FzZSAnc3lzdGVtLXN0YXRlJyBjb250YWluZXIs IHJvb3QgZGF0YSBub2RlcyBhcmUgZW5jb2RlZA0KDQogICB1c2luZyBkZWx0YXMuDQoiDQoNCkkg dGhpbmsgdGhhdCBpdCBpcyBxdWl0ZSBwbGF1c2libGUgdGhhdCB0aGUgc2VyaWFsaXplciBtYXkg a25vdyB0aGUgU0lEcyBmb3IgYWxsIG5vZGVzIGluIHRoZSBkYXRhIHRyZWUsIHdoaWNoIHRoZSB0 ZXh0IGltcGxpZXMgaXQgY291bGQgdGhlbiB1c2UgYSByZWxhdGl2ZSBTSUQgZm9yIHRoZSB0b3Ag bm9kZS4gIFBhcnRpY3VsYXJseSwgaWYgdGhlIHRvcCBsZXZlbCBub2RlIHdhcyBleHBsaWNpdCBm cm9tIHRoZSByZXF1ZXN0Lg0KDQpIZW5jZSwgSSB0aGluayB0aGF0IHRoaXMgZHJhZnQgY291bGQg cHJvYmFibHkgYmVuZWZpdCBpbiBiZWluZyBtb3JlIGV4cGxpY2l0IG9uIGV4YWN0bHkgd2hlbiBh IHRvcCBsZXZlbCBub2RlIHVzZXMgYW4gYWJzb2x1dGUgU0lELCBhbmQgaW4gd2hhdCBzY2VuYXJp b3MgaXQgbWF5IGVuZCB1cCB1c2luZyBhIGEgcmVsYXRpdmUgU0lELiAgSWYgdGhpcyBkaXN0aW5j dGlvbiBpcyBkb3duIHRvIHRoZSBwcm90b2NvbCBiZWluZyB1c2VkLCB0aGVuIHBlcmhhcHMgdGhh dCBjb3VsZCBiZSBzdGF0ZWQ/DQoNCk9uZSBvdGhlciBuaXQ6DQoNClNlY3Rpb24gNC40LjEgc2F5 cyAiZGVsdGEgZW5jb2RpbmcgY2FuIGJlIHBlcmZvcm1lZCIsIGJ1dCBJIHRoaW5rIHRoYXQgdGhp cyBzaG91bGQgcHJvYmFibHkgYmUgImRlbHRhIGVuY29kaW5nIE1VU1QgYmUgcGVyZm9ybWVkIi4N ClRoYW5rcywNClJvYg0KDQoNCg0KDQo= --_000_DM5PR06MB2777C2ABB330D1054D2E1D8D9A440DM5PR06MB2777namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SGkgUm9iZXJ0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPkFuZHkgYWxzbyBhc2tlZCBmb3IgYSBjbGFyaWZpY2F0aW9uIGFib3V0IHRo ZSBlbmNvZGluZyBvZiB0aGUgcm9vdCBkYXRhIG5vZGUgaWRlbnRpZmllciAoYWJzb2x1dGUgdnMu IGRlbHRhKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlNlY3Rpb24gNC40LjEuIGhh dmUgYSBzZW50ZW5jZSBhZGRyZXNzaW5nIHRoaXMgdG9waWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJdCBpcyBpbXBv cnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBwcm90b2NvbCBvciBtZXRob2Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVzaW5n IHRoaXMgbWFwcGluZyBtYXkgY2FycnkgYSBwYXJlbnQgU0lEIG9yIG1heSBoYXZlIHRoZSBrbm93 bGVkZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IG9mIHRoaXMgcGFyZW50IFNJRCBiYXNlZCBvbiBpdHMgY29udGV4dC4m bmJzcDsgSW4gdGhlc2UgY2FzZXMsIGRlbHRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBlbmNvZGluZyBjYW4gYmUgcGVy Zm9ybWVkIGJhc2VkIG9uIHRoaXMgcGFyZW50IFNJRCB3aGljaCBtaW5pbWl6ZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IHRoZSBzaXplIG9mIHRoZSBlbmNvZGVkIGRhdGEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+QSBzaW1pbGFyIHNlbnRlbmNlIG5lZWQgdG8g YmUgYWRkZWQgdG8gc2VjdGlvbiA0LjIuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PldlIGFsc28gbmVlZCB0byBjbGFyaWZ5IHRoYXQgdGhlIHByb3RvY29sIG9yIG1ldGhvZCB1c2lu ZyB0aGlzIGVuY29kaW5nIG11c3QgbWFuZGF0ZSB3aGljaCBhcHByb2FjaCBpcyBpbXBsZW1lbnRl ZCwgdGhlIGRhdGEgc2VyaWFsaXplZCBkb27igJl0IGNhcnJ5IHRoaXMgaW5mb3JtYXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5NaWNoZWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25A Y2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSA5LCAyMDE4IDExOjAw IEFNPGJyPg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yQGlldGYub3JnOyBj b3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt Y29yZS15YW5nLWNib3ItMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5IaSw8bzpwPjwv bzpwPjwvcD4NCjxwPkkndmUgcmVhZCB0aGlzIGRyYWZ0LCBhbmQgdGhpbmsgdGhhdCBpdCBpcyB3 ZWxsIHdyaXR0ZW4uPG86cD48L286cD48L3A+DQo8cD5UaGVyZSBpcyBvbmUgYXJlYSBvZiB0aGUg ZHJhZnQgdGhhdCBpcyBzb21ld2hhdCB1bmNsZWFyIHRvIG1lIHdoZW4gdXNpbmcgU0lEIGVuY29k aW5nczombmJzcDsgSXMgdGhlIHJvb3Qgbm9kZShzKSBvZiBhIHJlcXVlc3Qgb3IgYSByZXNwb25z ZSBhbHdheXMgYW4gYWJzb2x1dGUgU0lEIHZhbHVlLCBvciBjb3VsZCBpdCBzdGlsbCBiZSBhIGRl bHRhPzxvOnA+PC9vOnA+PC9wPg0KPHA+SW4gcGFydGljdWxhcjo8bzpwPjwvbzpwPjwvcD4NCjxw PlNlYyAyLjEgaW5kaWNhdGVzIHRoYXQgdGhlIHRyYW5zbGF0aW9uIHRvL2Zyb20gU0lEIGRlbHRh cyBpcyBzdGF0ZWxlc3MsIHdoaWNoIGltcGxpZXMgdG8gbWUgdGhhdCB0aGUgcm9vdCBub2RlKHMp IG9mIGEgcmVxdWVzdC9yZXNwb25zZSB3b3VsZCBhbHdheXMgYmUgYW4gYWJzb2x1dGUgU0lEIHZh bHVlLjxvOnA+PC9vOnA+PC9wPg0KPHA+U2VjIDQuMi4xIGdpdmVzIGFuIGV4YW1wbGUgdXNpbmcg YSBhYnNvbHV0ZSBTSUQgZm9yIHRoZSB0b3Agbm9kZS4mbmJzcDsgSXQgdGhlbiBoYXMgdGhpcyB0 ZXh0OiAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFn ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0 aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPiZuYnNwOyZuYnNwOyBPbiB0aGUg b3RoZXIgaGFuZCwgaWYgdGhlIHNlcmlhbGl6ZXIgaXMgYXdhcmUgb2YgdGhlIHBhcmVudCBTSUQs IDE3MTY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW4gdGhlIGNhc2UgJ3N5 c3RlbS1zdGF0ZScgY29udGFpbmVyLCByb290IGRhdGEgbm9kZXMgYXJlIGVuY29kZWQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdXNpbmcgZGVsdGFzLjxvOnA+PC9vOnA+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPkkgdGhp bmsgdGhhdCBpdCBpcyBxdWl0ZSBwbGF1c2libGUgdGhhdCB0aGUgc2VyaWFsaXplciBtYXkga25v dyB0aGUgU0lEcyBmb3IgYWxsIG5vZGVzIGluIHRoZSBkYXRhIHRyZWUsIHdoaWNoIHRoZSB0ZXh0 IGltcGxpZXMgaXQgY291bGQgdGhlbiB1c2UgYSByZWxhdGl2ZSBTSUQgZm9yIHRoZSB0b3Agbm9k ZS4mbmJzcDsgUGFydGljdWxhcmx5LCBpZiB0aGUgdG9wIGxldmVsIG5vZGUgd2FzIGV4cGxpY2l0 IGZyb20gdGhlIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cD5IZW5jZSwgSSB0aGluayB0aGF0 IHRoaXMgZHJhZnQgY291bGQgcHJvYmFibHkgYmVuZWZpdCBpbiBiZWluZyBtb3JlIGV4cGxpY2l0 IG9uIGV4YWN0bHkgd2hlbiBhIHRvcCBsZXZlbCBub2RlIHVzZXMgYW4gYWJzb2x1dGUgU0lELCBh bmQgaW4gd2hhdCBzY2VuYXJpb3MgaXQgbWF5IGVuZCB1cCB1c2luZyBhIGEgcmVsYXRpdmUgU0lE LiZuYnNwOyBJZiB0aGlzIGRpc3RpbmN0aW9uIGlzIGRvd24gdG8gdGhlIHByb3RvY29sIGJlaW5n IHVzZWQsIHRoZW4NCiBwZXJoYXBzIHRoYXQgY291bGQgYmUgc3RhdGVkPzxvOnA+PC9vOnA+PC9w Pg0KPHA+T25lIG90aGVyIG5pdDo8bzpwPjwvbzpwPjwvcD4NCjxwPlNlY3Rpb24gNC40LjEgc2F5 cyAmcXVvdDtkZWx0YSBlbmNvZGluZyBjYW4gYmUgcGVyZm9ybWVkJnF1b3Q7LCBidXQgSSB0aGlu ayB0aGF0IHRoaXMgc2hvdWxkIHByb2JhYmx5IGJlICZxdW90O2RlbHRhIGVuY29kaW5nIE1VU1Qg YmUgcGVyZm9ybWVkJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR06MB2777C2ABB330D1054D2E1D8D9A440DM5PR06MB2777namp_-- From nobody Mon Jul 9 08:23:20 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C96130DF4; Mon, 9 Jul 2018 08:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqkrn0OdgG2Y; Mon, 9 Jul 2018 08:23:16 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A649126DBF; Mon, 9 Jul 2018 08:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w69FN7AD016540; Mon, 9 Jul 2018 17:23:07 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41PTcB6SXlzDXh1; Mon, 9 Jul 2018 17:23:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 9 Jul 2018 17:23:06 +0200 Cc: Robert Wilton , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 552842584.212991-87f30ae4d7620d03f8e7bbd226c836ee Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> To: Michel Veillette X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:23:19 -0000 It is much less confusing to always talk of deltas in the structure. Just say that the context SID value (the one that the delta is computed = from) is 0 at the root of a tree. Gr=C3=BC=C3=9Fe, Carsten > On Jul 9, 2018, at 17:18, Michel Veillette = wrote: >=20 > Hi Robert > =20 > Andy also asked for a clarification about the encoding of the root = data node identifier (absolute vs. delta). > Section 4.4.1. have a sentence addressing this topic. > It is important to note that the protocol or method > using this mapping may carry a parent SID or may have the knowledge > of this parent SID based on its context. In these cases, delta > encoding can be performed based on this parent SID which minimizes > the size of the encoded data. > =20 > A similar sentence need to be added to section 4.2.1. > We also need to clarify that the protocol or method using this = encoding must mandate which approach is implemented, the data serialized = don=E2=80=99t carry this information. > =20 > Regards, > Michel > =20 > From: Robert Wilton [mailto:rwilton@cisco.com]=20 > Sent: Monday, July 9, 2018 11:00 AM > To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org > Subject: Comments on draft-ietf-core-yang-cbor-06 > =20 > Hi, >=20 > I've read this draft, and think that it is well written. >=20 > There is one area of the draft that is somewhat unclear to me when = using SID encodings: Is the root node(s) of a request or a response = always an absolute SID value, or could it still be a delta? >=20 > In particular: >=20 > Sec 2.1 indicates that the translation to/from SID deltas is = stateless, which implies to me that the root node(s) of a = request/response would always be an absolute SID value. >=20 > Sec 4.2.1 gives an example using a absolute SID for the top node. It = then has this text: " >=20 > On the other hand, if the serializer is aware of the parent SID, = 1716 > in the case 'system-state' container, root data nodes are encoded > using deltas. > " > I think that it is quite plausible that the serializer may know the = SIDs for all nodes in the data tree, which the text implies it could = then use a relative SID for the top node. Particularly, if the top = level node was explicit from the request. >=20 > Hence, I think that this draft could probably benefit in being more = explicit on exactly when a top level node uses an absolute SID, and in = what scenarios it may end up using a a relative SID. If this = distinction is down to the protocol being used, then perhaps that could = be stated? >=20 > One other nit: >=20 > Section 4.4.1 says "delta encoding can be performed", but I think that = this should probably be "delta encoding MUST be performed". >=20 > Thanks, > Rob > =20 >=20 > =20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 9 08:31:25 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C52130E63 for ; Mon, 9 Jul 2018 08:31:23 -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=[BAYES_40=-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 B_tGzkvN9UMZ for ; Mon, 9 Jul 2018 08:31:21 -0700 (PDT) Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 767AD130DC1 for ; Mon, 9 Jul 2018 08:31:21 -0700 (PDT) Received: by anna.localdomain (Postfix, from userid 501) id 1AC7922FCEF4; Mon, 9 Jul 2018 17:31:19 +0200 (CEST) Date: Mon, 9 Jul 2018 17:31:19 +0200 From: Juergen Schoenwaelder To: core@ietf.org Message-ID: <20180709153119.nqvakgcqckk4p63w@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20180622 Archived-At: Subject: [core] ietf-comi:sid and draft-ietf-core-sid-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:31:23 -0000 Hi, I see that ietf-sid-file (defined in draft-ietf-core-sid-04.txt) imports ietf-comi in order to use ietf-comi:sid, which is defined as: typedef sid { type uint64; description "YANG Schema Item iDentifier"; reference "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; } I think it would be better if the sid type would be defined as part of I-D.ietf-core-sid instead of being defined in ietf-comi. (I assume I could use YANG/CBOR/SID with RESTCONF without having a dependency on COMI.) [It seems this is another case where people use YANG to define data that is not implemented in a datastore. Too bad we still have no proper way to do this.] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 9 08:37:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FA51310FF; Mon, 9 Jul 2018 08:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZUDx91oFhEj; Mon, 9 Jul 2018 08:37:14 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA521310FD; Mon, 9 Jul 2018 08:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3936; q=dns/txt; s=iport; t=1531150634; x=1532360234; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=L0juNTpK6en4d/gpX7q/XxOsfQJH5v87rof8QkUySPQ=; b=HNVHmV2c2FiEQ3JlU5UgSmLdYwj84KEfKoBCEvDlBOZ978x95bR9aJWw N1jkHXGZkhmnuHtqhnuoEtdUsGCq0LHt/bltxPfquao2YVihfJEf2ko1A dy4t7CQ8U6DpxsdMuvMNKNERDLsbAT+TfhN4KL+6Rrv9lBPBmH/Dlr/31 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQDIf0Nb/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMbgRB/KIN6iGONMwgilywLGAuESQKCZjcVAQIBAQIBAQJ?= =?us-ascii?q?tHAyFNgEBAQECAQEBIQ8BBTYLEAkCDgMEAQEBAgIjAwICJx8JCAYBDAYCAQE?= =?us-ascii?q?XgwUBgXcID446m0iCHIRbg2yBNQWBC4k5P4EPJwyCXIMYAQGEYYJVAplPCYg?= =?us-ascii?q?0hmoGgUKGVCWFIow8hVSBVyKBUjMaCBsVO4JpgiEDF4hZhT8+MI5RAQE?= X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="scan'208";a="5068297" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 15:37:10 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w69Fb9Wu028813; Mon, 9 Jul 2018 15:37:10 GMT To: Carsten Bormann , Michel Veillette Cc: "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> From: Robert Wilton Message-ID: Date: Mon, 9 Jul 2018 16:37:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:37:27 -0000 On 09/07/2018 16:23, Carsten Bormann wrote: > It is much less confusing to always talk of deltas in the structure. > > Just say that the context SID value (the one that the delta is computed from) is 0 at the root of a tree. Yes, I completely agree. I'm not convinced that it is worth optimizing for the case where the protocol knows the SID of the parent node, and hence deltas can be used for the top node.  Always using 0 as the parent of the root node just seems to facilitate simpler interop.  However, it is worth adding a caveat to my statement that I'm reviewing the encoding more from a RESTCONF protocol perspective rather than constrained devices so simplicity is more important me to saving a small number of bytes. If saving those few extra bytes for delta SIDs over absolute SIDs for the top level SIDs is critical then I think that another solution would be to put an extra non-presence container in the data model.  Hence the NP-container uses a absolute SID and all children use deltas again. Of course, this depends on the data model being written in CBOR+SID friendly way. Thanks, Rob > > Grüße, Carsten > > >> On Jul 9, 2018, at 17:18, Michel Veillette wrote: >> >> Hi Robert >> >> Andy also asked for a clarification about the encoding of the root data node identifier (absolute vs. delta). >> Section 4.4.1. have a sentence addressing this topic. >> It is important to note that the protocol or method >> using this mapping may carry a parent SID or may have the knowledge >> of this parent SID based on its context. In these cases, delta >> encoding can be performed based on this parent SID which minimizes >> the size of the encoded data. >> >> A similar sentence need to be added to section 4.2.1. >> We also need to clarify that the protocol or method using this encoding must mandate which approach is implemented, the data serialized don’t carry this information. >> >> Regards, >> Michel >> >> From: Robert Wilton [mailto:rwilton@cisco.com] >> Sent: Monday, July 9, 2018 11:00 AM >> To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org >> Subject: Comments on draft-ietf-core-yang-cbor-06 >> >> Hi, >> >> I've read this draft, and think that it is well written. >> >> There is one area of the draft that is somewhat unclear to me when using SID encodings: Is the root node(s) of a request or a response always an absolute SID value, or could it still be a delta? >> >> In particular: >> >> Sec 2.1 indicates that the translation to/from SID deltas is stateless, which implies to me that the root node(s) of a request/response would always be an absolute SID value. >> >> Sec 4.2.1 gives an example using a absolute SID for the top node. It then has this text: " >> >> On the other hand, if the serializer is aware of the parent SID, 1716 >> in the case 'system-state' container, root data nodes are encoded >> using deltas. >> " >> I think that it is quite plausible that the serializer may know the SIDs for all nodes in the data tree, which the text implies it could then use a relative SID for the top node. Particularly, if the top level node was explicit from the request. >> >> Hence, I think that this draft could probably benefit in being more explicit on exactly when a top level node uses an absolute SID, and in what scenarios it may end up using a a relative SID. If this distinction is down to the protocol being used, then perhaps that could be stated? >> >> One other nit: >> >> Section 4.4.1 says "delta encoding can be performed", but I think that this should probably be "delta encoding MUST be performed". >> >> Thanks, >> Rob >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > . > From nobody Mon Jul 9 08:39:51 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F813102C; Mon, 9 Jul 2018 08:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HwZoE-KpSCN; Mon, 9 Jul 2018 08:39:39 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B437B130E48; Mon, 9 Jul 2018 08:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AxmOF67fLDihEyJ/NgcD8wxgxVxnIWS99B/j3eO20z0=; b=aCkQIBqrcSsiHi4IkxntkXhOL456+c1t5KYJYEnwS9KTSgkTsGxoTlY1Ska/aqhi9lRULFYdCct2WPAshox40Qoc9bfmtH45M10+psBbur98v6FNPZX3S+tMKneTKgUPGW6G9utltG6L27KTZNo2wKKw9my4XphJB50ehfd4pI8= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB3179.namprd06.prod.outlook.com (10.174.240.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Mon, 9 Jul 2018 15:39:36 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300%5]) with mapi id 15.20.0930.022; Mon, 9 Jul 2018 15:39:35 +0000 From: Michel Veillette To: Carsten Bormann CC: Robert Wilton , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" Thread-Topic: [core] Comments on draft-ietf-core-yang-cbor-06 Thread-Index: AQHUF5WX0PmR6lU92EO3Kbe/Vd91WaSG/U6QgAAE/wCAAABMQA== Date: Mon, 9 Jul 2018 15:39:35 +0000 Message-ID: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB3179; 7:DPr0L50+QwdvhSlCroxuVHyd9aGoEmuYXaKiepJK05U3ZpymLk/ck8RcJ10Bc/PFEJrNZWEjrbYOFm7yQ92uyFbROUQvn2gi/H/VjVbfgZ2WWY8hJWw3zHKKdnpBBCaydpUHAa1k61yicYZzOGKOyE0Qe12p8kwsHpj6SvXN1vhVVpPgJ7rFs1pxk1550x6/tzJIL0wLEdIl/uH091+0guNMckL19tqaUX4UPSsO22AxuESHoeevdrXO7qfGN3Yk x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 78c8830e-f8cb-4cd2-9b5b-08d5e5b22cb4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB3179; x-ms-traffictypediagnostic: DM5PR06MB3179: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB3179; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB3179; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39840400004)(396003)(346002)(366004)(51444003)(189003)(199004)(13464003)(5660300001)(74316002)(229853002)(966005)(305945005)(7736002)(2906002)(81156014)(81166006)(8676002)(53936002)(8936002)(33656002)(6116002)(3846002)(14454004)(6916009)(6246003)(25786009)(68736007)(54906003)(6306002)(76176011)(9686003)(55016002)(99286004)(5250100002)(316002)(97736004)(4326008)(2900100001)(106356001)(105586002)(102836004)(186003)(478600001)(26005)(6506007)(53546011)(14444005)(72206003)(66066001)(86362001)(6436002)(476003)(486006)(11346002)(7696005)(256004)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB3179; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: iNVUsaPtj/gHxG6qysrRXQ5QMJMy9zLBNrbnddh5d5a29brpnCRWmv2828MQWeDfJ97fCuBxYw1oAsoHgJMW+qS9dysh1soRHE+28YtNfhyrQkQMpbsWHtJmpJTFmZ1esbvWci/NlmYLE9oBnBODNv5FpS3/RIC81zJUUkGfSTGZQsEZpv1iTPdbqnl2kPTjLgLv+YOKrH236JFWNs49k0+klpSopok5hCt3Y6pJj4y0CH+CMHg4Mf6kZn3XA/GMrm5KpAWka2qe/1d9I3H4E8mV1iMIvFSHQ6I180tAXlphUlcl0CSy0thu0L/JqTV9wfdjML6ZY5T2SP6FVbBomdzF8MfKQWVGjWZpeZ2EyDE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78c8830e-f8cb-4cd2-9b5b-08d5e5b22cb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 15:39:35.8203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3179 Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:39:50 -0000 SGkgQ2Fyc3Rlbg0KDQpDb01JIGZvciBleGFtcGxlLCB1c2VzIGRlbHRhIGZvciB0aGUgZmlyc3Qg cm9vdCBkYXRhIG5vZGUgYmFzZWQgb24gdGhlIHJlcXVlc3RlZCBTSUQuDQpJbiB0aGUgZm9sbG93 aW5nIGV4YW1wbGUsIHRoZSArMiBpcyByZWxhdGl2ZSB0byBTSUQgMTcyMSB3aGljaCBpcyBwYXJ0 IG9mIHRoZSByZXF1ZXN0ZWQgVVJJIChpLmUuIGE1KS4NClRoaXMgcmVxdWVzdGVkIFNJRCBuZWVk IHRvIGJlIG1haW50YWluZWQgaW4gdGhlIGNsaWVudCBzdGF0ZSBpbiBvcmRlciB0byBwcm9jZXNz IHRoZSByZXNwb25zZS4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y29yZS1jb21pLTAzI3NlY3Rpb24tNS4yLjMuMQ0KDQogICBSRVE6IEdFVCBleGFtcGxlLmNvbS9j L2E1DQoNCiAgIFJFUzogMi4wNSBDb250ZW50IChDb250ZW50LUZvcm1hdDogYXBwbGljYXRpb24v eWFuZy12YWx1ZStjYm9yKQ0KICAgew0KICAgICArMiA6ICIyMDE0LTEwLTI2VDEyOjE2OjUxWiIs ICAgLyBjdXJyZW50LWRhdGV0aW1lIFNJRCAxNzIzIC8NCiAgICAgKzEgOiAiMjAxNC0xMC0yMVQw MzowMDowMFoiICAgIC8gYm9vdC1kYXRldGltZSBTSUQgMTcyMiAvDQogICB9DQoNClJlZ2FyZHMs DQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9y bWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgOSwgMjAxOCAx MToyMyBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50 LmNvbT4NCkNjOiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT47IGRyYWZ0LWlldGYt Y29yZS15YW5nLWNib3JAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29y ZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jvci0wNg0KDQpJdCBpcyBtdWNo IGxlc3MgY29uZnVzaW5nIHRvIGFsd2F5cyB0YWxrIG9mIGRlbHRhcyBpbiB0aGUgc3RydWN0dXJl Lg0KDQpKdXN0IHNheSB0aGF0IHRoZSBjb250ZXh0IFNJRCB2YWx1ZSAodGhlIG9uZSB0aGF0IHRo ZSBkZWx0YSBpcyBjb21wdXRlZCBmcm9tKSBpcyAwIGF0IHRoZSByb290IG9mIGEgdHJlZS4NCg0K R3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCj4gT24gSnVsIDksIDIwMTgsIGF0IDE3OjE4LCBNaWNoZWwg VmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudC5jb20+IHdyb3RlOg0KPiANCj4g SGkgUm9iZXJ0DQo+ICANCj4gQW5keSBhbHNvIGFza2VkIGZvciBhIGNsYXJpZmljYXRpb24gYWJv dXQgdGhlIGVuY29kaW5nIG9mIHRoZSByb290IGRhdGEgbm9kZSBpZGVudGlmaWVyIChhYnNvbHV0 ZSB2cy4gZGVsdGEpLg0KPiBTZWN0aW9uIDQuNC4xLiBoYXZlIGEgc2VudGVuY2UgYWRkcmVzc2lu ZyB0aGlzIHRvcGljLg0KPiAgICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBwcm90 b2NvbCBvciBtZXRob2QNCj4gICAgdXNpbmcgdGhpcyBtYXBwaW5nIG1heSBjYXJyeSBhIHBhcmVu dCBTSUQgb3IgbWF5IGhhdmUgdGhlIGtub3dsZWRnZQ0KPiAgICBvZiB0aGlzIHBhcmVudCBTSUQg YmFzZWQgb24gaXRzIGNvbnRleHQuICBJbiB0aGVzZSBjYXNlcywgZGVsdGENCj4gICAgZW5jb2Rp bmcgY2FuIGJlIHBlcmZvcm1lZCBiYXNlZCBvbiB0aGlzIHBhcmVudCBTSUQgd2hpY2ggbWluaW1p emVzDQo+ICAgIHRoZSBzaXplIG9mIHRoZSBlbmNvZGVkIGRhdGEuDQo+ICANCj4gQSBzaW1pbGFy IHNlbnRlbmNlIG5lZWQgdG8gYmUgYWRkZWQgdG8gc2VjdGlvbiA0LjIuMS4NCj4gV2UgYWxzbyBu ZWVkIHRvIGNsYXJpZnkgdGhhdCB0aGUgcHJvdG9jb2wgb3IgbWV0aG9kIHVzaW5nIHRoaXMgZW5j b2RpbmcgbXVzdCBtYW5kYXRlIHdoaWNoIGFwcHJvYWNoIGlzIGltcGxlbWVudGVkLCB0aGUgZGF0 YSBzZXJpYWxpemVkIGRvbuKAmXQgY2FycnkgdGhpcyBpbmZvcm1hdGlvbi4NCj4gIA0KPiBSZWdh cmRzLA0KPiBNaWNoZWwNCj4gIA0KPiBGcm9tOiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRv bkBjaXNjby5jb21dIA0KPiBTZW50OiBNb25kYXksIEp1bHkgOSwgMjAxOCAxMTowMCBBTQ0KPiBU bzogZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2JvckBpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLTA2DQo+ICANCj4g SGksDQo+IA0KPiBJJ3ZlIHJlYWQgdGhpcyBkcmFmdCwgYW5kIHRoaW5rIHRoYXQgaXQgaXMgd2Vs bCB3cml0dGVuLg0KPiANCj4gVGhlcmUgaXMgb25lIGFyZWEgb2YgdGhlIGRyYWZ0IHRoYXQgaXMg c29tZXdoYXQgdW5jbGVhciB0byBtZSB3aGVuIHVzaW5nIFNJRCBlbmNvZGluZ3M6ICBJcyB0aGUg cm9vdCBub2RlKHMpIG9mIGEgcmVxdWVzdCBvciBhIHJlc3BvbnNlIGFsd2F5cyBhbiBhYnNvbHV0 ZSBTSUQgdmFsdWUsIG9yIGNvdWxkIGl0IHN0aWxsIGJlIGEgZGVsdGE/DQo+IA0KPiBJbiBwYXJ0 aWN1bGFyOg0KPiANCj4gU2VjIDIuMSBpbmRpY2F0ZXMgdGhhdCB0aGUgdHJhbnNsYXRpb24gdG8v ZnJvbSBTSUQgZGVsdGFzIGlzIHN0YXRlbGVzcywgd2hpY2ggaW1wbGllcyB0byBtZSB0aGF0IHRo ZSByb290IG5vZGUocykgb2YgYSByZXF1ZXN0L3Jlc3BvbnNlIHdvdWxkIGFsd2F5cyBiZSBhbiBh YnNvbHV0ZSBTSUQgdmFsdWUuDQo+IA0KPiBTZWMgNC4yLjEgZ2l2ZXMgYW4gZXhhbXBsZSB1c2lu ZyBhIGFic29sdXRlIFNJRCBmb3IgdGhlIHRvcCBub2RlLiAgSXQgdGhlbiBoYXMgdGhpcyB0ZXh0 OiAiDQo+IA0KPiAgICBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlIHNlcmlhbGl6ZXIgaXMgYXdh cmUgb2YgdGhlIHBhcmVudCBTSUQsIDE3MTYNCj4gICAgaW4gdGhlIGNhc2UgJ3N5c3RlbS1zdGF0 ZScgY29udGFpbmVyLCByb290IGRhdGEgbm9kZXMgYXJlIGVuY29kZWQNCj4gICAgdXNpbmcgZGVs dGFzLg0KPiAiDQo+IEkgdGhpbmsgdGhhdCBpdCBpcyBxdWl0ZSBwbGF1c2libGUgdGhhdCB0aGUg c2VyaWFsaXplciBtYXkga25vdyB0aGUgU0lEcyBmb3IgYWxsIG5vZGVzIGluIHRoZSBkYXRhIHRy ZWUsIHdoaWNoIHRoZSB0ZXh0IGltcGxpZXMgaXQgY291bGQgdGhlbiB1c2UgYSByZWxhdGl2ZSBT SUQgZm9yIHRoZSB0b3Agbm9kZS4gIFBhcnRpY3VsYXJseSwgaWYgdGhlIHRvcCBsZXZlbCBub2Rl IHdhcyBleHBsaWNpdCBmcm9tIHRoZSByZXF1ZXN0Lg0KPiANCj4gSGVuY2UsIEkgdGhpbmsgdGhh dCB0aGlzIGRyYWZ0IGNvdWxkIHByb2JhYmx5IGJlbmVmaXQgaW4gYmVpbmcgbW9yZSBleHBsaWNp dCBvbiBleGFjdGx5IHdoZW4gYSB0b3AgbGV2ZWwgbm9kZSB1c2VzIGFuIGFic29sdXRlIFNJRCwg YW5kIGluIHdoYXQgc2NlbmFyaW9zIGl0IG1heSBlbmQgdXAgdXNpbmcgYSBhIHJlbGF0aXZlIFNJ RC4gIElmIHRoaXMgZGlzdGluY3Rpb24gaXMgZG93biB0byB0aGUgcHJvdG9jb2wgYmVpbmcgdXNl ZCwgdGhlbiBwZXJoYXBzIHRoYXQgY291bGQgYmUgc3RhdGVkPw0KPiANCj4gT25lIG90aGVyIG5p dDoNCj4gDQo+IFNlY3Rpb24gNC40LjEgc2F5cyAiZGVsdGEgZW5jb2RpbmcgY2FuIGJlIHBlcmZv cm1lZCIsIGJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBzaG91bGQgcHJvYmFibHkgYmUgImRlbHRhIGVu Y29kaW5nIE1VU1QgYmUgcGVyZm9ybWVkIi4NCj4gDQo+IFRoYW5rcywNCj4gUm9iDQo+ICANCj4g DQo+ICANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Mon Jul 9 08:58:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66F130E4A for ; Mon, 9 Jul 2018 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable 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 uX0-gRNPoM3P for ; Mon, 9 Jul 2018 08:58:30 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 54DB9130DC2 for ; Mon, 9 Jul 2018 08:58:30 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g6-v6so4983907lfb.11 for ; Mon, 09 Jul 2018 08:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dlelu3xfLDRBMF23mCn9ZVYjWUT9Tf/ZpxxWo126qio=; b=oRZDFqOapWT4n/5F7CE9qSiKrzeADODVMju61sR9tpj29eXm39ZJPyzGoSvbCd63Rx /NSdovOvcIqCLJsP0ENmhXveTTjhA3A46asOdzJ81Q8MV2eoKZNWA6BsdBacxJMCnxk0 ROxDUcyD4n3wG5ScINRKE3LH4sp01uF2/c0W6Ku/LuLQsQqKAQg4cQzsmmdFP+TfDI7x 1iISAuU+jTOgCDawbkelt4gtEnikHE5Sg1mTv4I99RDXtuhwi3CPcYACNETUh3m3WIqz M1SjXX8E5fBu3lDqLjn6xIWEgcD84l+3IgW6dLjurFx5ctUysBhGXS4O/+3MsJC5SiZI tFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dlelu3xfLDRBMF23mCn9ZVYjWUT9Tf/ZpxxWo126qio=; b=Dvi3JS92dCO4T7KWP6dqq9ZXKkeZJLvxGQO3VIKkivErT/7t0grEl61KJ80p7Q21Ig M9fZEl91cgIumr8Phv1mUanJ6pZMPs9Pwa3IwTpZLjQOUUC6hKHGQNUYrazTwuCy9Q+L WaK7RtstKkde1OXj3yTvxtDT4vtaPi5iO8d95vuHFqsr5h23AS8Hiy/tkPeVXVtnRQBm JZxBxLcvFOmdKP3fXjRv+xA5/KO22bvCCGCxqlM8KdTqiIZHqcM1s88XMnhsLwY9RdJH SIKsvLMnl7ohU1O/he4rlO06ECwaqgiojv/bgDJfanjHEbgUrLvmQs+0TiOVE41l9NZ1 yJfQ== X-Gm-Message-State: APt69E0GKRUC8jeULa0Bnx6EhLi5k8+dakoXlY2TuZoDLmJUmrzQTvct GqPlppOT5Lm7h1BlkuAY46XEUQeDmqN24Es06aqKng== X-Google-Smtp-Source: AAOMgpdqyTvC4PMCfua5ELdq3RRptKV+cIkLW32seRJaIWBXFc02skiU/vkkDVIcgM1fxRBkS151bh8/eQ+4eabgByU= X-Received: by 2002:a19:204f:: with SMTP id g76-v6mr132955lfg.66.1531151908423; Mon, 09 Jul 2018 08:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 08:58:27 -0700 (PDT) In-Reply-To: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> From: Andy Bierman Date: Mon, 9 Jul 2018 08:58:27 -0700 Message-ID: To: Robert Wilton Cc: Carsten Bormann , Michel Veillette , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000099667505709315c7" Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:58:35 -0000 --00000000000099667505709315c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 9, 2018 at 8:37 AM, Robert Wilton < rwilton=3D40cisco.com@dmarc.ietf.org> wrote: > > > On 09/07/2018 16:23, Carsten Bormann wrote: > >> It is much less confusing to always talk of deltas in the structure. >> >> Just say that the context SID value (the one that the delta is computed >> from) is 0 at the root of a tree. >> > Yes, I completely agree. > > I'm not convinced that it is worth optimizing for the case where the > protocol knows the SID of the parent node, and hence deltas can be used f= or > the top node. Always using 0 as the parent of the root node just seems t= o > facilitate simpler interop. However, it is worth adding a caveat to my > statement that I'm reviewing the encoding more from a RESTCONF protocol > perspective rather than constrained devices so simplicity is more importa= nt > me to saving a small number of bytes. > > If saving those few extra bytes for delta SIDs over absolute SIDs for the > top level SIDs is critical then I think that another solution would be to > put an extra non-presence container in the data model. Hence the > NP-container uses a absolute SID and all children use deltas again. Of > course, this depends on the data model being written in CBOR+SID friendly > way. > > IMO it is a really bad idea to make the payload completely unusable unless the top-node SID is saved in some implementation-specific way. Toolchains have a way of growing over time, so even if there is just 1 monolithic application now (so of course it can remember the SID), that may not be the case in the future. Thanks, > Rob > > Andy > > >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> On Jul 9, 2018, at 17:18, Michel Veillette >> m> wrote: >>> >>> Hi Robert >>> Andy also asked for a clarification about the encoding of the root >>> data node identifier (absolute vs. delta). >>> Section 4.4.1. have a sentence addressing this topic. >>> It is important to note that the protocol or method >>> using this mapping may carry a parent SID or may have the knowledge >>> of this parent SID based on its context. In these cases, delta >>> encoding can be performed based on this parent SID which minimizes >>> the size of the encoded data. >>> A similar sentence need to be added to section 4.2.1. >>> We also need to clarify that the protocol or method using this encoding >>> must mandate which approach is implemented, the data serialized don=E2= =80=99t carry >>> this information. >>> Regards, >>> Michel >>> From: Robert Wilton [mailto:rwilton@cisco.com] >>> Sent: Monday, July 9, 2018 11:00 AM >>> To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org >>> Subject: Comments on draft-ietf-core-yang-cbor-06 >>> Hi, >>> >>> I've read this draft, and think that it is well written. >>> >>> There is one area of the draft that is somewhat unclear to me when usin= g >>> SID encodings: Is the root node(s) of a request or a response always a= n >>> absolute SID value, or could it still be a delta? >>> >>> In particular: >>> >>> Sec 2.1 indicates that the translation to/from SID deltas is stateless, >>> which implies to me that the root node(s) of a request/response would >>> always be an absolute SID value. >>> >>> Sec 4.2.1 gives an example using a absolute SID for the top node. It >>> then has this text: " >>> >>> On the other hand, if the serializer is aware of the parent SID, 17= 16 >>> in the case 'system-state' container, root data nodes are encoded >>> using deltas. >>> " >>> I think that it is quite plausible that the serializer may know the SID= s >>> for all nodes in the data tree, which the text implies it could then us= e a >>> relative SID for the top node. Particularly, if the top level node was >>> explicit from the request. >>> >>> Hence, I think that this draft could probably benefit in being more >>> explicit on exactly when a top level node uses an absolute SID, and in = what >>> scenarios it may end up using a a relative SID. If this distinction is >>> down to the protocol being used, then perhaps that could be stated? >>> >>> One other nit: >>> >>> Section 4.4.1 says "delta encoding can be performed", but I think that >>> this should probably be "delta encoding MUST be performed". >>> >>> Thanks, >>> Rob >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> . >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000099667505709315c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 9, 2018 at 8:37 AM, Robert Wilton <rwil= ton=3D40cisco.com@dmarc.ietf.org> wrote:


On 09/07/2018 16:23, Carsten Bormann wrote:
It is much less confusing to always talk of deltas in the structure.

Just say that the context SID value (the one that the delta is computed fro= m) is 0 at the root of a tree.
Yes, I completely agree.

I'm not convinced that it is worth optimizing for the case where the pr= otocol knows the SID of the parent node, and hence deltas can be used for t= he top node.=C2=A0 Always using 0 as the parent of the root node just seems= to facilitate simpler interop.=C2=A0 However, it is worth adding a caveat = to my statement that I'm reviewing the encoding more from a RESTCONF pr= otocol perspective rather than constrained devices so simplicity is more im= portant me to saving a small number of bytes.

If saving those few extra bytes for delta SIDs over absolute SIDs for the t= op level SIDs is critical then I think that another solution would be to pu= t an extra non-presence container in the data model.=C2=A0 Hence the NP-con= tainer uses a absolute SID and all children use deltas again. Of course, th= is depends on the data model being written in CBOR+SID friendly way.


IMO it is a really bad idea to make th= e payload completely unusable unless the top-node SID is
saved in= some implementation-specific way. =C2=A0 Toolchains have a way of growing = over time,
so even if there is just 1 monolithic application now = (so of course it can remember the SID),
that may not be the case = in the future.



Thanks,
Rob


Andy
=C2=A0


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


On Jul 9, 2018, at 17:18, Michel Veillette <Michel.Veillette@trilliant.com= > wrote:

Hi Robert
=C2=A0 Andy also asked for a clarification about the encoding of the root d= ata node identifier (absolute vs. delta).
Section 4.4.1. have a sentence addressing this topic.
=C2=A0 =C2=A0 It is important to note that the protocol or method
=C2=A0 =C2=A0 using this mapping may carry a parent SID or may have the kno= wledge
=C2=A0 =C2=A0 of this parent SID based on its context.=C2=A0 In these cases= , delta
=C2=A0 =C2=A0 encoding can be performed based on this parent SID which mini= mizes
=C2=A0 =C2=A0 the size of the encoded data.
=C2=A0 A similar sentence need to be added to section 4.2.1.
We also need to clarify that the protocol or method using this encoding mus= t mandate which approach is implemented, the data serialized don=E2=80=99t = carry this information.
=C2=A0 Regards,
Michel
=C2=A0 From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Monday, July 9, 2018 11:00 AM
To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org
Subject: Comments on draft-ietf-core-yang-cbor-06
=C2=A0 Hi,

I've read this draft, and think that it is well written.

There is one area of the draft that is somewhat unclear to me when using SI= D encodings:=C2=A0 Is the root node(s) of a request or a response always an= absolute SID value, or could it still be a delta?

In particular:

Sec 2.1 indicates that the translation to/from SID deltas is stateless, whi= ch implies to me that the root node(s) of a request/response would always b= e an absolute SID value.

Sec 4.2.1 gives an example using a absolute SID for the top node.=C2=A0 It = then has this text: "

=C2=A0 =C2=A0 On the other hand, if the serializer is aware of the parent S= ID, 1716
=C2=A0 =C2=A0 in the case 'system-state' container, root data nodes= are encoded
=C2=A0 =C2=A0 using deltas.
"
I think that it is quite plausible that the serializer may know the SIDs fo= r all nodes in the data tree, which the text implies it could then use a re= lative SID for the top node.=C2=A0 Particularly, if the top level node was = explicit from the request.

Hence, I think that this draft could probably benefit in being more explici= t on exactly when a top level node uses an absolute SID, and in what scenar= ios it may end up using a a relative SID.=C2=A0 If this distinction is down= to the protocol being used, then perhaps that could be stated?

One other nit:

Section 4.4.1 says "delta encoding can be performed", but I think= that this should probably be "delta encoding MUST be performed".=

Thanks,
Rob
=C2=A0
=C2=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
.


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

--00000000000099667505709315c7-- From nobody Mon Jul 9 09:09:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83482130E48; Mon, 9 Jul 2018 09:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0zaSywtAWu0; Mon, 9 Jul 2018 09:09:48 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79D7130E31; Mon, 9 Jul 2018 09:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4835; q=dns/txt; s=iport; t=1531152588; x=1532362188; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=r4lVzlO9wgUw5viryUrKpw78jwGnVUqwN+dKAqqffog=; b=fcnJLU6PVx7HXGeoKiV7GI9lI9Wz45ST2XCekqY0z6Ne3MTyDjmutTwO x3JLUyTk3gU6G/qojCm2WQUr8ggSkTjwSTGQsqiir0I7pP2XhuJpUXUsq zXGLLUGok9VYH9UNaatpU1np4mlce5FNTbhr/tSrLHzXqGvNIJDLFFepF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQDOh0Nb/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQrfyiDeohjjTQqlywLGAuESQKCZjcVAQIBAQIBAQJtHAy?= =?us-ascii?q?FNgEBAQECAQEBIQ8BBTYLDAQJAhEEAQEBAgIjAwICJx8JCAYBDAYCAQGDHAG?= =?us-ascii?q?BdwgPjlmbSIIchFuDboE6gQuJOT+BDyeCaIMYAQECAYReglUCiAGEUYEqi1M?= =?us-ascii?q?JhgiCLDiGMgaBQkOGESWFIoo4ggSFVIFXIoFSMxoIGxU7gmkJghsXg0WFFIU?= =?us-ascii?q?/PjABAQGOTgEB?= X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="scan'208";a="5008189" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 16:09:43 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w69G9hxP017716; Mon, 9 Jul 2018 16:09:43 GMT To: Michel Veillette , Carsten Bormann Cc: "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> From: Robert Wilton Message-ID: <46e3466e-4ac6-4108-6490-c81891560648@cisco.com> Date: Mon, 9 Jul 2018 17:09:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 16:09:51 -0000 On 09/07/2018 16:39, Michel Veillette wrote: > Hi Carsten > > CoMI for example, uses delta for the first root data node based on the requested SID. > In the following example, the +2 is relative to SID 1721 which is part of the requested URI (i.e. a5). > This requested SID need to be maintained in the client state in order to process the response. > > https://tools.ietf.org/html/draft-ietf-core-comi-03#section-5.2.3.1 > > REQ: GET example.com/c/a5 > > RES: 2.05 Content (Content-Format: application/yang-value+cbor) > { > +2 : "2014-10-26T12:16:51Z", / current-datetime SID 1723 / > +1 : "2014-10-21T03:00:00Z" / boot-datetime SID 1722 / > } OK, so the JSON YANG encoding mitigates the equivalent issue by always including the name of the element being returned. E.g. presumably something like this: RES: 2.05 Content (Content-Format: application/yang-value+cbor) a5 : { +2 : "2014-10-26T12:16:51Z", / current-datetime SID 1723 / +1 : "2014-10-21T03:00:00Z" / boot-datetime SID 1722 / } But I presume that you have already considered this previously and have rejected it for compactness reasons. I'm not sure that I'm a big fan of the ambiguity as to whether the top level nodes are using absolute or delta sids.  Another choice would be to define a CBOR tag that explicitly reports the parent SID, although that seems more convoluted that just always including the name ... Thanks, Rob > > Regards, > Michel > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Monday, July 9, 2018 11:23 AM > To: Michel Veillette > Cc: Robert Wilton ; draft-ietf-core-yang-cbor@ietf.org; core@ietf.org > Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 > > It is much less confusing to always talk of deltas in the structure. > > Just say that the context SID value (the one that the delta is computed from) is 0 at the root of a tree. > > Grüße, Carsten > > >> On Jul 9, 2018, at 17:18, Michel Veillette wrote: >> >> Hi Robert >> >> Andy also asked for a clarification about the encoding of the root data node identifier (absolute vs. delta). >> Section 4.4.1. have a sentence addressing this topic. >> It is important to note that the protocol or method >> using this mapping may carry a parent SID or may have the knowledge >> of this parent SID based on its context. In these cases, delta >> encoding can be performed based on this parent SID which minimizes >> the size of the encoded data. >> >> A similar sentence need to be added to section 4.2.1. >> We also need to clarify that the protocol or method using this encoding must mandate which approach is implemented, the data serialized don’t carry this information. >> >> Regards, >> Michel >> >> From: Robert Wilton [mailto:rwilton@cisco.com] >> Sent: Monday, July 9, 2018 11:00 AM >> To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org >> Subject: Comments on draft-ietf-core-yang-cbor-06 >> >> Hi, >> >> I've read this draft, and think that it is well written. >> >> There is one area of the draft that is somewhat unclear to me when using SID encodings: Is the root node(s) of a request or a response always an absolute SID value, or could it still be a delta? >> >> In particular: >> >> Sec 2.1 indicates that the translation to/from SID deltas is stateless, which implies to me that the root node(s) of a request/response would always be an absolute SID value. >> >> Sec 4.2.1 gives an example using a absolute SID for the top node. It then has this text: " >> >> On the other hand, if the serializer is aware of the parent SID, 1716 >> in the case 'system-state' container, root data nodes are encoded >> using deltas. >> " >> I think that it is quite plausible that the serializer may know the SIDs for all nodes in the data tree, which the text implies it could then use a relative SID for the top node. Particularly, if the top level node was explicit from the request. >> >> Hence, I think that this draft could probably benefit in being more explicit on exactly when a top level node uses an absolute SID, and in what scenarios it may end up using a a relative SID. If this distinction is down to the protocol being used, then perhaps that could be stated? >> >> One other nit: >> >> Section 4.4.1 says "delta encoding can be performed", but I think that this should probably be "delta encoding MUST be performed". >> >> Thanks, >> Rob >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 9 09:17:33 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0796D131025; Mon, 9 Jul 2018 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um0OOVIoUEnD; Mon, 9 Jul 2018 09:17:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB47613101E; Mon, 9 Jul 2018 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w69GHHsg026406; Mon, 9 Jul 2018 18:17:17 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41PVpj3lNPzDXhL; Mon, 9 Jul 2018 18:17:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 9 Jul 2018 18:17:16 +0200 Cc: Robert Wilton , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 552845833.5686359-fd2b97ed761ad00344a1e34a288942e5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> To: Michel Veillette X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 16:17:33 -0000 Hi Michel, > https://tools.ietf.org/html/draft-ietf-core-comi-03#section-5.2.3.1 >=20 > REQ: GET example.com/c/a5 >=20 > RES: 2.05 Content (Content-Format: application/yang-value+cbor) > { > +2 : "2014-10-26T12:16:51Z", / current-datetime SID 1723 / > +1 : "2014-10-21T03:00:00Z" / boot-datetime SID 1722 / > } I actually didn=E2=80=99t want to exclude this example (just wanted to = make sure all those places in the tree are deltas), but the comments = from Robert and Andy make me think again. The idea of depending on the request path for decoding the response is = akin to all the issues we have with base URIs and charsets in HTML files = saved from the browser. Turning this into > RES: 2.05 Content (Content-Format: application/yang-value+cbor) > { > +1723 : =E2=80=9C2014-10-26T12:16:51Z=E2=80=9D, / = current-datetime SID 1723 / > +1722 : =E2=80=9C2014-10-21T03:00:00Z" / boot-datetime SID 1722 = / > } by not using the context makes little difference in this specific = example, but if the data items are not the heavyweight strings from this = example but some numbers, it can make a difference. If we had a way to put the context SID into the response, we would still = waste a few bytes for that, but at least not for every single map key = below that. An alternative would be to keep it as is for the exchange but nail down = a format for *saved* yang-cbor that includes the context SID. Tools = would then know to never save a naked body but instead wrap it into = something like: [=E2=80=9Capplication/yang-value+cbor=E2=80=9D, =20 1721, { +2 :=E2=80=A6 I put in the media type there (we probably would really use the = content-format number) as well to make it easier to understand stored = yang-cbor. (We could also spend a number of tags for the media types as = in RFC 8152; long ones to turn them into a magic number as we did with = 55799 in RFC 7049.) Gr=C3=BC=C3=9Fe, Carsten > On Jul 9, 2018, at 17:39, Michel Veillette = wrote: >=20 > Hi Carsten >=20 > CoMI for example, uses delta for the first root data node based on the = requested SID. > In the following example, the +2 is relative to SID 1721 which is part = of the requested URI (i.e. a5). > This requested SID need to be maintained in the client state in order = to process the response. >=20 > https://tools.ietf.org/html/draft-ietf-core-comi-03#section-5.2.3.1 >=20 > REQ: GET example.com/c/a5 >=20 > RES: 2.05 Content (Content-Format: application/yang-value+cbor) > { > +2 : "2014-10-26T12:16:51Z", / current-datetime SID 1723 / > +1 : "2014-10-21T03:00:00Z" / boot-datetime SID 1722 / > } >=20 > Regards, > Michel >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: Monday, July 9, 2018 11:23 AM > To: Michel Veillette > Cc: Robert Wilton ; = draft-ietf-core-yang-cbor@ietf.org; core@ietf.org > Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 >=20 > It is much less confusing to always talk of deltas in the structure. >=20 > Just say that the context SID value (the one that the delta is = computed from) is 0 at the root of a tree. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Jul 9, 2018, at 17:18, Michel Veillette = wrote: >>=20 >> Hi Robert >>=20 >> Andy also asked for a clarification about the encoding of the root = data node identifier (absolute vs. delta). >> Section 4.4.1. have a sentence addressing this topic. >> It is important to note that the protocol or method >> using this mapping may carry a parent SID or may have the knowledge >> of this parent SID based on its context. In these cases, delta >> encoding can be performed based on this parent SID which minimizes >> the size of the encoded data. >>=20 >> A similar sentence need to be added to section 4.2.1. >> We also need to clarify that the protocol or method using this = encoding must mandate which approach is implemented, the data serialized = don=E2=80=99t carry this information. >>=20 >> Regards, >> Michel >>=20 >> From: Robert Wilton [mailto:rwilton@cisco.com]=20 >> Sent: Monday, July 9, 2018 11:00 AM >> To: draft-ietf-core-yang-cbor@ietf.org; core@ietf.org >> Subject: Comments on draft-ietf-core-yang-cbor-06 >>=20 >> Hi, >>=20 >> I've read this draft, and think that it is well written. >>=20 >> There is one area of the draft that is somewhat unclear to me when = using SID encodings: Is the root node(s) of a request or a response = always an absolute SID value, or could it still be a delta? >>=20 >> In particular: >>=20 >> Sec 2.1 indicates that the translation to/from SID deltas is = stateless, which implies to me that the root node(s) of a = request/response would always be an absolute SID value. >>=20 >> Sec 4.2.1 gives an example using a absolute SID for the top node. It = then has this text: " >>=20 >> On the other hand, if the serializer is aware of the parent SID, = 1716 >> in the case 'system-state' container, root data nodes are encoded >> using deltas. >> " >> I think that it is quite plausible that the serializer may know the = SIDs for all nodes in the data tree, which the text implies it could = then use a relative SID for the top node. Particularly, if the top = level node was explicit from the request. >>=20 >> Hence, I think that this draft could probably benefit in being more = explicit on exactly when a top level node uses an absolute SID, and in = what scenarios it may end up using a a relative SID. If this = distinction is down to the protocol being used, then perhaps that could = be stated? >>=20 >> One other nit: >>=20 >> Section 4.4.1 says "delta encoding can be performed", but I think = that this should probably be "delta encoding MUST be performed". >>=20 >> Thanks, >> Rob >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 From nobody Mon Jul 9 09:20:35 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84A131028; Mon, 9 Jul 2018 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEMRStbZq0TO; Mon, 9 Jul 2018 09:20:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DA3131025; Mon, 9 Jul 2018 09:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w69GKNii000394; Mon, 9 Jul 2018 18:20:23 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41PVtH34jszDXhN; Mon, 9 Jul 2018 18:20:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <46e3466e-4ac6-4108-6490-c81891560648@cisco.com> Date: Mon, 9 Jul 2018 18:20:22 +0200 Cc: Michel Veillette , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 552846020.144585-cc6ccc5ad8852d8223b275b06b13f7b7 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> <46e3466e-4ac6-4108-6490-c81891560648@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 16:20:33 -0000 On Jul 9, 2018, at 18:09, Robert Wilton wrote: >=20 > ambiguity as to whether the top level nodes are using absolute or = delta sids We don=E2=80=99t need to be able to include =E2=80=9Cabsolute SIDs=E2=80=9D= (1) into the delta positions in the encoding. The deltas are always deltas. They just happen to be relative to a = context SID at the top of the tree; mostly, that is 0 (but that=E2=80=99s = what we are also discussing here). Gr=C3=BC=C3=9Fe, Carsten (1) there is no need for this term; SIDs are SIDs and SID deltas are SID = deltas. The map key positions in YANG-CBOR are always SID deltas. From nobody Mon Jul 9 09:39:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50889130E4D; Mon, 9 Jul 2018 09:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQv33LG4uBT5; Mon, 9 Jul 2018 09:39:11 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4135130E2A; Mon, 9 Jul 2018 09:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1746; q=dns/txt; s=iport; t=1531154351; x=1532363951; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mOwTiA2DGTb547b8A8/KLNe9UaH6HZY4JI6uaEewkSI=; b=FdITSQIxPEY/sJ1RrZeNwrLU+uLo9o4UGFQCBPqH0DjAmLtrqxeXQ9UY ysje7MbuPW6YqARrj2nv0YwHNwTjJhrHKoEdPFKlfF2V+XnxbJt67D7Xr vK2yArKopi4t0ENo+glnCdN8dwpW4oDUV2xJekOqW7T4u7HFsnzDeTSF4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAdj0Nb/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUqKIN6iGONNAgilywLhGwCgmY4FAECAQECAQECbSiFNgE?= =?us-ascii?q?BAQECASMPAQVBEAkCDgoCAiYCAlcGDQYCAQGDHIF4CI52m0iCHIRbg2+BOoE?= =?us-ascii?q?LiTk/gQ8nDIJch3uCVQKZTwmPHgaIFoVHjDyFVIFYIYFSMxoIGxWDJIIhAxe?= =?us-ascii?q?OGD4wjlEBAQ?= X-IronPort-AV: E=Sophos;i="5.51,330,1526342400"; d="scan'208";a="5069401" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 16:39:07 +0000 Received: from [10.63.23.105] (dhcp-ensft1-uk-vla370-10-63-23-105.cisco.com [10.63.23.105]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w69Gd5B4026579; Mon, 9 Jul 2018 16:39:06 GMT To: Carsten Bormann Cc: Michel Veillette , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> <46e3466e-4ac6-4108-6490-c81891560648@cisco.com> From: Robert Wilton Message-ID: Date: Mon, 9 Jul 2018 17:39:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 16:39:14 -0000 On 09/07/2018 17:20, Carsten Bormann wrote: > On Jul 9, 2018, at 18:09, Robert Wilton wrote: >> ambiguity as to whether the top level nodes are using absolute or delta sids > We don’t need to be able to include “absolute SIDs”(1) into the delta positions in the encoding. > The deltas are always deltas. They just happen to be relative to a context SID at the top of the tree; mostly, that is 0 (but that’s what we are also discussing here). Apologies if my terminology was confusing. I agree, that we are discussing whether the parent of the top level nodes should always have a SID of 0, or otherwise if it should be explicitly specified. For me, one of the big advantages of CBOR over schema based encodings like protobuf, is that the structure of the encoded data is self describing.  I think that it is worth spending a few extra bytes in the encoding to get this property.  So, if I get a bad CBOR message that I can't interpret then I can easily convert it into a human readable structure to debug the problem (or know the CBOR itself is invalid/corrupt).  I see that requiring external knowledge for the parent SID of the top level nodes seems to take a step away from that. E.g. if the device accidentally gives a response for the wrong node in the tree, and if the response relies on the SID in the request to be fully decodeable then the response will somewhat look like garbage and it will be harder to debug.  Is this worth saving a couple of bytes for? Thanks, Rob > > Grüße, Carsten > > (1) there is no need for this term; SIDs are SIDs and SID deltas are SID deltas. The map key positions in YANG-CBOR are always SID deltas. > > > . > From nobody Mon Jul 9 10:04:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25DA130E88 for ; Mon, 9 Jul 2018 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable 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 W9u3oIFMiffM for ; Mon, 9 Jul 2018 10:04:05 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DA9130E2A for ; Mon, 9 Jul 2018 10:04:04 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q5-v6so14619719ljh.12 for ; Mon, 09 Jul 2018 10:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KZgdV9imRe/dzw2MexmFXWmQVx3BsUE0HW4mjCAjBaI=; b=DoBUGCcJTvZ/Ydy32yEWI3CLBueT7p3CJhNSy3/oxe4avaa4qbcLZhebsg1xwj75Gq qRu4byrPy1QiDg+vqBYv6jPQ0Xj+pZKqgqHx/POBu0xgHvQe6XBvLMfunB66iW9o7f3u gCH1fp3wKrAq8wxiOkGdVhjx0ca1notZzZrel5YnAlKHnuTKCllsqOQgWqwIAFquhUZm XZVSQ5vG5t8nryc/voBL/LxuSIDtoHH/aPzAoUa0FpySP8oOQzvw4c5gW+xqW1CfqTuf mLEk3hMSjBp7Pat7AuDzLx1KoOA0jRBUrEiXCnB4uXWhN1qYhGiz09CPSwCkCIfSE0VY nNbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KZgdV9imRe/dzw2MexmFXWmQVx3BsUE0HW4mjCAjBaI=; b=WnYIzEbWSZfLowaE6e5/uI0YKnuSWZjkS775H0KQyQ4/c8/M6TgNRKPQAZ+XtCOh/D Law5rOL2z+JBrBzusNuStNse3ktbeI9x6EpYIPMxUUpPMDXX4nT0Diz327HoBzQTqr0x Pdv1m+0HnutuPwXo/0CAmUMa3K9CPEDrG7Qm1dP1PYjg9riEZi9e4Mj9GC7OlA+6IpnI Wm9or+FDi3opfENChFpivsWy9pw/Ddc/+RlSCsZHqJrnVbv4oXC/w3QsDn/QCe2y//Qb s3Mt2yftrDyw4d8RIAw6E6v3KUvWaqZt3OgQ2nXy+jIY8gxc7GL3BLIPBfK0QyWjO6Ux KQOA== X-Gm-Message-State: APt69E1JWOmMoXN+L3awgxVUWGyEGFNRJdNu5Vl8I4/AcshoJ8Dph3E1 81kPZJHWpQK1lIdfXRFNuGaOFXD0ZW5J2wP51S3hZA== X-Google-Smtp-Source: AAOMgpf0xdHTpJ4Ke3z7zo93ewvz7Bh0FJxyrY0gHR04UI4Wg2AFeAONAtYHpmf1LWikfj9+4G2w/3fkXlPOYOr6ekI= X-Received: by 2002:a2e:1c6:: with SMTP id f67-v6mr13952087lji.88.1531155842788; Mon, 09 Jul 2018 10:04:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 10:04:01 -0700 (PDT) In-Reply-To: References: <6ff65b2e-ab4f-5d92-8fff-68c08584682e@cisco.com> <46e3466e-4ac6-4108-6490-c81891560648@cisco.com> From: Andy Bierman Date: Mon, 9 Jul 2018 10:04:01 -0700 Message-ID: To: Robert Wilton Cc: Carsten Bormann , "draft-ietf-core-yang-cbor@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001b073b0570940079" Archived-At: Subject: Re: [core] Comments on draft-ietf-core-yang-cbor-06 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 17:04:08 -0000 --0000000000001b073b0570940079 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 9, 2018 at 9:39 AM, Robert Wilton < rwilton=3D40cisco.com@dmarc.ietf.org> wrote: > > > On 09/07/2018 17:20, Carsten Bormann wrote: > >> On Jul 9, 2018, at 18:09, Robert Wilton wrote: >> >>> ambiguity as to whether the top level nodes are using absolute or delta >>> sids >>> >> We don=E2=80=99t need to be able to include =E2=80=9Cabsolute SIDs=E2=80= =9D(1) into the delta >> positions in the encoding. >> The deltas are always deltas. They just happen to be relative to a >> context SID at the top of the tree; mostly, that is 0 (but that=E2=80=99= s what we >> are also discussing here). >> > Apologies if my terminology was confusing. > > I agree, that we are discussing whether the parent of the top level nodes > should always have a SID of 0, or otherwise if it should be explicitly > specified. > > For me, one of the big advantages of CBOR over schema based encodings lik= e > protobuf, is that the structure of the encoded data is self describing. = I > think that it is worth spending a few extra bytes in the encoding to get > this property. So, if I get a bad CBOR message that I can't interpret th= en > I can easily convert it into a human readable structure to debug the > problem (or know the CBOR itself is invalid/corrupt). I see that requiri= ng > external knowledge for the parent SID of the top level nodes seems to tak= e > a step away from that. > > I was thinking the same thing. Do you really want to deploy a protocol that is near impossible to debug with wireshark? > E.g. if the device accidentally gives a response for the wrong node in th= e > tree, and if the response relies on the SID in the request to be fully > decodeable then the response will somewhat look like garbage and it will = be > harder to debug. Is this worth saving a couple of bytes for? > > Decoding SIDs incorrectly can crash the device or set the wrong object so I would say that correctness in NM is important no matter how many bytes it takes. > Thanks, > Rob > Andy > > > >> Gr=C3=BC=C3=9Fe, Carsten >> >> (1) there is no need for this term; SIDs are SIDs and SID deltas are SID >> deltas. The map key positions in YANG-CBOR are always SID deltas. >> >> >> . >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000001b073b0570940079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 9, 2018 at 9:39 AM, Robert Wilton <rwil= ton=3D40cisco.com@dmarc.ietf.org> wrote:


On 09/07/2018 17:20, Carsten Bormann wrote:
On Jul 9, 2018, at 18:09, Robert Wilton <rwilton@cisco.com> wrote:
ambiguity as to whether the top level nodes are using absolute or delta sid= s
We don=E2=80=99t need to be able to include =E2=80=9Cabsolute SIDs=E2=80=9D= (1) into the delta positions in the encoding.
The deltas are always deltas.=C2=A0 They just happen to be relative to a co= ntext SID at the top of the tree; mostly, that is 0 (but that=E2=80=99s wha= t we are also discussing here).
Apologies if my terminology was confusing.

I agree, that we are discussing whether the parent of the top level nodes s= hould always have a SID of 0, or otherwise if it should be explicitly speci= fied.

For me, one of the big advantages of CBOR over schema based encodings like = protobuf, is that the structure of the encoded data is self describing.=C2= =A0 I think that it is worth spending a few extra bytes in the encoding to = get this property.=C2=A0 So, if I get a bad CBOR message that I can't i= nterpret then I can easily convert it into a human readable structure to de= bug the problem (or know the CBOR itself is invalid/corrupt).=C2=A0 I see t= hat requiring external knowledge for the parent SID of the top level nodes = seems to take a step away from that.


I was thinking the same thing.
Do you really want to deploy a protocol that is near impossible to debug= with wireshark?

=C2=A0
E.g. if the device accidentally gives a response for the wrong node in the = tree, and if the response relies on the SID in the request to be fully deco= deable then the response will somewhat look like garbage and it will be har= der to debug.=C2=A0 Is this worth saving a couple of bytes for?


Decoding SIDs incorrectly can crash th= e device or set the wrong object so I would
say that correctness = in NM is important no matter how many bytes it takes.

<= div>=C2=A0
Thanks,
Rob

Andy
=C2=A0



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

(1) there is no need for this term; SIDs are SIDs and SID deltas are SID de= ltas.=C2=A0 The map key positions in YANG-CBOR are always SID deltas.


.


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

--0000000000001b073b0570940079-- From nobody Tue Jul 10 02:10:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CC130E14 for ; Tue, 10 Jul 2018 02:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ydpD4b-Nd22K for ; Tue, 10 Jul 2018 02:10:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A9813112B for ; Tue, 10 Jul 2018 02:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531213837; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RSoYNHcdNaQoaGk04esYhpKeimgYSmy+6295culwrLE=; b=Njkm0WAmpLbv/DkMm2s4DM3kSA1/hcQo538iev/xnqtk+rKNzaTyVhoe1oAhsOp4 N5NBopZ2gL1/aSejTfS/+ssKraAqyGaN76Glm4Qiu+EqHGbN0R+1oVF9vOMhmtOr Ebl7NVGlIxrxMisxuwbQ3zggHOdzkUvyx6zNysR0vBA=; X-AuditID: c1b4fb3a-9e9ff700000079c1-96-5b44780d0ff3 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.92.31169.D08744B5; Tue, 10 Jul 2018 11:10:37 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 10 Jul 2018 11:10:37 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Tue, 10 Jul 2018 11:10:37 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Jim Schaad CC: Core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb2YgZHJhZnQtaWV0Zi1jb3JlLXRvby1tYW55?= =?utf-8?Q?-reqs-02?= Thread-Index: AQHUFGJQqjwNHnXwzEeGTHHM9wZN/aSIMvZO Date: Tue, 10 Jul 2018 09:10:37 +0000 Message-ID: <69958BDF-BE66-4504-8E0B-C63BC8B89EC1@ericsson.com> References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org>, <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> In-Reply-To: <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7kS5vhUu0wexlUhb73q5ntlg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx9OFJpoI5yhVvVp9hbGBcodTFyMkhIWAi cWnCVOYuRi4OIYGjjBLHt61lh3C+MUrMefgEKrOMUeLz/qvMIC1sArYST1r3sYLYIgLqEltX 32QCsZkFJCSmTm4EiwsL5Ei0H1zGDlGTK/Hrwj1GCNtI4tmjdWBzWARUJbafPAVm8wrYS1w9 9BysXkggT2Lp7PssIDangIPElNevwHoZBcQkvp9aA7VLXOLWk/lMEC8ISCzZc54ZwhaVePn4 H9ANHEA1mhLrd+lDlCtKTOl+yA6xSlDi5MwnLBMYRWchmTQLoWMWko5ZSDoWMLKsYhQtTi0u zk03MtJLLcpMLi7Oz9PLSy3ZxAiMk4NbflvtYDz43PEQowAHoxIPr2qZS7QQa2JZcWXuIUYJ DmYlEV6DHOdoId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxOaRZRQgLpiSWp2ampBalFMFkmDk6p Bkb1fPFX3s9WzhP6FHOBaVODPp/gva+XLCctlNaP81jyqmR6w5UCk6faTR/lxOv/ruxKVqpQ Xc1k/r/+xKuVm5XFrWpjNv6J3MniJHepK0z/xpncXQ87dj6NW5rgdWRyZeeXY0/eTNFfvCBp teJP0d/GTrWG8rMXv9L5sK1pSYRWo22u6LLjbluUWIozEg21mIuKEwFxRVtOjwIAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 10 Jul 2018 09:10:51 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IEppbSENCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4g T24gNSBKdWwgMjAxOCwgYXQgMTYuMTUsIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5j b20+IHdyb3RlOg0KPiANCj4gVGhlIGRyYWZ0IGxvb2tzIGZpbmUgdG8gbWUuDQo+IA0KPiBUaGUg c2VydmVyIGdldHMgdG8gaGF2ZSBhIGRlZmluaXRpb24gb2Ygd2hhdCBpdCBtZWFucyBmb3Igc29t ZXRoaW5nIHRvIGJlICJ0b28gc2ltaWxhciIgZm9yIGEgcmVxdWVzdCBhbmQgdGhlcmUgaXMgbm8g d2F5IGZvciB0aGlzIHN0YW5kYXJkIHRvIGJlIGNvbW11bmljYXRlZCB0byB0aGUgY2xpZW50LiAg VGh1cyB0aGUgY2xpZW50J3MgaWRlYSB0aGF0IHNpbWlsYXIgbWVhbnMgJ3RoZSBzYW1lIHBheWxv YWQnIG1heSBub3QgYmUgdGhlIHNlcnZlcnMgaWRlYSBvZiAnYW55IHBheWxvYWQnLiAgSSBkb24n dCBrbm93IGhvdyB0byBmaXggdGhpcyBzbyBJIGV4cGVjdCBpdCB0byBiZSBpZ25vcmVkLg0KDQpX aGlsZSB0aGVyZSBpcyBubyBnb29kIHdheSB0byBjb21tdW5pY2F0ZSB0aGF0IGluIGdlbmVyaWMg ZmFzaGlvbiwgYW5kIHRyeWluZyB0byBkZXNpZ24gb25lIGhlcmUgc291bmRzIGEgYml0IG92ZXJr aWxsLCB0aGUg4oCcc3RhbmRhcmQgZm9yIHNpbWlsYXJpdHnigJ0gY2FuIGJlIHBhcnQgb2YgdGhl IGFwcGxpY2F0aW9uLiBIZW5jZSBjbGllbnQgY2FuIGhhdmUgY29udGV4dCBpbmZvcm1hdGlvbiB3 aGF0IGlzIHNpbWlsYXIgYW5kIHdoYXQgaXMgbm90LiBBbmQgY2FuIGV2ZW50dWFsbHkgZmlndXJl IG91dCBmcm9tIHNlcnZlcuKAmXMgcmVwbHkgdGhhdCBhIHJlcXVlc3QgaXQgc2VudCB3YXMgY29u c2lkZXJlZCBzaW1pbGFyLg0KDQpUaGUgb3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gZGVm aW5lIGhlcmUgZXhwbGljaXRseSBhbmQgZXhjbHVzaXZlbHkgd2hhdCBpcyBzaW1pbGFyIGJ1dCB0 aGF0IHdvdWxkIHJlc3RyaWN0IHRoZSB1c2UgY2FzZXMuDQoNCj4gVGhlIGRvY3VtZW50IGFwcGVh cnMgdG8gc2F5IHRoYXQgdGhpcyByZXNwb25zZSBjb2RlIGlzIGZvciBkZWFsaW5nIHdpdGggYSBz aW5nbGUgY2xpZW50LiAgVGhhdCBpcyB0aGUgdHJhZmZpYyBtZXRyaWMgaXMgY2FsY3VsYXRlZCBp bmRpdmlkdWFsbHkgZm9yIGVhY2ggY2xpZW50LiAgVGhlIHByb3h5IGZvciBlYWNoIGNsaWVudCBw cmVzdW1hYmx5IGJlaW5nIHNvdXJjZSBJUCwgcG9ydCBwYWlyLiAgSWYgdGhlIHRyYWZmaWMgbWV0 cmljIGlzIGNhbGN1bGF0ZWQgZm9yIGV2ZXJ5Ym9keSB0aGVuIGl0IHNob3VsZCByZXR1cm4gNS4w My4gIElmIHRoYXQgaXMgbm90IHRoZSBpbnRlbnQgdGhlbiB0aGlzIG5lZWRzIHRvIGJlIG1hZGUg Y2xlYXJlci4NCg0KSWYgdGhlIHNlcnZlciBpcyBhYmxlIHRvIHVzZSBvdGhlciBpbmZvcm1hdGlv biAoZS5nLiwgc2VjdXJpdHkgY3JlZGVudGlhbHMgLyBjb29raWVzIG9mIHNvbWUgc29ydCkgdG8g bWFrZSBhIHNlcGFyYXRpb24gcGVyIGNsaWVudCwgdGhhdCBjb3VsZCBiZSB1c2VkIGV2ZW4gdmlh IHByb3h5LiANCg0KSSBndWVzcyBhIGtleSBkaWZmZXJlbmNlIHRvIDUuMDMgYmVzaWRlcyBiZWlu ZyBwZXIgY2xpZW50LCBpcyB0aGF0IHRvby1tYW55LXJlcXMgaXMgYWxzbyBwZXIg4oCcc2ltaWxh ciByZXF1ZXN0cyAvIHJlcXVlc3QgdHlwZeKAnSB3aGVyZWFzIDUuMDMgaW1wbGllcyB0aGF0IGFu eSByZXF1ZXN0IHdvdWxkIGJlIHJlamVjdGVkLiBEb2VzIHRoYXQgbWFrZSBzZW5zZT8gDQoNCj4g Tm90ZSB0aGF0IGEgY2xpZW50IGNvdWxkIGdldCB0aGlzIGFzIGEgcmVzcG9uc2UgZXZlbiBvbiBp dHMgZmlyc3QgcmVxdWVzdCBpZiB0aGUgcGF0aCB0byB0aGUgc2VydmVyIGdvZXMgdGhyb3VnaCBh IHByb3h5IGFnZW50Lg0KDQpJbmRlZWQuIFdlIGNvdWxkIGFkZCBhIG5vdGUgYWJvdXQgdGhhdCB0 byBtYWtlIGl0IGxlc3MgdW5leHBlY3RlZC4NCg0KDQpDaGVlcnMsDQpBcmkNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KPj4gU2VudDogTW9uZGF5LCBKdWx5IDIsIDIw MTggNjo1NCBBTQ0KPj4gVG86IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBbY29y ZV0g8J+UlCBXR0xDIG9mIGRyYWZ0LWlldGYtY29yZS10b28tbWFueS1yZXFzLTAyDQo+PiANCj4+ IERlYXIgQ29SRSBXRywNCj4+IA0KPj4gZHVyaW5nIHRoZSBMb25kb24gSUVURiwgd2Ugc2FpZCB3 ZSB3YW50IHRvIHF1aWNrbHkgZmluaXNoIHRoZSBzcGVjIG9mIHRoZQ0KPj4gcmVzcG9uc2UgY29k ZSA0LjI5ICh0b28gbWFueSByZXF1ZXN0cykuDQo+PiBUaGUgYXV0aG9yIGhhcyBub3cgc3VibWl0 dGVkIGEgcmV2aXNlZCB2ZXJzaW9uIGRlYWxpbmcgd2l0aCB0aGUgcmVjZW50DQo+PiBjb21tZW50 cyBhbmQgYmVsaWV2ZXMgaXQgaXMgcmVhZHkgZm9yIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsLg0K Pj4gDQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXRvby1t YW55LXJlcXMtMDINCj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY29yZS10b28tbWFueS1yZXFzLTAyDQo+PiANCj4+IFRoZSBXR0xDIHdpbGwgZW5kIGluIGV4 YWN0bHkgMzM2IGhvdXJzIHNvIHdlIGNhbiBkaXNjdXNzIHRoZSBvdXRjb21lIGF0IHRoZQ0KPj4g Q29SRSBXRyBtZWV0aW5nDQo+PiANCj4+IEdyw7zDn2UsIENhcnN0ZW4NCj4+IA0KPj4gUFMuOiBB IGJvbnVzIGZvciB0aGUgZmlyc3Qgb25lIHdobyBmaW5kcyB0aGUgb25lIG1hbGZvcm1lZCBzZW50 ZW5jZSBJIGZvdW5kDQo+PiBkdXJpbmcgY2hhaXIgcmV2aWV3Og0KPj4gWW914oCZbGwgZ2V0IHNv bWUgRmlubmlzaCBTYWxtaWFra2kgYXQgdGhlIE1vbnRyZWFsIG1lZXRpbmcuDQo+PiANCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBjb3JlIG1h aWxpbmcgbGlzdA0KPj4gY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Tue Jul 10 07:01:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1FE130FB8 for ; Tue, 10 Jul 2018 07:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwYHcCwqSK0l for ; Tue, 10 Jul 2018 07:01:09 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 54BDE130FB7 for ; Tue, 10 Jul 2018 07:01:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id r3-v6so7857604ywc.5 for ; Tue, 10 Jul 2018 07:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fZ1gn5wnOxQVsPrTtUBm5ZgxeVxd4INVlra51Iwxsj0=; b=Zcq4za5FGNBX52uod20m/qxYBcVCYlw94RhXGvwmouW8kIhl/3B1p/EeroiQv+juW4 s+UDJc8Ix8ANEJCQqAgpfwEytdLzqc39yTJTfh0W+MnjZYLe+fv8Rwj47v+Iv1cdqsGI MIny7onZSDmxsIXwzc8QMsDDGemWSzZBZzqdK1nOjpJ9mc6IZvhWX00VLSxB4mEogUDC NslifYeWEiKoUMA1o64zI2sKWH5vzdBW79IADqdhZM6Hl5m9YpCEYedYVTFrQTGCOOhO ewlB6/B/WXWwve5yX3zrqpjhhQVZeUmdzy8rTvc6aaB8QHspPfp/nz0Zy01q7RWCVSDA FXxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fZ1gn5wnOxQVsPrTtUBm5ZgxeVxd4INVlra51Iwxsj0=; b=Xcuu/ipFGMLrWQ9AT7Qloq8L6vF/7v5isFAbGG1c1e9CENkKQwiYY2an0h2367e2d9 556ki+wn57B996YWrWv/8m9pZhpXyOHEAPSyGcympVSOW/eT9l3cyoAEtCpg8QrW3RTo qv/4SjQwslN18fBeO2Nl0uKpS+XXsu8fKS/GQdNOcAQZw8EivkRC9wTbKPHxE1F0D0kB jvuT5CoC7Z6cDWUUAAaQDEEJjgK/7gbosKhJ9OfyJIKeIV6Db1RS1Pg84nk7xKgOqnmY VgxyejYMh++VGD7UAXK6uKRTSZWtgZFEUXSsu3hkVpl80+6TxgrSNLRgSXYPMb3tfJo8 qa5A== X-Gm-Message-State: APt69E0PxxoBS3JMrmoTVcmlbTXh8sXts48FGVtkmOq5FYiMtzagmwNi WyBPoBfgNMVY4VElkUhFQMg= X-Google-Smtp-Source: AAOMgpeWAdA9h5HrmYeDnc8iOpb5EYA5r2GHxtr/PfxJYnluSuBAbkeM2rlta+vKMn/Sx1nc87Q+LQ== X-Received: by 2002:a0d:f1c7:: with SMTP id a190-v6mr3439887ywf.321.1531231267714; Tue, 10 Jul 2018 07:01:07 -0700 (PDT) Received: from [10.0.0.2] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id z206-v6sm7837182ywa.97.2018.07.10.07.01.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 07:01:06 -0700 (PDT) From: Michael Koster Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1AA97119-49EB-403E-933F-15E90182BBCD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 10 Jul 2018 07:01:04 -0700 In-Reply-To: <69958BDF-BE66-4504-8E0B-C63BC8B89EC1@ericsson.com> Cc: Jim Schaad , Core To: =?utf-8?Q?Ari_Ker=C3=A4nen?= References: <8EEE411B-6268-4103-9F5F-681D21E1AD48@tzi.org> <008c01d41462$44c26c90$ce4745b0$@augustcellars.com> <69958BDF-BE66-4504-8E0B-C63BC8B89EC1@ericsson.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-core-too-many-r?= =?utf-8?q?eqs-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 10 Jul 2018 14:01:13 -0000 --Apple-Mail=_1AA97119-49EB-403E-933F-15E90182BBCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I think it's out of scope for this draft to specify *how* the server = determines there are too many requests, and similar related concerns. The 4xx code indicates that the client can do something about it, and = the proxy would indeed be a more confusing case. Surely there are other = cases where the proxy needs to have a defined behavior in the face of = things that can be retried. At least 4xx gives the proxy a chance to do = something reasonable. For example, the server could keep a ranking of the request rate from = different clients and sending the TMR code preferentially to the higher = ranking clients. But that may not be appropriate for all situations. We want to keep the scope of the meaning of the code to be narrow, I = think. Best regrds, Michael > On Jul 10, 2018, at 2:10 AM, Ari Ker=C3=A4nen = wrote: >=20 > Thank you for the review Jim! >=20 > Please see inline. >=20 >> On 5 Jul 2018, at 16.15, Jim Schaad > wrote: >>=20 >> The draft looks fine to me. >>=20 >> The server gets to have a definition of what it means for something = to be "too similar" for a request and there is no way for this standard = to be communicated to the client. Thus the client's idea that similar = means 'the same payload' may not be the servers idea of 'any payload'. = I don't know how to fix this so I expect it to be ignored. >=20 > While there is no good way to communicate that in generic fashion, and = trying to design one here sounds a bit overkill, the =E2=80=9Cstandard = for similarity=E2=80=9D can be part of the application. Hence client can = have context information what is similar and what is not. And can = eventually figure out from server=E2=80=99s reply that a request it sent = was considered similar. >=20 > The other alternative would be to define here explicitly and = exclusively what is similar but that would restrict the use cases. >=20 >> The document appears to say that this response code is for dealing = with a single client. That is the traffic metric is calculated = individually for each client. The proxy for each client presumably = being source IP, port pair. If the traffic metric is calculated for = everybody then it should return 5.03. If that is not the intent then = this needs to be made clearer. >=20 > If the server is able to use other information (e.g., security = credentials / cookies of some sort) to make a separation per client, = that could be used even via proxy.=20 >=20 > I guess a key difference to 5.03 besides being per client, is that = too-many-reqs is also per =E2=80=9Csimilar requests / request type=E2=80=9D= whereas 5.03 implies that any request would be rejected. Does that make = sense?=20 >=20 >> Note that a client could get this as a response even on its first = request if the path to the server goes through a proxy agent. >=20 > Indeed. We could add a note about that to make it less unexpected. >=20 >=20 > Cheers, > Ari >=20 > -----Original Message----- >>> From: core On Behalf Of Carsten Bormann >>> Sent: Monday, July 2, 2018 6:54 AM >>> To: Core >>> Subject: [core] =F0=9F=94=94 WGLC of = draft-ietf-core-too-many-reqs-02 >>>=20 >>> Dear CoRE WG, >>>=20 >>> during the London IETF, we said we want to quickly finish the spec = of the >>> response code 4.29 (too many requests). >>> The author has now submitted a revised version dealing with the = recent >>> comments and believes it is ready for Working Group last call. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02 >>> A diff from the previous version is available at: >>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-02= >>>=20 >>> The WGLC will end in exactly 336 hours so we can discuss the outcome = at the >>> CoRE WG meeting >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> PS.: A bonus for the first one who finds the one malformed sentence = I found >>> during chair review: >>> You=E2=80=99ll get some Finnish Salmiakki at the Montreal meeting. >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_1AA97119-49EB-403E-933F-15E90182BBCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = think it's out of scope for this draft to specify *how* the server = determines there are too many requests, and similar related = concerns.

The 4xx = code indicates that the client can do something about it, and the proxy = would indeed be a more confusing case. Surely there are other cases = where the proxy needs to have a defined behavior in the face of things = that can be retried. At least 4xx gives the proxy a chance to do = something reasonable.

For example, the server could keep a ranking of the request = rate from different clients and sending the TMR code preferentially to = the higher ranking clients. But that may not be appropriate for all = situations.

We = want to keep the scope of the meaning of the code to be narrow, I = think.

Best = regrds,

Michael




On Jul 10, 2018, at 2:10 AM, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:

Thank you for the review = Jim!

Please see inline.
On 5 Jul 2018, at 16.15, Jim = Schaad <ietf@augustcellars.com> wrote:

The draft looks fine to me.

The = server gets to have a definition of what it means for something to be = "too similar" for a request and there is no way for this standard to be = communicated to the client.  Thus the client's idea that similar = means 'the same payload' may not be the servers idea of 'any payload'. =  I don't know how to fix this so I expect it to be ignored.

While there is no good way to communicate = that in generic fashion, and trying to design one here sounds a bit = overkill, the =E2=80=9Cstandard for similarity=E2=80=9D can be part of = the application. Hence client can have context information what is = similar and what is not. And can eventually figure out from server=E2=80=99= s reply that a request it sent was considered similar.
The other alternative would be to define here = explicitly and exclusively what is similar but that would restrict the = use cases.

The document appears to say = that this response code is for dealing with a single client.  That = is the traffic metric is calculated individually for each client. =  The proxy for each client presumably being source IP, port pair. =  If the traffic metric is calculated for everybody then it should = return 5.03.  If that is not the intent then this needs to be made = clearer.

If the server is able to use = other information (e.g., security credentials / cookies of some sort) to = make a separation per client, that could be used even via proxy. 
I guess a key difference to 5.03 besides being = per client, is that too-many-reqs is also per =E2=80=9Csimilar requests = / request type=E2=80=9D whereas 5.03 implies that any request would be = rejected. Does that make sense? 
Note that a client could get = this as a response even on its first request if the path to the server = goes through a proxy agent.

Indeed. We could add a note about that to make = it less unexpected.

Cheers,
Ari
-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, July 2, 2018 6:54 AM
To: Core = <core@ietf.org>
Subject: [core] =F0=9F=94=94 WGLC of = draft-ietf-core-too-many-reqs-02

Dear CoRE = WG,

during the London IETF, we said we want = to quickly finish the spec of the
response code 4.29 (too = many requests).
The author has now submitted a revised = version dealing with the recent
comments and believes it = is ready for Working Group last call.

https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-02
A diff from the previous version is available at:
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-= reqs-02

The WGLC will end in exactly 336 = hours so we can discuss the outcome at the
CoRE WG = meeting

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

PS.: A bonus for the first one who finds the = one malformed sentence I found
during chair review:
You=E2=80=99ll get some Finnish Salmiakki at the Montreal = meeting.

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

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

= --Apple-Mail=_1AA97119-49EB-403E-933F-15E90182BBCD-- From nobody Wed Jul 11 05:00:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A2130E60 for ; Wed, 11 Jul 2018 05:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 1s0TXeStrLTu for ; Wed, 11 Jul 2018 05:00:27 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6793D130E3A for ; Wed, 11 Jul 2018 05:00:27 -0700 (PDT) Received: from [192.168.1.109] (p54BDE38A.dip0.t-ipconnect.de [84.189.227.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 93CDD203A4; Wed, 11 Jul 2018 14:00:25 +0200 (CEST) To: consultancy@vanderstok.org References: <3d39562b-5a57-6fd6-03f7-9d13d2c58ffd@tzi.de> <6a6095b3681e9d3da32eb98c14ec2239@bbhmail.nl> Cc: core@ietf.org From: Stefanie Gerdes Message-ID: <8c297b25-b38d-abc7-88c7-fabda3935482@tzi.de> Date: Wed, 11 Jul 2018 14:00:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6a6095b3681e9d3da32eb98c14ec2239@bbhmail.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Resource Directory Authorization Problems X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 12:00:32 -0000 Hi Peter, Thank you for your explanation. Please find some more thoughts below. >> >> In section 9.2 you define the new CWT fields rd_epn and rd_sct. I don't >> think new fields should be defined in the security considerations. >> >> We agree; that is not done; Section 9 is stand alone; Section 8 refers to it; that's all. >> May be I misunderstand your concern here. >> Sorry, I misread the document structure. But defining new fields for an example may also be difficult. >> Also, lookup and registration of RD entries do not seem to differ that >> much from the access to other resources. We may not want to define new >> CWT fields for every use case. That the subject of the access token is >> only allowed to register for the registree-ep given in rd_epn, sounds >> more like an access token scope to me. >> >> scope is from client to AS? >> I did not discuss that part, but indeed the client first asks the AS permission to register an endpoint name into the RD. >> The AS, when happy, creates an endpoint name, and authorizes the client to register the endpoint name by specifying its value with rd_epn. >> Do you have an alternative to solve the problem. Can you modify the example? >> The scope defines the authorization, e.g., which resource may be accessed, and how (see [1], [2]). If I understand section 9.2 correctly, the CWT with the new fields authorizes the CT to register the endpoint with a certain certificate identifier and sector name. Since these fields scope the authorization (define which endpoint the CT is allowed to register), I wonder why you cannot use an access token scope for this purpose. The RD would then need to validate that the scope covers the requested resources (see [2]), i.e., that the CT is allowed to register resources for the endpoint, which is what we aim at, right? Scopes are defined by the application (see [3]), and therefore could be used for this purpose. There are some more open question concerning the authorization that may need to be considered here, e.g.: How does the RD server know the Authorization Server (they must have a security association)? How does the RD server know that a certain AS is authorized to issue access tokens for a certain endpoint registration or lookup? Does the RD server protect every lookup? If it doesn't, how does the RD server know which resources it must protect? Viele Gruesse Steffi [1] https://tools.ietf.org/html/rfc6749#section-3.3 [2] https://tools.ietf.org/html/rfc6749#section-7 [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13#section-5.8 From nobody Wed Jul 11 10:32:02 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFA1130F2D; Wed, 11 Jul 2018 10:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYvrWnHsp_my; Wed, 11 Jul 2018 10:31:58 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6872130E69; Wed, 11 Jul 2018 10:31:55 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Jul 2018 10:28:18 -0700 From: Jim Schaad To: CC: 'Core' Date: Wed, 11 Jul 2018 10:31:43 -0700 Message-ID: <053f01d4193d$0a72c460$1f584d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdQYaoV37BbZYpdJQZC3S1xD1eNBeQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Reading -13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 17:32:01 -0000 * Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. * In section 5.4 you have the text request_piv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the request_piv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. * Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? * Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id. From nobody Thu Jul 12 01:03:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC53130EC9 for ; Thu, 12 Jul 2018 01:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NETEG1acX13K for ; Thu, 12 Jul 2018 01:03:23 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248F4130E0E for ; Thu, 12 Jul 2018 01:03:21 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 0D913100E86C3; Thu, 12 Jul 2018 08:03:20 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:72:152:355:379:582:599:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2559:2568:2570:2634:2682:2685:2693:2703:2859:2894:2897:2901:2918:2933:2937:2939:2942:2945:2947:2951:2954:3022:3354:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:4362:5007:6117:6119:6261:7875:7903:8603:9025:10004:10400:10450:10455:11658:12740:13139:13144:13161:13229:13230, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: event96_57414d3a48207 X-Filterd-Recvd-Size: 7742 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA; Thu, 12 Jul 2018 08:03:19 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f4bc3865e62880d5a4ce5d9d3687631f" Date: Thu, 12 Jul 2018 10:03:19 +0200 From: Peter van der Stok To: Stefanie Gerdes Cc: consultancy@vanderstok.org, core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8c297b25-b38d-abc7-88c7-fabda3935482@tzi.de> References: <3d39562b-5a57-6fd6-03f7-9d13d2c58ffd@tzi.de> <6a6095b3681e9d3da32eb98c14ec2239@bbhmail.nl> <8c297b25-b38d-abc7-88c7-fabda3935482@tzi.de> Message-ID: <819180117a33e706b40f533fce182122@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [82.95.140.48] Archived-At: Subject: Re: [core] Resource Directory Authorization Problems X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 08:03:27 -0000 --=_f4bc3865e62880d5a4ce5d9d3687631f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Steffi, thanks for a continued conversation. The cted text has helped me to understand better the the reach and purpose of scope parameter. Stefanie Gerdes schreef op 2018-07-11 14:00: > Hi Peter, > > > Concerning section 9 "example" > I will put it above the "security considerations" > The Example text is meant as a warning shot to RD users, not as a normative text. > Introducing the scope, as you suggest, validates that approach. > > The scope defines the authorization, e.g., which resource may be > accessed, and how (see [1 [1]], [2 [2]]). If I understand section 9.2 correctly, > the CWT with the new fields authorizes the CT to register the endpoint > with a certain certificate identifier and sector name. Since these > fields scope the authorization (define which endpoint the CT is allowed > to register), I wonder why you cannot use an access token scope for this > purpose. The RD would then need to validate that the scope covers the > requested resources (see [2 [2]]), i.e., that the CT is allowed to register > resources for the endpoint, which is what we aim at, right? Scopes are > defined by the application (see [3 [3]]), and therefore could be used for > this purpose. > > > Many thanks for the concrete text portions; that helps enormously. > next step for me is to modify the example using scope. > > > There are some more open question concerning the authorization that may > need to be considered here, e.g.: How does the RD server know the > Authorization Server (they must have a security association)? How does > the RD server know that a certain AS is authorized to issue access > tokens for a certain endpoint registration or lookup? Does the RD server > protect every lookup? If it doesn't, how does the RD server know which > resources it must protect? > > > I fully agree with your open questions. > another one: How does the AS server know which endpoint is authorized to specify what in the RD. > Personally, I still think that an RD security draft (in ACE?) is needed in addition to example text in RD draft. > > > Viele Gruesse > Steffi > > [1] https://tools.ietf.org/html/rfc6749#section-3.3 > [2] https://tools.ietf.org/html/rfc6749#section-7 > [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13#section-5.8 Links: ------ [1] https://tools.ietf.org/html/rfc6749#section-3.3 [2] https://tools.ietf.org/html/rfc6749#section-7 [3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13#section-5.8 --=_f4bc3865e62880d5a4ce5d9d3687631f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Steffi,

thanks for a continued conversation.
The cted te= xt has helped me to understand better the the reach and purpose of scope pa= rameter.

Stefanie Gerdes schreef op 2018-07-11 14:00:

= Hi Peter,

<pvds>
Concerning section 9 "example"
= I will put it above the "security considerations"
The Example text is = meant as a warning shot to RD users, not as a normative text.
Introduc= ing the scope, as you suggest, validates that approach.
</pvds><= br /> The scope defines the authorization, e.g., which resource may be
accessed, and how (see [1], [2]). If I understand section 9.2 correctly,
the CWT with the ne= w fields authorizes the CT to register the endpoint
with a certain ce= rtificate identifier and sector name. Since these
fields scope the au= thorization (define which endpoint the CT is allowed
to register), I = wonder why you cannot use an access token scope for this
purpose. The= RD would then need to validate that the scope covers the
requested r= esources (see [2]), i.e., that the CT is allowed to= register
resources for the endpoint, which is what we aim at, right?= Scopes are
defined by the application (see [3]), and therefore could be used for
this p= urpose.

<pvds>
Many thanks for the concrete text port= ions; that helps enormously.
next step for me is to modify the example= using scope.
</pvds>

There are some more open quest= ion concerning the authorization that may
need to be considered here,= e.g.: How does the RD server know the
Authorization Server (they mus= t have a security association)? How does
the RD server know that a ce= rtain AS is authorized to issue access
tokens for a certain endpoint = registration or lookup? Does the RD server
protect every lookup? If i= t doesn't, how does the RD server know which
resources it must protec= t?

<pvds>
I fully agree with your open questions.
another one: How does the AS server know which endpoint is authorized to = specify what in the RD.
Personally, I still think that an RD security = draft (in ACE?) is needed in addition to example text in RD draft.
<= ;/pvds>

Viele Gruesse
Steffi

[1] https://tools.ietf.org/html/rfc6749#section-3.3
[= 2] https://tools.ietf.org/html/rfc6749#section-7 [3] https://tools.ietf.org/= html/draft-ietf-ace-oauth-authz-13#section-5.8
--=_f4bc3865e62880d5a4ce5d9d3687631f-- From nobody Thu Jul 12 22:09:29 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90502130DE0 for ; Thu, 12 Jul 2018 22:09:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMvkr6avPhnR for ; Thu, 12 Jul 2018 22:09:25 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37688124D68 for ; Thu, 12 Jul 2018 22:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6D59L0n017808 for ; Fri, 13 Jul 2018 07:09:21 +0200 (CEST) Received: from [192.168.217.102] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Rgp86JCPzDWtb; Fri, 13 Jul 2018 07:09:20 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_86AAAA30-1CC4-4D96-80DE-C239B44E1571" X-Mao-Original-Outgoing-Id: 553151358.351882-4d3b504c54ad5ad57733fd0016bebf24 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 13 Jul 2018 07:09:20 +0200 Message-Id: <20AFF4F7-88B8-4EBB-9A0B-213B569F69FA@tzi.org> References: To: Core X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [core] Fwd: statement regarding keepalives X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 05:09:29 -0000 --Apple-Mail=_86AAAA30-1CC4-4D96-80DE-C239B44E1571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is a discussion going on in tsvarea on keepalives. It seems to me that the facilities in RFC 8323 are already in line with = the thinking at least of the initial draft statement (and so is RFC = 7252=E2=80=99s original =E2=80=9CCoAP ping=E2=80=9D). Those who care about keepalives, ping/pong etc. may want to follow this = discussion=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Kent Watsen > > Subject: statement regarding keepalives > Date: July 13, 2018 at 02:37:59 GMT+2 > To: "tsv-area@ietf.org " > > Cc: "tsvwg-ads@tools.ietf.org " = >, = "tls-ads@ietf.org " >, "netconf-chairs@ietf.org = " > > Archived-At: = > >=20 >=20 > Dear TSVAREA, >=20 > The folks working with the BBF asked the NETMOD WG to consider = modifying draft-ietf-netconf-netconf-client-server to support TCP = keepalives [1]. However, it is unclear what IETF's position is on the = use of keepalives, especially with regards to keepalives provided in = protocol stacks (e.g., over HTTP over TLS over TCP). >=20 > After some discussion with Transport ADs (Spencer and Mijra) and the = TLS ADs (Eric and Ben), the following draft statement has been crafted. = Spencer and Mijra have requested TSVAREA critique it before, perhaps, = developing a consensus document around it in TSVWG. >=20 > It would be greatly appreciated if folks here could review and provide = comments on the draft statement below. The scope of the statement can = be increased or reduced as deemed appropriate.=20 >=20 > [1] = https://mailarchive.ietf.org/arch/msg/netconf/MOzcZKp2rSxPVMTGdmmrVInwx2M = =20 >=20 > Thanks, > Kent (and Mahesh) // NETCONF chairs >=20 >=20 > =3D=3D=3D=3D=3D STATEMENT =3D=3D=3D=3D=3D >=20 > When the initiator of a networking session needs to maintain a = persistent connection [1], it is necessary for it to periodically test = the aliveness of the remote peer. In such cases, it is RECOMMENDED that = the aliveness check happens at the highest protocol layer possible that = is most meaningful to the application, to maximize the depth of the = aliveness check. =20 >=20 > E.g., for an HTTPS connection to a simple webserver, HTTP-level = keepalives would test more aliveness than TLS-level keepalives. = However, for a webserver that is accessed via a load-balancer that = terminates TLS connections, TLS-level aliveness checks may be the most = meaningful check that could be performed. >=20 > In order to ensure aliveness checks can always occur at the highest = protocol layer, it is RECOMMENDED that protocol designers always include = an aliveness check mechanism in the protocol and, for client/server = protocols, that the aliveness check can be initiated from either peer, = as sometimes the "server" is the initiator of the underlying networking = connection (e.g., RFC 8071). >=20 > Some protocol stacks have a secure transport protocol layer (e.g., = TLS, SSH, DTLS) that sits on top of a cleartext protocol layer (e.g., = TCP, UDP). In such cases, it is RECOMMENDED that the aliveness check = occurs within protection envelope afforded by the secure transport = protocol layer. In such cases, the aliveness checks SHOULD NOT occur = via the cleartext protocol layer, as an adversary can block aliveness = check messages in either direction and send fake aliveness check = messages in either direction. >=20 > [1] While reasons may vary for why the initiator of a networking = session feels compelled to maintain a persistent connection. If the = session is primarily quiet, and the use case can cope with the = additional latency of starting a new connection, it is RECOMMENDED to = use short-lived connections, instead of maintaining a long-lived = persistent connection using aliveness checks. >=20 >=20 >=20 >=20 --Apple-Mail=_86AAAA30-1CC4-4D96-80DE-C239B44E1571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There= is a discussion  going on in tsvarea on keepalives.
It seems to me that  the facilities in RFC 8323 are = already in line with the thinking at least of the initial draft = statement (and so is RFC 7252=E2=80=99s original =E2=80=9CCoAP = ping=E2=80=9D).
Those who care about keepalives, = ping/pong etc. may want to follow this discussion=E2=80=A6

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


Begin = forwarded message:

From: = Kent Watsen <kwatsen@juniper.net>
Subject: = statement = regarding keepalives
Date: = July 13, 2018 at 02:37:59 = GMT+2
To: = "tsv-area@ietf.org" = <tsv-area@ietf.org>
Cc: "tsvwg-ads@tools.ietf.org" <tsvwg-ads@tools.ietf.org>, "tls-ads@ietf.org" <tls-ads@ietf.org>, = "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Archived-At: = <https://mailarchive.ietf.org/arch/msg/tsv-area/fmz3WMUmZUiRUMm2= AJgsA85QY94>


Dear TSVAREA,

The folks working with the BBF asked the NETMOD WG to = consider modifying draft-ietf-netconf-netconf-client-server to support = TCP keepalives [1].  However, it is unclear what IETF's position is = on the use of keepalives, especially with regards to keepalives provided = in protocol stacks (e.g., <some-app> over HTTP over TLS over = TCP).

After some discussion with Transport = ADs (Spencer and Mijra) and the TLS ADs (Eric and Ben), the following = draft statement has been crafted.  Spencer and Mijra have requested = TSVAREA critique it before, perhaps, developing a consensus document = around it in TSVWG.

It would be greatly = appreciated if folks here could review and provide comments on the draft = statement below.  The scope of the statement can be increased or = reduced as deemed appropriate.

[1] https://mailarchive.ietf.org/arch/msg/netconf/MOzcZKp2rSxPVMTGd= mmrVInwx2M

Thanks,
Kent = (and Mahesh) // NETCONF chairs


=3D=3D=3D=3D=3D STATEMENT =3D=3D=3D=3D=3D

When the initiator of a networking session needs to maintain = a persistent connection [1], it is necessary for it to periodically test = the aliveness of the remote peer.  In such cases, it is RECOMMENDED = that the aliveness check happens at the highest protocol layer possible = that is most meaningful to the application, to maximize the depth of the = aliveness check.  

E.g., for an HTTPS = connection to a simple webserver, HTTP-level keepalives would test more = aliveness than TLS-level keepalives.  However, for a webserver that = is accessed via a load-balancer that terminates TLS connections, = TLS-level aliveness checks may be the most meaningful check that could = be performed.

In order to ensure aliveness = checks can always occur at the highest protocol layer, it is RECOMMENDED = that protocol designers always include an aliveness check mechanism in = the protocol and, for client/server protocols, that the aliveness check = can be initiated from either peer, as sometimes the "server" is the = initiator of the underlying networking connection (e.g., RFC 8071).

Some protocol stacks have a secure transport = protocol layer (e.g., TLS, SSH, DTLS) that sits on top of a cleartext = protocol layer (e.g., TCP, UDP).  In such cases, it is RECOMMENDED = that the aliveness check occurs within protection envelope afforded by = the secure transport protocol layer.  In such cases, the aliveness = checks SHOULD NOT occur via the cleartext protocol layer, as an = adversary can block aliveness check messages in either direction and = send fake aliveness check messages in either direction.

[1] While reasons may vary for why the initiator of a = networking session feels compelled to maintain a persistent connection. =  If the session is primarily quiet, and the use case can cope with = the additional latency of starting a new connection, it is RECOMMENDED = to use short-lived connections, instead of maintaining a long-lived = persistent connection using aliveness checks.





= --Apple-Mail=_86AAAA30-1CC4-4D96-80DE-C239B44E1571-- From nobody Fri Jul 13 14:35:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE2130E37 for ; Fri, 13 Jul 2018 14:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihZRF04YgYms for ; Fri, 13 Jul 2018 14:35:21 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 617A912F1AC for ; Fri, 13 Jul 2018 14:35:16 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id b15-v6so28375319qtp.11 for ; Fri, 13 Jul 2018 14:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=C1fYqtftFNsyqEXBXYW8Vc2SXAZDREMSpZiNFSgRwj8=; b=IuXCzLkufz8nKpv0hs2Y9B+m1We+BHzBiiIZ41cxmkiX03kcwrigFHP/whChbvil3j YHezUORrP7Y9+3LfGScmbhJsx593xhJEZP2V9nIThM9HQ5V0cl9zCggyCAPZx0+ZuBPK ihiyvhUixPVNnGIBHYpySli4VpqvMjE8+jHaETEUea60e9EgI1IFE9Cfms5++j8jN29w bl8bVPeNuQCOgYoFTAMl6dl0dNpmN8lshvR10A06lpWmhExM2OdWvpRN0peKfCvhlkHQ Ee3zcv82yVkZpZRIdk0gaRP/vU9eYFFVl8a5daHoRV3SBcS5QuW31z/RTmfLHly+HZoR Ejcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=C1fYqtftFNsyqEXBXYW8Vc2SXAZDREMSpZiNFSgRwj8=; b=IZjIe5yXX2lG4N6Fu1V9m9RRwinSCnQdGqOcvmprJnMQKn8agHLSrnG8YRUPDA/J5r DYIfv4SlBbZbFxmFLPuGJ9CZU20fY3xixr93AcbiKg6V5rcIsoNA4C1LdhwTVPYdpoTT ZJ6sdjkMPrLbaLLFRCXFb1LaJuGZeBUdWpP0oIiy8BFy8hgcVxiUnh2lrqLTUGqtUYvN eaonLhmVtVUGEn/aPrYwN48XyWhGhkBbF8h7DGXLdJxBe56Q1yun+4KaXNjb+rU/B6Dm 0J4ZBhvi3+5NLPjY4fTISmKyPNA9fzxa6KYkYMkG7NZk5NR2ulepHbHAxEf8L7Pzh8tw mObg== X-Gm-Message-State: AOUpUlGRdPXzBhlJLKqfdhxuWN2wPHwzVqr72/foZ0N1LntqHEAr35kg a2cqKqlCcj8BhB7P0/NB4EjCHQ== X-Google-Smtp-Source: AAOMgpc9jZ9vbJVRNTmX+rYmgtih/sSARJfxzG1vwLABp45YRAhbDaSJTrA4cLEl5DjIjeHNzSPu4A== X-Received: by 2002:a0c:cd83:: with SMTP id v3-v6mr8958030qvm.232.1531517715443; Fri, 13 Jul 2018 14:35:15 -0700 (PDT) Received: from [172.20.33.141] ([207.134.103.162]) by smtp.gmail.com with ESMTPSA id d4-v6sm23952945qtd.72.2018.07.13.14.35.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 14:35:14 -0700 (PDT) From: Alexander Pelov Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 13 Jul 2018 17:35:12 -0400 In-Reply-To: <042A223B-722C-43DD-9478-EC8D014133F4@ackl.io> Cc: core@ietf.org, netmod@ietf.org, yot@ietf.org, hackathon@ietf.org To: Alexander Pelov References: <042A223B-722C-43DD-9478-EC8D014133F4@ackl.io> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] Hackathon - open-source CoMI implementation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 21:35:24 -0000 --Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hell all, In anticipation of tomorrow's Hackathon on CoMI, please find the steps = of preparation and the things we will be doing tomorrow and on Sunday : https://etherpad.tools.ietf.org/p/comi = We will be combining work from F-Interop, CoAP, CBOR, and YDK, so that = one is going to be really interesting. Drop by if you have expertise and = even if you don't participate directly, if you are able to share some of = your wisdom. See you tomorrow, Alexander > On 6 Jul 2018, at 11:03, Alexander Pelov wrote: >=20 > Dear all, >=20 > The way to use YANG for IoT - CoMI - has been stable for some time and = the missing piece as always has been.. running OPEN-SOURCE code! >=20 > Montreal is the place to change that! Join us at the Hackathon in the = first structured effort to provide an open-source implementation of a = CoMI server and CoMI client. > I personally will be coding in Python, but in case other folks want to = use something else - that's even better. >=20 > See you on the Hackathon! > Alexander >=20 > PS. > If people knowledgable in YDK want to join, that would be really = perfect! >=20 >=20 > The description is here: > https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon >=20 --Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hell all,

In anticipation of tomorrow's Hackathon on CoMI, please find = the steps of preparation and the things we will be doing tomorrow and on = Sunday :

https://etherpad.tools.ietf.org/p/comi

We will be combining work from = F-Interop, CoAP, CBOR, and YDK, so that one is going to be really = interesting. Drop by if you have expertise and even if you don't = participate directly, if you are able to share some of your = wisdom.

See = you tomorrow,
Alexander




On 6 Jul 2018, at 11:03, Alexander Pelov <a@ackl.io> wrote:

Dear = all,

The way to use YANG for IoT - CoMI - = has been stable for some time and the missing piece as always has been.. = running OPEN-SOURCE code!

Montreal is the = place to change that! Join us at the Hackathon in the first structured = effort to provide an open-source implementation of a CoMI server and = CoMI client.
I personally will be coding in Python, but in = case other folks want to use something else - that's even better.

See you on the Hackathon!
Alexander

PS.
If = people knowledgable in YDK want to join, that would be really = perfect!


The description is = here:
https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon

= --Apple-Mail=_87B96EC8-A248-445C-A3D6-953E21CC1C6F-- From nobody Sun Jul 15 18:25:47 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48A130E65 for ; Sun, 15 Jul 2018 18:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp08dTr4tBXT for ; Sun, 15 Jul 2018 18:25:43 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 873F812D949 for ; Sun, 15 Jul 2018 18:25:43 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id c15-v6so11331436qtp.0 for ; Sun, 15 Jul 2018 18:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qVk5vlUpQWa8wHp1zM/Zi8wwFxsbpLwfCS5fGYiUc2I=; b=y4hSqiFDGynsgjkVs3zW02+S3i5rDwhVWTFbraZtdgNiHSxpPNB8jYzHkxqiCUUYW9 +s3p2HTA5x45l+zhAr7D63Rhne0/ii2T6wWYrdEHI+L5Zrt5Xh0X7RCcF0gYjHYsNQCC hoZ9kkRbulLS91QFF0uR38ako3MJKKGGSqYvD3MwzeN4KzitmIltmJiamSliCqV5eNUk 2BNnDAtgailCl1G0/49SyLP8kVF7rWXcHSWgT1GJP6buWUkFHr5YqVe+1b3m1wcNj3ia +D/QqgBTX0L5vlRurPZMXc6EsFcTzboty5oNgEU7XnzcCczX3hkEOc/8c7724OOXkEzX vDzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qVk5vlUpQWa8wHp1zM/Zi8wwFxsbpLwfCS5fGYiUc2I=; b=SUMWYkzVvNxkNjolNbwccsiHHgMpAFeK9x2tNnxdpJWBNWGAEv2Fgw9XFLeVmSsXPP f/sGLA1ehHSS5ZDLOwu7DyRzWTvSuvGEXOZnQpZDVbb/15ym4c7l0SXI71s0BMC6eF/B 6wdNAo0rn5oovLlEUAiuhQ0brsTQ8bVtIhhcABiuAI4MkaEW3Lw5/KT+b6xgRWZ9f5RZ r6b4G3NSV1OlPE/eUGg0F19zeoXy9ShLmQtYoIUjZUqZvMAjEIOvN86ziIE/sBNOYQJp tFuHWMHzI0quXj1FjWmGATYJ0mO6DFOdifS9ffbJHRt5+Qnn/lzeE9dcT1GCojzVvGHF me1w== X-Gm-Message-State: AOUpUlFgpIc6m/wvlQ21V2kElvD0vNLmvwdDsACHVxU8DpDEbPdSrDOu bAKS8ktBzdJNtmnxWr14druXAYbeSMw= X-Google-Smtp-Source: AAOMgpfvcTySQ9C+eAgAdkYa2Et1nlVsDw8bl/2O1KawCb9RZYRoySddr+gL5EL6lKnvejPDxEVH0A== X-Received: by 2002:ac8:2b23:: with SMTP id 32-v6mr13948202qtu.119.1531704342596; Sun, 15 Jul 2018 18:25:42 -0700 (PDT) Received: from evariste.lan (modemcable018.183-83-70.mc.videotron.ca. [70.83.183.18]) by smtp.gmail.com with ESMTPSA id n25-v6sm6371615qtp.94.2018.07.15.18.25.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Jul 2018 18:25:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Alexander Pelov In-Reply-To: <20180709153119.nqvakgcqckk4p63w@anna.jacobs.jacobs-university.de> Date: Sun, 15 Jul 2018 21:25:39 -0400 Cc: core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0DBD50A1-C2BA-4EEB-9870-17EADCEF26A7@ackl.io> References: <20180709153119.nqvakgcqckk4p63w@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] ietf-comi:sid and draft-ietf-core-sid-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 01:25:46 -0000 Hi Juergen, Good catch on that! Also agree with you that it would be best to define SID in = draft-ietf-core-sid-04.txt and import it from CoMI. Cheers, Alexander > On 9 Jul 2018, at 11:31, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > I see that ietf-sid-file (defined in draft-ietf-core-sid-04.txt) = imports > ietf-comi in order to use ietf-comi:sid, which is defined as: >=20 > typedef sid { > type uint64; > description > "YANG Schema Item iDentifier"; > reference > "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; > } >=20 > I think it would be better if the sid type would be defined as part of > I-D.ietf-core-sid instead of being defined in ietf-comi. (I assume I > could use YANG/CBOR/SID with RESTCONF without having a dependency on > COMI.) >=20 > [It seems this is another case where people use YANG to define data > that is not implemented in a datastore. Too bad we still have no > proper way to do this.] >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Jul 15 18:28:06 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40342130EF7 for ; Sun, 15 Jul 2018 18:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRax2OrXKZzE for ; Sun, 15 Jul 2018 18:28:02 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 E51C7130E9B for ; Sun, 15 Jul 2018 18:28:01 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id b15-v6so31655069qtp.11 for ; Sun, 15 Jul 2018 18:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qVk5vlUpQWa8wHp1zM/Zi8wwFxsbpLwfCS5fGYiUc2I=; b=beeDhDkiW+3V5Vsv00wJlFpq5NdGoQjeHWEqIfBJGeEofQ61LrsSwwv3fKjX2z5sLc Uz64MaCTwcnwHP0lOrNqpsFX3uB4TgQX3OWUnkcp9lLWpeMCLSfiuLlUbFytzOXfE9yU STVJVKFzSotzSWrjb/0aFtkM53mPAHEZ2x4krgV0tmU5aWh6r/53KYTIO5c4qbzYoz3l G2wXS2RkVDDpzco+DGhyevDQd415Y+QoIWYZTgKYN3fJ8uV3ZVRVFpSN2G3X1v6ijVvg Al/vQxKGEAmky9L1bHJjgDhpDreqFHKcE8IlkyzxFAgKe3fV5kyLsQxdiPQTLYrCiz+n N/Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qVk5vlUpQWa8wHp1zM/Zi8wwFxsbpLwfCS5fGYiUc2I=; b=HoTZkCzNOi68t7qXYXAJzaD27ht9zkON2wg1cGttmL8e9r4vcxv9VqZhmPgkiPrq+U RUo1GkBM3zxT0PRdY0xmGWlC8A4vacJLQD3un3RqmW2UEAfZYCgf+PHIETalYLoAMtRC ZLgigtT8A+EjJAx55rML3G4m2WmTTEfVozAkQX6P1nUF8LOxXPewiG/LYwFjuhtqZVYh gGCirQYKD1zuSPB41l33765Hi9dCzjOQ/qlze3p5uBSZZEQNBYoYvrTd18vVTG6Ehily JkOM/GTCwGpKrGYC3zSr3DlhWxm9Bz8j6Dzhy2Pokr2hf4nH0GYVK3t4w9aC6M0Dsyw7 tsIw== X-Gm-Message-State: AOUpUlFz7Ty5PEQZXQ6qaXl5xSQpYE7BaZxy4ofkXAmvpVQ7HL+V+4tG 7/GW1vB0Bvotufc0Xhm8bMkt84DE8DI= X-Google-Smtp-Source: AAOMgpcQu4oIIOs+U+y9HUdFMCAmPRqsEeFokFNh+laAvH4jE8PV7G30qIUgQBN/wYDscXv6uKzVOQ== X-Received: by 2002:ac8:fd0:: with SMTP id f16-v6mr5069048qtk.13.1531704481088; Sun, 15 Jul 2018 18:28:01 -0700 (PDT) Received: from evariste.lan (modemcable018.183-83-70.mc.videotron.ca. [70.83.183.18]) by smtp.gmail.com with ESMTPSA id a19-v6sm9032129qta.50.2018.07.15.18.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Jul 2018 18:28:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Alexander Pelov In-Reply-To: <20180709153119.nqvakgcqckk4p63w@anna.jacobs.jacobs-university.de> Date: Sun, 15 Jul 2018 21:27:59 -0400 Cc: core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <33155478-C76F-4ED4-A5CA-98BA2D0AEBE9@ackl.io> References: <20180709153119.nqvakgcqckk4p63w@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [core] ietf-comi:sid and draft-ietf-core-sid-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 01:28:05 -0000 Hi Juergen, Good catch on that! Also agree with you that it would be best to define SID in = draft-ietf-core-sid-04.txt and import it from CoMI. Cheers, Alexander > On 9 Jul 2018, at 11:31, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > I see that ietf-sid-file (defined in draft-ietf-core-sid-04.txt) = imports > ietf-comi in order to use ietf-comi:sid, which is defined as: >=20 > typedef sid { > type uint64; > description > "YANG Schema Item iDentifier"; > reference > "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; > } >=20 > I think it would be better if the sid type would be defined as part of > I-D.ietf-core-sid instead of being defined in ietf-comi. (I assume I > could use YANG/CBOR/SID with RESTCONF without having a dependency on > COMI.) >=20 > [It seems this is another case where people use YANG to define data > that is not implemented in a datastore. Too bad we still have no > proper way to do this.] >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 16 14:04:18 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2A8130EBA; Mon, 16 Jul 2018 14:04:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, Carsten Bormann , core@ietf.org, alexey.melnikov@isode.com, cabo@tzi.org, draft-ietf-core-object-security@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153177504868.21715.17839039095053328344.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2018 14:04:08 -0700 Archived-At: Subject: [core] Last Call: (Object Security for Constrained RESTful Environments (OSCORE)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:04:09 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Object Security for Constrained RESTful Environments (OSCORE)' as Proposed Standard This is the Second IETF Last Call on the document, as the document has changed significantly after IESG review and IETF community should be given a change to review the changes. In particular interested readers should review updated Section 11 (HTTP Operations) and newly added Appendix D (Overview of Security Properties). The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-07-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 16 14:09:56 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CA113125F for ; Mon, 16 Jul 2018 14:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ZBXnaICnJdbM for ; Mon, 16 Jul 2018 14:09:33 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0137.outbound.protection.outlook.com [104.47.32.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0D6131268 for ; Mon, 16 Jul 2018 14:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kUEicDmPKP/AbqNC3jnzRi/tJpG5c97T25lN3Ke4l+Y=; b=N59guiJE4w+tizywNsewvxT5CgonEkMsJT7agemqPROgwhHlnN+2Stz1cjM4KisWuRYy4ySk03B6DRyI6+Px44q96pBrwdiao3FlCGjM9uVnmXxDvEFjsgtE0ydBBLzBPfpBzsNE+gQ6SRcIBC8qOSQ5JhjYjLmyFBEUkwrKQ8U= Received: from DM5PR2101MB0805.namprd21.prod.outlook.com (10.167.105.149) by DM5PR2101MB0933.namprd21.prod.outlook.com (52.132.131.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.1; Mon, 16 Jul 2018 21:09:31 +0000 Received: from DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::8416:6f:8f6b:3fb7]) by DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::8416:6f:8f6b:3fb7%3]) with mapi id 15.20.0995.000; Mon, 16 Jul 2018 21:09:31 +0000 From: Dave Thaler To: "core@ietf.org" Thread-Topic: Link-format to DNS-SD mapping: URI rt values Thread-Index: AdQdSPtcZmGQuQl1TxG1okvHZp31QA== Date: Mon, 16 Jul 2018 21:09:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-07-16T21:09:11.4152156Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:67c:370:128:c4a9:2dde:c0c6:a81d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0933; 6:voJ8xDkVcJh8J2c4fzLeUcGw0wJhP46KFq/U8v1PNYWPiazxJL+424fL7js+VL2+3RWQWN2hdYKbUfQ+NlCHbv0+McVcuhbPJDAf1VrXdv7mdlPK4iWiiPAvaVpRCtCDJazl+EHiOPXzywPwpnBhey8srJC6QkeY1L0ZfNzV1W98/GUSKTn4bkFnOEUR7g/9SmRkgNDgbZZv73xer16+c79SHfb+paRN/N3NrU2//ebT+XMLhdLz0irSBFHEkQj3qkmPd8uKzObSlwfAipg3K1aqYoiJhZSbyQlUKo0V4+ZKFGtZ9vKj4TGpkA9G6sEsrXpW9fog19qcAsjRmj9aorRMv9hdgMwPNSLDnJ3cUuzt7UHCZgz/0SetQ8Q7HrKeEXJqYvpI19luxcz6nbb/pYZr49AyyGIpr+Jr/m/oTFntOWZhYAonMY3OThB8wZI1e+fXPBPSuUaReOWq9R4kGA==; 5:iqyegM9x+RlzaqZ1uLY6OtS/WpeY5gvcN4oi5gA508vRicyYuZr0wqphfTZHXbp6Y9xMRnNQfGRoCeClCdoj5IDRByraJ6LTdQXIknKDf7vt2SvPZ112NX2vDUDhmBZihuUe8bxfmm0LrcAdPWH32P9qr5AxUrTW72dA63Kzgek=; 7:/2miQ9M9ykk4izWySF3ioeKmiOIVZsFBk8rEKPBnPyIcIlrZxdSOlGErvFB5e8ioUugRqQ257TyudxxACrHu0szW18Nd+v8yJiUOZibV6KDYm7gn6EIq3ZS7c6LXRMmo5/y89KD0XlF7kBpQBW/8uwJQ1TwoRsxTs3Fcbxxsrtj4g7b1hsqjGsMHa2Wj6usqlJV9D7XCbYHoSA8nEQpVhFtO7UDHF0EUXJvlrjri964vTLhYrHd6dPMS6l693/9O x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9182ea27-3b2e-4e64-44ec-08d5eb606cd0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB0933; x-ms-traffictypediagnostic: DM5PR2101MB0933: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(2018427008)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0933; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0933; x-forefront-prvs: 073515755F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(136003)(396003)(366004)(39860400002)(346002)(376002)(199004)(189003)(2906002)(97736004)(86362001)(68736007)(33656002)(8936002)(2351001)(8676002)(1730700003)(81156014)(81166006)(86612001)(2900100001)(106356001)(105586002)(2501003)(22452003)(5250100002)(316002)(8990500004)(6116002)(9686003)(46003)(102836004)(186003)(5640700003)(55016002)(6436002)(99286004)(10290500003)(6916009)(10090500001)(256004)(6506007)(6306002)(478600001)(14454004)(486006)(53936002)(5660300001)(476003)(7696005)(25786009)(7736002)(305945005)(74316002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0933; H:DM5PR2101MB0805.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: TvQv2bur47h6uHzJkseiQnmYJrIX2yV2k/86zCRlsASKkKsVryOcV1SDls7RCKWJBn6eiNM3hkxce3lCh0113pJBaWB4obKAKsbeydYUBM/5ZhJfjL2ODkIDzv79h+j8VIxfYrYFHRs1Cl08exvfIBuHPU2Yyhw7wK+wGxlYXsUoOwQPNnd57Xn4N9wQhIJQOi6Qx1TeovhDfvC2h/dcAiLYjMRDTrx2WbX72VP2jOr2aaAurX0pZbq/vI82KmioxkRXfjvNcLctszQt6DO/LELhoO5IWZQUVqCT28AMX+YSYhR178N31Jb/KBAdy8yQFnrFpbt3H8X6n5OMYZ7rSXtoAg8UYaxVlzHhQFvsNbI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9182ea27-3b2e-4e64-44ec-08d5eb606cd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 21:09:31.5838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0933 Archived-At: Subject: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:09:44 -0000 Just to put to the list the question I raised in the meeting: RFC 6690 section 3.1 allows rt values to be either: a) IANA-assigned, OR b) URIs (e.g., "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature"=20 in the example in the RFC) The presentation today only mentioned (a). The question was: how would you handle (b)? Dave From nobody Mon Jul 16 14:31:03 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B700513127F for ; Mon, 16 Jul 2018 14:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNDc8S1l6ppI for ; Mon, 16 Jul 2018 14:30:49 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 51392131236 for ; Mon, 16 Jul 2018 14:30:49 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id y10-v6so24429338ioa.10 for ; Mon, 16 Jul 2018 14:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zZFP8uzI9KQBaPCERqDbcyBsq91zKxIgrBCxl+kNNY0=; b=aR5u6uNnOPbxFfk5sGP8tLt3d+GMmeP56+HYAHRhFT4+uX3jKMi4nkp0kiB4HIUDdA MlvDkoQ4R6aTpGXP0TcnHDhnF55vHXLENXed8X3uNlqmdeizNAUMjPkKtbr2yLLW96eq ThBg9A9LzpMa4N0CZvRz50Sc7O50JopJrz+uXqYvqMVQoYDSj8e0efgdlh6gPRLLRUwl BXSi0AZlvUe0E7qhIZZkwsfzlkhx+RTJVWnwy2W8us9JpOXCIDpjeehRvH/wQE9+XYCt CUec4WnVEQAA30B61Qn15J4kfSyg2bZBYj+k1dGIYpWrI4wbCzIEMhfsAQff7sQeKLkO cWyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zZFP8uzI9KQBaPCERqDbcyBsq91zKxIgrBCxl+kNNY0=; b=M7jxWCZg4HOISyePa4a+y9sopk/QJdp1MrSzyAG9sgEDFUfGqc16CuAboTJSsEcPIF zoWYqFX0F8uQRJjzyigtwI+WsrjggWpZQWz372ebFsGfW11bBNvoScuYT1+D/rBZ/EAq iNa7KLAOtticAac6khjh3t2CU3zHk04+LwOEZG3ycXjQXnmdfQjFftPmdl8c31E+PwiK QAfo2W/DHmc6HC7SK4K4DtzR+CW8w7P0ofui1UQ8EvasBqS6+LMqaUQxI2yJo6AAG0+W 9RSid3IWgHzpF6++8PVZf3g331obN+xtVSRp/72ON3uEmFP996ZF8+hYuKtRQFnk9WRG Y2rw== X-Gm-Message-State: AOUpUlG17LMvRRlSMXpVa18bzgjxU95HyvYuKpy8O8cLcUoZnHnHy8vI 7dlUHPBr5tSuRsfS0CSezWvcEP45 X-Google-Smtp-Source: AAOMgpdro01P2Y6MfYDavOqG4jisVCeRSCCy/sybULLLIpXKPGbmnTglQaWYd1027B9eZqKGgUGTwA== X-Received: by 2002:a6b:9303:: with SMTP id v3-v6mr7192891iod.264.1531776648705; Mon, 16 Jul 2018 14:30:48 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:e9f7:c25f:62ef:1280? ([2001:67c:370:128:e9f7:c25f:62ef:1280]) by smtp.gmail.com with ESMTPSA id z195-v6sm3713602ioe.38.2018.07.16.14.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 14:30:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: Date: Mon, 16 Jul 2018 17:30:46 -0400 Cc: "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> References: To: Dave Thaler X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:31:01 -0000 Or the URN form may also be used, e.g. "rt=3Durn:myorg:sensor:temperature"= which can enable an organization to manage its own namespace > On Jul 16, 2018, at 5:09 PM, Dave Thaler = wrote: >=20 > Just to put to the list the question I raised in the meeting: > RFC 6690 section 3.1 allows rt values to be either: > a) IANA-assigned, OR > b) URIs (e.g., "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature"=20 > in the example in the RFC) >=20 > The presentation today only mentioned (a). > The question was: how would you handle (b)? >=20 > Dave >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 17 11:05:57 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69720130F13; Tue, 17 Jul 2018 11:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoYFsIxP90wd; Tue, 17 Jul 2018 11:05:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC3B130E4C; Tue, 17 Jul 2018 11:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6694; q=dns/txt; s=iport; t=1531850752; x=1533060352; h=from:to:cc:subject:date:message-id:mime-version; bh=fCju/WNsL1xelHetzRqGZLKYS3yAn9zVZao+kUU6z3Q=; b=YA7wvqYsbvGrAiLWeIPmmzAQdQR4Ovr6NFNeLCjsroTLfTSgKC9619B9 5EYInnQFwWCnItjSrZKCQiCOIImunsNbh/lbu6b7m6LX78b2kJ83WroeZ Ch65k9qbZx/91pVAUNkVe9YvrqiUb/rBjvOLjTQPUzSwZ4AygGaBiu4Gp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAgA4L05b/4cNJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJTdmN/MoNzlECSNocJC4RsGYJZITcVAQIBAQIBAQJtHQuFYFY?= =?us-ascii?q?SAUoCBDAnBA6DJQGBG2SqdIEuhFuFTokCgVc/gTiKZjGCJAKRcYdrCQKPJY1?= =?us-ascii?q?lkW0CERSBJDMiJoEscBU7KgGCP4IkF44XjRWBGgEB?= X-IronPort-AV: E=Sophos;i="5.51,366,1526342400"; d="scan'208,217";a="144519988" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 18:05:52 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w6HI5pi6022797 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2018 18:05:52 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Jul 2018 13:05:51 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Tue, 17 Jul 2018 13:05:51 -0500 From: "Reshad Rahman (rrahman)" To: "draft-ietf-core-sid@ietf.org" CC: "core@ietf.org" Thread-Topic: Questions/comments on draft-ietf-core-sid-04 Thread-Index: AQHUHfjMVEMw08sPw0STjWF2kfjwDA== Date: Tue, 17 Jul 2018 18:05:51 +0000 Message-ID: <510E8389-232B-4AFC-B359-CB9330C15280@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.55] Content-Type: multipart/alternative; boundary="_000_510E8389232B4AFCB359CB9330C15280ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [core] Questions/comments on draft-ietf-core-sid-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 18:05:55 -0000 --_000_510E8389232B4AFCB359CB9330C15280ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZvciDigJxsaXN0IGl0ZW1z4oCdOg0KDQogIDEuICBJdCBpcyBhIGxpc3Qgd2l0aCBj b21wb3NpdGUga2V5IG5hbWVzcGFjZSBhbmQgaWRlbnRpZmllciwgd2h5IG5vdCBoYXZlIDIgbGV2 ZWxzIGluc3RlYWQsIGkuZS4gYSBuYW1lc3BhY2UgbGlzdCAoa2V5ZWQgb24gbmFtZXNwYWNlKSBh bmQgZWFjaCBuYW1lc3BhY2UgaGFzIGEgbGlzdCBvZiBpZGVudGlmaWVycyAoa2V5ZWQgb24gaWRl bnRpZmllcikNCiAgMi4gIFdvdWxkIGl0IGJlIHVzZWZ1bCB0byBoYXZlIGFub3RoZXIga2V5IGJh c2VkIG9uIHNpZD8NCg0KUmVnYXJkcywNClJlc2hhZC4NCg== --_000_510E8389232B4AFCB359CB9330C15280ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <25E05C5682641942AD12B745A695C4BA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjE5OTU1MjQwODg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4NzYzNTE0MjYgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rm9yIOKAnGxpc3QgaXRlbXPigJ06PG86 cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEi IHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkl0IGlzIGEgbGlzdCB3aXRoIGNvbXBvc2l0ZSBrZXkgbmFtZXNw YWNlIGFuZCBpZGVudGlmaWVyLCB3aHkgbm90IGhhdmUgMiBsZXZlbHMgaW5zdGVhZCwgaS5lLiBh IG5hbWVzcGFjZSBsaXN0IChrZXllZCBvbiBuYW1lc3BhY2UpIGFuZA0KIGVhY2ggbmFtZXNwYWNl IGhhcyBhIGxpc3Qgb2YgaWRlbnRpZmllcnMgKGtleWVkIG9uIGlkZW50aWZpZXIpPG86cD48L286 cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+V291bGQgaXQgYmUgdXNlZnVsIHRvIGhhdmUgYW5vdGhlciBr ZXkgYmFzZWQgb24gc2lkPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_510E8389232B4AFCB359CB9330C15280ciscocom_-- From nobody Tue Jul 17 11:35:42 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2D130FAE; Tue, 17 Jul 2018 11:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX_iC_8hMXgt; Tue, 17 Jul 2018 11:35:36 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D9613107D; Tue, 17 Jul 2018 11:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=00k1JpGa06mD6SPqUlz/YyKkrc5BWqSOKQXSZgku42c=; b=eCUbz/Z8gGWVKRBS+9NWWinP3xG/hyYUAgV9X85p4i3WYQliv4gZhP8tXHc7vzhpohdzyN31WAmo+5SEAVOhihxlDSm9iYazchg8DX9eFgLjdign2rQzuLlYR4X47MfLWhCEJ9r2gD+8FPteEpty2dSoOftR2+0vKpnizowIJbA= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2778.namprd06.prod.outlook.com (10.175.107.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.20; Tue, 17 Jul 2018 18:35:33 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300%5]) with mapi id 15.20.0952.021; Tue, 17 Jul 2018 18:35:33 +0000 From: Michel Veillette To: "Reshad Rahman (rrahman)" , "draft-ietf-core-sid@ietf.org" CC: "core@ietf.org" Thread-Topic: Questions/comments on draft-ietf-core-sid-04 Thread-Index: AQHUHfjMVEMw08sPw0STjWF2kfjwDKSTtudg Date: Tue, 17 Jul 2018 18:35:33 +0000 Message-ID: References: <510E8389-232B-4AFC-B359-CB9330C15280@cisco.com> In-Reply-To: <510E8389-232B-4AFC-B359-CB9330C15280@cisco.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [31.133.142.43] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB2778; 7:xN+gD7x0wWVikJYl3rluS28wv6DguCK+lGGipcb63Dfb8H4Xs6t71XSXevPU1fWNQGyOi2Mhq+x2eHPH4QaK0ol8ZioK+iesIS0XEX24/9DYs+D8GxbLzujrw5aeyUsKZVDQIBw4sKUppL4JX/AkYxddwGxTtgyQ9DlrGxbKx9fJfwfUupNn6V0eTKvdVJgI+RsXyTQLU7y2hAd5upqi8EPBaQFAzEkG3sRYPjFDaKbBGkOKRuPOJcGvD1I3Zwre x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 56c058e8-75b7-4050-caf1-08d5ec1414e7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2778; x-ms-traffictypediagnostic: DM5PR06MB2778: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB2778; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2778; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(366004)(396003)(39850400004)(189003)(199004)(102836004)(8936002)(26005)(5660300001)(68736007)(7736002)(6306002)(76176011)(9326002)(4326008)(54896002)(33656002)(6506007)(53546011)(2906002)(478600001)(72206003)(97736004)(8676002)(186003)(106356001)(105586002)(81166006)(81156014)(6246003)(446003)(11346002)(486006)(476003)(14454004)(2900100001)(14444005)(25786009)(7696005)(6436002)(6116002)(74316002)(53936002)(790700001)(110136005)(316002)(55016002)(66066001)(256004)(2501003)(3846002)(9686003)(99286004)(229853002)(5250100002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2778; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5l+ceF5f+J7Ivbk1eL/XbgMrO/MFnSvkjb6sbf87ju+pq6tAh/S4wL9FljlBpU5m7bImorAre+fAoy2JY/xGQ8pMph8a+D2mqxrUAR3392RWyszWQ+LDMvrT2IWJ7eLnWV6xagPqLPUU3zHMbfq1qqtXCXXnUnTBDU0bShS4zlC8caLSyoeg3g0SIbMhgtW+T9G2+BcUBk+LYKdY1Zb2Fxa7wmwILANa5JV5Uq8NgLJ4ONbIVNv4YDaRkFZWwCRSIfPA4dtT6dfp8sqYu8GlhGhdtP2jCa0NLqViXU7uzCcVkEfEhwJ+CXL87KnB+8UfcowIB+dDyRA/vReiF7zBMeimYO616sOlvp9JP87w5Xg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR06MB2777CEBF0002C7BA8E1485A29A5C0DM5PR06MB2777namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56c058e8-75b7-4050-caf1-08d5ec1414e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 18:35:33.5788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2778 Archived-At: Subject: Re: [core] Questions/comments on draft-ietf-core-sid-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 18:35:41 -0000 --_000_DM5PR06MB2777CEBF0002C7BA8E1485A29A5C0DM5PR06MB2777namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmVzaGFkDQoNCkFib3V0ICJ3aHkgbm90IGhhdmUgMiBsZXZlbHMgaW5zdGVhZCINCg0KVGhl IGN1cnJlbnQgc2luZ2xlIGxpc3Qgc29sdXRpb24gaGFzIGJlZW4gc2VsZWN0ZWQgZm9yIGl0cyBz aW1wbGljaXR5IHRvIGltcGxlbWVudCB0aGUgc2lwLnB5IHB5YW5nIHBsdWdpbi4NClRoZSBzaXpl IG9mIHRoaXMgbW9kdWxlIHdhcyBub3QgYSBjb25jZXJuIHNpbmNlIHdlIGhhZCBubyBpbnRlbnRz IHRvIGltcGxlbWVudCB0aGlzIG1vZHVsZSBpbiB0aGUgY29uc3RyYWluZWQgZGV2aWNlIGl0c2Vs Zi4NCid5YW5nLWRhdGEnIG1pZ2h0IGJlIHVzZWQgaW4gdGhlIG5leHQgdmVyc2lvbiB0byBjbGFy aWZ5IHRoaXMgcG9pbnQuDQoNCkFib3V0ICJXb3VsZCBpdCBiZSB1c2VmdWwgdG8gaGF2ZSBhbm90 aGVyIGtleSBiYXNlZCBvbiBzaWQiLg0KDQpVbmxlc3MgSSdtIHdyb25nLCBZQU5HIGFsbG93IGEg c2luZ2xlICdrZXknIHN0YXRlbWVudCBwZXIgbGlzdC4NCkhvd2V2ZXIsIGEgJ3VuaXF1ZScgc3Rh dGVtZW50IGNhbiBiZSBhZGRlZCB0byB2ZXJpZnkgdGhlIHVuaXF1ZW5lc3Mgb2YgdGhpcyBsZWFm Lg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZyb206IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIFtt YWlsdG86cnJhaG1hbkBjaXNjby5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDI6 MDYgUE0NClRvOiBkcmFmdC1pZXRmLWNvcmUtc2lkQGlldGYub3JnDQpDYzogY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUXVlc3Rpb25zL2NvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY29yZS1zaWQtMDQN Cg0KSGksDQoNCkZvciDigJxsaXN0IGl0ZW1z4oCdOg0KDQogIDEuICBJdCBpcyBhIGxpc3Qgd2l0 aCBjb21wb3NpdGUga2V5IG5hbWVzcGFjZSBhbmQgaWRlbnRpZmllciwgd2h5IG5vdCBoYXZlIDIg bGV2ZWxzIGluc3RlYWQsIGkuZS4gYSBuYW1lc3BhY2UgbGlzdCAoa2V5ZWQgb24gbmFtZXNwYWNl KSBhbmQgZWFjaCBuYW1lc3BhY2UgaGFzIGEgbGlzdCBvZiBpZGVudGlmaWVycyAoa2V5ZWQgb24g aWRlbnRpZmllcikNCiAgMi4gIFdvdWxkIGl0IGJlIHVzZWZ1bCB0byBoYXZlIGFub3RoZXIga2V5 IGJhc2VkIG9uIHNpZD8NCg0KUmVnYXJkcywNClJlc2hhZC4NCg== --_000_DM5PR06MB2777CEBF0002C7BA8E1485A29A5C0DM5PR06MB2777namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdl aWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDU4NDczNjQwOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo3NzAzNjU2NTI7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTk5 NTUyNDA4ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTg3NjM1MTQyNiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkgPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5SZXNoYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkFib3V0ICZxdW90O3doeSBub3QgaGF2ZSAyIGxldmVscyBpbnN0ZWFkJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgY3VycmVu dCBzaW5nbGUgbGlzdCBzb2x1dGlvbiBoYXMgYmVlbiBzZWxlY3RlZCBmb3IgaXRzIHNpbXBsaWNp dHkgdG8gaW1wbGVtZW50IHRoZSBzaXAucHkgcHlhbmcgcGx1Z2luLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5UaGUgc2l6ZSBvZiB0aGlzIG1vZHVsZSB3YXMgbm90IGEgY29uY2VybiBzaW5jZSB3ZSBoYWQg bm8gaW50ZW50cyB0byBpbXBsZW1lbnQgdGhpcyBtb2R1bGUgaW4gdGhlIGNvbnN0cmFpbmVkIGRl dmljZSBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPid5YW5nLWRhdGEnIG1pZ2h0IGJlIHVzZWQg aW4gdGhlIG5leHQgdmVyc2lvbiB0byBjbGFyaWZ5IHRoaXMgcG9pbnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BYm91dCAmcXVvdDtXb3VsZCBpdCBiZSB1c2Vm dWwgdG8gaGF2ZSBhbm90aGVyIGtleSBiYXNlZCBvbiBzaWQmcXVvdDsuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Vbmxlc3MgSSdtIHdyb25nLCBZQU5HIGFsbG93 IGEgc2luZ2xlICdrZXknIHN0YXRlbWVudCBwZXIgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SG93 ZXZlciwgYSAndW5pcXVlJyBzdGF0ZW1lbnQgY2FuIGJlIGFkZGVkIHRvIHZlcmlmeSB0aGUgdW5p cXVlbmVzcyBvZiB0aGlzIGxlYWYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NaWNoZWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4gUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgW21haWx0bzpycmFobWFuQGNpc2Nv LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDI6MDYgUE08 YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtY29yZS1zaWRAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8 L2I+IGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUXVlc3Rpb25zL2NvbW1lbnRz IG9uIGRyYWZ0LWlldGYtY29yZS1zaWQtMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gb3Ig4oCcbGlzdCBpdGVtc+KA nTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFy dD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omwx IGxldmVsMSBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SXQgaXMgYSBsaXN0 IHdpdGggY29tcG9zaXRlIGtleSBuYW1lc3BhY2UgYW5kIGlkZW50aWZpZXIsIHdoeSBub3QgaGF2 ZSAyIGxldmVscyBpbnN0ZWFkLCBpLmUuIGEgbmFtZXNwYWNlIGxpc3QgKGtleWVkIG9uIG5hbWVz cGFjZSkgYW5kIGVhY2ggbmFtZXNwYWNlIGhhcyBhIGxpc3Qgb2YgaWRlbnRpZmllcnMNCiAoa2V5 ZWQgb24gaWRlbnRpZmllcik8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5Xb3VsZCBpdCBiZSB1c2VmdWwgdG8gaGF2ZSBhbm90aGVyIGtleSBiYXNlZCBv biBzaWQ/PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR06MB2777CEBF0002C7BA8E1485A29A5C0DM5PR06MB2777namp_-- From nobody Tue Jul 17 11:58:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC58F131031; Tue, 17 Jul 2018 11:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPwQT4LHWOFc; Tue, 17 Jul 2018 11:58:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB81F130FF6; Tue, 17 Jul 2018 11:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16112; q=dns/txt; s=iport; t=1531853884; x=1533063484; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aOj/dkaUUxWAuwIegc1bHv3a/eYKkTPKt7I6gqOj5GM=; b=A6ZnVzffcPhdODmSzzet2W642EJOBTC/ygV+CBCia7hlIrhv2zLZpGNs GZ5EtbMcPQlPIBIvwZXjqMjwS89CMeoAdWb/wDHuGV1rPO+Nj+WezBZ20 GIE4sgyxxltTbWAUG5wHsR7ZErQJCkiGZDXvVO88GE+kNhBOhV/oNA4TI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQADO05b/5BdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdmN/KAqDc5RBggyQKoUPgXoLG4RRAheCWSE2FgECAQE?= =?us-ascii?q?CAQECbRwMhTYBAQEEI1YQAgEIEQMBAQEoAwICAjAUCQgCBAENBRuDBQGBG2S?= =?us-ascii?q?rMoEuiiiJAoFXP4E4gmqFGxYIgkMxgiQCiFGJIIdrCQKGCIkdjWWRbQIRFIE?= =?us-ascii?q?kJAEwJoEscBU7KgGCPgmCHBeJKoRtb4wmgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,366,1526342400"; d="scan'208,217";a="207139964" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 18:58:03 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w6HIw3P3006672 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2018 18:58:03 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Jul 2018 13:58:03 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Tue, 17 Jul 2018 13:58:03 -0500 From: "Reshad Rahman (rrahman)" To: Michel Veillette , "draft-ietf-core-sid@ietf.org" CC: "core@ietf.org" Thread-Topic: Questions/comments on draft-ietf-core-sid-04 Thread-Index: AQHUHfjMVEMw08sPw0STjWF2kfjwDKSTtudggAAeFwA= Date: Tue, 17 Jul 2018 18:58:03 +0000 Message-ID: <319BA6CD-D03B-4BE2-B337-24C3B4C6DE9D@cisco.com> References: <510E8389-232B-4AFC-B359-CB9330C15280@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.55] Content-Type: multipart/alternative; boundary="_000_319BA6CDD03B4BE2B33724C3B4C6DE9Dciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Questions/comments on draft-ietf-core-sid-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 18:58:27 -0000 --_000_319BA6CDD03B4BE2B33724C3B4C6DE9Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGVsLA0KDQpTb3JyeSB5b3UgYXJlIHJpZ2h0LCBpdOKAmXMgMSBrZXkgcGVyIGxpc3Qu IEFkZGluZyB1bmlxdWUgd291bGQgYmUgZ29vZC4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0KRnJv bTogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KRGF0 ZTogVHVlc2RheSwgSnVseSAxNywgMjAxOCBhdCAyOjM1IFBNDQpUbzogIlJlc2hhZCBSYWhtYW4g KHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+LCAiZHJhZnQtaWV0Zi1jb3JlLXNpZEBpZXRm Lm9yZyIgPGRyYWZ0LWlldGYtY29yZS1zaWRAaWV0Zi5vcmc+DQpDYzogImNvcmVAaWV0Zi5vcmci IDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFF1ZXN0aW9ucy9jb21tZW50cyBvbiBkcmFm dC1pZXRmLWNvcmUtc2lkLTA0DQoNCkhpIFJlc2hhZA0KDQpBYm91dCAid2h5IG5vdCBoYXZlIDIg bGV2ZWxzIGluc3RlYWQiDQoNClRoZSBjdXJyZW50IHNpbmdsZSBsaXN0IHNvbHV0aW9uIGhhcyBi ZWVuIHNlbGVjdGVkIGZvciBpdHMgc2ltcGxpY2l0eSB0byBpbXBsZW1lbnQgdGhlIHNpcC5weSBw eWFuZyBwbHVnaW4uDQpUaGUgc2l6ZSBvZiB0aGlzIG1vZHVsZSB3YXMgbm90IGEgY29uY2VybiBz aW5jZSB3ZSBoYWQgbm8gaW50ZW50cyB0byBpbXBsZW1lbnQgdGhpcyBtb2R1bGUgaW4gdGhlIGNv bnN0cmFpbmVkIGRldmljZSBpdHNlbGYuDQoneWFuZy1kYXRhJyBtaWdodCBiZSB1c2VkIGluIHRo ZSBuZXh0IHZlcnNpb24gdG8gY2xhcmlmeSB0aGlzIHBvaW50Lg0KDQpBYm91dCAiV291bGQgaXQg YmUgdXNlZnVsIHRvIGhhdmUgYW5vdGhlciBrZXkgYmFzZWQgb24gc2lkIi4NCg0KVW5sZXNzIEkn bSB3cm9uZywgWUFORyBhbGxvdyBhIHNpbmdsZSAna2V5JyBzdGF0ZW1lbnQgcGVyIGxpc3QuDQpI b3dldmVyLCBhICd1bmlxdWUnIHN0YXRlbWVudCBjYW4gYmUgYWRkZWQgdG8gdmVyaWZ5IHRoZSB1 bmlxdWVuZXNzIG9mIHRoaXMgbGVhZi4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQpGcm9tOiBSZXNo YWQgUmFobWFuIChycmFobWFuKSBbbWFpbHRvOnJyYWhtYW5AY2lzY28uY29tXQ0KU2VudDogVHVl c2RheSwgSnVseSAxNywgMjAxOCAyOjA2IFBNDQpUbzogZHJhZnQtaWV0Zi1jb3JlLXNpZEBpZXRm Lm9yZw0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFF1ZXN0aW9ucy9jb21tZW50cyBvbiBk cmFmdC1pZXRmLWNvcmUtc2lkLTA0DQoNCkhpLA0KDQpGb3Ig4oCcbGlzdCBpdGVtc+KAnToNCg0K ICAxLiAgSXQgaXMgYSBsaXN0IHdpdGggY29tcG9zaXRlIGtleSBuYW1lc3BhY2UgYW5kIGlkZW50 aWZpZXIsIHdoeSBub3QgaGF2ZSAyIGxldmVscyBpbnN0ZWFkLCBpLmUuIGEgbmFtZXNwYWNlIGxp c3QgKGtleWVkIG9uIG5hbWVzcGFjZSkgYW5kIGVhY2ggbmFtZXNwYWNlIGhhcyBhIGxpc3Qgb2Yg aWRlbnRpZmllcnMgKGtleWVkIG9uIGlkZW50aWZpZXIpDQogIDIuICBXb3VsZCBpdCBiZSB1c2Vm dWwgdG8gaGF2ZSBhbm90aGVyIGtleSBiYXNlZCBvbiBzaWQ/DQoNClJlZ2FyZHMsDQpSZXNoYWQu DQo= --_000_319BA6CDD03B4BE2B33724C3B4C6DE9Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo4MzM2NDkzNTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEzMzcwNTI5Mjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTk1NTI0MDg4Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODc2MzUxNDI2IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1i b3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5IaSBNaWNoZWwsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5T b3JyeSB5b3UgYXJlIHJpZ2h0LCBpdOKAmXMgMSBrZXkgcGVyIGxpc3QuIEFkZGluZyB1bmlxdWUg d291bGQgYmUgZ29vZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPlJlc2hhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1pY2hlbCBWZWlsbGV0dGUgJmx0O01pY2hlbC5WZWls bGV0dGVAdHJpbGxpYW50LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSnVseSAx NywgMjAxOCBhdCAyOjM1IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSZXNoYWQgUmFobWFuIChy cmFobWFuKSZxdW90OyAmbHQ7cnJhaG1hbkBjaXNjby5jb20mZ3Q7LCAmcXVvdDtkcmFmdC1pZXRm LWNvcmUtc2lkQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWNvcmUtc2lkQGlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7Y29yZUBpZXRmLm9yZyZxdW90OyAmbHQ7Y29yZUBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFF1ZXN0aW9ucy9jb21tZW50cyBv biBkcmFmdC1pZXRmLWNvcmUtc2lkLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5IaSBSZXNoYWQ8L3NwYW4+PG86cD48L286cD48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWJvdXQgJnF1b3Q7 d2h5IG5vdCBoYXZlIDIgbGV2ZWxzIGluc3RlYWQmcXVvdDs8L3NwYW4+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VGhlIGN1cnJlbnQgc2luZ2xlIGxpc3Qgc29sdXRpb24gaGFzIGJlZW4gc2Vs ZWN0ZWQgZm9yIGl0cyBzaW1wbGljaXR5IHRvIGltcGxlbWVudCB0aGUgc2lwLnB5IHB5YW5nIHBs dWdpbi48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBzaXplIG9mIHRoaXMgbW9kdWxlIHdhcyBub3QgYSBjb25j ZXJuIHNpbmNlIHdlIGhhZCBubyBpbnRlbnRzIHRvIGltcGxlbWVudCB0aGlzIG1vZHVsZSBpbiB0 aGUgY29uc3RyYWluZWQgZGV2aWNlIGl0c2VsZi48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPid5YW5nLWRhdGEnIG1p Z2h0IGJlIHVzZWQgaW4gdGhlIG5leHQgdmVyc2lvbiB0byBjbGFyaWZ5IHRoaXMgcG9pbnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFib3V0ICZxdW90O1dvdWxkIGl0IGJlIHVz ZWZ1bCB0byBoYXZlIGFub3RoZXIga2V5IGJhc2VkIG9uIHNpZCZxdW90Oy48L3NwYW4+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VW5sZXNzIEknbSB3cm9uZywgWUFORyBhbGxvdyBhIHNpbmds ZSAna2V5JyBzdGF0ZW1lbnQgcGVyIGxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ib3dldmVyLCBhICd1bmlx dWUnIHN0YXRlbWVudCBjYW4gYmUgYWRkZWQgdG8gdmVyaWZ5IHRoZSB1bmlxdWVuZXNzIG9mIHRo aXMgbGVhZi48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPk1pY2hlbDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIFttYWlsdG86cnJhaG1hbkBjaXNj by5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAxOCAyOjA2IFBN PGJyPg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLWNvcmUtc2lkQGlldGYub3JnPGJyPg0KPGI+Q2M6 PC9iPiBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFF1ZXN0aW9ucy9jb21tZW50 cyBvbiBkcmFmdC1pZXRmLWNvcmUtc2lkLTA0PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPC9zcGFuPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkZvciDigJxsaXN0IGl0ZW1z4oCdOjwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8z Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SXQgaXMgYSBsaXN0IHdpdGggY29tcG9zaXRlIGtleSBuYW1l c3BhY2UgYW5kIGlkZW50aWZpZXIsIHdoeSBub3QgaGF2ZSAyIGxldmVscyBpbnN0ZWFkLCBpLmUu IGEgbmFtZXNwYWNlIGxpc3QgKGtleWVkIG9uIG5hbWVzcGFjZSkNCiBhbmQgZWFjaCBuYW1lc3Bh Y2UgaGFzIGEgbGlzdCBvZiBpZGVudGlmaWVycyAoa2V5ZWQgb24gaWRlbnRpZmllcik8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDps MSBsZXZlbDEgbGZvMyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldvdWxkIGl0IGJlIHVzZWZ1bCB0byBo YXZlIGFub3RoZXIga2V5IGJhc2VkIG9uIHNpZD88L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9v bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZXNoYWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_319BA6CDD03B4BE2B33724C3B4C6DE9Dciscocom_-- From nobody Tue Jul 17 13:31:51 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B7E131064 for ; Tue, 17 Jul 2018 13:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98Ww5HjiOoP7 for ; Tue, 17 Jul 2018 13:31:38 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 2D70013105D for ; Tue, 17 Jul 2018 13:31:38 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id l25-v6so2125396ioh.12 for ; Tue, 17 Jul 2018 13:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=YJI0N/cmWfRKyK12vqto4JP9vwAR0G9E1zuVOnTpxQ0=; b=SQS5ZEwhyhSYvvH/PbgP37462rycfiipDN9EJvWPfnaMEkXsgfAJewKPYYqyDLb5Jv 1mbw5d21tWHXLfdVZ/92WREdCYoLGwM2CzdMV/Ct5E8TLtsb4Q1D1t9aDv56uRHJuOBf i4BRtocRh11yOHqeJkOTSq2bXEBp2T3bprizg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=YJI0N/cmWfRKyK12vqto4JP9vwAR0G9E1zuVOnTpxQ0=; b=m+8UAkJr5ozUA1SYGL1BDpF+k2F6BklBz94/uJf39eG1ir498EWF1WHw2JrJhdYgWb pjma4PAUsIn49tJ5ZZ5ul4Hz0ijV7CTgV808bSEY4NwpD9eRto5WHHSPuyW9zkx4dhBV ISaw0I9WnMcN8YyJAAhpIb3Z/ZEvHwFz1U4w1ptJma5KHT/LjBoG0ZRtVRk41qIoH1/u XJ5fj7xzm69Hv5FLS8uMNoFfLyh6aP+fOb3r6JUKdekViHW1fvwiyhIh/bO23GCQ0VEk Eew5WUycLHUWR+OxArzR/ZD6dsTSgO55xMPPL6GqvJyoh8urjD69U+UReJxwCZGdoHo4 2ZSQ== X-Gm-Message-State: AOUpUlGfl3hC91XRtEn9WZg/1KyoEu9uwaE0/IxowhribbWXxJvfSPLf /niMcJTEKYlmcRH7/l02S7ZSwQ== X-Google-Smtp-Source: AA+uWPwEIon2K/Ct2JmyJArGOn/wRQUzjzSUDJYhqFh6/8oFJRVX5IGYjP55RmS/fFp8adn5L2ys+g== X-Received: by 2002:a6b:d611:: with SMTP id w17-v6mr2838375ioa.216.1531859497536; Tue, 17 Jul 2018 13:31:37 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id b205-v6sm233473itg.23.2018.07.17.13.31.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 13:31:36 -0700 (PDT) To: Michael Koster , Dave Thaler Cc: "core@ietf.org" References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 17 Jul 2018 14:31:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7owUHknHZPcB379uBXXQoSqbg8tzvpYad" Archived-At: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:31:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7owUHknHZPcB379uBXXQoSqbg8tzvpYad Content-Type: multipart/mixed; boundary="GQF1QCRLr5ccpD1AkZ5JLkKOHk2PPhcLH"; protected-headers="v1" From: Peter Saint-Andre To: Michael Koster , Dave Thaler Cc: "core@ietf.org" Message-ID: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> In-Reply-To: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> --GQF1QCRLr5ccpD1AkZ5JLkKOHk2PPhcLH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/16/18 3:30 PM, Michael Koster wrote: > Or the URN form may also be used, e.g. "rt=3Durn:myorg:sensor:temperatu= re" which can enable an organization to manage its own namespace Don't do that. You can't just create your own URN namespaces: https://tools.ietf.org/html/rfc8141#section-5 It's better to use URIs with the domain name of your organization, or use the urn:example namespace: https://tools.ietf.org/html/rfc6963 Peter --GQF1QCRLr5ccpD1AkZ5JLkKOHk2PPhcLH-- --7owUHknHZPcB379uBXXQoSqbg8tzvpYad Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltOUicACgkQZWGMGH9o FKl/2g//R1qG+xRo4F9xTbpd8ksHmZuY2dDsnuWxf06aEAo7OrEYtp/dvgcNslm/ /kIm91/ZZ5rtvkpoJX0+2O6+PuLOP1PW7hRPwV/gbqDfaguf1y2pgLtR2ZAyAoZu U+DkCB22JMFmihPMqE5pzA3OjG1klrCw+SdbtOBCRXCllxmUAi8KlX/Te9Ip+G9Q oJfBTa/f4B9rYshUOnC7Ig942QtqVRtLVIighio3Uw55/t40g2DjTbolzfTMbXRW 44AO3jekmV5xNC84VS6CFliPwbuI04Q9oNyR+Hq85WDlDm2bQudDxM1DR+n4sybP X8t4ggBzAqUWrklHer0ZEK7GT4mcDSrbiORWT+H1ehlNknshle5rf2k3Q9Peo4bM 2NAttdp8wb0mOAw/c4u8uM22/mOMAehPvuM0br2h7cWqssuHNt1RFXE7bgQTvsEH oGwNYHmHNDp9Ozxd0jzqp8aNsXcRqOCfq5cba9E6fUMl02nge+MKaBan4MjAF4Co XJyRCN4PgCIkS3HOTQ41HRRHnta1RD7PlSvvI6R3GKT6ijIPtK8jcN++9GA0Q0p3 hHEV2VCcP9Ci66SAIfaMGKD0vfQZjBk9ks5/zE44+J0FpKKmwErokIjqpeSTRdYX djEbz6CLmfrNGqxcFObgzdWiFbBmkNOv4+3CM3xj90zaFO2UW/0= =uMdz -----END PGP SIGNATURE----- --7owUHknHZPcB379uBXXQoSqbg8tzvpYad-- From nobody Tue Jul 17 13:55:49 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3A129C6B for ; Tue, 17 Jul 2018 13:55:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hvORqntFUo-h for ; Tue, 17 Jul 2018 13:55:30 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 A6718130DE2 for ; Tue, 17 Jul 2018 13:55:30 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id q19-v6so2191239ioh.11 for ; Tue, 17 Jul 2018 13:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f8vQu2tKpPDg5N3liZIY819kBgdxL2E0ZKZiAbkwn5k=; b=gZZa5cXe6y2ZHvqd5aGly3mlG2e2b53A2TzXBK5VNujA97YxLJXT487YQzupPmpAps vEkF0PBUjQZTJzfakLOEgfK3ZhZzWYC0X4KMYqlL+9Memb5Lsh1nPLY2I3yYvDHyGykk uwXIP1dsRDZpAORorfZj3F0ODzqAOlBUV6xFy102kzOfl6Zg1zUkLJ9KI/YIybxRvWKK 7dSuUypTaWOeyq3ArrD/gJUdHXsXbwE/3bdxrWMn0u6cFRfW/gLAlpYhVuqKv48vsFwy 48ek2ujMnyk30ZWZDmOM8GDQJFii6xy4dYvNfwM4RoWq0GCwqIFD/yOrGO5R/gZRYs1v XUUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f8vQu2tKpPDg5N3liZIY819kBgdxL2E0ZKZiAbkwn5k=; b=HNln95H4Mq+/uah8MwKiStBGUipi8S+L+ic5ImXX9sjEObkY/lAlLsSe8YXNSo7Dqo VOmX6vAapmwF3dkD2yiu5/rGJDRh5uz4ecGp/mSzlBIZpZm/JtA+A6xVno9rgisroTpN C62xlDRib3UYPkylQQ0FQUJ28C6dt0RNtI0dyOGgUMLOQHDAYvfjWAsUuTM9eFTfDQZx m7OzMS1HSekVIbOd3V4hQMoB9N7IKUjZZKizK5VlPWv1zQxkvHkeAmSTYlj7CakyC+cc ZXKQ1i2qOmbGADtX7HyRV6cJS35zDwDbeY8WjddEyzPwZtX8UQKL6k0q3C+filuixTnt k4aw== X-Gm-Message-State: AOUpUlEeURFmqQWxr7rVMvONPP4+kxnNsxrVYe4g6zE6tw1nwXB1mIfj /moWmI0BlZV+pUg7BW/c4/NRl/Ba X-Google-Smtp-Source: AA+uWPzdS7VaVPDsUbjP0xeaGkIXG2+VzcePGtlAaKbOSv4yZ3fEQgDh9pVUTPcBtnQQ+BhTBCr1DA== X-Received: by 2002:a6b:18c4:: with SMTP id 187-v6mr2793709ioy.192.1531860930086; Tue, 17 Jul 2018 13:55:30 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:f4d1:33bb:7e11:f80d? ([2001:67c:1232:144:f4d1:33bb:7e11:f80d]) by smtp.gmail.com with ESMTPSA id e21-v6sm900892iob.20.2018.07.17.13.55.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 13:55:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: Date: Tue, 17 Jul 2018 16:55:27 -0400 Cc: Dave Thaler , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:55:36 -0000 Yes obviously... My example assumes that one has a URN namespace.=20 Is that an unreasonabe assumption? Many of the organizations I work with have or plan to have URN = namespaces. Best regards, Michael > On Jul 17, 2018, at 4:31 PM, Peter Saint-Andre = wrote: >=20 > On 7/16/18 3:30 PM, Michael Koster wrote: >> Or the URN form may also be used, e.g. = "rt=3Durn:myorg:sensor:temperature" which can enable an organization to = manage its own namespace >=20 > Don't do that. You can't just create your own URN namespaces: >=20 > https://tools.ietf.org/html/rfc8141#section-5 >=20 > It's better to use URIs with the domain name of your organization, or > use the urn:example namespace: >=20 > https://tools.ietf.org/html/rfc6963 >=20 > Peter >=20 >=20 From nobody Tue Jul 17 14:04:27 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE44130DEB for ; Tue, 17 Jul 2018 14:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZm_PUIF91pg for ; Tue, 17 Jul 2018 14:04:22 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 0D2C2131028 for ; Tue, 17 Jul 2018 14:04:22 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l7-v6so2229763ioj.1 for ; Tue, 17 Jul 2018 14:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=HdoRhADjuYyO4U73lN1zzxDRJllJSSqYlvAdZOVxVCY=; b=a0pzxztvvELMLr6s7oifrFLmPrdBHITWlOI42aJwJyqKZCFGZexv8ZI6gPU+BBFbLq 32OM7pEhrNgEsnyUEwhnCrRyC6j9t7kHmUqb/kRVarlb79oVh1qJUuBl0iRmoWGlBQN2 w7FRvuio9dGJrHy2MDb6P5REYYJCrruugqOWc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=HdoRhADjuYyO4U73lN1zzxDRJllJSSqYlvAdZOVxVCY=; b=ZsCUNoETZx/55cpAKO36YKtZuIaWmtx8qZjAYidl2tR0TGeo17iTaINIkebxDani1O A+KxaIHI6XfioA/qVtuBFmxRlXW4s8UvZB1Twv/3V5HKNOmFd2ur7SjFCwfpAGK6K70U p9OtH5CJQ75kIP0qL9g4JvaAVq0HvL8vUgWQCcGpJDYDOjkuYZLzxE2jpaMs5lgpjEIM uSQAokUrnHfLJ3CvpdeSJcZmm5BVBje/lOQxvBbHG9YOokRVAzGP4RvkBdgVJfj/gzD7 QAK0BQb02nbRavjPxlEwSiWVlWckLoIXAH9kkCBx7MNJfq4zNjxeraj4+fGlTswTCQGM ZuWQ== X-Gm-Message-State: AOUpUlEqUFAFTRvBmSlkhATfgO0PADQL+wUO5vgSZrszM00YVxVIiWgY k2WJU0ia2sj2Cc7YTYrniyXIlqlZwik= X-Google-Smtp-Source: AAOMgpfEUWsaNxR3ZzxmdxQHcnlYSTeO7z6slRljltBB+7ll/U65NPqfmauBSVJWjpMPvjq2FzxCtg== X-Received: by 2002:a6b:e403:: with SMTP id u3-v6mr2760341iog.131.1531861461448; Tue, 17 Jul 2018 14:04:21 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id h75-v6sm960840ioh.50.2018.07.17.14.04.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 14:04:20 -0700 (PDT) To: Michael Koster Cc: Dave Thaler , "core@ietf.org" References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <56f4ed81-5f87-86d9-5acc-f7864a788f06@mozilla.com> Date: Tue, 17 Jul 2018 15:04:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J0AQWdTtKzeIGwTg8zxz3Gw1NXBDNQUx7" Archived-At: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:04:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J0AQWdTtKzeIGwTg8zxz3Gw1NXBDNQUx7 Content-Type: multipart/mixed; boundary="3mjpUwd6tFwH5wR9Z4qdeeTozSyyl5nMI"; protected-headers="v1" From: Peter Saint-Andre To: Michael Koster Cc: Dave Thaler , "core@ietf.org" Message-ID: <56f4ed81-5f87-86d9-5acc-f7864a788f06@mozilla.com> Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> In-Reply-To: --3mjpUwd6tFwH5wR9Z4qdeeTozSyyl5nMI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/17/18 2:55 PM, Michael Koster wrote: > Yes obviously... My example assumes that one has a URN namespace.=20 >=20 > Is that an unreasonabe assumption? Well, it depends on what kind of organizations we're talking about. When I worked at Cisco, I saw developers creating urn:cisco:foo URNs and you can't just mint your namespaces, so that was bad. > Many of the organizations I work with have or plan to have URN namespac= es. Excellent. Please point them to RFC 8141 for the updated definition of URNs and the updated registration process for URN namespaces... :-) https://tools.ietf.org/html/rfc8141 Peter (team lead, URN namespace expert review team) >=20 > Best regards, >=20 > Michael >=20 >> On Jul 17, 2018, at 4:31 PM, Peter Saint-Andre w= rote: >> >> On 7/16/18 3:30 PM, Michael Koster wrote: >>> Or the URN form may also be used, e.g. "rt=3Durn:myorg:sensor:tempera= ture" which can enable an organization to manage its own namespace >> >> Don't do that. You can't just create your own URN namespaces: >> >> https://tools.ietf.org/html/rfc8141#section-5 >> >> It's better to use URIs with the domain name of your organization, or >> use the urn:example namespace: >> >> https://tools.ietf.org/html/rfc6963 >> >> Peter >> >> >=20 --3mjpUwd6tFwH5wR9Z4qdeeTozSyyl5nMI-- --J0AQWdTtKzeIGwTg8zxz3Gw1NXBDNQUx7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltOWdMACgkQZWGMGH9o FKnBrxAAkKmAMIFMmCV/WrHMG2485KkjLT/GBgS6IFvvTUWBU+xW4Z3ZQ0lusSpu e3NZ5YXqrFc4HutkaQN/sdcHDHrVwsbpIlf0LRFQl9Xon3ub1WKTsxlhQ6U5x86j amX6fQyx9plaK52baQvg4MjVidY8ler9oGYoAUNn6cPRCkQCxdGUaLbxoQviyGZu ZK+sEiVRSx75oz9rUZiEVQpngM7E5FIf6ibA/vrHjeLxZ1thZjKTeXxKUtoNMkhn Onjqs1DZpbHb26201qicWklTcehnGTvN2yEcd1Jyktd3Sm8scG5xMJnwscnXFeoF AQFYiKP+xaXcTaBJMmXAGWVb7Iak+TnzYJCy730Y66iMpf8Jp9snF5FYLx4HPeCo pXe/R/Gdml72+qgv21puBiVH3tih9G7Q8j8s5e/3S3d8JgRvrOxxoz/q8gV+D6ij Mn1gIil69NK+/lPq9kINtif1Plv6oOxUcqy2827TPf3ypBueifOVCZ3tT+PyVAd+ cLvvuf57BIhFCga9Pq2/UVajfrX1qhO4ou9IKuZrsEZGp3+A77Y5CnS7wH5gMd5E STGleKzjvumuMwC89k4ulhsPN1jQj4puEzXU02UfyYisM76skZjxoGDsbcYUbsBV bd1RfVaFj5vp9gvn/QeG1l/II/OMGtvitOCJKW8mgJJ2GfzPe2U= =BGR+ -----END PGP SIGNATURE----- --J0AQWdTtKzeIGwTg8zxz3Gw1NXBDNQUx7-- From nobody Tue Jul 17 14:15:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB06130DEB; Tue, 17 Jul 2018 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 S6POHUksTVEQ; Tue, 17 Jul 2018 14:15:02 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 98C27129C6B; Tue, 17 Jul 2018 14:15:01 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p6-v6so2209404ljc.5; Tue, 17 Jul 2018 14:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=S1Ay7VHAREBtMaL9slmGhr2RB/zN+K1fPCO9OlRLWhM=; b=blhc0gJflfJ9Yaep0jCzrtruIUPR+LyOy8w6J5c0E9+q66jATOAcaxGSiGy8zJ/5kj cVizU4xZL88+qja3n2sJxtLSJ7mYbyj/NVwtq8VCA536hKt1InSKbd7hRJj839ZDyTxC LQSz7w4EYKiDFcHG1sglEieRY9iJXXiYlFikOGkLUo6nObVGD5+YqsQP5mof47bmvd5z NTT2hHldj66dskBkVGYHuIzfWrohivENEy3NyhX/idXU3L21ehIIYn8Rbok3wsB83c+C nbobBYR1NqMbqwwdmQ7ljAQO461kht2aIPiM3OAV88cmONq+yrq7PQ+Bls/hXRSXo+G2 mSLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=S1Ay7VHAREBtMaL9slmGhr2RB/zN+K1fPCO9OlRLWhM=; b=XUNIrFpE/Awq37/c3PAzw4IsPKEfXOPjwtFWU4UkLmG6gAJMwTGPeVGBvr5J/YQGCW 3Vsu1IzP3B8EZF9uMsE4l/5249/RKlOhqp+949EdVCFZdsL68uFHtplhUsMBzL2cPh0W U3tBTv2dWI3X2JlMFxYDNQ4KWLwZSpp/yQYzWLMtVkanS6BTbIiOHZjZsRNZZPYZJSGN BLusIJ44rhOv2fCG4oPIG2y3xreW0ybQNYEviXZMJQ67k5Q8EDu+jaDzv51F3hmHV7GL FLXfYZ1rYKDYY3psLbPxJRKE1nRLq37jmR1kJ1y2w3XfNmJqj3f8d7XADTLSikXdOQZf nASQ== X-Gm-Message-State: AOUpUlF5XJ83we0+F5YIt4GndbL+5CI+n7TCtH41p6N3J4ijkHLUgT7u VKy5xHZNMx+k3PVkrug4aTgJiUUTkf0yI0Zs8yXBsBpf X-Google-Smtp-Source: AAOMgpce/GsaACFL/lMv5xa3QnqocYmkUiFTrZPXavpSAyCCQ8Tpe00lYef551NcYd5YKh/A0iQ0F5iTmkZu0B9juWs= X-Received: by 2002:a2e:2ac3:: with SMTP id q186-v6mr2454264ljq.123.1531862099580; Tue, 17 Jul 2018 14:14:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:2bce:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 14:14:59 -0700 (PDT) From: Pascal Urien Date: Tue, 17 Jul 2018 23:14:59 +0200 Message-ID: To: core , core-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a5c9e0571387077" Archived-At: Subject: [core] Bockchain and IoT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:15:06 -0000 --0000000000004a5c9e0571387077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The today paradigm of IoT is oriented towards cloud environments managed in a way or another by a third trusted party. One benefit of the blockchain technology is that there is no third trusted party. In the Blockchain IoT paradigm objects forward data in signed transactions, what imply a relationship between a blockchain address and an object (managing a private key). The draft https://www.ietf.org/id/draft-urien-core-blockchain-transaction-protocol-00= .txt is a first tentative toward a =E2=80=9Cno third trusted party IoT architec= ture=E2=80=9D If some people are interested by this direction we can meet at the end of the core session on Thursday ? Draft summary. The goal of the blockchain transaction protocol for constraint nodes is to enable the generation of blockchain transactions by constraint nodes, according to the following principles : - transactions are triggered by Provisioning-Messages that include the needed blockchain parameters. - binary encoded transactions are returned in Transaction-Messages, which include sensors/actuators data. Constraint nodes, associated with blockchain addresses, compute the transaction signature. Pascal Urien --0000000000004a5c9e0571387077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The today par= adigm of IoT is oriented towards cloud environments managed in a way or another by a third trusted party.

One benefit o= f the blockchain technology is that there is no third trusted party.

In the Blockc= hain IoT paradigm objects forward data in signed transactions, what imply a relationship between a blockchain address and an object (managing a private key).

The draft=C2= =A0https://www.ietf.org/id/draft-urien-core-blockchain-tra= nsaction-protocol-00.txt =C2=A0is a first tentative toward a =E2=80=9Cn= o third trusted party IoT architecture=E2=80=9D

If some peopl= e are interested by this direction we can meet at the end of the core session on Thursday ?

Draft = =C2=A0summary.

The goal of t= he blockchain transaction protocol for constraint nodes =C2=A0=C2=A0is to enable the generation of blockchain transactions by constraint =C2=A0= nodes, according to the following principles :

=C2=A0<= /span>- transactions are triggered by Provisioning-Messages that include =C2= =A0the needed blockchain parameters.

- binary enco= ded transactions are returned in Transaction-Messages, =C2=A0which include sensors/actuators data. Constraint nodes, associated with blockchain addres= ses, compute the transaction signature.

Pascal Urien
--0000000000004a5c9e0571387077-- From nobody Tue Jul 17 16:21:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7238130E2E for ; Tue, 17 Jul 2018 16:21:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uFm-OBTrWuks for ; Tue, 17 Jul 2018 16:21:07 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 CF6B9130E4F for ; Tue, 17 Jul 2018 16:21:06 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id z19-v6so2488119ioh.4 for ; Tue, 17 Jul 2018 16:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=orGNYPfO7EPhznnw4HYYnzSAG8CrZTPuQHhH+0AxfoI=; b=gxvbrYTB59SSIOU/3eb/yM1RCwfyUGXR3bEn3j5Gp39BWxYt8gWjjJUqhQM7rjwDe+ kL67/Rco9q+FipxLJdOSCqq1N2H2k1Bx+w1iYiHi2r3nbQsZUUyS1jFVskr4pokBdT9O Y8oCal34EVDJF+yBijZS0lx8yg8/FvUZ/n/POUmG9fMNpF6eKiQ9wh6CnTe8IR4gOYGp kUQdgZs6AFys7rYRTP8tSkDM+OmKizPNzSRvNsGyAmvl5iPvxSwW6tzOzeA6sm3nVNAT 5BcRMYWr2nK/Ho/vmDJHJkVbYPUuOvI2MrGvm2/e2ulX4FH7N2Syz2nkZ0hZsydGHHqp QqHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=orGNYPfO7EPhznnw4HYYnzSAG8CrZTPuQHhH+0AxfoI=; b=gd2Jf3dsckL5Z5MbSbMS9WMu/X4ixurt2idtWNagt8C962ufcAvau3er0tqA4FJiaN CMd4J/abfI5GOF3LOaSA2BeYevp7mZdUilmMsAtwGR7NNUx6xTLHUByKGbem42+V8UN2 osUceV5BDq9dmL0S6CPwfCIKgdKYZGFK79EJaaNjULDcEjzvYKJVe79cHUDkOfAKpmAR 2xRTCfsjNVgyEmC8epdvo1inKbdmyfWrHqe+N3/VdQVnaehySmwzr+4PuLxWjKyb4C+C Wr5mP1xGv36bfj/5yC/GYabyVCJQMywgiGdhouk/cW3+38fo+NgVIXs0Fib+e9ghHR7j K3DA== X-Gm-Message-State: AOUpUlH3FFYE9EUD/HZC9miDsLxuJuatFv6HjGmsY4YZR2dgsjfK5Jcy 7RsiXKlBIKYu6NOiVP2XYuxAfvoA X-Google-Smtp-Source: AA+uWPzy7dqtO8lvL9ZZlagXBUGVpooBxu5ee8NERhPrhwUTTwDRV0ms14hGqvDR5CZQg1VrBhg12Q== X-Received: by 2002:a6b:7a05:: with SMTP id h5-v6mr3328657iom.238.1531869666195; Tue, 17 Jul 2018 16:21:06 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:f4d1:33bb:7e11:f80d? ([2001:67c:1232:144:f4d1:33bb:7e11:f80d]) by smtp.gmail.com with ESMTPSA id i70-v6sm1114635ioi.33.2018.07.17.16.21.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 16:21:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Koster In-Reply-To: <56f4ed81-5f87-86d9-5acc-f7864a788f06@mozilla.com> Date: Tue, 17 Jul 2018 19:21:03 -0400 Cc: Dave Thaler , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <18410D8B-9683-488B-A4CC-CDB737206256@gmail.com> References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> <56f4ed81-5f87-86d9-5acc-f7864a788f06@mozilla.com> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:21:09 -0000 Thanks, Peter, For future reference, how should one format URN examples, in messages = and drafts, so as not to imply that they are being freely minted? Best regards, Michael > On Jul 17, 2018, at 5:04 PM, Peter Saint-Andre = wrote: >=20 > On 7/17/18 2:55 PM, Michael Koster wrote: >> Yes obviously... My example assumes that one has a URN namespace.=20 >>=20 >> Is that an unreasonabe assumption? >=20 > Well, it depends on what kind of organizations we're talking about. = When > I worked at Cisco, I saw developers creating urn:cisco:foo URNs and = you > can't just mint your namespaces, so that was bad. >=20 >> Many of the organizations I work with have or plan to have URN = namespaces. >=20 > Excellent. Please point them to RFC 8141 for the updated definition of > URNs and the updated registration process for URN namespaces... :-) >=20 > https://tools.ietf.org/html/rfc8141 >=20 > Peter >=20 > (team lead, URN namespace expert review team) >=20 >=20 >=20 >>=20 >> Best regards, >>=20 >> Michael >>=20 >>> On Jul 17, 2018, at 4:31 PM, Peter Saint-Andre = wrote: >>>=20 >>> On 7/16/18 3:30 PM, Michael Koster wrote: >>>> Or the URN form may also be used, e.g. = "rt=3Durn:myorg:sensor:temperature" which can enable an organization to = manage its own namespace >>>=20 >>> Don't do that. You can't just create your own URN namespaces: >>>=20 >>> https://tools.ietf.org/html/rfc8141#section-5 >>>=20 >>> It's better to use URIs with the domain name of your organization, = or >>> use the urn:example namespace: >>>=20 >>> https://tools.ietf.org/html/rfc6963 >>>=20 >>> Peter >>>=20 >>>=20 >>=20 >=20 From nobody Tue Jul 17 17:13:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13403130E8C for ; Tue, 17 Jul 2018 17:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3TfxpKsv2wu for ; Tue, 17 Jul 2018 17:13:05 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 B396F130E91 for ; Tue, 17 Jul 2018 17:13:05 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l14-v6so2563530iob.7 for ; Tue, 17 Jul 2018 17:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R2PhTdrJrEGTFVFW4XVaPdz2Eu7A0QIKLQm5HzjzJrs=; b=U7FqV3U3tRMZ0JjoGM131I/DJsUf3ajdYH2ziIo5F+oDWmALkHzQXsxt9JtKRe5JGg /Z2uR1JTcSDAVlx5G/F/zoqT2mPLXOJdNWZ7hXRGTdDg2tnzTA7vwo/IVmLZzPwrRh9C gtLtabkQefS+FLNNXvhXoCx6GFEjv7QqvVZug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R2PhTdrJrEGTFVFW4XVaPdz2Eu7A0QIKLQm5HzjzJrs=; b=X1rEaQgg6Xjl/vHiLwmRjf9KwUIQnjRGbBOc+oXqwEjZmeFSaCgckQDxHMKnkwtz+a eHDonyyLzCrWmimzZDngqtLxwq0CSvRzmPvQ3zNpGbRXEDsNFg2BmGi4DRnzYHT15IWw Ye9CtXsiz/TJxr9z0sWTT1aPDhine921zJYVPxWBW4csTgrOsFB0NdxoUxbCkL1O6E6y j5qAR+iIAbBDJVXmyPjJzxU7O/C9QB3eAKencen8lsORwhp6iPTpb2xxNzNl2afVKAyP oquxPLqKJJJXYne0KlFjcdHx+b7hYV7IJKnn0aaDaFQmpSYvcxX51d62AdWVnyWQf2Vk iuew== X-Gm-Message-State: AOUpUlHRvzCvEZBAP9TEEcSTPHmNltDGTXtgBcIbGfl5+X8pS1mbD8QY 3AI8F/JPbcj2a9G6YMkPDn3qdFXyqVI= X-Google-Smtp-Source: AA+uWPzqmV8g+UM1YSiNlki4dG32tNZllrzcaKaEQbKUXy4R2VMKNBU+QLxy/3OJ+6KyO0nwaS0wpQ== X-Received: by 2002:a5e:dc49:: with SMTP id s9-v6mr3237655iop.237.1531872784878; Tue, 17 Jul 2018 17:13:04 -0700 (PDT) Received: from [192.168.1.10] ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id z22-v6sm1090962iog.63.2018.07.17.17.13.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 17:13:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Peter Saint-Andre X-Mailer: iPhone Mail (15F79) In-Reply-To: <18410D8B-9683-488B-A4CC-CDB737206256@gmail.com> Date: Tue, 17 Jul 2018 18:13:03 -0600 Cc: Dave Thaler , "core@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <132BF0EA-F284-4857-BE93-2A04608D828A@gmail.com> <56f4ed81-5f87-86d9-5acc-f7864a788f06@mozilla.com> <18410D8B-9683-488B-A4CC-CDB737206256@gmail.com> To: Michael Koster Archived-At: Subject: Re: [core] Link-format to DNS-SD mapping: URI rt values X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 00:13:08 -0000 > On Jul 17, 2018, at 5:21 PM, Michael Koster w= rote: >=20 > Thanks, Peter, >=20 > For future reference, how should one format URN examples, in messages and d= rafts, so as not to imply that they are being freely minted? It=E2=80=99s best to use the urn:example namespace from RFC 6963. Peter >=20 > Best regards, >=20 > Michael >=20 >> On Jul 17, 2018, at 5:04 PM, Peter Saint-Andre wrot= e: >>=20 >> On 7/17/18 2:55 PM, Michael Koster wrote: >>> Yes obviously... My example assumes that one has a URN namespace.=20 >>>=20 >>> Is that an unreasonabe assumption? >>=20 >> Well, it depends on what kind of organizations we're talking about. When >> I worked at Cisco, I saw developers creating urn:cisco:foo URNs and you >> can't just mint your namespaces, so that was bad. >>=20 >>> Many of the organizations I work with have or plan to have URN namespace= s. >>=20 >> Excellent. Please point them to RFC 8141 for the updated definition of >> URNs and the updated registration process for URN namespaces... :-) >>=20 >> https://tools.ietf.org/html/rfc8141 >>=20 >> Peter >>=20 >> (team lead, URN namespace expert review team) >>=20 >>=20 >>=20 >>>=20 >>> Best regards, >>>=20 >>> Michael >>>=20 >>>> On Jul 17, 2018, at 4:31 PM, Peter Saint-Andre wr= ote: >>>>=20 >>>> On 7/16/18 3:30 PM, Michael Koster wrote: >>>>> Or the URN form may also be used, e.g. "rt=3Durn:myorg:sensor:temperat= ure" which can enable an organization to manage its own namespace >>>>=20 >>>> Don't do that. You can't just create your own URN namespaces: >>>>=20 >>>> https://tools.ietf.org/html/rfc8141#section-5 >>>>=20 >>>> It's better to use URIs with the domain name of your organization, or >>>> use the urn:example namespace: >>>>=20 >>>> https://tools.ietf.org/html/rfc6963 >>>>=20 >>>> Peter >>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Wed Jul 18 07:00:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5CA1311C7 for ; Wed, 18 Jul 2018 07:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 vQnS_uUubk6g for ; Wed, 18 Jul 2018 07:00:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898901311A4 for ; Wed, 18 Jul 2018 07:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531922409; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q1gsdOy+z7quAQDXM1meBHmdknUV18pGPziSkDBGVkI=; b=bukRtngq/bhB+Wr9lZJGsrPfBLlc0xI1GWd17XyPEDPp9xOIapcESdwgJDgbdpFW bqwEqaGcqQPaiVNt1Qel81MjFKUDJIfZAzOg+PggwFuw2qPcyBZHPzBCx8S/6Qr3 PR5TVK/ff4Oo/Om/OPKBxUPFUL6ygKQsqsURr8oEooc=; X-AuditID: c1b4fb2d-20bff700000055ff-f4-5b4f47e9fed4 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.59.22015.9E74F4B5; Wed, 18 Jul 2018 16:00:09 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 18 Jul 2018 16:00:09 +0200 Received: from ESESSMB502.ericsson.se ([153.88.183.190]) by ESESSMB502.ericsson.se ([153.88.183.190]) with mapi id 15.01.1466.003; Wed, 18 Jul 2018 16:00:09 +0200 From: Klaus Hartke To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] ue of resource type in collections Thread-Index: AQHUF1wyuOvf++gaV0iTcZ7wQsQKq6SVD5Ag Date: Wed, 18 Jul 2018 14:00:09 +0000 Message-ID: <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> References: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> In-Reply-To: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2J7ie5Ld/9og6n3jCwe7V/FZrHv7Xpm ByaPJUt+MnmcaNjOHsAUxWWTkpqTWZZapG+XwJWxbgdrwR7OilXtE9kbGOdwdjFyckgImEgc uPGMuYuRi0NI4CijxKYPm1lBEkIC3xglZq3XhEgsY5To2PmRGSTBJqAnsWrqD3YQW0QgVGLP rkVsILawgJnEvouLgOIcQHFzidmvyiBKjCT+dD8EK2ERUJW4f/UnC4jNK2At8XLrMRaQciEB S4mD/21AwpwCVhKbe9uYQGxGATGJ76fWgNnMAuISt57MZ4K4WUBiyZ7zzBC2qMTLx/9YIWwl ib3HroONZBbQlFi/Sx+iVVFiSvdDdoitghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hx anFxbrqRsV5qUWZycXF+nl5easkmRmB8HNzyW3cH4+rXjocYBTgYlXh4lS39o4VYE8uKK3MP MUpwMCuJ8B587xctxJuSWFmVWpQfX1Sak1p8iFGag0VJnFdv1Z4oIYH0xJLU7NTUgtQimCwT B6dUA+PC9d/7uM7dmzRZXMi9ionpt0H/uwjLW/PeXXyY/3HN6R+aO1SuT9/yLuYlU6DM+VrJ H7c+X6yOOdHLcoblw1e+48xXp5cY34u+u4tV6U8n0/Pf2XtX35jzkmOXN69U5tKZJROTgjf9 PHxze9GrB2U9mld3rLqgtvjAhT0Hk0wFHqatsg5y+7mKT4mlOCPRUIu5qDgRAI/ZXzSLAgAA Archived-At: Subject: Re: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 14:00:23 -0000 UGV0ZXIgdmFuIGRlciBTdG9rIHdyb3RlOg0KPiBUaGUgY29hcHMtZXN0IHNlcnZlciB1c2VzIGEg Y29sbGVjdGlvbiBvZiByZXNvdXJjZXM6DQo+IFRoZSBjb2xsZWN0aW9uIHJlc291cmNlIGhhcyBi ZWVuIGFzc2lnbmVkIHJ0PWFjZS5lc3QNCj4gSXQgaXMgbm90IGNsZWFyIHdoYXQgdGhlIHJlc291 cmNlIHR5cGVzIG9mIHRoZSB1bmRlcmx5aW5nIHJlc291cmNlcyBzaG91bGQNCj4gYmUuDQoNCkFj Y29yZGluZyB0byBCQ1AgMTkwIFsxXSwgdGhlIGNvYXBzLWVzdCBkcmFmdCBzaG91bGQgbm90IG1h bmRhdGUgcGFydGljdWxhciBmb3JtcyBvZiBVUkkgc3Vic3RydWN0dXJlLiBTbyBhIHNlcnZlciBz aG91bGQgYmUgZnJlZSB0byBzdHJ1Y3R1cmUgVVJJcyBhcyBpdCBzZWVzIGZpdCwgZS5nLjoNCg0K PC9hPjtydD0iYWNlLmVzdCINCjwvYj47cnQ9ImFjZS5lc3QiDQo8L2M+O3J0PSJhY2UuZXN0Ig0K PC9kPjtydD0iYWNlLmVzdCINCjwvZT47cnQ9ImFjZS5lc3QiDQo8L2Y+O3J0PSJhY2UuZXN0Ig0K DQpJZiBhIGNsaWVudCBoYXMgdHJvdWJsZSBzZWxlY3RpbmcgdGhlIHJpZ2h0IGxpbmsgZnJvbSB0 aGUgYWJvdmUgbGlzdCAoYW5kIHRoZXkgYWxsIGxvb2sgaW50ZXJjaGFuZ2VhYmxlIHRvIG1lKSwg dGhlbiB5b3UnZCBuZWVkIHRvIHByb3ZpZGUgbW9yZSBzcGVjaWZpYyBsaW5rIGluZm9ybWF0aW9u LCBlLmcuOg0KDQo8L2E+O3J0PSJhY2UuZXN0LnNrZyINCjwvYj47cnQ9ImFjZS5lc3QuY3J0cyIN CjwvYz47IHJ0PSJhY2UuZXN0Ig0KPC9kPjtydD0iYWNlLmVzdC5hdHQiDQo8L2U+O3J0PSJhY2Uu ZXN0LnNyZW4iDQo8L2Y+O3J0PSJhY2UuZXN0LnNlbiINCg0KS2xhdXMNCg0KWzFdIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9iY3AxOTANCg== From nobody Wed Jul 18 16:47:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA5B130DF4 for ; Wed, 18 Jul 2018 16:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taitradio.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 T27ekZArVLrV for ; Wed, 18 Jul 2018 16:47:12 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 E42CB1311A8 for ; Wed, 18 Jul 2018 16:47:10 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id y5-v6so5690716qti.12 for ; Wed, 18 Jul 2018 16:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taitradio.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=7e7qx8y8KDhVWYC657GjX+77kOiGnh0sRoXH89oPpE8=; b=I364m96L5DwyZec2bmEr1SjeIJFGgoVuiGskA1luC4jbLQiTxfSQAtNqOvYUg/OMwD LqaSLkJRf8utKn/2+PEn1OnUVxCLQIQp2ftdAm6qzR7RuRDwP1woLIeKAoTGcZpY/5Cu JP9wKp83fve81MP8swxwlvn/hf5uyHkEkxJUE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7e7qx8y8KDhVWYC657GjX+77kOiGnh0sRoXH89oPpE8=; b=YLCVl3A+7a5/kOkq/5fDZnE3HXcYk7/wdDEUUikRgGOaW4lm2jC4w0xVxXOWBGCdoI Uz7qmawrcEokrWDLKqykQHhGvHSRiWWDP+YPjsWBN2ELr9S0r+jpygm0fFoq9bVV00sA jLuuDfQD1PUDA8Tfj4fYIWR3vRtBWZhqNEheGhJMGKYV4GrnPJCJQfeQjCCvskNvsvEz /gTUudv222k4IDOsrk2C3eQXaDq+D3XE1p5KlEnqcP5hZwV9mG8YKQrwhKJs5H1w8Pho uh1pp3Ri4vP6u2DH22I0Ue7hdsMuybnvN3nPNhQipty3u9hQantdSPycPMYTNDa7pJhW c8WQ== X-Gm-Message-State: AOUpUlEucJ24JTIjhhqoyGwSvNMmTsXDViEpz7ir2heTQmWDhe80kqGv yW0dnuibjjybBuCINP9lRjZPTuVkjs+r/sb7zwZ4MXfkA6Rv3ccLzAXNK1klaMlO3ItLH/agFHX Q4J5GSDc+q7RO X-Google-Smtp-Source: AAOMgpdLuvRosi2qqgUEjt3T2/sBjfYuh0gA/Jv3wLI3hsBUYj2lJFcDKO+2+S9yKqh+ivCMQSJ2SVv7JMIX6ROklL4= X-Received: by 2002:ac8:1bdd:: with SMTP id m29-v6mr7660261qtk.318.1531957629745; Wed, 18 Jul 2018 16:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:233d:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 16:46:49 -0700 (PDT) From: John Carter Date: Thu, 19 Jul 2018 11:46:49 +1200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="000000000000550f2905714eae2e" Archived-At: Subject: [core] CoRE Tools X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 23:47:15 -0000 --000000000000550f2905714eae2e Content-Type: text/plain; charset="UTF-8" Alas, the exceedingly useful and friendly firefox add-on "Cu" has gone unmaintained and no longer works. It was pretty much the "face" of coap in terms of demonstrating the concept and convincing non-technical people. Are there any other user friendly / cross platform tools that speak CoAP and or any of the other CoRE technologies? Thanks! -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer --000000000000550f2905714eae2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alas, the exceedingly useful and friendly firefox add= -on "Cu" has gone unmaintained and no longer works.
It was pretty much the "face" of coap in terms of dem= onstrating the concept and convincing non-technical people.
<= br>
Are there any other user friendly / cross platform tools that= speak CoAP and or any of the other CoRE technologies?


Thanks!

--
John Carte= r
Phone : (64)(3) 358 6639
Tait Electronics=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0
= PO Box 1645 Christchurch
New Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--000000000000550f2905714eae2e-- From nobody Wed Jul 18 17:03:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F39131209 for ; Wed, 18 Jul 2018 17:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ebUHdY24x37 for ; Wed, 18 Jul 2018 17:02:51 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B91131241 for ; Wed, 18 Jul 2018 17:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6J02XZm022033; Thu, 19 Jul 2018 02:02:33 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:a037:154d:77cf:6c12] (unknown [IPv6:2001:67c:1232:144:a037:154d:77cf:6c12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41WDjP0dTmzDWQr; Thu, 19 Jul 2018 02:02:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 18 Jul 2018 20:02:31 -0400 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 553651350.285481-7baa52227e5f9751ea7f9306c08c4e09 Content-Transfer-Encoding: quoted-printable Message-Id: <4FF558E2-DD1F-4DA3-8418-02C958D40259@tzi.org> References: To: John Carter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] CoRE Tools X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:03:08 -0000 On Jul 18, 2018, at 19:46, John Carter = wrote: >=20 > Alas, the exceedingly useful and friendly firefox add-on =E2=80=9CCu" = has gone unmaintained Actually, not quite. > and no longer works. That one, sadly, is true. When Mozilla was recently renovated, the = extension APIs were overhauled, too, and the one Copper relies on to do = UDP communications went by the wayside. > It was pretty much the =E2=80=9Cface" of coap in terms of = demonstrating the concept and convincing non-technical people. Indeed. > Are there any other user friendly / cross platform tools that speak = CoAP and or any of the other CoRE technologies? You can install an old version of Firefox just for Copper. There is also a port for Chrome, but that is not quite as friendly as = the Firefox Copper was/is. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 18 17:08:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FDF1311F5 for ; Wed, 18 Jul 2018 17:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taitradio.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 gI-H12t8Rf_b for ; Wed, 18 Jul 2018 17:08:10 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 4A80B1310D1 for ; Wed, 18 Jul 2018 17:08:10 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id b5-v6so3383766qkg.6 for ; Wed, 18 Jul 2018 17:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taitradio.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B4pqM/gwNLroj1agL5Jhx+4LhPVeJBtjnLBhPrR+8Uw=; b=depb37KMugAoa+hUV7kPym1YLo2ne44s8mHF+8Lo9/whxtrQamuUhHVQb79W3mpnrd HxWZ0YVmpydyGS9Lf6HuZ4rlNdl66P6Kci78yF/ultSaJy/Ag+e/ZOmpkyXTPVDCmSJN 0XBXNDZRG5eRT7cnnmrFEsoF7L1ENTfa3G23U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B4pqM/gwNLroj1agL5Jhx+4LhPVeJBtjnLBhPrR+8Uw=; b=ZqBAYiEFHuNtm5RvOurJZWKNlFI7g43fU61iHeyJCH28ZGRLAjgTd1oLmbhKhIjM6y 4HsdWUHviQh7cdeuKSpNmIgh2IHIIwXywzqQzrYZSWDpUyDPzVu2egOAjXe85fsJE5vy XvP5NzzIwhth73U5BkWGJYCehjtgikUK25gY/9ap2RBDeTHdU4UKUnUvhWQhrAlcQQKv FWOimhZWjFubZW6zwFMQPASJwQ0kvhQ56yQ6+Z6cCPJgVrNalW1LVeWauLq3GTHhxd1k xGJa2QguTDbzZOFy131MWwGTQL14oyicYTlwud4EJLmjYqzhsqP7FLI+ba089OWcQ2k+ vY0A== X-Gm-Message-State: AOUpUlF6vzeQUgwlHLRwEyWxLtCAGu16+tgT5cn3GDRetgrIJPyG0KXs AP2F3IZHnbUCfeiC4Puv2ffoEJ+6+9bfTmv4WLPHt9za+/DJIv1VodjTQ0RIIfPz8LONjMPPKB9 vVFSCA5KcU0wY X-Google-Smtp-Source: AAOMgpeydKs7DfxGZgP11DfJo6RrNqZR9tmudaDJjAaw9Ipn/ueo3GI3nv3V7kiZKx1IufNmmsfjPFzHkclr22Eq8Ww= X-Received: by 2002:a37:608:: with SMTP id 8-v6mr7216677qkg.125.1531958889420; Wed, 18 Jul 2018 17:08:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:233d:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 17:07:48 -0700 (PDT) In-Reply-To: <4FF558E2-DD1F-4DA3-8418-02C958D40259@tzi.org> References: <4FF558E2-DD1F-4DA3-8418-02C958D40259@tzi.org> From: John Carter Date: Thu, 19 Jul 2018 12:07:48 +1200 Message-ID: To: Carsten Bormann Cc: core@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a36b105714ef99f" Archived-At: Subject: Re: [core] CoRE Tools X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:08:14 -0000 --0000000000006a36b105714ef99f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> Alas, the exceedingly useful and friendly firefox add-on =E2=80=9CCu" ha= s gone unmaintained > Actually, not quite. Is there a more recent version of the source somewhere then? The versions on github I have found were last touched in 2016. On Thu, Jul 19, 2018 at 12:02 PM, Carsten Bormann wrote: > On Jul 18, 2018, at 19:46, John Carter wrote: > > > > Alas, the exceedingly useful and friendly firefox add-on =E2=80=9CCu" h= as gone > unmaintained > > Actually, not quite. > > > and no longer works. > > That one, sadly, is true. When Mozilla was recently renovated, the > extension APIs were overhauled, too, and the one Copper relies on to do U= DP > communications went by the wayside. > > > It was pretty much the =E2=80=9Cface" of coap in terms of demonstrating= the > concept and convincing non-technical people. > > Indeed. > > > Are there any other user friendly / cross platform tools that speak CoA= P > and or any of the other CoRE technologies? > > You can install an old version of Firefox just for Copper. > There is also a port for Chrome, but that is not quite as friendly as the > Firefox Copper was/is. > > Gr=C3=BC=C3=9Fe, Carsten > > --=20 John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand --=20 This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer=20 --0000000000006a36b105714ef99f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> Alas, the exceedingly us= eful and friendly firefox add-on =E2=80=9CCu" has gone unmaintained
> Actually, not quite.

Is there a more r= ecent version of the source somewhere then? The versions on github I have f= ound were last touched in 2016.




On Thu, Jul 19,= 2018 at 12:02 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Jul 18, 2018, at 19:46, John = Carter <john.carter@taitrad= io.com> wrote:
>
> Alas, the exceedingly useful and friendly firefox add-on =E2=80=9CCu&q= uot; has gone unmaintained

Actually, not quite.

> and no longer works.

That one, sadly, is true.=C2=A0 When Mozilla was recently renovated, the ex= tension APIs were overhauled, too, and the one Copper relies on to do UDP c= ommunications went by the wayside.

> It was pretty much the =E2=80=9Cface" of coap in terms of demonst= rating the concept and convincing non-technical people.

Indeed.

> Are there any other user friendly / cross platform tools that speak Co= AP and or any of the other CoRE technologies?

You can install an old version of Firefox just for Copper.
There is also a port for Chrome, but that is not quite as friendly as the F= irefox Copper was/is.

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




--
John Carter
= Phone : (64)(3) 358 6639
Tait Electronics=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0
PO Box = 1645 Christchurch
New Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--0000000000006a36b105714ef99f-- From nobody Thu Jul 19 04:37:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1D130F04 for ; Thu, 19 Jul 2018 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqNkikIq_F7L for ; Thu, 19 Jul 2018 04:37:34 -0700 (PDT) Received: from bne.vrt.com.au (bne.vrt.com.au [43.252.125.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96EEC130DD5 for ; Thu, 19 Jul 2018 04:37:33 -0700 (PDT) Received: from bne.vrt.com.au (localhost [127.0.0.1]) by bne.vrt.com.au (Postfix) with ESMTP id DBAC11D143E4 for ; Thu, 19 Jul 2018 21:37:30 +1000 (AEST) Received: by bne.vrt.com.au (Postfix, from userid 8) id C80EF1D143E3; Thu, 19 Jul 2018 21:37:30 +1000 (AEST) Received: from bneprdmail (unknown [10.87.160.28]) by bne.vrt.com.au (Postfix) with ESMTP id B3E8C1D143E0 for ; Thu, 19 Jul 2018 21:37:28 +1000 (AEST) Received: from [192.168.65.126] (eth2015.qld.adsl.internode.on.net [150.101.176.226]) by bneprdmail (Postfix) with ESMTPSA id 72A0717279E for ; Thu, 19 Jul 2018 21:37:28 +1000 (AEST) To: core@ietf.org References: <4FF558E2-DD1F-4DA3-8418-02C958D40259@tzi.org> From: Stuart Longland Openpgp: id=77102FB21549FFDE5E13B83A0C7F53F4F359B8EF; url=https://stuartl.longlandclan.id.au/key.asc Organization: VRT Systems Message-ID: Date: Thu, 19 Jul 2018 21:37:27 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <4FF558E2-DD1F-4DA3-8418-02C958D40259@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [core] CoRE Tools X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 11:37:37 -0000 On 19/07/18 10:02, Carsten Bormann wrote: >> Are there any other user friendly / cross platform tools that speak CoAP and or any of the other CoRE technologies? > You can install an old version of Firefox just for Copper. > There is also a port for Chrome, but that is not quite as friendly as the Firefox Copper was/is. I too was a bit miffed when I updated Firefox and lost Copper… actually the latest update has had me wondering why I don't switch to Chromium. (Guess old habits die hard… I was a Netscape user for a long time.) But, no use lamenting over that. Two downsides with Copper though: 1. it didn't do scoped addresses (e.g. ff02::1%wpan0; fe80::c0:fffe:1%eth0) 2. to my knowledge it didn't support encodings such as CBOR. The latter point made it difficult to work with the CoMI implementation I've been working on (although to be truthful, it's probably only a partial CoMI implementation, and likely lots of things I got wrong). I'd cook something up in Python, but haven't run across a CoAP library I'm happy with yet. (Tried coapthon and txthings, coapthon didn't work well at all, and txthings has problems with IPv6 multicast.) There's NodeJS libraries that work well for CoAP/CBOR, not sure if these would work with Electron or other NodeJS/Webkit UI toolkits. Then again, having something that runs as a daemon and you hit with a web browser could work well for certain things (lots of Raspberry Pi-based 6LoWPAN gateways out there, e.g. OpenThread Border Router). Postman has some good ideas regarding HTTP that'd be worth "borrowing" which could help in debugging other protocols like block transfers, CoMI and others. I haven't heard of alternatives to Copper, it was by far the best UI I've seen for dealing with CoAP. If people know of others, I'm all ears, otherwise though, maybe it's time to roll the sleeves up and DIY. Regards, -- _ ___ Stuart Longland - Systems Engineer \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas Street F: +61 7 3535 9699 SYSTEMS Milton QLD 4064 http://www.vrt.com.au From nobody Thu Jul 19 06:55:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93CB13106D for ; Thu, 19 Jul 2018 06:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjfcC_5VvmFg for ; Thu, 19 Jul 2018 06:54:56 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA46C130F8A for ; Thu, 19 Jul 2018 06:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XM8SC5AzgobagQhobunrzSoUKADPpj8biGRWsQSy35c=; b=vzZfkTt7wUZ18ovMOEpsXDLq0rIWwUuOh2O/hngfG9ZcxotXYDCsAs8OGFhHb/Otvno3aEN7weLQn2PqUUPi+hExx3uanLPw1V/VYK47eezZ/Rp8LJWrKKN/7haukigLpEI2C9pACEnQyKxFDO7ZarS3AXFqhZ67DZT0nzEaQFs= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB3081.namprd06.prod.outlook.com (10.174.191.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.20; Thu, 19 Jul 2018 13:54:53 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300%5]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 13:54:53 +0000 From: Michel Veillette To: Klaus Hartke , "consultancy@vanderstok.org" , Core Thread-Topic: [core] ue of resource type in collections Thread-Index: AQHUF1w1TydcNWe1mk+GT/oY8fEqlKSVEI6AgAGPHGA= Date: Thu, 19 Jul 2018 13:54:53 +0000 Message-ID: References: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> In-Reply-To: <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [31.133.142.43] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB3081; 7:oiNh5cAkWyELGEpmHKc8+4YC1zO3XuBKNoyPL/8JVLy4PKet5nfjiWQN3y6xQ1Y77pOx3CeHSiCJ6bn7ZD8W7czQiKAOEtGISZuO9Q/xivThSWKkI4HH3hG4tJPYPb9Ad+3gjVraOqEv6DTyTJRETFpUHMMfAHFboKmzVQC7bM1JVufcgbKw44J2c4q/yNPHb/eGl4NLEJhkxYwYgZLcu7tGBR0PUlogc4GNFOTcLZzB3asP7sFlA+CDTQ7DKATy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ff169911-2d98-4716-afc6-08d5ed7f344b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB3081; x-ms-traffictypediagnostic: DM5PR06MB3081: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB3081; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB3081; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(39850400004)(376002)(396003)(199004)(189003)(13464003)(14454004)(66066001)(5660300001)(6116002)(68736007)(6246003)(3846002)(256004)(110136005)(316002)(102836004)(478600001)(53936002)(966005)(72206003)(25786009)(74316002)(2501003)(6306002)(7696005)(99286004)(186003)(8676002)(81156014)(9686003)(305945005)(5250100002)(26005)(7736002)(105586002)(229853002)(476003)(446003)(86362001)(55016002)(6436002)(8936002)(6506007)(11346002)(81166006)(97736004)(2900100001)(33656002)(2906002)(53546011)(486006)(106356001)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB3081; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: PPB/6bcNJYIrB3dOvv7HSbRdXlGfwd1lMkSaP9A+e0TdU2EPQmmxq1wWL64fKRrAJQflBzN6bQ8uk8rMAI01bsaxKS4VDqlOZEt4TWIt+dmr925yYZD7XJAm3fsTFcyGrU7jgwHTbOODjpjSWVI4ayNOoBUn0Do+nRkFVFrgRzd2lww7gI5qrc2fsg+c4VqizRLHbvktZ26RaS8QvxSSOHatFldahGBIbJIt9wIPozmvaHfno9i0z8W3lpT3ndNp/FhAUonRgPF1U2TM7zkCu6iMMSMsSNHs/IXiv9HZC/F3WKl55zCD9yzC7un07kudd107co+JF4ROWrShiL7bKC+ax/024eR1sxxrnvYa1eM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff169911-2d98-4716-afc6-08d5ed7f344b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 13:54:53.4776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3081 Archived-At: Subject: Re: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:55:11 -0000 The recommended list of CoAP resources listed in the original email conflic= t with current CoMI recommended resource (/c). To minimize the likelihood o= f conflicts, I recommend to define these resources under a single root reso= urce. For example: ;rt=3D"ace.est.skg" ;rt=3D"ace.est.crts" ; rt=3D"ace.est" ;rt=3D"ace.est.att" ;rt=3D"ace.est.sren" ;rt=3D"ace.est.sen" Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Klaus Hartke Sent: Wednesday, July 18, 2018 10:00 AM To: consultancy@vanderstok.org; Core Subject: Re: [core] ue of resource type in collections Peter van der Stok wrote: > The coaps-est server uses a collection of resources: > The collection resource has been assigned rt=3Dace.est It is not clear=20 > what the resource types of the underlying resources should be. According to BCP 190 [1], the coaps-est draft should not mandate particular= forms of URI substructure. So a server should be free to structure URIs as= it sees fit, e.g.: ;rt=3D"ace.est" ;rt=3D"ace.est" ;rt=3D"ace.est" ;rt=3D"ace.est" ;rt=3D"ace.est" ;rt=3D"ace.est" If a client has trouble selecting the right link from the above list (and t= hey all look interchangeable to me), then you'd need to provide more specif= ic link information, e.g.: ;rt=3D"ace.est.skg" ;rt=3D"ace.est.crts" ; rt=3D"ace.est" ;rt=3D"ace.est.att" ;rt=3D"ace.est.sren" ;rt=3D"ace.est.sen" Klaus [1] https://tools.ietf.org/html/bcp190 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 19 07:14:12 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B06130F06 for ; Thu, 19 Jul 2018 07:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 lBE2oPrBimHO for ; Thu, 19 Jul 2018 07:13:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEEF130F52 for ; Thu, 19 Jul 2018 07:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532009634; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=09WM8orWeqWh8xhjDo/UEZGKtO8ucyoG9il7mT2vSxs=; b=L19pKuX5ercHkwqFcbMZEQeH/gFGuIaVRdWX/v/imBQdR0PTU/hD/RdC3HSRvEB4 3JHnvRpVnD/8sddcQepMPjZBFz7ImAA4QASoLmqiWYRj619zVv4z+CbCW1VBLd/q N8kppPGJQUC0KoCWB1RQyc1gGmt9wHKz0rxVMXqS5NQ=; X-AuditID: c1b4fb2d-20bff700000055ff-78-5b509ca2e292 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CC.78.22015.2AC905B5; Thu, 19 Jul 2018 16:13:54 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 19 Jul 2018 16:13:54 +0200 Received: from ESESSMB502.ericsson.se ([153.88.183.190]) by ESESSMB502.ericsson.se ([153.88.183.190]) with mapi id 15.01.1466.003; Thu, 19 Jul 2018 16:13:54 +0200 From: Klaus Hartke To: Michel Veillette , "consultancy@vanderstok.org" , Core Thread-Topic: [core] ue of resource type in collections Thread-Index: AQHUF1wyuOvf++gaV0iTcZ7wQsQKq6SVD5AggAFwU4CAACJd8A== Date: Thu, 19 Jul 2018 14:13:53 +0000 Message-ID: <83b6eff6240048c7a4cb71b5f0a6ddfc@ericsson.com> References: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbG9WHfRnIBog6U3xCwe7V/FZrHv7Xpm i1U/PrM4MHssWfKTyWNn+xU2jxMN29kDmKO4bFJSczLLUov07RK4Mg7t2MBW0CdTcfPBGfYG xg3SXYycHBICJhI/t15j62Lk4hASOMoosePMFCjnG6PE3c63jCBVQgLLGCXm3UwEsdkE9CRW Tf3BDmKLCHQxSiz6mgtiCwuYSey7uAgozgEUN5eY/aoMosRJYt7ffSwgNouAqkT/gXNgNq+A tcSFZWehxu9jlNjanQ1icwrESvy7doAVxGYUEJP4fmoNE4jNLCAucevJfCaIowUkluw5zwxh i0q8fPyPFcJWkth77DoLyAnMApoS63fpQ7QqSkzpfsgOsVZQ4uTMJywTGEVnIZk6C6FjFpKO WUg6FjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjJuDW37r7mBc/drxEKMAB6MSDy97 Z0C0EGtiWXFl7iFGCQ5mJRHeRx5AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rx6q/ZECQmkJ5ak ZqemFqQWwWSZODilGhijk45eFNeMXOM4/+lJuctF/T+bz+iZy/g1ewnpthzaeSdmy0O9K4FN 2uvyXVqPzy3jmena4haof/+vzGm5uJlnlVaXsP5K61iZqXLwXknO4QdCqhp/f08/c/t1ydPQ P4/ecc7cmRbXEyMtwPgl8JXXq1MhTuly17OkprfcXVtwbIvdK9VZKzyVWIozEg21mIuKEwFl nnr7lwIAAA== Archived-At: Subject: Re: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:14:11 -0000 SGkgTWljaGVsLA0KDQp0aGUgcG9pbnQgaXMgdGhhdCBhIHNlcnZlciBpcyBmcmVlIHRvIG9yZ2Fu aXplIGl0cyBVUkkgc3BhY2UgYXMgaXQgc2VlcyBmaXQgYW5kIGxpbmsgYW5ub3RhdGlvbnMgYXJl IG5lZWRlZCB0byBmaW5kIHRoZSByaWdodCByZXNvdXJjZS4NCg0KSXQncyBub3QgcG9zc2libGUg dG8gcmVzZXJ2ZSBVUkkgcGF0aHMgZm9yIGFueSBwdXJwb3NlICh3aXRoIHRoZSBleGNlcHRpb24g b2YgLndlbGwta25vd24gcGF0aHMpLiBZb3UgY2FuIHVzZSAvYyBpbiB5b3VyIGV4YW1wbGVzIGlm IHlvdSB3YW50LCBidXQgeW91IGNhbm5vdCBtYW5kYXRlIHRoYXQgaW1wbGVtZW50YXRpb25zIGRv IHRoZSBzYW1lIG9yIGNsYWltIGl0IGZvciBDb01JLiBBbmQgSSBkb24ndCB0aGluayBpdCdzIHRp bWUgd2VsbCBzcGVudCBpZiB3ZSdkIHRyeSB0byBlbnN1cmUgdGhhdCBubyBleGFtcGxlIHVzZXMg YSBwYXRoIHRoYXQgYWxyZWFkeSBhcHBlYXJzIGluIGFub3RoZXIgZXhhbXBsZS4NCg0KS2xhdXMN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pY2hlbCBWZWlsbGV0 dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50LmNvbT4NCj4gU2VudDogVGh1cnNkYXksIDE5 IEp1bHksIDIwMTggMTU6NTUNCj4gVG86IEtsYXVzIEhhcnRrZSA8a2xhdXMuaGFydGtlQGVyaWNz c29uLmNvbT47DQo+IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBDb3JlIDxjb3JlQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSRTogW2NvcmVdIHVlIG9mIHJlc291cmNlIHR5cGUgaW4gY29sbGVj dGlvbnMNCj4gDQo+IFRoZSByZWNvbW1lbmRlZCBsaXN0IG9mIENvQVAgcmVzb3VyY2VzIGxpc3Rl ZCBpbiB0aGUgb3JpZ2luYWwgZW1haWwgY29uZmxpY3QNCj4gd2l0aCBjdXJyZW50IENvTUkgcmVj b21tZW5kZWQgcmVzb3VyY2UgKC9jKS4gVG8gbWluaW1pemUgdGhlIGxpa2VsaWhvb2Qgb2YNCj4g Y29uZmxpY3RzLCBJIHJlY29tbWVuZCB0byBkZWZpbmUgdGhlc2UgcmVzb3VyY2VzIHVuZGVyIGEg c2luZ2xlIHJvb3QNCj4gcmVzb3VyY2UuDQo+IA0KPiBGb3IgZXhhbXBsZToNCj4gPC9lc3Qvc2tn PjtydD0iYWNlLmVzdC5za2ciDQo+IDwvZXN0L2NydHM+O3J0PSJhY2UuZXN0LmNydHMiDQo+IDwv ZXN0PjsgcnQ9ImFjZS5lc3QiDQo+IDwvZXN0L2F0dD47cnQ9ImFjZS5lc3QuYXR0Ig0KPiA8L2Vz dC9zcmVuPjtydD0iYWNlLmVzdC5zcmVuIg0KPiA8L2VzdC9zZW4+O3J0PSJhY2UuZXN0LnNlbiIN Cj4gDQo+IFJlZ2FyZHMsDQo+IE1pY2hlbA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEtsYXVzIEhhcnRrZQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTgsIDIwMTggMTA6MDAg QU0NCj4gVG86IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBDb3JlIDxjb3JlQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIHVlIG9mIHJlc291cmNlIHR5cGUgaW4gY29sbGVjdGlv bnMNCj4gDQo+IFBldGVyIHZhbiBkZXIgU3RvayB3cm90ZToNCj4gPiBUaGUgY29hcHMtZXN0IHNl cnZlciB1c2VzIGEgY29sbGVjdGlvbiBvZiByZXNvdXJjZXM6DQo+ID4gVGhlIGNvbGxlY3Rpb24g cmVzb3VyY2UgaGFzIGJlZW4gYXNzaWduZWQgcnQ9YWNlLmVzdCBJdCBpcyBub3QgY2xlYXINCj4g PiB3aGF0IHRoZSByZXNvdXJjZSB0eXBlcyBvZiB0aGUgdW5kZXJseWluZyByZXNvdXJjZXMgc2hv dWxkIGJlLg0KPiANCj4gQWNjb3JkaW5nIHRvIEJDUCAxOTAgWzFdLCB0aGUgY29hcHMtZXN0IGRy YWZ0IHNob3VsZCBub3QgbWFuZGF0ZSBwYXJ0aWN1bGFyDQo+IGZvcm1zIG9mIFVSSSBzdWJzdHJ1 Y3R1cmUuIFNvIGEgc2VydmVyIHNob3VsZCBiZSBmcmVlIHRvIHN0cnVjdHVyZSBVUklzIGFzIGl0 DQo+IHNlZXMgZml0LCBlLmcuOg0KPiANCj4gPC9hPjtydD0iYWNlLmVzdCINCj4gPC9iPjtydD0i YWNlLmVzdCINCj4gPC9jPjtydD0iYWNlLmVzdCINCj4gPC9kPjtydD0iYWNlLmVzdCINCj4gPC9l PjtydD0iYWNlLmVzdCINCj4gPC9mPjtydD0iYWNlLmVzdCINCj4gDQo+IElmIGEgY2xpZW50IGhh cyB0cm91YmxlIHNlbGVjdGluZyB0aGUgcmlnaHQgbGluayBmcm9tIHRoZSBhYm92ZSBsaXN0IChh bmQgdGhleSBhbGwNCj4gbG9vayBpbnRlcmNoYW5nZWFibGUgdG8gbWUpLCB0aGVuIHlvdSdkIG5l ZWQgdG8gcHJvdmlkZSBtb3JlIHNwZWNpZmljIGxpbmsNCj4gaW5mb3JtYXRpb24sIGUuZy46DQo+ IA0KPiA8L2E+O3J0PSJhY2UuZXN0LnNrZyINCj4gPC9iPjtydD0iYWNlLmVzdC5jcnRzIg0KPiA8 L2M+OyBydD0iYWNlLmVzdCINCj4gPC9kPjtydD0iYWNlLmVzdC5hdHQiDQo+IDwvZT47cnQ9ImFj ZS5lc3Quc3JlbiINCj4gPC9mPjtydD0iYWNlLmVzdC5zZW4iDQo+IA0KPiBLbGF1cw0KPiANCj4g WzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9iY3AxOTANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4g Y29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUNCg== From nobody Thu Jul 19 07:48:37 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8E13106B for ; Thu, 19 Jul 2018 07:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldhbJ8YnueOS for ; Thu, 19 Jul 2018 07:48:20 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0094.outbound.protection.outlook.com [104.47.38.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4726D1310ED for ; Thu, 19 Jul 2018 07:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7J76HYp8lwrqAQxEzuIxeim31mG3009OSXpwzDPfHVU=; b=ZuLFszZsyPFyO9Owmg6G+YDlTsm+k8bfoMBTCCg+0MpaMHyK1u0lTfcEE0C9BkOEyamNjXRYJ3JA/bm98ALQrZnKtjleVoYf6nQQ33CWLn6RH/+HpIINqP/bi7wuPfUE4/TYoKN+ribA3MxYHnImgD/NwmFFxwFKrYz5+UHHxn4= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2922.namprd06.prod.outlook.com (10.175.108.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Thu, 19 Jul 2018 14:48:10 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::b822:6d77:2b7f:e300%5]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 14:48:10 +0000 From: Michel Veillette To: Klaus Hartke , "consultancy@vanderstok.org" , Core Thread-Topic: [core] ue of resource type in collections Thread-Index: AQHUF1w1TydcNWe1mk+GT/oY8fEqlKSVEI6AgAGPHGCAAAcPgIAABm8A Date: Thu, 19 Jul 2018 14:48:10 +0000 Message-ID: References: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> <83b6eff6240048c7a4cb71b5f0a6ddfc@ericsson.com> In-Reply-To: <83b6eff6240048c7a4cb71b5f0a6ddfc@ericsson.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [31.133.142.43] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB2922; 6:YKgoGtqUUEYi8ijDq0W+RUA57bC9m9JLqQvYU01bX8zH8HC0eU95CWNP0Fnqzyg6ZJWEOZCR1aX2v6zSlNV0DiWnkh+QixzZ0qK94tMzlD4ar3eNaqk3EavHYfpePFIgH/4e4FqpsuSvxIZyOt9yQ4mFPXnuY50xN5wRO3EOGktHwqEJtOsktS5acNJuywgPIBkWoib5/PG8bAmb0CIL78ux3qvpViUU7nGRB2qZpN0bYKlVf+DmF3asd7nlNTBw9uXHks/Aq/jp+RAKn/31eERI/8yygH1MV+0aSeY5L0K7XdvLdt+0Py1mpfYMWHEqpbZJaTEchfCgdYxME/szTjfwNEeZ4R3AAUsH8/XzK3Ze7OVhdwChiYpEo9E/lfvtYcUEqRVGEeh2zH7QK8bOyfg3R/OFssiKsJdX5GD5HLPr9EqSvooXvJ3BBvdmIGyWN6pJNQ7qbsQJMISrpnzvnw==; 5:xkwHvm+SekJn5kku4rnawupMa7qeZuMQWEsWTPWXX/fvcS1UB0kWCPwaRHx4TdApob1axeWQacXd/89R6IDeNu2lTgwLMhAKMqymL9eaWIEfuQwYrdj4rmBq9paLgzkXfyqzJqMSj/9+nq+p2nZcLLTHgcWNvxzO8mZnvoSmg1I=; 7:5VO6SRjPqi4IMsgvRh667ineH9GmcBkubSfn3jCoQdRlkcaLY2OZdOlsDE/xuxKkUsHaqJXK+VBWBwjASCNvsbZTtWIrNyZenkEQ8MfEBIYIsqkYgbC/FBS9trYzb9P7ychndIwLkrmrRXVE45bFiYpfGyunHfZa0a+Doo9DlUM7Z9PrGPpPH3KAQmYSln1E6nOa/BVe/s8FhC3wVORORQnYgJaRCa9igTZo7sUlgTcpfk/gAgW9gD7NLTUpZHw8 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0c66447a-82bc-4591-11d3-08d5ed86a58d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2922; x-ms-traffictypediagnostic: DM5PR06MB2922: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR06MB2922; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2922; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39850400004)(396003)(366004)(136003)(13464003)(199004)(189003)(26005)(2501003)(9686003)(476003)(72206003)(5250100002)(33656002)(305945005)(486006)(966005)(7736002)(66066001)(3846002)(6116002)(186003)(55016002)(478600001)(99286004)(14454004)(2900100001)(229853002)(25786009)(446003)(6436002)(11346002)(68736007)(93886005)(6306002)(76176011)(256004)(105586002)(102836004)(5660300001)(81166006)(81156014)(97736004)(7696005)(8936002)(6246003)(106356001)(74316002)(86362001)(2906002)(53936002)(110136005)(6506007)(316002)(8676002)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2922; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: En7F6Rm7q/vy+EZmN86feQD4H+DLPEbRQUrzYsEu+WaViB4a7Mvjm4o0wzZxgeiZxwGuqxAJVE4/J8vJcq6nGI48QBP+aDjGHIGldwKD4hie9IRB5/UzBPQIp7Lvmx+lULLodPkksStvCm0PVMKockFGjVMFBy7c6gqzP2zN2V1lQHd3uNxFuykbGyfHE8PSCui4ijUE4M5qNRPIfw5ABdfTg4/UHjV2gUoTzulIpfb7ci5lwt8bOisx/uSSpRz0386GEvJvmPNc7n2Tjp3s+pcLm/Jc952YYCJUMuCtEe6vg/dJIgtUpMUEEA+L42aAuM53fIgAvl2kojA+cvn7o5Z15X6ddF+6YWbzr1IvvXA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c66447a-82bc-4591-11d3-08d5ed86a58d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 14:48:10.0358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2922 Archived-At: Subject: Re: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:48:36 -0000 SGkgS2xhdXMNCg0KSSB1bmRlcnN0YW5kIHRoYXQgcmVzb3VyY2UgYXNzaWdubWVudHMgYXJlIG5v dCBjb21wdWxzb3J5LCBvbmx5IHJlY29tbWVuZGVkLiBBdm9pZGluZyBjb25mbGljdHMgYmV0d2Vl biB0aGVzZSByZWNvbW1lbmRhdGlvbnMgd2l0aGluIElFVEYgYW5kIHdpdGggb3RoZXIgd2VsbCBr bm93biBlY29zeXN0ZW1zIHNob3VsZCBqdXN0IGJlbmVmaXQgdGhlIENvQVAgY29tbXVuaXR5Lg0K DQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEtsYXVzIEhhcnRr ZSBbbWFpbHRvOmtsYXVzLmhhcnRrZUBlcmljc3Nvbi5jb21dIA0KU2VudDogVGh1cnNkYXksIEp1 bHkgMTksIDIwMTggMTA6MTQgQU0NClRvOiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxl dHRlQHRyaWxsaWFudC5jb20+OyBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzsgQ29yZSA8Y29y ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbY29yZV0gdWUgb2YgcmVzb3VyY2UgdHlwZSBpbiBj b2xsZWN0aW9ucw0KDQpIaSBNaWNoZWwsDQoNCnRoZSBwb2ludCBpcyB0aGF0IGEgc2VydmVyIGlz IGZyZWUgdG8gb3JnYW5pemUgaXRzIFVSSSBzcGFjZSBhcyBpdCBzZWVzIGZpdCBhbmQgbGluayBh bm5vdGF0aW9ucyBhcmUgbmVlZGVkIHRvIGZpbmQgdGhlIHJpZ2h0IHJlc291cmNlLg0KDQpJdCdz IG5vdCBwb3NzaWJsZSB0byByZXNlcnZlIFVSSSBwYXRocyBmb3IgYW55IHB1cnBvc2UgKHdpdGgg dGhlIGV4Y2VwdGlvbiBvZiAud2VsbC1rbm93biBwYXRocykuIFlvdSBjYW4gdXNlIC9jIGluIHlv dXIgZXhhbXBsZXMgaWYgeW91IHdhbnQsIGJ1dCB5b3UgY2Fubm90IG1hbmRhdGUgdGhhdCBpbXBs ZW1lbnRhdGlvbnMgZG8gdGhlIHNhbWUgb3IgY2xhaW0gaXQgZm9yIENvTUkuIEFuZCBJIGRvbid0 IHRoaW5rIGl0J3MgdGltZSB3ZWxsIHNwZW50IGlmIHdlJ2QgdHJ5IHRvIGVuc3VyZSB0aGF0IG5v IGV4YW1wbGUgdXNlcyBhIHBhdGggdGhhdCBhbHJlYWR5IGFwcGVhcnMgaW4gYW5vdGhlciBleGFt cGxlLg0KDQpLbGF1cw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog TWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnQuY29tPg0KPiBTZW50 OiBUaHVyc2RheSwgMTkgSnVseSwgMjAxOCAxNTo1NQ0KPiBUbzogS2xhdXMgSGFydGtlIDxrbGF1 cy5oYXJ0a2VAZXJpY3Nzb24uY29tPjsgDQo+IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBD b3JlIDxjb3JlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW2NvcmVdIHVlIG9mIHJlc291cmNl IHR5cGUgaW4gY29sbGVjdGlvbnMNCj4gDQo+IFRoZSByZWNvbW1lbmRlZCBsaXN0IG9mIENvQVAg cmVzb3VyY2VzIGxpc3RlZCBpbiB0aGUgb3JpZ2luYWwgZW1haWwgDQo+IGNvbmZsaWN0IHdpdGgg Y3VycmVudCBDb01JIHJlY29tbWVuZGVkIHJlc291cmNlICgvYykuIFRvIG1pbmltaXplIHRoZSAN Cj4gbGlrZWxpaG9vZCBvZiBjb25mbGljdHMsIEkgcmVjb21tZW5kIHRvIGRlZmluZSB0aGVzZSBy ZXNvdXJjZXMgdW5kZXIgYSANCj4gc2luZ2xlIHJvb3QgcmVzb3VyY2UuDQo+IA0KPiBGb3IgZXhh bXBsZToNCj4gPC9lc3Qvc2tnPjtydD0iYWNlLmVzdC5za2ciDQo+IDwvZXN0L2NydHM+O3J0PSJh Y2UuZXN0LmNydHMiDQo+IDwvZXN0PjsgcnQ9ImFjZS5lc3QiDQo+IDwvZXN0L2F0dD47cnQ9ImFj ZS5lc3QuYXR0Ig0KPiA8L2VzdC9zcmVuPjtydD0iYWNlLmVzdC5zcmVuIg0KPiA8L2VzdC9zZW4+ O3J0PSJhY2UuZXN0LnNlbiINCj4gDQo+IFJlZ2FyZHMsDQo+IE1pY2hlbA0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtsYXVzIEhhcnRrZQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1 bHkgMTgsIDIwMTggMTA6MDAgQU0NCj4gVG86IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBD b3JlIDxjb3JlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIHVlIG9mIHJlc291cmNl IHR5cGUgaW4gY29sbGVjdGlvbnMNCj4gDQo+IFBldGVyIHZhbiBkZXIgU3RvayB3cm90ZToNCj4g PiBUaGUgY29hcHMtZXN0IHNlcnZlciB1c2VzIGEgY29sbGVjdGlvbiBvZiByZXNvdXJjZXM6DQo+ ID4gVGhlIGNvbGxlY3Rpb24gcmVzb3VyY2UgaGFzIGJlZW4gYXNzaWduZWQgcnQ9YWNlLmVzdCBJ dCBpcyBub3QgY2xlYXIgDQo+ID4gd2hhdCB0aGUgcmVzb3VyY2UgdHlwZXMgb2YgdGhlIHVuZGVy bHlpbmcgcmVzb3VyY2VzIHNob3VsZCBiZS4NCj4gDQo+IEFjY29yZGluZyB0byBCQ1AgMTkwIFsx XSwgdGhlIGNvYXBzLWVzdCBkcmFmdCBzaG91bGQgbm90IG1hbmRhdGUgDQo+IHBhcnRpY3VsYXIg Zm9ybXMgb2YgVVJJIHN1YnN0cnVjdHVyZS4gU28gYSBzZXJ2ZXIgc2hvdWxkIGJlIGZyZWUgdG8g DQo+IHN0cnVjdHVyZSBVUklzIGFzIGl0IHNlZXMgZml0LCBlLmcuOg0KPiANCj4gPC9hPjtydD0i YWNlLmVzdCINCj4gPC9iPjtydD0iYWNlLmVzdCINCj4gPC9jPjtydD0iYWNlLmVzdCINCj4gPC9k PjtydD0iYWNlLmVzdCINCj4gPC9lPjtydD0iYWNlLmVzdCINCj4gPC9mPjtydD0iYWNlLmVzdCIN Cj4gDQo+IElmIGEgY2xpZW50IGhhcyB0cm91YmxlIHNlbGVjdGluZyB0aGUgcmlnaHQgbGluayBm cm9tIHRoZSBhYm92ZSBsaXN0IA0KPiAoYW5kIHRoZXkgYWxsIGxvb2sgaW50ZXJjaGFuZ2VhYmxl IHRvIG1lKSwgdGhlbiB5b3UnZCBuZWVkIHRvIHByb3ZpZGUgDQo+IG1vcmUgc3BlY2lmaWMgbGlu ayBpbmZvcm1hdGlvbiwgZS5nLjoNCj4gDQo+IDwvYT47cnQ9ImFjZS5lc3Quc2tnIg0KPiA8L2I+ O3J0PSJhY2UuZXN0LmNydHMiDQo+IDwvYz47IHJ0PSJhY2UuZXN0Ig0KPiA8L2Q+O3J0PSJhY2Uu ZXN0LmF0dCINCj4gPC9lPjtydD0iYWNlLmVzdC5zcmVuIg0KPiA8L2Y+O3J0PSJhY2UuZXN0LnNl biINCj4gDQo+IEtsYXVzDQo+IA0KPiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Jj cDE5MA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Thu Jul 19 08:03:00 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94871311B7 for ; Wed, 18 Jul 2018 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcep5SrEB59V for ; Wed, 18 Jul 2018 07:47:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFA2131188 for ; Wed, 18 Jul 2018 07:47:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8CFA2B810BB; Wed, 18 Jul 2018 07:47:54 -0700 (PDT) To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, cabo@tzi.org, jaime.jimenez@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: marian.buschsieweke@ovgu.de, core@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180718144754.8CFA2B810BB@rfc-editor.org> Date: Wed, 18 Jul 2018 07:47:54 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 19 Jul 2018 08:02:56 -0700 Subject: [core] [Technical Errata Reported] RFC7252 (5429) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 14:48:12 -0000 The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5429 -------------------------------------- Type: Technical Reported by: Marian Buschsieweke Section: 4.4 Original Text ------------- An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient. The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is changed each time a new Confirmable or Non- confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely. Corrected Text -------------- An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. Message IDs of subsequence messages send to the same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending (wrapping around at a value of 65535). Additionally, two subsequently send Message IDs to the same endpoint SHOULD have a difference of at most 16. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient. The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is incremented each time a new Confirmable or Non- confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely. Notes ----- Without any restrictions on how Message IDs are generated, an implementation of CoAP duplication detection must be prepared to receive a random sequence of Message IDs. One simple implementation strategy would be to store the received Message IDs along with a timestamp when they were received. If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID would be required. If additionaly a CoAP server expects requests to be received at a rate of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB have to be allocated per client. A class 1 (see RFC 7228 Section 3) server could handle at most 10 clients in parallel, if anything apart duplicate detection could be implemented without using any memory at all. If instead Message IDs have to be generated by incrementing a (global or per endpoint/network prefix/...) counter variable, duplicate detection can be implemented in a time and memory efficient way without limiting the rate of the message exchange between to nodes. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7252 (draft-ietf-core-coap-18) -------------------------------------- Title : The Constrained Application Protocol (CoAP) Publication Date : June 2014 Author(s) : Z. Shelby, K. Hartke, C. Bormann Category : PROPOSED STANDARD Source : Constrained RESTful Environments APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Thu Jul 19 09:02:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E593D13110B for ; Thu, 19 Jul 2018 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y2NK5h06x1k for ; Thu, 19 Jul 2018 09:02:26 -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 38D6B1310FF for ; Thu, 19 Jul 2018 09:02:26 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 388F740213; Thu, 19 Jul 2018 18:02:24 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2099A26; Thu, 19 Jul 2018 18:02:23 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4c8c:d7dc:98e5:d86]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D080A2E; Thu, 19 Jul 2018 18:02:22 +0200 (CEST) Received: (nullmailer pid 22689 invoked by uid 1000); Thu, 19 Jul 2018 16:02:22 -0000 Date: Thu, 19 Jul 2018 18:02:22 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: RFC Errata System Cc: ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jaime.jimenez@ericsson.com, marian.buschsieweke@ovgu.de, core@ietf.org Message-ID: <20180719160221.GB22079@hephaistos.amsuess.com> References: <20180718144754.8CFA2B810BB@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline In-Reply-To: <20180718144754.8CFA2B810BB@rfc-editor.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] [Technical Errata Reported] RFC7252 (5429) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:02:36 -0000 --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Marian, hello CoRE WG, (CC list stripped expecting that the authors are subscribed to CoRE) On Wed, Jul 18, 2018 at 07:47:54AM -0700, RFC Errata System wrote: > [...] Message IDs of subsequence messages send to the > same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending > (wrapping around at a value of 65535). Additionally, two > subsequently send Message IDs to the same endpoint SHOULD have a > difference of at most 16. > [...] >=20 > Notes > ----- > Without any restrictions on how Message IDs are generated, an > implementation of CoAP duplication detection must be prepared to > receive a random sequence of Message IDs. > > One simple implementation strategy would be to store the received > Message IDs along with a timestamp when they were received. > > If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID > would be required. > > If additionaly a CoAP server expects requests to be received at a rate > of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB > have to be allocated per client. > > A class 1 (see RFC 7228 Section 3) server could handle at most 10 > clients in parallel, if anything apart duplicate detection could be > implemented without using any memory at all. >=20 > If instead Message IDs have to be generated by incrementing a (global > or per endpoint/network prefix/...) counter variable, duplicate > detection can be implemented in a time and memory efficient way > without limiting the rate of the message exchange between to nodes. The memory requirements may have their point, but I think that this change would be far too severe for an erratum. If servers started relying on this change, that would easily invalidate duplicate message detection with existing implementations that use a single increasing message ID counter for all their peers. That aside, I'm not sure the overhead estimations work that way. Duplicate message detection not only means that the message ID and the timestamp must be stored (your 4 bytes), but also the often much larger response message. As that is costly and should be avoided, constrained implementations will look into whether they need to deduplicate at all: * For safe or idempotent request messages, message deduplication can be skipped. (You'd build the response to a GET once again when a duplicate hits you rather than storing the old response. For PUT, you'll set the resource's state anew, and if that's part of a race condition, so would a delayed package have been). Even some cases of POST can be treated like that (the application would need to let the library know that). * For observe notifications, the recipient would silently disregard the apparently out-of-order package. * For non-observe non-piggy-backed responses, the client would RST the duplicate response rather than ACK it, which is just as good. (There are no "The client received the response" semantics to the ACK). Constrained implementations should avoid keeping MIDs and timestamps around for any of those. Only non-idempotent (POST; which most applications will try to avoid) requests actually need the duplicate detection -- and then, there is also a response message to store, and then the overhead of actually storing the MID becomes far less significant. I'd be happy to be shown wrong, so please let's have the discussion if I am, but this is not something that should easily go into the errata. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --OwLcNYc0lM97+oe1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAltQtgkACgkQOY0REtOk veHj0g//UFsU/dEnT2eaCqi8OqaofwmhRkT8XoKbaI3VA9ZRP9b+pMmS3nJIK2Qh hJgAqSly0OZuPR7A/OQvGTg16coVh3/8/20LYIuhqtCCeLCHJwBGEP2Zj13vsCvY jH06oPoEagwF5aCKEzYa+beegoGOiY30QQTUc9dFFApkj20cHylWvGaaaqvjo+ej 2KadtM4HCmYcN6mGcaa/2c9V29FjCdhTqBnHAFFxaaN/FOSsHOM29nsgf/BjMjIv 6ocEWHYcZvM3f0WY8EDGwrk+9fiXGVVAWIZPPLOWgkCpBfEpuSH4ewxfecqXvyqT 7HIe8/PhMpFJNHNvqPH9MB1AAPgqNIl6hGVB7aOq2YWwF1m8nVmebHcgtls1i8ez 6f1yIZpeD6em9TV3aYwxQYI8R8bkvVrf+OHVORik5sFCncbGdd9H1GtmZpzDFfWw lZ8YHIGHQ/lJUgIRGZ1HoemBKNfi8/tW1uUgJUyVV4JUeM7owXDPVySQmJet8VKq 4iSFTzKcbC5P1Pmka+0YaDQxRA3k67tr5rboE78LAzyAXLSXiJOPiVwmcDbFGRct eG4kYAkafXNyijrCi7iIZO73fxFxhk1FowYc3AxUJ06CcXeo91h44V7cSqAdYGox Op/fRwbdq8ZJaIjP9YMFZWwyVSTvQbE4F5xvfnHYPsqsaAz++3A= =PZQ9 -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1-- From marian.buschsieweke@ovgu.de Thu Jul 19 13:02:01 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947F2130DC6 for ; Thu, 19 Jul 2018 13:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zMayK-kiawr for ; Thu, 19 Jul 2018 13:01:56 -0700 (PDT) Received: from mail.ovgu.de (mail.ovgu.de [141.44.1.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C27130DC9 for ; Thu, 19 Jul 2018 13:01:54 -0700 (PDT) Received: from mail.ovgu.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A67FE40065; Thu, 19 Jul 2018 22:01:52 +0200 (CEST) Received: from faultier2go (x4db3412b.dyn.telefonica.de [77.179.65.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ovgu.de (Postfix) with ESMTPSA id 663924005F; Thu, 19 Jul 2018 22:01:51 +0200 (CEST) Date: Thu, 19 Jul 2018 22:01:47 +0200 From: Marian Buschsieweke To: Christian =?UTF-8?B?QW1zw7xzcw==?= Cc: RFC Errata System , ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jaime.jimenez@ericsson.com, core@ietf.org, "Prof. Dr. Mesut =?UTF-8?B?R8O8bmXFnw==?=" Message-ID: <20180719220147.305db3cd@faultier2go> In-Reply-To: <20180719160221.GB22079@hephaistos.amsuess.com> References: <20180718144754.8CFA2B810BB@rfc-editor.org> <20180719160221.GB22079@hephaistos.amsuess.com> Organization: =?UTF-8?B?T3R0by12b24tR3Vlcmlja2UtVW5pdmVyc2l0w6R0?= Magdeburg X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/rgipNpyKMBS=uEQ69+rV9/C"; protocol="application/pgp-signature" X-PMX-Version: 6.4.4.2767743, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.7.19.195717, AntiVirus-Engine: 5.50.0, AntiVirus-Data: 2018.7.19.5500001 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, INVALID_MSGID_NO_FQDN 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_URI_HTTPS 0, REFERENCES 0, URI_ENDS_IN_HTML 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __ATTACHMENT_SIZE_0_10K 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __FROM_DOMAIN_IN_ANY_CC1 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_ATTACHMENT 0, __HAS_ATTACHMENT2 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITH_PATH 0' X-PMX-consideredAsSpam: no Archived-At: Subject: Re: [core] [Technical Errata Reported] RFC7252 (5429) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:05:07 -0000 --Sig_/rgipNpyKMBS=uEQ69+rV9/C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Christian, thanks for the fast reply. > The memory requirements may have their point, but I think that this > change would be far too severe for an erratum. If servers started > relying on this change, that would easily invalidate duplicate message > detection with existing implementations that use a single increasing > message ID counter for all their peers. The suggested change does not make it mandatory to have more than one count= er. The only mandatory change would be to actually use counters (one or more) at all and to increment them for generating a new Message ID. It is suggested to use more than one counter if a node is communicating with many nodes at the same time, as it SHOULD keep jumps in Message IDs less than or equal to 16. With messages coming in out of order or being lost a server st= ill expects jumps to be potentially bigger. But it is extremely likely that Message IDs will remain in a range of lets say 64 consecutively numbers (wrapping around at 65535). As a result, only the number of the lowest expected Message ID needs to be stored and a 64 bit bitmask can be used to store which Messages IDs have so far been used. This "window" can be moved upwards as needed and any Message ID below that "window" is almost certainl= y a duplicate. (I can provide more details how an efficient implementation could look like and how also the time can be tracked efficiently regarding memory= and computational requirements - but I believe that might not be relevant for t= he discussion.) As far as I know, no CoAP implementation that is actively used employs a different strategy than using counter(s) and increments it/them. If that is true, it wouldn't hurt to make that behavior mandatory. > That aside, I'm not sure the overhead estimations work that way. > Duplicate message detection not only means that the message ID and the > timestamp must be stored (your 4 bytes), but also the often much larger > response message. This is only partly true. With NSTART =3D 1 at most one request is outstand= ing. As a result, at most one response needs to be cached per client - a client wou= ld not send a new request without having the last response received or no long= er expecting to receive the response. The required memory for a single respons= e is usually much less than the 1 KiB for duplicate detection. > Only non-idempotent (POST; which most applications will try to avoid) > requests actually need the duplicate detection In a scenario with many simultaneous clients this might not be true. E.g. if Client A turns smart light on and Client B turns it off (e.g. "PUT /light o= n" and "PUT /light off"), both requests would be idempotent. The expected resu= lt would be that on requests comes in first - let's say the one of client A. So the light turns first on and than off. But with many duplicates and no duplicate detection, the light would be constantly switching on and off. Kind regards, Marian ------------------------------------------------------------- M.Sc. Marian Buschsieweke Dept. Communication and Networked Systems (ComSys) Institute for Intelligent Cooperating Systems (IKS) Otto-von-Guericke-University of Magdeburg Universit=C3=A4tsplatz 2, Building 29, Room 314 39106 Magdeburg Germany http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html Tel.: +49 - 391 - 67 - 52673 Fax: +49 - 391 - 67 - 41161 ------------------------------------------------------------- On Thu, 19 Jul 2018 18:02:22 +0200 Christian Ams=C3=BCss wrote: > Hello Marian, hello CoRE WG, >=20 > (CC list stripped expecting that the authors are subscribed to CoRE) >=20 > On Wed, Jul 18, 2018 at 07:47:54AM -0700, RFC Errata System wrote: > > [...] Message IDs of subsequence messages send to the > > same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending > > (wrapping around at a value of 65535). Additionally, two > > subsequently send Message IDs to the same endpoint SHOULD have a > > difference of at most 16. > > [...] > >=20 > > Notes > > ----- > > Without any restrictions on how Message IDs are generated, an > > implementation of CoAP duplication detection must be prepared to > > receive a random sequence of Message IDs. > > > > One simple implementation strategy would be to store the received > > Message IDs along with a timestamp when they were received. > > > > If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID > > would be required. > > > > If additionaly a CoAP server expects requests to be received at a rate > > of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB > > have to be allocated per client. > > > > A class 1 (see RFC 7228 Section 3) server could handle at most 10 > > clients in parallel, if anything apart duplicate detection could be > > implemented without using any memory at all. > >=20 > > If instead Message IDs have to be generated by incrementing a (global > > or per endpoint/network prefix/...) counter variable, duplicate > > detection can be implemented in a time and memory efficient way > > without limiting the rate of the message exchange between to nodes. >=20 > The memory requirements may have their point, but I think that this > change would be far too severe for an erratum. If servers started > relying on this change, that would easily invalidate duplicate message > detection with existing implementations that use a single increasing > message ID counter for all their peers. >=20 > That aside, I'm not sure the overhead estimations work that way. > Duplicate message detection not only means that the message ID and the > timestamp must be stored (your 4 bytes), but also the often much larger > response message. As that is costly and should be avoided, constrained > implementations will look into whether they need to deduplicate at all: >=20 > * For safe or idempotent request messages, message deduplication can be > skipped. (You'd build the response to a GET once again when a > duplicate hits you rather than storing the old response. For PUT, > you'll set the resource's state anew, and if that's part of a race > condition, so would a delayed package have been). >=20 > Even some cases of POST can be treated like that (the application > would need to let the library know that). >=20 > * For observe notifications, the recipient would silently disregard the > apparently out-of-order package. >=20 > * For non-observe non-piggy-backed responses, the client would RST the > duplicate response rather than ACK it, which is just as good. (There > are no "The client received the response" semantics to the ACK). >=20 > Constrained implementations should avoid keeping MIDs and timestamps > around for any of those. >=20 > Only non-idempotent (POST; which most applications will try to avoid) > requests actually need the duplicate detection -- and then, there is > also a response message to store, and then the overhead of actually > storing the MID becomes far less significant. >=20 >=20 > I'd be happy to be shown wrong, so please let's have the discussion if I > am, but this is not something that should easily go into the errata. >=20 > Best regards > Christian >=20 --Sig_/rgipNpyKMBS=uEQ69+rV9/C Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTCygBuMypPDEZ59jZh9kxlmbFTnwUCW1DuKwAKCRBh9kxlmbFT n1pDAQD2VjoWEBVMDSzQmTXOYQQbiSXCjonVqzVSs33acB8e8wEAv05CFFuaBtX4 2JAH0UG7/ysROBORGZGQvdq1Htk1nQ8= =HG5O -----END PGP SIGNATURE----- --Sig_/rgipNpyKMBS=uEQ69+rV9/C-- From nobody Thu Jul 19 16:50:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F479130E60; Thu, 19 Jul 2018 16:50: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN-w9EGyXKrv; Thu, 19 Jul 2018 16:50:11 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0144.hostedemail.com [216.40.44.144]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA22130E43; Thu, 19 Jul 2018 16:50:11 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 5B22A180188A7; Thu, 19 Jul 2018 23:50:10 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:355:379:582:800:962:967:969:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1431:1436:1437:1516:1517:1518:1534:1541:1568:1575:1588:1589:1592:1594:1711:1714:1730:1776:1792:2525:2527:2561:2564:2682:2685:2829:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3586:3740:3865:3866:3867:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4605:4659:5007:6261:6298:6659:6678:6684:7903:8603:9015:9025:9177:9388:10004:10215:10400:10848:11232:11658:11914:12043:12295:12555:12679:12895:12986:13139:13141:13161:13199:13229:13230:13439:13846:13972:14181:14721:21080:21433:21451:21625:21691:30012:30045:30048:30054:30076, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: plant38_1e8dd93f02520 X-Filterd-Recvd-Size: 3321 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA; Thu, 19 Jul 2018 23:50:09 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_094e18dc25450f30a45085bb29a4eed2" Date: Thu, 19 Jul 2018 20:50:09 -0300 From: Peter van der Stok To: carsten bormann , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= Cc: Ace , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.147.176] Archived-At: Subject: [core] early registration of content format specifid in est-coaps X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:50:15 -0000 --=_094e18dc25450f30a45085bb29a4eed2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Dear CoRE co-chairs, Given the advanced state of the implementation of est-coaps, it is requested that the content-format specified in draft-ietf-core-multipart-ct is registered early before the draft has become RFC. That permits to fill in the definite content-format codes in the implementation code. The required content-format is specified below | application/multict | - | C-F nr | [I-D.ietf-core-multipart-ct] | Many thanks, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_094e18dc25450f30a45085bb29a4eed2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Dear CoRE co-chairs,

Given the advanced= state of the implementation of est-coaps, it  is requested that the c= ontent-format specified in draft-ietf-core-multipart-ct is
registered early before the draft has become RFC.
That permits to fill in the definite content-format codes in the implemen= tation code.

The required content-format is specifi= ed below

   | application/multict     | - &nbs= p;    |  C-F nr  | [I-D.ietf-core-multipart-ct]&nb= sp;            =      |
  

Many thanks,

Peter
--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org
www: = = www.vanderstok.org
tel NL: +31(0)492474673    &nbs= p;F: +33(0)966015248
--=_094e18dc25450f30a45085bb29a4eed2-- From nobody Thu Jul 19 19:08:13 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A15D6130F88; Thu, 19 Jul 2018 19:08:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153205248660.10636.17459130896592894639@ietfa.amsl.com> Date: Thu, 19 Jul 2018 19:08:06 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-object-security-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 02:08:07 -0000 Reviewer: Joel Halpern 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 treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-object-security-13 Reviewer: Joel Halpern Review Date: 2018-07-19 IETF LC End Date: 2018-07-30 IESG Telechat date: Not scheduled for a telechat Summary: this document is ready for publication as a Proposed Standard RFC. My minor concerns from draft -08 have been addressed. Major issues: N/A Minor issues: Section 7.2 is about sequence numbers. The first sentence in 7.2 discusses Nonces. Then the discussion switches to sequence numbers? My guess is that the Nonce is left over from previous text? Nits/editorial comments: In the first paragraph of 3.3, the text reads: The requirement that Sender ID SHALL be unique in the set of all security contexts using the same Master Secret, Master Salt, and ID Context guarantees unique (key, nonce) pairs, which avoids nonce reuse. Unfortunately, that is not a grammatical sentence. From nobody Fri Jul 20 04:56:17 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7243130DC0 for ; Fri, 20 Jul 2018 04:56:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFxslWqQGb1d for ; Fri, 20 Jul 2018 04:56:13 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DD3127AC2 for ; Fri, 20 Jul 2018 04:56:12 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id D0410180A8428; Fri, 20 Jul 2018 11:56:11 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:41:72:152:355:379:582:599:960:962:966:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1712:1730:1776:1792:2068:2069:2196:2198:2199:2200:2525:2528:2559:2566:2570:2682:2685:2693:2703:2859:2892:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4362:4385:5007:6117:6119:6261:6298:7464:7875:7903:8603:9010:9025:9416:10004:10346:10400:11658:12740:13139:13161:13229:13237:30056, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: lace64_703f3b45f9225 X-Filterd-Recvd-Size: 5053 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf09.hostedemail.com (Postfix) with ESMTPA; Fri, 20 Jul 2018 11:56:11 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_47efd45355af39d1f92d1b49e060c6e1" Date: Fri, 20 Jul 2018 08:56:10 -0300 From: Peter van der Stok To: Klaus Hartke Cc: consultancy@vanderstok.org, Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> References: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> Message-ID: <041cdbf4a822a5879f8236a90eb13bc5@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.147.176] Archived-At: Subject: Re: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 11:56:16 -0000 --=_47efd45355af39d1f92d1b49e060c6e1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Thanks Klaus for the comments. The new resource types have to be registered, and can then be used in an interoperable way for discovery. That makes it difficult to not prescribe them in the draft. Given that some of the resources in the collection are not compulsory to have, I will provide the more extensive example no 2 in est-coaps. Greetings, Peter Klaus Hartke schreef op 2018-07-18 11:00: > Peter van der Stok wrote: > >> The coaps-est server uses a collection of resources: >> The collection resource has been assigned rt=ace.est >> It is not clear what the resource types of the underlying resources should >> be. > > According to BCP 190 [1 [1]], the coaps-est draft should not mandate particular forms of URI substructure. So a server should be free to structure URIs as it sees fit, e.g.: > > ;rt="ace.est" > ;rt="ace.est" > ;rt="ace.est" > ;rt="ace.est" > ;rt="ace.est" > ;rt="ace.est" > > If a client has trouble selecting the right link from the above list (and they all look interchangeable to me), then you'd need to provide more specific link information, e.g.: > > ;rt="ace.est.skg" > ;rt="ace.est.crts" > ; rt="ace.est" > ;rt="ace.est.att" > ;rt="ace.est.sren" > ;rt="ace.est.sen" > > Klaus > > [1] https://tools.ietf.org/html/bcp190 Links: ------ [1] https://tools.ietf.org/html/bcp190 --=_47efd45355af39d1f92d1b49e060c6e1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Thanks Klaus for the comments.
The new resource types have to be regis= tered, and can then be used in an interoperable way for discovery.
Tha= t makes it difficult to not prescribe them in the draft.
Given that so= me of the resources in the collection are not compulsory to have,
I wi= ll provide the more extensive example no 2 in est-coaps.

Greetin= gs,

Peter

Klaus Hartke schreef op 2018-07-18 11:00:

= Peter van der Stok wrote:
The coaps-est server uses a collection of resources: The collection resource has been assigned rt=3Dace.est
It is not= clear what the resource types of the underlying resources should
be= =2E

According to BCP 190 [1], the coaps-est draft should no= t mandate particular forms of URI substructure. So a server should be free = to structure URIs as it sees fit, e.g.:

</a>;rt=3D"ace.es= t"
</b>;rt=3D"ace.est"
</c>;rt=3D"ace.est"
&l= t;/d>;rt=3D"ace.est"
</e>;rt=3D"ace.est"
</f>;rt= =3D"ace.est"

If a client has trouble selecting the right link f= rom the above list (and they all look interchangeable to me), then you'd ne= ed to provide more specific link information, e.g.:

</a>;= rt=3D"ace.est.skg"
</b>;rt=3D"ace.est.crts"
</c>; r= t=3D"ace.est"
</d>;rt=3D"ace.est.att"
</e>;rt=3D"ac= e.est.sren"
</f>;rt=3D"ace.est.sen"

Klaus

[1] https://tools.ietf.org/html/bcp190
--=_47efd45355af39d1f92d1b49e060c6e1-- From nobody Fri Jul 20 05:41:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7C7130DEC for ; Fri, 20 Jul 2018 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itron.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 u_MGecLQIYP6 for ; Fri, 20 Jul 2018 05:41:12 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0085.outbound.protection.outlook.com [104.47.34.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFFF130E2F for ; Fri, 20 Jul 2018 05:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itron.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rhjgo/gT7iYn4r0CK4ZsZ3FH/3w1iXJ9wN2aADHqpVE=; b=XfANaSnVRvi/eVn4E0kn1zIvu0vS5Wmf5mcgPuiX5Buwjtsqkglbvk9Hsm+3/UloOQCIfOvKnJoNM72q4N3nelm1Wc/AEnOXb3/oLYFKb8/t5VcS1t9MD3A1+MOAa0WuM5Ca/oL01ATxkkMgOrzNy0Jq7JiSsxFEweT8sKnM3eE= Received: from CY1PR04MB1962.namprd04.prod.outlook.com (10.166.191.10) by CY1PR04MB2122.namprd04.prod.outlook.com (10.166.191.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.20; Fri, 20 Jul 2018 12:41:09 +0000 Received: from CY1PR04MB1962.namprd04.prod.outlook.com ([fe80::7cf1:c332:bc3b:7fc9]) by CY1PR04MB1962.namprd04.prod.outlook.com ([fe80::7cf1:c332:bc3b:7fc9%4]) with mapi id 15.20.0973.018; Fri, 20 Jul 2018 12:41:09 +0000 From: "Damm, Benjamin" To: core Thread-Topic: ECN with CoAP? Thread-Index: AQHUICZNT4EpDTcPnESmFljCcpbKBg== Date: Fri, 20 Jul 2018 12:41:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Benjamin.Damm@itron.com; x-originating-ip: [20.36.220.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR04MB2122; 6:CdOC1tmUO3tNQToYEKGvWw9OaFTvQ8GrFz1SQPSg3r7cMiQq1TT4o6cRkVZo9nFb1XHtgxGoyVRNtx7UOKxp9aOgqW/996jwf3R3VBOK0a1Z7QioBlYZppVTg/P3+HePnjsu8y6Q+tkM6Xd2JiPcU9Xe6pcA7r78qooUfUkg5z4c0EcY2gslH5pzMcE4c5KrpWnVEvMQh2zSVezVvJYbB35U1FYEGGSEy6uvfPWxJoBwBfwFCEVUWsfiItMNge4xoryLpciOA+9TIK6tGYQOpApDB35yeajcJX2O4Qj9t4O8GrTfQ+AqwYu3BgmZFkRMtviQ3A5o4D/7UMLXMOk74FOhuQGN47ToKf5bBLk89melPTDmNxrw83smYHxNvkgXrZmkLCfsHbaxGXOAvLGcLdIuBmLLYMLNH8XmvBVWmmpRIMr42x1wEL9IL+0W3mLWIhA9ljL4IzZxbBNduM2zVA==; 5:4bAatsm7DSsVQA/Aj0SzPWH85Nw+4iAQizTJh6VclpRquXceioB84lF3sZJROKWMQG9xJWlNAx8WYnzxAxpyIF5vZ3aZPwTuPU2QdIaovT9PXu4Tw98BSCH+eG6I3U01eISpwq540n/KBeo9haZjQG63i4nuQne0uCTVcByyowA=; 7:g4K8TTwci368tFmAfJFP29kwbwsT7Wzrih5lMoq3WvARIi7PM7XbRXaoWOWTWqeg+PWbm7EPihrxO+vcHFkvDoi39XhK17AUMQrva9c5ASM8W0unjeTbAYRTip5CTt8PrvhmCDcpjyAsL84UHB26sGZ98Pi2Y3Gun+dqmxpa9N8vWbI8ncRYypMsW7rMvTr7nvu9gCijvms513TvHYYHni9N9ChXB2aTqKURAxpsWgo5XWDQYBRKGOARxspGklzl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0f01395b-0d47-49d6-ffff-08d5ee3e11c2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:CY1PR04MB2122; x-ms-traffictypediagnostic: CY1PR04MB2122: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(111885846020525); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY1PR04MB2122; BCL:0; PCL:0; RULEID:; SRVR:CY1PR04MB2122; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(102836004)(6116002)(74316002)(3846002)(186003)(3480700004)(5660300001)(54896002)(26005)(6306002)(7696005)(6436002)(6916009)(9686003)(68736007)(7116003)(55016002)(316002)(86362001)(256004)(7736002)(478600001)(486006)(14454004)(33656002)(476003)(72206003)(966005)(53936002)(6506007)(25786009)(81156014)(81166006)(5250100002)(99286004)(8936002)(2900100001)(66066001)(97736004)(8676002)(106356001)(2906002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR04MB2122; H:CY1PR04MB1962.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: itron.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: PZnYEtv6rGEP5dBDgy2TnoahksZpSwSr2Rnny3BcNtBzpkboXKlXewyqLGgZzA7UyEO5uSyprrMs41+z2yRzatm6ONgmZOXa5pJKdaS9hKyA7BLUiixEeV4F0NJcqSNh8dTHk44WY4HrxwvDZvgDXilpUv6LTbc5RHZ3MMx31uq8CM6feHV0SemHxQQA9t8PYGu9/wAI95UvHrGF+Xbi1JfCqVABuZ1vQYBmZXyGEtgI8vPnBGioNVO54+fvN/b1bu7A4msSxCx8Ik970xp9jVB5z4ShrszQZZLbMDfNuTM3hbb+kvrBIjKYpUxfMgva3FGT9/uLvzCT9UbobQJ7A0kGN8hwedPcUeY4ShMNGnc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR04MB196213F7A3F3AF7ED62E89FAF8510CY1PR04MB1962namp_" MIME-Version: 1.0 X-OriginatorOrg: itron.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f01395b-0d47-49d6-ffff-08d5ee3e11c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 12:41:09.5855 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5818bd20-bf25-47b1-b996-d419d7e6e8ba X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR04MB2122 Archived-At: Subject: [core] ECN with CoAP? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 12:41:14 -0000 --_000_CY1PR04MB196213F7A3F3AF7ED62E89FAF8510CY1PR04MB1962namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello core, I=92m interested in ECN response flags for use with CoAP/UDP/IPv6[ECN]. Has= anyone tackled this yet? A set of CoAP options for ECN response handling m= akes sense to me and I=92d be happy to write it up if it hasn=92t been done= already. Benjamin Damm Platform Architect Cell: +1-415-297-5474 Web: https://Itron.com --_000_CY1PR04MB196213F7A3F3AF7ED62E89FAF8510CY1PR04MB1962namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello core,

I=92m interested in ECN response flags for u= se with CoAP/UDP/IPv6[ECN]. Has anyone tackled this yet? A set of CoAP opti= ons for ECN response handling makes sense to me and I=92d be happy to write= it up if it hasn=92t been done already.

Benjamin Damm
Platform Architect
Cell: +1-415-297-5474
Web: https://Itron.com
--_000_CY1PR04MB196213F7A3F3AF7ED62E89FAF8510CY1PR04MB1962namp_-- From nobody Fri Jul 20 06:15:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346A0130F27 for ; Fri, 20 Jul 2018 06:15: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, 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 svKAQQCuFT_2 for ; Fri, 20 Jul 2018 06:15:40 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205EF126F72 for ; Fri, 20 Jul 2018 06:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6KDFaiW002570 for ; Fri, 20 Jul 2018 15:15:36 +0200 (CEST) Received: from [IPv6:2001:67c:370:128:dda6:8f9c:2eaf:131] (unknown [IPv6:2001:67c:370:128:dda6:8f9c:2eaf:131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41XBG01YGBzDWmt; Fri, 20 Jul 2018 15:15:36 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 553785332.746138-27b8f9357a58aeff702501da6f6f84d5 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 20 Jul 2018 09:15:34 -0400 Message-Id: To: Core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CoRE@IETF102: Summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 13:15:42 -0000 Below is the chairs=E2=80=99 summary of what happened in CoRE at = IETF102. Corrections (and additions that keep the summary form) appreciated. Detailed minutes are being prepared; see link to raw minutes below. Gr=C3=BC=C3=9Fe, Carsten CoRE WG - Summary IETF102 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= * Video Recordings: [Session = 1](https://www.youtube.com/watch?v=3D2i9VAOJq8LU), Session 2 not yet available * = [Slides](https://datatracker.ietf.org/meeting/102/materials/slides-102-cor= e-consolidated-slides/) * [Raw = minutes](https://etherpad.tools.ietf.org/p/notes-ietf-102-core?useMonospac= eFont=3Dtrue) # CoRE @ IETF102 WG summary * draft-ietf-core-links-json-10 and draft-ietf-core-cocoa-03 are in IESG processing and are awaiting new versions from the authors. Side meetings at this meeting have made progress addressing some of the open issues from AD and IESG input. * draft-ietf-core-object-security-13 is in IESG processing and is waiting for a review from Eric Rescorla, with a view to Eric clearing the remaining DISCUSS held on the document. Technical Changes resulting from IESG and directorate inputs were discussed. Responsible AD Alexey triggered a second IETF last call to cover those changes. * draft-ietf-core-oscore-groupcomm-02 is nearing WG last call. The plan is to progress this independently from the related ACE documents as the membership and group key management can be done by other means (e.g., using a simple REST API). Before the WGLC another interop should be held (implementation draft then to be published based on outcome of the processing of basic OSCORE). * draft-ietf-core-echo-request-tag-02 requires a few more reviews; no formal dependency but it would be good to finish this approximately on the same timeline as OSCORE. * draft-ietf-core-resource-directory-14 was discussed, with some focus of the semantics of the incoming (registration) and outgoing (lookup) links. With several implementations becoming available An interop would be next; September/early October time frame is envisioned. Next step then could be WGLC. * draft-ietf-core-rd-dns-sd-02 was discussed (and later presented in DNSSD WG as well). Much of the discussion centered about how the rt=3D target attribute can be turned into a service type on the DNSSD side. (Later in the DNSSD meeting, the question came up whether that is the right pairing in the first place.) All DNSSD service = types must be registered (15 ldh characters max); CoRE resource types can be registered (63 characters max) or can be URIs. Further work on this is needed, as is on the pairing of ins=3D and DNSSD instance identifiers. * The CoRECONF cluster (new old name for yang-cbor draft-ietf-core-yang-cbor-06, comi draft-ietf-core-comi-03, and sid draft-ietf-core-sid-04) has recently received reviews fro the netmod community; a few more from the CoRE side and maybe another interop would be good before WGLC of this cluster, envisioned to close before IETF103. draft-veillette-core-yang-library has a little more time. As a major technical change it was agreed to always start a yang-cbor tree with a SID delta base of 0. This has slight performance disadvantages, but makes handling the payloads much less error-prone. The CoRE WG is not the place to develop YANG modules that match this functionality. A group will initiate the steps toward a new WG, tentatively called Yang Of Things (yot). * draft-ietf-core-dev-urn-02 was presented, with a focus on the small changes needed for alignment with OMA LWM2M. There was some support for this alignment in the room. Jari Arkko will coordinate with OMA and report back. (end of Monday meeting) * draft-ietf-core-senml-16 is in AUTH48 as of 2018-07-19, RFC-to-be 8428. * A quick heads up from Roman Danyliw pointed to the 2nd WGLC of DOTS signaling draft-ietf-dots-signal-channel-21, which uses CoAP. Interested reviewers were found. * draft-keranen-core-senml-fetch-01 found a few reviewers. Interest to be confirmed on the mailing list, in the case of success followed by a call for WG adaption. * A procedural point about IANA registering of SenML fields was discussed. If a registrant is not interested in EXI, no attempt should be made to register a new XML/EXI schema name. Authors to check with IANA whether the schema could be stored with the registration. As the first exercise of the registry went less than perfectly, AUTH48 to be used to add a couple of clarifying sentences. * For stateless forward proxies, there was good interest to explore the option of introducing an extended token. The plan is to realize (WGLC) or dismiss (revert to separate option, now also called Extended Token) before Bangkok. * draft-ietf-core-too-many-reqs-02 has passed WGLC. Authors will fix typos and then publication will be requested (instead of a second WGLC we will use the IETF last call for any emerging WG comments). * draft-ietf-core-multipart-ct-01 is ready for WGLC. As thw WG tends to think this will be successful, early registration of the Content-Format codepoint will now be pursued (following the procedure for this). * draft-bormann-core-proactive-ct-00 received good support. Next step is WG adoption call on mailing list. The second meeting ran over time significantly. The remaining items on the agenda, CoRE interfaces, dynlink, pubsub, and protocol negotiation, as well as presentation and discussion of draft-jarvinen-core-fasor-00, will move to interim meetings. * CoRE will hold regular virtual interims starting from Aug 15. The regular date envisioned is every second Wednesday (with some gaps) at 0800 California time. From nobody Sat Jul 21 05:24:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FEB128BAC for ; Sat, 21 Jul 2018 05:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8ERhgucBf8d for ; Sat, 21 Jul 2018 05:24:12 -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 523FF12F1AC for ; Sat, 21 Jul 2018 05:24: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 0D8DD40932 for ; Sat, 21 Jul 2018 14:24:10 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9E1C726 for ; Sat, 21 Jul 2018 14:24:08 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4c8c:d7dc:98e5:d86]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3A26B2E for ; Sat, 21 Jul 2018 14:24:08 +0200 (CEST) Received: (nullmailer pid 8778 invoked by uid 1000); Sat, 21 Jul 2018 12:24:06 -0000 Date: Sat, 21 Jul 2018 14:24:06 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20180721122403.GA17787@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Review of dynlink X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 12:24:16 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello dynlink authors, These are notes from reviewing the dynlink draft; sorry for not assembling those earlier, I hope they are still appreciated. The document I'm reading is is post-06 git version dc0bbaff1. Observation attributes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I'd like to refer back to one of my earlierst mails on this mailing list at [CA2013]. The answer to "why not just observe as it was in earlier drafts" about cachi= ng was not really satisfying, given that this scheme breaks caching just as the original but just worse (previously, a cache would just not have a response ready; now, it sees an observation and thinks the value is current where it's actually from an observation to a client that's not interested in details). The way of PUTting empty values onto query-parameter identified resources is incompatible with multiple observations. Moreover, its use is unclear to me from reading it. The sentence "These query parameters MUST be treated as resources that are read using GET and updated using PUT" seems to indicate that they are used like this: | GET /temp?pmin | 2.05 Content | Payload: "0" (or however undefined is expressed there) | PUT /temp?pmin | Payload: "10" | 2.04 Changed But "Multiple parameters MAY be updated at the same time by including the values in the query string of a PUT" makes it sound like it should be | PUT /temp?pmin=3D10&pmax=3D20 | empty payload | 2.04 Changed -- are both permissible? And if only the latter: How is this accessed with GET? Examples might help, but explicit words would be good too. Another open question is how to turn those limits off again. Would I just DELETE the resources?=20 This was all a whole lot clearer when one could observer | GET /temp?pmin=3D10&pmax=3D20 and have those limits per observation without any new state introduced to the server -- a behavior I would still prefer to see there. [CA2013]: http://ietf.org/mail-archive/web/core/current/msg04270.html Observation attributes in bindings =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D There are two components in this document I percieve as relatively separate -- the link bindings, and the limiting attributes. Link bindings work well on their own. With in-query observation attributes, there would not be any need to define the attributes additionally as link attributes (where, judging =66rom RD discussions, it can be confusing to have both). Especially troublesome about the attributes is that they are not target attributes, but link attributes. (All other common attributes in link-format documents are target attributes, with the exception of anchor=3D and rel=3D/rev=3D which are core to the web linking model). That means that using other web link formats (eg. CoRAL, RDF; don't know about HSML) will have a hard time expressing those. I think that non-target link attributes should be limited to data that is meaningful on the web linking level and not for arbitrary attributes. Mandatory and exhaustive bind attribute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that there are several bind methods missing: * "Observe+Push". The device executing this binding has neither source nor destination resource locally, but will observe (or for a "Poll+Push", poll) the source and PUT to the destination. This is useful when two devices are to be connected, neither of which has a binding site, but a device between them (eg. a border proxy or home access point) does. * "Native". Used for resources on the same server. Neither, or both, of observation and pushing are applicable here, but it's really up to the server whether it establishes either, short-circuits the resources in software or (in case of a gateway I worked on last year) configures the bus represented by the resources to link those. * Possibly "On-Demand" (not fully thought-through). When the destination resource is queried, the binding site issues a request to the source resource (or uses a fresh cached state maybe) and only responds when that arrives, or establishes an observation when the destination is observed. (Note that an actuator resource behaves like the hardware has an observation on the resource, but that's not the case for all resources, and the client might even allow creation of destination resources). In general, I don't think that a bind=3D attribute should be mandated. A binding site with the source local and the destination remote will know to PUT the data, and a site with the source remote will GET+Observe anyway if it can, and fall back to polling if the observation is declined. It's useful to have the methods named and discussed, but I doubt the need for them to be present in the actual transmitted data (especially as link attributes, see observation attributes) -- and what would happen to a `POST /bnd: ;anchor=3D"/a";bind=3D"push"`? Is that 4.00? That brings us to... Error behavior of binding tables =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D How would a binding site react to * unknown/-implemented schemes? * permanent or intermittent network unreachability? * all kind of error codes, especially 4.01/.03? I don't expect a full treatise of the ways a binding can go wrong in the document, but at least the issue of creating a traffic storm in response to an error, whether an error can make a binding just disappear, and whether the binding site can indicate any error state of a binding should be covered IMO. Assorted =3D=3D=3D=3D=3D=3D=3D=3D * boundTo is capitalized differently. * "The binding conditions are mapped as query string parameters (see Section 4)." =20 Ie. by the time the binding is established, the binding site PUTs the parameters the destination resource? Would it need to do that whenever the observation is set up, or only once? (That's probably a point that could go to to the first section too: there's no text about persistence of that state. Is it soft state? How does the client know?) * "A resource using an interface description defined in this specification and marked as Observable in its link description SHOULD support these observation parameters." The only interface description defined in this specification is core.bnd, and while it does make sense to observe a binding site for monitoring purposes, most of the observation attributes are nonsentical on a non-numerical resource. Could this be a leftover from when this was a single document with core-interfaces? * links-json will hopefully pass some time soon. Can those formats be used with dynlinks (subject to advertisement in ct=3D and content format negotiation, of course)? Summary =3D=3D=3D=3D=3D=3D=3D Many of the issues described with links were not present in the pre-2013 way of passing observation parameters as query parameters to that observation; I recommend that that way be re-evaluated. I see much value in having the both bindings and observation thresholds, and the semantics of the threshold parameters (band etc) seem to be mature by now, but I would ask for in-depth discussion of the above points. Best regards Christian --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAltTJd0ACgkQOY0REtOk veFfURAAhbUmR4WB7bvPYR0XFLDcomzNQQzPPVE4HmmJVa5D2+mCN2+YKPTMPuZQ S5chnuj1cKDKUPbTqNf+n3Dp6H7SSkhrSmVhtOTFq1+DiIK8LSSU51Plp2x7TSTX fEur/J6U5UtmOeJqcDSmeRSQVv0hiXhbXPyqqlG8eXdYBtNMnRSD/x1MI8Yp9JWH l858Lgb/2sboFWDPWLHSa8hlKM4w4NidIE7h7DjilXFq2bxJAp8RnULQlfP9mX4N uKcWlO9nZLu7+lA2Bb0JnnV3uaOtVF9QoLGHiMGfIl2MnsahFHCPh8slqubYF/a6 8EGk6k8aj0x4VGFikiwpjqmHocBqQ8tN6qfIQoi/D6NHiEjZeCq5s4LMo4ALMtFs klTqS7dDuYo4rkMi7NKJc90BFLkVQEJVFN5T1Y0c94rfZG0F3ApjBVrPnYsdE2fI ZaBCq7kk3YVBNXl5Yxf0GxQKHNOUUc6ijs64wJG25LeEZLxlZnLXWCU8nVhwKd0Y gErbxDH/nzif1W3vJPjJfjp95C2NekLQAIEqFO4rD76CR6URct2DgYex+24t/ZMg Knd80++mYoOiM2OxmHRAt0okNOf4qpxVTIbTP0uJRnmfQ8Bdr+45UZun0rtcyOoT k7CuFxzyUeDvNjMX0b39DdEcCDLbSc8CdHCZfAoJlrL9Vm+01ik= =zKXc -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From nobody Sun Jul 22 01:54:16 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2352712872C; Sun, 22 Jul 2018 01:54:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <153224965510.22962.4995458745738185408@ietfa.amsl.com> Date: Sun, 22 Jul 2018 01:54:15 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-too-many-reqs-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 08:54:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Too Many Requests Response Code for the Constrained Application Protocol Author : Ari Keranen Filename : draft-ietf-core-too-many-reqs-03.txt Pages : 5 Date : 2018-07-22 Abstract: A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 22 01:58:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9D12872C for ; Sun, 22 Jul 2018 01:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 HusXOkZMysJJ for ; Sun, 22 Jul 2018 01:58:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336A5130E6A for ; Sun, 22 Jul 2018 01:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532249905; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LG0wZ2cj1Tr5CZXzJls13bidXNvDKTmesrpu5X5vzag=; b=TeZ85lPM7dznXHNdwZ8IO5e/MIlSgU0nwoWxnED9w1qEMAjFezO2yn7FJRA3FNho WAcJOCPSNq9NWkV9UIQrke50YZb0jJt+sK9V+s87kePiyVrEMFip2cTXLBRNK95f wixXr6ZIG2m7C/o8fKmLHZEgoFIm/au9AKPQFT9lBjc=; X-AuditID: c1b4fb30-1f7ff700000059c2-b0-5b544731e8d2 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.CE.22978.137445B5; Sun, 22 Jul 2018 10:58:25 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 22 Jul 2018 10:58:24 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Sun, 22 Jul 2018 10:58:24 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-03.txt Thread-Index: AQHUIZmXj9f55ZjAWUaLBvwQsznsmqSaz5AA Date: Sun, 22 Jul 2018 08:58:24 +0000 Message-ID: References: <153224965510.22962.4995458745738185408@ietfa.amsl.com> In-Reply-To: <153224965510.22962.4995458745738185408@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5B0D1CCAAAC3AA45949985E8148B1AC4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbG9StfQPSTa4PdPcYt9b9czOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+SCu0wFm/krvl0/xtzAuJKni5GTQ0LARGLGzOssXYxcHEIC RxklmuZOYYNwvjFKPFy9ghXCWcYo8fn9PnaQFjYBe4nJaz4ygtgiAhISnV/3A8U5OIQFXCQm /0+CCLtK3H79kAnCNpI413ISzGYRUJXoXrmLGcTmBRpzdG0zG4gtJOAssWTtCjCbE2jMxj+9 LCA2o4CYxPdTa8B6mQXEJW49mc8EcbWAxJI955khbFGJl4//sULYShJ7j11ngajXk7gxdQob hG0t8WDZIihbW2LZwtdQNwhKnJz5hGUCo9gsJCtmIWmfhaR9FpL2WUjaFzCyrmIULU4tTspN NzLSSy3KTC4uzs/Ty0st2cQIjKKDW34b7GB8+dzxEKMAB6MSD6+JdUi0EGtiWXFl7iFGCQ5m JRHe2s7gaCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Fn6bo4QE0hNLUrNTUwtSi2CyTBycUg2M jtEa81cUt6Xv3s9m7wGE80/fcH/wUuLpmr37bwTIlv3uCHki8N794iFB5gd2uzfzcp/xY5nN 8ctf1aRDWOboU9v9uf1ftE1kYhO6w3Qs73QK/hTSmpfp3PprT6zCzjvMUzZobhFJcBOYU/98 dfzLw48+FgpUixxjDdp6W0hhp/X8vx3hD5RYijMSDbWYi4oTASv/hoWeAgAA Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 22 Jul 2018 08:58:31 -0000 This update fixes the broken sentence and clarifies the similarity of reque= sts, as discussed in the Montreal meeting. Also the RFC2119 boilerplate was= updated to the current one. Cheers, Ari > On 22 Jul 2018, at 11.54, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > Title : Too Many Requests Response Code for the Constrai= ned Application Protocol > Author : Ari Keranen > Filename : draft-ietf-core-too-many-reqs-03.txt > Pages : 5 > Date : 2018-07-22 >=20 > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-03 > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Jul 22 02:11:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD91F130E58 for ; Sun, 22 Jul 2018 02:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zayGaviEkoKi for ; Sun, 22 Jul 2018 02:11:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5267B127598 for ; Sun, 22 Jul 2018 02:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6M9B1qO008151 for ; Sun, 22 Jul 2018 11:11:01 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41YJks0glgzDX39; Sun, 22 Jul 2018 11:11:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sun, 22 Jul 2018 11:11:00 +0200 X-Mao-Original-Outgoing-Id: 553943458.797886-332d7bea39f5840c67850ad4437bdd8d Content-Transfer-Encoding: quoted-printable Message-Id: <69F8CD2B-780C-493C-9DD2-DF2DDDC51074@tzi.org> References: To: Core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] CoRE@IETF102: Summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 22 Jul 2018 09:11:08 -0000 On Jul 20, 2018, at 15:15, Carsten Bormann wrote: >=20 > Session 2 not yet available Now at: https://www.youtube.com/watch?v=3DM0XfeVynCAY Please keep the fixes and updates for the summary coming; minutes based = on that will be posted soon. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 22 13:12:08 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92663120049; Sun, 22 Jul 2018 13:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxYCIzKdPD5d; Sun, 22 Jul 2018 13:12:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EABD130EC6; Sun, 22 Jul 2018 13:12:04 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 22 Jul 2018 13:08:27 -0700 From: Jim Schaad To: CC: 'Core' Date: Sun, 22 Jul 2018 13:11:57 -0700 Message-ID: <00f901d421f8$3f6310d0$be293270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdQh01bZVq4NgnJpThmQICdlENWX5w== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Review comments on draft-ietf-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 22 Jul 2018 20:12:07 -0000 1. Welcome to the world of how CoAP defined resolving of URIs. RFC 6690 either did not do a good job of explaining things or got them wrong. There is a special case for /.well-known/core in terms of how the resolution of links are done. As I understand things if you do this GET /ps?rt="temperature" And get back in the content ;rt="temperature";ct=50 When you ask for the resource you will look in the following address GET /ps/ps/currentTemp This is because the URI is resolved against the origin of the target URI and not against just the authority part of the target URI. Note that this is the case for /.well-known/core. I don't know how you want to address this. I am not sure that anybody has actually implemented what the RFC says, but I also don't know if anything other than /.well-known/core and the RD have used this feature. RD "gave up" and said that everything returned is going be resolved by the RD before sending it back. 2. It is well defined that one can not create a multiple level new topic using POST to a topic. It is not clear if one is allowed to have more than one item in the link format description for a CREATE operation. POST /ps/ ";ct=50,;ct=40" 3. In section 4.3 in the discussion of garbage collection. If the broker does not retain the most recently published value, what is the correct response to return in a subscribe/read request? Is this to be treated as if the Max-Age had been exceeded? These are just from reading the document. I have not yet gotten to the point of trying to update my implementation. Jim From nobody Sun Jul 22 13:47:59 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC69E130E11; Sun, 22 Jul 2018 13:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLo-Ynlcw8LN; Sun, 22 Jul 2018 13:47:55 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BAB130DCE; Sun, 22 Jul 2018 13:47:55 -0700 (PDT) Received: from mail-qt0-f173.google.com ([209.85.216.173]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fhLGh-0006VH-P5; Sun, 22 Jul 2018 22:47:51 +0200 Received: by mail-qt0-f173.google.com with SMTP id a5-v6so14781761qtp.2; Sun, 22 Jul 2018 13:47:51 -0700 (PDT) X-Gm-Message-State: AOUpUlHyfyzQoppZWypMr5flfQS6XwijT2i44qGRHn93PlsNo1M36rXA IHEAXWQN4zRTGklJXVbZyCF+Jxs2+zFqPO6O7pc= X-Google-Smtp-Source: AAOMgpdaLgd4tcx7l8PRpcvpoRwOyGO44Dbbk/tEDBj96DlW5q0a9jRrhFPxY99cVeugNHUubNfKMO/7a1e4pKhYoSE= X-Received: by 2002:a0c:f643:: with SMTP id s3-v6mr8904773qvm.131.1532292470736; Sun, 22 Jul 2018 13:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:d04c:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 13:47:10 -0700 (PDT) In-Reply-To: <00f901d421f8$3f6310d0$be293270$@augustcellars.com> References: <00f901d421f8$3f6310d0$be293270$@augustcellars.com> From: Klaus Hartke Date: Sun, 22 Jul 2018 22:47:10 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: draft-ietf-core-coap-pubsub@ietf.org, Core Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1532292475; 49a9a1a2; X-HE-SMSGID: 1fhLGh-0006VH-P5 Archived-At: Subject: Re: [core] Review comments on draft-ietf-core-coap-pubsub-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 22 Jul 2018 20:47:58 -0000 Jim Schaad wrote: > 1. Welcome to the world of how CoAP defined resolving of URIs. RFC 6690 > either did not do a good job of explaining things or got them wrong. There > is a special case for /.well-known/core in terms of how the resolution of > links are done. As I understand things if you do this > > GET /ps?rt="temperature" > > And get back in the content > > ;rt="temperature";ct=50 > > When you ask for the resource you will look in the following address > > GET /ps/ps/currentTemp Is this really true? I didn't read RFC 6690 for a very long time, but this would be really surprising. From a quick glance at RFCs 6690/3986/6454 I would assume the following: * Reference resolution has two inputs: a URI reference to resolve and a base URI [RFC 3986, Section 5.2]. * Since the above link does not have an anchor parameter, the base URI is the origin of the target URI [RFC 6690, Section 2.1]. * Assuming the target URI is , then the origin of the target URI is the triple ("coap", "example.com", 5683) [RFC 6454, Section 4]. * This presumably means that the base URI is [??]. * Resolving against results in [RFC 3986, Section 5.2]. Klaus From nobody Mon Jul 23 01:51:05 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC3130EA4 for ; Mon, 23 Jul 2018 01:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tutfi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48tkNX4dPLVL for ; Mon, 23 Jul 2018 01:51:00 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9430E130E5C for ; Mon, 23 Jul 2018 01:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tutfi.onmicrosoft.com; s=selector1-tut-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mDsYwLmG+wec7gA0n6B86sbP0UoA0fPDEYN4hAOc4gs=; b=ekgMmY/y6e8vWWYj3iM4P+csVykyAW2QMWPULbxFnUSgAoFLBdC5OIksuOgnejJoWZR3DHrSR8C6ld9LNceK39HtlQYkHtVOoiqmyXzGT39bESdAPal2VfjdfodyB3Lq2K4WIWF2kQpJXzsSrZR253Y80rFd5vky9KCfQ6dJcOc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=bilhanan.silverajan@tut.fi; Received: from dyn-152-112.public.tut.fi (2001:708:310:156:a168:9b29:1845:f9ea) by AM5PR0201MB2371.eurprd02.prod.outlook.com (2603:10a6:203:33::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Mon, 23 Jul 2018 08:50:54 +0000 To: core@ietf.org References: <018f504348d7d168df65951dae5a44a4@bbhmail.nl> <8a5f01b18f574ed6a6724dc49e4e47e6@ericsson.com> <041cdbf4a822a5879f8236a90eb13bc5@bbhmail.nl> From: Bill Silverajan Message-ID: <1d218650-9dde-0e1b-f177-5c5566cdb955@tut.fi> Date: Mon, 23 Jul 2018 11:50:44 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <041cdbf4a822a5879f8236a90eb13bc5@bbhmail.nl> Content-Type: multipart/alternative; boundary="------------37258C5CACED9774ACCFE205" Content-Language: en-US X-Originating-IP: [2001:708:310:156:a168:9b29:1845:f9ea] X-ClientProxiedBy: DB6PR07CA0010.eurprd07.prod.outlook.com (2603:10a6:6:2d::20) To AM5PR0201MB2371.eurprd02.prod.outlook.com (2603:10a6:203:33::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d1ba9ef-5bfc-4b29-6fa7-08d5f079669c X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM5PR0201MB2371; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0201MB2371; 3:Hih/th5wDMGhtEOzLKIaqYXdwnRCLSjyRbAVFoP7VcfuxqDeIPR/TUIWv+FJeNmu+M75G9tIx0FObXDvwSbJU6nXOVv7kGmokPgQQPpiiqxJOvQy9nmLDrPjiMtH5aEt86faCd2nN3K4v15iuZCDje+3ChKJgYdsOQDHlIv7cZx5kWQnYhoexVS1S6G7wlJLJalQ8oqzj/48NwBBDloLhqNjztrWzOg4zvKTH42+eRxHbonar8+ZWptJbog19R9m; 25:CBhhozEZ20THfNCYmFlIxeBMc+uzfa015FhmlS7GDjHJ6M2MSAo9lVatCuol4c9sAk0kdltwcA99sAZ3RHt9HI36nwFyZuEapgKrUM9P/uEANkDnezYGxmfmsqpiPZhUwd87MQ9ySxJkcsga2aSeVkzgSx5VKTQZxanTeuzLhndM/vExOaLfu1ZYDUe/Q1VVs96NYxmKxUxQJtuxSzVcH11rHSEqrmQI2VxSU2NhhjjqWJQGVM0mnVC+KmrRDwJyf3FY3aVJFFWVZMjduONwWgvwsZK1u/7vIW154fxEF4yO+BlHs8YnrX1YLMX/iI1ItlNCQJF0vJhJvVSXWZrRQA==; 31:sGc6XA8fNbsKwY2Ov0e2iw2OE1cu7b3kYH5fFQblHwtIg/yPeiAqq5oqBuC+H75qWYK+aOXRXY/RE+/0EO4t/uSgasKJXI5cv+kaf9Jmo6px07LBEPhqVXb6mbW94Be39TSzubz3RScC0zUQHsl+ZRaGekawAtRi0RuFtIE5+8TIFxBYqRUr5N/L1WP4uMduCFjSA4ANmC/FwYXnzOzV673ySpXRoWNky5l4CIJ4RR0= X-MS-TrafficTypeDiagnostic: AM5PR0201MB2371: X-Microsoft-Exchange-Diagnostics: 1; AM5PR0201MB2371; 20:8OsygQxclvuZWk/2lZmmBF7oz14oOvIOEJd3S5GsUW7k1OcFNCDI0+MSw6O9d/PNba5wtMIDnHODNreKKRwHqHjhlweqaln7SObpbMksEo99NapKa8a9u9Y9FSmMA03NBxtOoCfBk8RbP8rBTHalCmOPAiazIC/W9unPDP6EqKCjQ9AN9i+U1jzz0wUqejXhu3fJHLeV4UtXUaQ0+vStu1hYaMw/tdA2XuiUt+TKY12OltumRrnKBeR3KANu8TS6nWRMJq+xkEJnqbZWwDCCUXi1XJ4YzRYQn7A/lLUUPFEWi6O5S88AVu4uahzHob6pXufM/0YDsgJLQJh1C3jOEw==; 4:8pmWKuHmIFpWhejsPUFZfcHJOp+DWlw3Zpmm2iubpIq8xkVLDXOMxadfHqgIytgTXSv/oKSB5lMYDxkxGYykYmuu+0eeYPbC2s6V8SiodCHhLxG/lXxOywJqZmKn1/syvaXEctxJf8Q3XtMzL3OP6ZfXMEEKC/Wkpi4tYhPPjHiWwYyHFIg0njvBp3zm29RaoxM4cGEdgH7UvXBkqj9gN6AMswny3zbgxY7IWCiI1SuKRIh6niZAzJGowp37ztylZGxhLhvYtm+QZCwlNQtmZsDXHlyWRDKrvhy98mZXep8FeOXpBC6G8osCcgQHF/XL X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0201MB2371; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0201MB2371; X-Forefront-PRVS: 0742443479 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(136003)(396003)(346002)(39850400004)(366004)(376002)(199004)(189003)(25786009)(6306002)(316002)(58126008)(65806001)(65956001)(54896002)(786003)(37036004)(16586007)(6246003)(53936002)(52116002)(7736002)(53416004)(76176011)(8676002)(64126003)(7696005)(2361001)(2616005)(6116002)(6666003)(68736007)(33964004)(476003)(31686004)(270700001)(33896004)(6486002)(8936002)(6916009)(52396003)(236005)(5660300001)(2351001)(2906002)(966005)(606006)(11346002)(69596002)(84326002)(65826007)(446003)(74482002)(486006)(105586002)(31696002)(86362001)(81156014)(186003)(16526019)(386003)(229853002)(53546011)(97736004)(36756003)(46003)(106356001)(81166006)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0201MB2371; H:dyn-152-112.public.tut.fi; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: tut.fi does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0201MB2371; 23:Bh0wd70wD2xe0rh/DGqwtmsuzXR4YHFCVnpP280?= =?us-ascii?Q?EVf+zwhlt8LbF4+XqCZQ6p3dUvG783M5D+NfDeS01Ur/uBppo2AEwCBP+lYH?= =?us-ascii?Q?/fCXvrK5rOk8ORj79CMAebDxDorKNZ1ZQsuDTl9J8bzial1+Vi4mYV5gzI3M?= =?us-ascii?Q?UozPE1dhmbciInOI5NbU27kMO7k7BKkNUa5CA2Her3YlxYqtasGMy3GUrDx1?= =?us-ascii?Q?/7D1jIcqfXoCJESDLC29Tgph5pxRAoiFMtwv5X/dAKV0EP2AaPU8cUrw4HLn?= =?us-ascii?Q?g6QA4rW65yCeWMAF8x1xbZ8CUKbEYx7MfHRS0/K9Uk8qFpyJ4kxTE3oW3zjD?= =?us-ascii?Q?nwKG4ycc8MpotbXxyP8WUVJ+9bJ3fn1JECpdVeBogQwHe9REphCwfAU7LQP9?= =?us-ascii?Q?isgmAWGSrRB6paClPYbtsUjpRZc/2vgcDSIRvVs22lGa8cpBwffHiRPXyJKe?= =?us-ascii?Q?VJO8tRhbW7XCSHEgbOjbk/F82HQaL3xdJBqWysLrbGtZVw2shdRmcF7r3Sm5?= =?us-ascii?Q?0XkqsgCp8YcZY6I6aUFIdE6YT75YDKcgjzP8YIRaH9zF0Her7mIxFX7imwfJ?= =?us-ascii?Q?N66WHOwvgsAo8hmG4JUQMlHuLRsL/sEs1r9b0HW+5yb3BqM1w1IftRLZFJ8v?= =?us-ascii?Q?lsC3CZibg/m+/MYB9BpQLf8vW3h52wBqGweW/gYgbV//8zPs2I8YsGN77No1?= =?us-ascii?Q?Rm0WNwcW5NDtFjSu7YpfkHPFpM9tLkgBfKuRVVOHHKustqUVhC2jhzamC+W5?= =?us-ascii?Q?D9pnhlWrvadMG6blQUZFMHFGuSpPSKwCSqZtJ1TboFp6vK+KMwcMONIOMklq?= =?us-ascii?Q?7mO99FKpw+P8YGqUDucwABEnKoRP0TvNlH5I8q5/or2ftH+WpvDnKcs1pEpV?= =?us-ascii?Q?QqdUmGP6tbFn/a28ZtOnmf3u+dYCVHF9eFhTIDkbLTPyOesSwzreOhc1efP5?= =?us-ascii?Q?vVZmbviZR6qZoGfjL+9AsAuAX639JmkS8830xpK3lgv4TEuTlVTfoigceay/?= =?us-ascii?Q?3t474+Zlw2u3FJe0qSe0fcR34BbzE+WAhv2QptDdN1ur/Nkh4Z4IpJKCouBM?= =?us-ascii?Q?ng+qply5Ety9Wbyo+7esoVTc4p1LBVRImou6h/WwpYp6Yr2bbdde95b2wm7g?= =?us-ascii?Q?ltyO/V2YewACPQqiYOvnYUrv0uH/tSi+PSQwcq2DcR12L71hBm9jcselBjk0?= =?us-ascii?Q?UuulOoB1E649lz2xvszZp6JpYwvTsp+M37frarn0g+tycb8PbMKc6N7Iqc1c?= =?us-ascii?Q?2dNfLChJSibDi2SDbG0LFCPCKA+sCXQj67hMhi+36M+t6iGpRDEYN4wT05a/?= =?us-ascii?Q?IVK63QQ+nE+xnoRWAh8ewGu69BuxVJsIRNCxS3hBOaU7Pc4s85H2ZRgAe/zY?= =?us-ascii?Q?bThQa0IPLdWU638fXEn0E8M1TF8VbgFqAGoYQIZ0U7avzEuro7AxCUweA6GE?= =?us-ascii?Q?GOnCJ7l4N+8BbpG/ygRlGyc+3yJ1ZS2XtDB18hiG9SD+4WTJt/lwfB7yGdpc?= =?us-ascii?Q?QhGpUG0o/1fcScg=3D=3D?= X-Microsoft-Antispam-Message-Info: RWOw5r8erSbJJjx4YGluzA7t6jgxq32vnBwmkaZ2Svuyx+BSmP8kmvK1DryqGKv10T5aSvcySJGMSIr77A+aE1GOaoZxSL66GkoE+1CzW5yXuqtUnYg64V1OqWjF2447XTWNIjZ5f9Zo0Ve4FZ/1Mh8p15N/+re56uiNDkZGgOg0mm1zCVh5obie9SQp4SLrbShz5tUsoGfVEOJgM7sCvaSSjYylkDz5hflllUdrZXNfhnM91MCQQ12/uFnalKGvfvRJaTIlviyUymgbFpiRV6EO/b6ghh+W04Y5SweyIMO0p7QtWjjVmS/fDZSNaDl8xeYdZeHuxvs6bvHhtWiGLedzZ7dQuN+pJFxhsifIehQ= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0201MB2371; 6:gzlGzaNQTYre0/lvBoVZSiyR4PBVHftjltjEi6xPptJVsTH1TQc2xQisu39vklK/LRj57fszuQUE6Bev5I3flz9NRNso12q3wDREckIcX1r/hBcWSQysCr/jgZGt0zEu9ChPOPx5dczicQi2x7CdPfJZPjfXIScbrcqyJj6NebFUaDbY6ZRrj2JBrhSq8JI+JSmHEjdep67A8zF2xyKvVX+Pb+8xyR4CqsRIqoH2kzftXtbvf7YBBJtblp2m+NGM/ufs7C0h/WpB9oxnnGrj/H5rxQ9Y23dqoq8MpipzI8VY75mSweiUn7+xjqB+nIbJ6Kn6hZzWxJ4FSUoTNvukgeAY5oeKHLAgsftdD6YsRMvEBucfwIx0E78UlzE3bmH86SwqBRYQ1FqdIn2JJboIYShx6szbJb7tfGxflnhri3t+IX9hSTRwrTVJ7bipDhLAh8GPVnalancImO3i78qrjQ==; 5:cZq8gCMobJz3iADibldAKPHf+IYIbJLoJfUTaG8xisQTuHEJeuUHXQPEsrqR6SqkK0EtqFC1tFppuzYJ0pJG+7XxF0E1kbvVPkrNJ7uQDg98mJDVBxC/y1WBOEKUibkTx/tDUh2uEok9so2WsdZdiYCCx1Q31rUlCVaGRXN4fXs=; 7:waRs11wPLSJTv0wCIZy5sWgIdorwauVjIOsFbJnGPK78lOtBKgQg52Kx3w64s2vwlInIouHCCgDNkSw6S2N/HmqJUgXELtBSPqzB2av1G1gL4egy5850kkic8kt/Kmnnm1Sjm6DWAtuM+BAicGT8Xovr6z7IbQITG8schYeogF9/ittr9pjEkUZVuB9JKIjgLASVzteyClF9kUfVolQRQ8SlpRVxX46gMgUFzEDhDS9XYcfLWy141roj/wwoOOa+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tut.fi X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2018 08:50:54.3530 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8d1ba9ef-5bfc-4b29-6fa7-08d5f079669c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 271a0e2b-2a07-4d45-840b-ca860972fd60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0201MB2371 Archived-At: Subject: Re: [core] ue of resource type in collections X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 08:51:04 -0000 This is a multi-part message in MIME format. --------------37258C5CACED9774ACCFE205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Peter, I have admittedly not gone through the coaps-est draft in detail, but draft-ietf-core-interfaces-12 provides a way to define and use resource collections, as well as items in the collections. Additionally both RFC 6573 as well as RFC 6690 discuss resource collections to a certain point. The resource collection in draft-ietf-core-interfaces-12 provides a flexible entry point, and each item in the collection can still retain the resource type "ace.est" Best regards, Bill On 20/07/18 14:56, Peter van der Stok wrote: > Thanks Klaus for the comments. > The new resource types have to be registered, and can then be used in > an interoperable way for discovery. > That makes it difficult to not prescribe them in the draft. > Given that some of the resources in the collection are not compulsory > to have, > I will provide the more extensive example no 2 in est-coaps. > > Greetings, > > Peter > > Klaus Hartke schreef op 2018-07-18 11:00: > >> Peter van der Stok wrote: >>> The coaps-est server uses a collection of resources: >>> The collection resource has been assigned rt=ace.est >>> It is not clear what the resource types of the underlying resources >>> should >>> be. >> >> According to BCP 190 [1 ], the >> coaps-est draft should not mandate particular forms of URI >> substructure. So a server should be free to structure URIs as it sees >> fit, e.g.: >> >> ;rt="ace.est" >> ;rt="ace.est" >> ;rt="ace.est" >> ;rt="ace.est" >> ;rt="ace.est" >> ;rt="ace.est" >> >> If a client has trouble selecting the right link from the above list >> (and they all look interchangeable to me), then you'd need to provide >> more specific link information, e.g.: >> >> ;rt="ace.est.skg" >> ;rt="ace.est.crts" >> ; rt="ace.est" >> ;rt="ace.est.att" >> ;rt="ace.est.sren" >> ;rt="ace.est.sen" >> >> Klaus >> >> [1] https://tools.ietf.org/html/bcp190 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------37258C5CACED9774ACCFE205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Peter,

I have admittedly not gone through the coaps-est draft in detail, but draft-ietf-core-interfaces-12 provides a way to define and use resource collections, as well as items in the collections. Additionally both RFC 6573 as well as RFC 6690 discuss resource collections to a certain point.

The resource collection in draft-ietf-core-interfaces-12 provides a flexible entry point, and each item in the collection can still retain the resource type "ace.est"

Best regards,
Bill

On 20/07/18 14:56, Peter van der Stok wrote:
Thanks Klaus for the comments.
The new resource types have to be registered, and can then be used in an interoperable way for discovery.
That makes it difficult to not prescribe them in the draft.
Given that some of the resources in the collection are not compulsory to have,
I will provide the more extensive example no 2 in est-coaps.

Greetings,

Peter

Klaus Hartke schreef op 2018-07-18 11:00:

Peter van der Stok wrote:
The coaps-est server uses a collection of resources:
The collection resource has been assigned rt=ace.est
It is not clear what the resource types of the underlying resources should
be.

According to BCP 190 [1], the coaps-est draft should not mandate particular forms of URI substructure. So a server should be free to structure URIs as it sees fit, e.g.:

</a>;rt="ace.est"
</b>;rt="ace.est"
</c>;rt="ace.est"
</d>;rt="ace.est"
</e>;rt="ace.est"
</f>;rt="ace.est"

If a client has trouble selecting the right link from the above list (and they all look interchangeable to me), then you'd need to provide more specific link information, e.g.:

</a>;rt="ace.est.skg"
</b>;rt="ace.est.crts"
</c>; rt="ace.est"
</d>;rt="ace.est.att"
</e>;rt="ace.est.sren"
</f>;rt="ace.est.sen"

Klaus

[1] https://tools.ietf.org/html/bcp190


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

--------------37258C5CACED9774ACCFE205-- From nobody Mon Jul 23 02:56:05 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49919130DEB; Mon, 23 Jul 2018 02:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcEh3po8CrJM; Mon, 23 Jul 2018 02:56:02 -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 1FC49130DE8; Mon, 23 Jul 2018 02:56:01 -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 F14B140936; Mon, 23 Jul 2018 11:55:58 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 550B026; Mon, 23 Jul 2018 11:55:57 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:41a6:be99:4801:9fb1]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EBCA479; Mon, 23 Jul 2018 11:55:56 +0200 (CEST) Received: (nullmailer pid 21372 invoked by uid 1000); Mon, 23 Jul 2018 09:55:56 -0000 Date: Mon, 23 Jul 2018 11:55:56 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Core WG mailing list , draft-ietf-core-interfaces@ietf.org Cc: draft-keranen-core-senml-fetch@ietf.org Message-ID: <20180723095555.GA5571@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [core] Review of core-interfaces-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 09:56:04 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello core-interfaces authors, these are my views on core-interfaces-12 as promised in London: Gradual reveal and RFC6690 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D What are the supposed semantics of the links in examples 3 and 4 of 3.6? If, being fetched from a collection at /coll/, they are * ;anchor=3D"/coll/" and ;anchor=3D"/sen/", respectively, then you're not using RFC6690 link format but Modernized Link Format as described in resource-directory; if they are * ;rt=3D"temperature" and ;anchor=3D"/sen/", then you're using the mental model I had of RFC6690 before Jim discovered in London that RFC6690 Section 2.1 says Origin with a capital O. My recommendation is to explicitly use a RFC8288 compatible interpretation by saying that all link-format documents on the core interfaces are to be interpreted as Modernized Link Format (better names still welcome) as described in resource-directory. (The second best option IMO would be to follow RFC6690 to the letter and have all links relative to the host root directory aka Origin). SenML and base names =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The SenML components appear to assume that the Base Name (bn) is implied to be the obtained document's URI; this is no longer the case since SenML -08[1]. Thus, a batch (like the example in 4.2) would need to have a "bn":"coap://example.com/s/" attribute in its first entry. Linked batches can not have their requested URI in that place (as SenML rules are only about string concatenation; if applications think in URIs, they must accomodate that), so their bn must be "coap://example.com". Thus, appending "/s/light" gives a good URI again. [1]: Until -07, it said that "If the object is a representation resulting from the request of a URI [RFC3986], then in the absence of the Base Name attribute, this URI is used as the default value of Base Name. Assorted =3D=3D=3D=3D=3D=3D=3D=3D * Updating links with merge-patch and PATCH ("Links in the collection MAY be"): Is this fully thought through? In RD we decided to delay that part until someone figures out how to correctly manipulate parts of a collection. The approach of putting query filtering in is interesting, but doesn't paint a full picture to me. With query filtering, can I delete a single link from an lb using `DELETE /linkedbatch/?href=3D/s/1`? =20 Is the client in a linked batch supposed to provide any attributes to the links? (If not, what changes warranting a merge-patch can there be made other than adding and removing links?) * 3.7: Whether a collection implements link filtering should be discoverable in some way IMO. How about additional if=3D"core.filter" on those that do? If that is not get advertised, the least that should be done is to say that query parameters MUST be ignored by collections if querying is not supported. (As it is with .well-known/core: Support is optional, but if a GET /.well-known/core?rt=3Dfoo comes along and the server can't filter, it does the safe thing and returns the complete set.) That's for reading; PUT/POSTing to a filtered query without filter support should be 4.02 Bad Option. * Actuators: Is every actuator supposed to support some POSTs? If not, I'd put the POST in Table 2 as optional. Similarly: May an actuator be write-only, and return Method not supported to a GET? * Security considerations: A linked batch can write to arbitrary resources on the server; considerations say something about whether it's the creator of the link batch or the writer who needs to have authority to write to linked resources. (It's a bit like with dynlinks, with only moderate mitigation by foreign links being forbidden. Writing to a linked batch and then putting a large application/octet-stream there can still go very bad.) Do I read this right? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D might be illustrated or made more explicit * 3.5 query filtering (when applied to the items): I like this idea; as I understand, I could do on a batch /b/1/ containing ;rt=3D"some.rgb";if=3D"core.a", ;rt=3D"some.rgb";if=3D"core.a", ;rt=3D"some.dimmer";if=3D"core.a" do a PUT /b/1/?rt=3Dsome.rgb, payload #ffff00, which would set all the RGB leds to yellow but leave light3 unaffected? * In the example of Figure 1, if I did not want to reveal all the /a/ subresources in a step, would there be anything wrong in saying it's if=3D"core.b core.ll"? (Just to verify our common understanding of the text). Small stuff =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * "with a Link List /d containing": It's /d/ in the above example * 3.4 mentions link-format+json, it should probably do the same with link-format+cbor The overall document, esp. having batches, parameters and actuators, has been stable for quite some time, so I expect that the remaining details (above and hopefully from other reviewers) can be worked out swiftly fo finally release this document. I'd suggest it to be reviewed by authors of SenML fetch/patch; it appears to me that there is some overlap to be considered. Best regards Christian --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAltVpicACgkQOY0REtOk veHUJhAAvMlc44Cw9ljCUQNTZK8pgi5upl7NPqid3L2gfuS1JzwrxjZnCK3bjR2C TviM1DttNEj8ZqW9GJ6lFnyGeOwRdNtruAgVKO+8r5BBvUkerWiKUt7hCDhbGGm7 JGdKNiqmlTAsZspiPejwEEk82hQViMnfgLFY4ytkCz9ILAV9Fxr6CKIKdropbW1u i/Vy7rYAPLlTZuEURndRkJ2eZK07MlqzrxK0iQjIBSKX5H8Lq04/xl+unUKo8pxo 8UXDXb4X1Ex882tCiFOlGS/RgvApJwLYva2AVKWAiPRCP8dgSSuXjEZWh9Eg6D4/ CntxoDhxQzPnYSgmx4Ew8n5aEaTzRRHAf54ERKjTVnkSDRLcy2LJiequyugATANF oy8CSuorNgOoxCopcg8kGc7pMLl2tuJLYTujN9SypxU8l/QkkenmVwAOPsf5W7Rj oFiN9Hv3RYBb6JBGJQlGfMLt7rWs9mQ0huFGS/aGX7/PT5RN88Kp3bCQ+7MFZzJ2 QwiMdKOs7cUSkTKmYUwZaCOeI1iwpWiT4amDXWgbLriZL3MNcdUL9Qg3e4oORJpp yKo9LPCUGtZdBzP9pm10aKl7mGgPipujHWdc/mDAJ9Niemb1YvZwiDA5jrIPFKA2 uCnOhW+batAmve0eHSyWfTlSs1R9+/J4Szy3WiOnP5AMCf+RzZg= =/H9S -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From nobody Tue Jul 24 05:35:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EB41310FB for ; Tue, 24 Jul 2018 05:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 g0mF0BzwbcSz for ; Tue, 24 Jul 2018 05:35:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447F71310CF for ; Tue, 24 Jul 2018 05:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532435738; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kpc0iOZl7t49A9B7KktA1g/fskV4Ggz23z/SsI9H/XI=; b=ZWU7/ctYbGjXA5Wnm145JVoONHH/b92e+FA0Cb2eYTL1ZF3pnv88FDZ827W0fNs8 65RUU2Dqr6IhLqr1vFF5iDp6A7WHNZcw2k3vnSUiPb3hYRi7j8CfLCVKtzZ7Oiz7 OV85mnftMApCFYvEYPZ+PCwhpW89TmoPeMymUyD1Mqs=; X-AuditID: c1b4fb25-b05ff70000006cb9-1a-5b571d1a486d Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.BE.27833.A1D175B5; Tue, 24 Jul 2018 14:35:38 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 24 Jul 2018 14:35:38 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Tue, 24 Jul 2018 14:35:38 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: New Version Notification for draft-keranen-core-senml-fetch-02.txt Thread-Index: AQHUI0pq02nqCnKnbU6r1PqRhi9DtA== Date: Tue, 24 Jul 2018 12:35:38 +0000 Message-ID: <0028588D-2FEC-4B28-9141-888C4B3BC70A@ericsson.com> References: <153243556026.22648.13038691247534057394.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2J7ta6UbHi0waH7yhb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRt+yu8wFS/kqGj/MZWxgPMndxcjJISFgIrH21FvWLkYuDiGB o4wSX7b9YYdwvjFKLDz7kxGkSkhgGaPEyUuqIDabgL3E5DUfweIiAhISnV/3s4PYwgJBEptf T2GBiAdJbJ++BqpGT2LKw/lgcRYBVYlDb6cBxTk4eIHmLG4PgBjvJ3Hz0SewEkYBMYnvp9Yw gdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwlib3HrrNA1OtJ3Jg6hQ3CtpZYvbILKq4t sWzha7BeXgFBiZMzn7BMYBSdhWTFLCTts5C0z0LSPgtJ+wJG1lWMosWpxUm56UbGeqlFmcnF xfl5enmpJZsYgbFycMtv1R2Ml984HmIU4GBU4uEV5g+PFmJNLCuuzD3EKMHBrCTCu0gUKMSb klhZlVqUH19UmpNafIhRmoNFSZz3ofnmKCGB9MSS1OzU1ILUIpgsEwenVAOjxt2P56t7N7aY lC75z2mz95TLI/upH9bNkRU/LMEkoO19SHGBV0eRxEHV+Gt3rF4r1Lgb8R0U+Lc0wOWgkEjt IReJfwVSnwqtX70u9WVWeLk3YWpJf/8Xq8xTdeqBcQsl7oY9PXawcV3QM+FSybW50S5Jv/Q/ 9RW7HP/gLW/J7WV+u0hX57kSS3FGoqEWc1FxIgD21nlDkQIAAA== Archived-At: Subject: [core] Fwd: New Version Notification for draft-keranen-core-senml-fetch-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 12:35:42 -0000 This version clarifies the terminology and patching procedures as discussed= in the Montreal meeting. Cheers, Ari > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-keranen-core-senml-fetch-02.t= xt > Date: 24 July 2018 at 15.32.40 EEST >=20 >=20 > A new version of I-D, draft-keranen-core-senml-fetch-02.txt > has been successfully submitted by Ari Keranen and posted to the > IETF repository. >=20 > Name: draft-keranen-core-senml-fetch > Revision: 02 > Title: FETCH & PATCH with Sensor Measurement Lists (SenML) > Document date: 2018-07-24 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-keranen-core-s= enml-fetch-02.txt > Status: https://datatracker.ietf.org/doc/draft-keranen-core-senml= -fetch/ > Htmlized: https://tools.ietf.org/html/draft-keranen-core-senml-fetc= h-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-keranen-core-= senml-fetch > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-keranen-core-se= nml-fetch-02 >=20 > Abstract: > The Sensor Measurement Lists (SenML) media type and data model can be > used to send collections of resources, such as batches of sensor data > or configuration parameters. The CoAP iPATCH, PATCH, and FETCH > methods enable accessing and updating parts of a resource or multiple > resources with one request. This document defines semantics for the > CoAP iPATCH, and FETCH methods for resources represented with the > SenML data model. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Tue Jul 24 06:52:47 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFDC130EB0; Tue, 24 Jul 2018 06:52:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <153244035927.22640.15207006290980496560@ietfa.amsl.com> Date: Tue, 24 Jul 2018 06:52:39 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 13:52: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 : Too Many Requests Response Code for the Constrained Application Protocol Author : Ari Keranen Filename : draft-ietf-core-too-many-reqs-04.txt Pages : 5 Date : 2018-07-24 Abstract: A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP Response Code for a server to indicate that a client should reduce the rate of requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 24 06:54:38 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD1130DD0 for ; Tue, 24 Jul 2018 06:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 peqbZjFd1LQ6 for ; Tue, 24 Jul 2018 06:54:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BDC130ED2 for ; Tue, 24 Jul 2018 06:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532440472; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bFbsdLlTUWLLP9hFotTvs71dLJybgRPcr9FOZvJJJh0=; b=JdOETm3gTBYZuP9vMRp06Cj30alrt70nQaNm855X1da88OilWYGf+TrpR7j6FN8Q QgWE+NxXyiDFHzHDIFyEBbjipcraLDzdp3UJ59iK0MBidgFT1AePYsio9dSBabQa OMqIyNP2kpFLiD3NelhfN8RSErOnY+JAadyKI81s49s=; X-AuditID: c1b4fb2d-20bff700000055ff-9b-5b572f9809bc Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.C6.22015.89F275B5; Tue, 24 Jul 2018 15:54:32 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 24 Jul 2018 15:54:32 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Tue, 24 Jul 2018 15:54:31 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt Thread-Index: AQHUI1WzbXIKgg1ILUm68vNdLZ7LV6SeQ36A Date: Tue, 24 Jul 2018 13:54:31 +0000 Message-ID: References: <153244035927.22640.15207006290980496560@ietfa.amsl.com> In-Reply-To: <153244035927.22640.15207006290980496560@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <02FD0D92320D034A91B24EEDBE810406@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbG9SHeGfni0wdoTMhb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqrHEgUf+Cr2/UtsYPzM3cXIySEhYCIx5+9rxi5GLg4hgaOM Evcun2WDcL4xSvzd1cIM4SxjlHj55z0zSAubgL3E5DUfGUFsEQEJic6v+9lBbGEBF4kDS+cw QcRdJb4cOcwCYRtJvFj6CqyXRUBV4vDCNawgNi/QnOMnOtlAbCGg3u/f14PZnEC993/2gNUz CohJfD+1Bmwms4C4xK0n85kgzhaQWLLnPDOELSrx8vE/VghbSWLvsessEPV6EjemTgGayQFk W0s8XxgPEdaWWLbwNTPECYISJ2c+YZnAKDYLyYZZSLpnIXTPQtI9C0n3AkbWVYyixanFxbnp RsZ6qUWZycXF+Xl6eaklmxiB8XNwy2/dHYyrXzseYhTgYFTi4VVQC48WYk0sK67MPcQowcGs JMK7SBQoxJuSWFmVWpQfX1Sak1p8iFGag0VJnFdv1Z4oIYH0xJLU7NTUgtQimCwTB6dUA6PP AeWlO3hXJwZGL3Tjsl0ace/I4+5ExnyBohaPV2qlpf5aeu3+51c531U//aT47RqJL5oGvxwK w4JeHYp1PxWj49uWG8XUq5fg/zHqWMdfWau0lR+/Po66tiwwUmH/X+4XPRFPGfo5Y/x+VG7X vSi1dqMWs/ajTd9YDmrfdI6JmskvtVhEXYmlOCPRUIu5qDgRAAqV0mSbAgAA Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 13:54:37 -0000 This version addresses the WGLC comment from Jim about the potential "unexp= ected" 4.29 responses to first request. Cheers, Ari > On 24 Jul 2018, at 16.52, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. >=20 > Title : Too Many Requests Response Code for the Constrai= ned Application Protocol > Author : Ari Keranen > Filename : draft-ietf-core-too-many-reqs-04.txt > Pages : 5 > Date : 2018-07-24 >=20 > Abstract: > A Constrained Application Protocol (CoAP) server can experience > temporary overload because one or more clients are sending requests > to the server at a higher rate than the server is capable or willing > to handle. This document defines a new CoAP Response Code for a > server to indicate that a client should reduce the rate of requests. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-04 > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 24 08:22:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DF7131122 for ; Tue, 24 Jul 2018 08:22:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HOEyFVNXk0L for ; Tue, 24 Jul 2018 08:22:06 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4487913112E for ; Tue, 24 Jul 2018 08:22:06 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 24 Jul 2018 08:18:29 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , 'core' References: <153244035927.22640.15207006290980496560@ietfa.amsl.com> In-Reply-To: Date: Tue, 24 Jul 2018 08:21:59 -0700 Message-ID: <022f01d42362$12712880$37537980$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGYXtu5WDYUO0iVMyfQxtL9GbguDwG93pdkpQgXaAA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 15:22:09 -0000 I believe that this document is ready to progress. > -----Original Message----- > From: core On Behalf Of Ari Ker=E4nen > Sent: Tuesday, July 24, 2018 6:55 AM > To: core > Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt >=20 > This version addresses the WGLC comment from Jim about the potential > "unexpected" 4.29 responses to first request. >=20 >=20 > Cheers, > Ari >=20 > > On 24 Jul 2018, at 16.52, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Constrained RESTful Environments WG = of the > IETF. > > > > Title : Too Many Requests Response Code for the Constrained > Application Protocol > > Author : Ari Keranen > > Filename : draft-ietf-core-too-many-reqs-04.txt > > Pages : 5 > > Date : 2018-07-24 > > > > Abstract: > > A Constrained Application Protocol (CoAP) server can experience > > temporary overload because one or more clients are sending = requests > > to the server at a higher rate than the server is capable or = willing > > to handle. This document defines a new CoAP Response Code for a > > server to indicate that a client should reduce the rate of = requests. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-04 > > = https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-04 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 24 09:45:12 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC02130EEC for ; Tue, 24 Jul 2018 09:45: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61Pc4Thv057J for ; Tue, 24 Jul 2018 09:45:07 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753D9130EA4 for ; Tue, 24 Jul 2018 09:45:06 -0700 (PDT) Received: from mail-qt0-f169.google.com ([209.85.216.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fi0Qr-0002wV-2i; Tue, 24 Jul 2018 18:45:05 +0200 Received: by mail-qt0-f169.google.com with SMTP id a5-v6so4767615qtp.2 for ; Tue, 24 Jul 2018 09:45:05 -0700 (PDT) X-Gm-Message-State: AOUpUlHaU3O9wVsV6fMykO+jB8vzeZAtdtlmubE/6E3gMrIqjqs0ZhqG RowqZ6Tln90ejbk6QNBnnBg1aY4rzSFaTs+cT0I= X-Google-Smtp-Source: AAOMgpfpw5eASV8snMmEvbUz0U1RqnGlT3mf61AQ4AEV6x98Uj31qK2TFjsT1JqqtbrY5X8sHeyrXm0LEgSi9mp1pyE= X-Received: by 2002:ac8:43da:: with SMTP id w26-v6mr17050437qtn.137.1532450704030; Tue, 24 Jul 2018 09:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:d04c:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:44:23 -0700 (PDT) In-Reply-To: <022f01d42362$12712880$37537980$@augustcellars.com> References: <153244035927.22640.15207006290980496560@ietfa.amsl.com> <022f01d42362$12712880$37537980$@augustcellars.com> From: Klaus Hartke Date: Tue, 24 Jul 2018 18:44:23 +0200 X-Gmail-Original-Message-ID: Message-ID: To: core Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1532450707; 1306e252; X-HE-SMSGID: 1fi0Qr-0002wV-2i Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 16:45:10 -0000 Jim Schaad wrote: > I believe that this document is ready to progress. +1 From nobody Tue Jul 24 11:09:00 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9FB130E22 for ; Tue, 24 Jul 2018 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZgGHZ2c5; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OuI1rkB1 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 Q-h4pCuRM6y8 for ; Tue, 24 Jul 2018 11:08:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB8C130DEA for ; Tue, 24 Jul 2018 11:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532455735; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0w0t/2XbsS0vNebzefLo22hBTyB2XQGzWOiBLER/72I=; b=ZgGHZ2c5+WqA/1wwYzoZbHQ6XOglHrtPZPJFne9c1uPJVcONu979QrIycENQnxmy 3GyJbe5SGLynr3dGIhk5wNclnfSFzmdJwKByo4+ZbSYpsutGr6615QinjXiaA1RB 8E8E5C0OuOBk8Dur01rZTAj+CF7RBfav7vmHGb1SNOc=; X-AuditID: c1b4fb25-ee5789c000006cb9-ec-5b576b378861 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.97.27833.73B675B5; Tue, 24 Jul 2018 20:08:55 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 24 Jul 2018 20:08:54 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 24 Jul 2018 20:08:54 +0200 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=7u7xcd31+iHe+J0L/W77jWwGc5Wyb6Xsa5ejgZzkuBw=; b=OuI1rkB19xYyd3QazL7icHRfS4PUB3NY4tdtfGsd/m1vOffnjtj7ZfkUimLZxR/WhwK8TgrvEosaN2OHPbyWlLZnhOs7kNGnr3UCsuUh2hgtbhW2GdbnPAH0tQi7ZTc0Qo82ZaG7sV6Hvo149najsZ9rcqMQTm8Of9G2xGcwJVY= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.10; Tue, 24 Jul 2018 18:08:52 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::64fd:702c:a60e:d563]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::64fd:702c:a60e:d563%5]) with mapi id 15.20.0995.014; Tue, 24 Jul 2018 18:08:52 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" CC: 'Core' Thread-Topic: Reading -13 Thread-Index: AdQYaoV37BbZYpdJQZC3S1xD1eNBeQLDdBBQ Date: Tue, 24 Jul 2018 18:08:52 +0000 Message-ID: References: <053f01d4193d$0a72c460$1f584d20$@augustcellars.com> In-Reply-To: <053f01d4193d$0a72c460$1f584d20$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2011; 6:6ZiqDBJBMfdBXFI3m6wzqkDIYc/olqtjx4Uy0D4/wzUJLUjJsWq2y55ULrlcn/MSKqw9Ta7KyHOGah2yAL+IhCPzWU+d3SRh6uVyaxvCTM7lwBGPCBhE5WVCWbt19AUQO1TiccpfCW4dhItvAxfVfzDdiPqBPlajy+mFeEkqIHTFBQltQ4na7V/HAJkNk8sruu/PnwW8niqX6rj7k644tHQ/sQqXwFr1FytIrantsfsOWSA41b9fFkFzEesGDP1cDd0NVdZ2Jq5H4SLpDT5mwoN5U6LGve85+arayGmwaz6FzKqebCBmNUUVSJ79NLcoQHggfkKtW2byMx1EnVJsZwgdrC/49+3+W4xpHPjnjrNXiKNhBtidh6nO8szemu/JhCLxrKD5iZ+NK5bP40MX6qPZ7NyPmg5fvcBNDIX87hoV3N5iPx6A/7YloX3iHZDDQDpQDj54yJ6CH2hSRAC6dg==; 5:FjagzHmUVtoM+/XEANf9Wn1dlkcB3C+NZLIZjNQqIskH14jGjhzdM7Xr6fSzhQJg8j5jPlyGCIgM6U1czRuMhOknGaTATZjW+LicnKP80h9rIabjmninRu9radd96A7LNDCkoW9moPn/aNkauWpjrB1qEQrJFtMBocMa1rMKKwA=; 7:12gxRrcnMCIPWT92bW5qnmtUfAlynO/YZAoJCX9b3dtetREBowIRZasE6n5Bv8w5gcW0LA9k44lrbP8rRdjr5jqvPDVwcmplZuX49aLdkL/FW9ZfmA0/PDWdZnNQGcH8PO3NYOzkSweuG1vvyelTTgiKhMSlfLdSeUi9uW4jMOS9uIL8uyvfnspq0aWNXv8rxsNmsrx2YH0Fp8o+7odcnd5oJ2oFvXyclUGODSW6vNLWdyXBD2mUmbqmn4Dm9KWS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 25607db1-ae97-4403-6664-08d5f19083a8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2011; x-ms-traffictypediagnostic: HE1PR0701MB2011: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB2011; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2011; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(396003)(346002)(39860400002)(13464003)(189003)(199004)(53754006)(55016002)(66066001)(76176011)(6306002)(14454004)(11346002)(6436002)(9686003)(446003)(14444005)(6506007)(26005)(476003)(256004)(53936002)(2900100001)(6246003)(7696005)(44832011)(8936002)(2906002)(486006)(68736007)(229853002)(966005)(25786009)(74316002)(478600001)(2501003)(7736002)(81156014)(110136005)(81166006)(33656002)(5250100002)(305945005)(6116002)(4326008)(105586002)(5660300001)(53546011)(316002)(99286004)(106356001)(8676002)(97736004)(86362001)(102836004)(7116003)(186003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2011; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: o1zTOkWogs3IoFZ0kHbggnHvDCqcDGLsvnRxhW51Oq3OtJbEAf+pzCHbSURwi4MBTd/YpjNnKHpERcV2A7kqL6u+pfHIO/OgRRSgRFmmMsXhkbyEfIttJJfUDk5sKJsWLtyQiMRODEElSdmPtV2QwUya854OjlR8bAnJF1v0wKqHUbmsVU3E6GNX2gr1+J9uoX4Yv4kBYrsh/PKYTrnLFsNJIBEdOpJaTVWkLSHRA9Q9GQzdLXwe59+O3iDpm9hUCBfXndTsI9t9c6b25qJdFL+5rF6/wtrxoKNtg2beA3tYEM5DIy9PD5k/iuAMy74v/ep/AoAIqG/EJN5BOTe5G6jD6FkGSw6xFa+g7WkD1ZA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 25607db1-ae97-4403-6664-08d5f19083a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2018 18:08:52.7510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2011 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42KZGbG9XNc8OzzaoGODrMW+t+uZLab9O8Ni sXr6dzYHZo+Nc6azeSxZ8pMpgCmKyyYlNSezLLVI3y6BK2NNwyuWgqfCFU92BzQwPubvYuTg kBAwkVjRItzFyMUhJHCUUeLQn1/MEM43Romd1+ayQjhLmCTWdDewgzgsAhOYJfZPeMQOkZnB JHHz1zyWLkZOIOcZo8TPdeUgNpuAjcSFh+/B2kUEmhglHs/tYwZJMAtISfScPMwEYgsLSEh0 d9xiB7FFBCQlvp0+xgRhG0ms/XeODcRmEVCVuHt1ElicVyBB4uyND4wQy+wldp5+DraYU8BB Yt7Lm2BzGAVkJb40robaJS5x68l8sF4JAQGJJXvOM0PYohIvH/9jhbCVJC79WQgVl5W4NL+b EeRoCYED7BLTH7yHataV+DB1KlSRr8TntktQRScZJbZffcgICUodiXNfSiGOSJa4cruPHaI+ X2LiUZheH4lljz9BzZSTWNX7kGUCo+EsJLdC2DoSC3Z/YoOwtSWWLXzNPAvsf0GJkzOfsCxg ZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJEZhADm75rbqD8fIbx0OMAhyMSjy8UYnh0UKs iWXFlbmHGCU4mJVEeE0DgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5H5pvjhISSE8sSc1OTS1I LYLJMnFwSjUwtnftdXRjc8nJCJHhsJPgTMzafNs9RHNLU3/16rlrg3hN9XofyzC9viO+lk2P f4pcRuJ8/sVz2urcHHlrK74dmPgt7oir7I0X83gvvHwwZ0bGl9WvGXdz6HCdi/l8egNz8L4N x1kn8G0qzvdgXpk56f3mKznXvq6f0Xpsyr7mzc+2PdLyrGRuUWIpzkg01GIuKk4EABADltQc AwAA Archived-At: Subject: Re: [core] Reading -13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:09:00 -0000 Hi all, I just wanted to point to the wg that, following discussion in Montreal, I = have now compiled the modifications in 5 different pull requests (inline fo= r links), to simplify the review. Jim has already started reviewing those, = please feel free to follow the discussion on the github! https://github.co= m/core-wg/oscoap/=20 Thanks Jim for the review and for the useful discussion in Montreal! Francesca > -----Original Message----- > From: Jim Schaad > Sent: den 11 juli 2018 19:32 > To: draft-ietf-core-object-security@ietf.org > Cc: 'Core' > Subject: Reading -13 >=20 > * Section 4.1.3.1 - I am unclear why an OSCORE error response can be cach= ed > by an OSCORE unaware intermediate would be cached, but a success > message is never going to be cached. Based on this, I don't plan to set = an > outer Max-Age option. >=20 Clarified in https://github.com/core-wg/oscoap/pull/235 > * In section 5.4 you have the text >=20 > request_piv: contains the value of the 'Partial IV' in the COSE object of= the > request (see Section 5), with one exception: in case of protection or > verification of Observe cancellations, the request_piv contains the value= of > the 'Partial IV' in the COSE object of the corresponding registration (se= e > Section 4.1.3.5.1). >=20 > I am unclear how/why this is different for observations. A cancelation = is > a message, so the IV is the request. A re-registration is a request mess= age, > any response would correspond to that request. The only interesting > question has to do with updating the MID on a re-registration but not how > PIVs work for this field. >=20 Cancellations do not have special processing of request_piv in https://gith= ub.com/core-wg/oscoap/pull/236 > * Section 6.1 - Is a registry needed for the leading byte of compression? > Behavior if bits 0, 1, or 2 is set in the flags byte on decode? >=20 Adding a registry in https://github.com/core-wg/oscoap/pull/237 > * Section C - given the way that my system is implemented, it would be ni= ce if > the outputs included the first full IV to be used for both the sender and= the > recipient. That would allow for a test that the combination of ids and > common ivs is done correctly. In my case I do not have the shared IV > available for testing as I immediately or in the id. >=20 >=20 Adding the nonces for the test vectors in https://github.com/core-wg/oscoap= /pull/239=20 From nobody Tue Jul 24 11:21:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E79130E66 for ; Tue, 24 Jul 2018 11:21:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 yhF8j9xWuFiG for ; Tue, 24 Jul 2018 11:21:05 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 55F60130EEE for ; Tue, 24 Jul 2018 11:21:05 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w6OIL43O036242 for ; Tue, 24 Jul 2018 14:21:04 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w6OIL43O036242 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1532456464; bh=U9ADM6F4AJRVP4+qClO9ahBe6v2Vah0GBcVdyd7HI1s=; h=From:To:Subject:Date:From; b=jAz8ziSXzQUpYY/t0Ph19lw98ub0FgyW+Dfp0O5Z4HBcfGZ165ZCaV1yEj7cozntC 65wXajLfTPURjhvh3+G9a6jTSAbSA6yFw3f+k3UtBHd+iWdlQY/gtJh1sYuRaWQ2MC BmPQB+LBZeUJ4bgDdLguqCJ5qUg4gqTaR3cEYsCA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w6OIL34j013413 for ; Tue, 24 Jul 2018 14:21:03 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0399.000; Tue, 24 Jul 2018 14:21:02 -0400 From: Roman Danyliw To: "core@ietf.org" Thread-Topic: [dots] 2nd WGLC on draft-ietf-dots-signal-channel-21 Thread-Index: AdQjeZ41lVjgIQxERPCA/Npd0yHM3g== Date: Tue, 24 Jul 2018 18:21:02 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C40B54E@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] FW: [dots] 2nd WGLC on draft-ietf-dots-signal-channel-21 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:21:09 -0000 Hello! At last week's meeting in Montreal, I briefly introduced the work of the DO= TS WG and elicited help in reviewing a protocol draft that uses CoAP. The = details for the WGLC on this draft, draft-ietf-dots-signal-channel-21, can = be found below. Please send any feedback to the DOTS WG mailing list [2]. Thanks, Roman [1] Slides 71 - 73 of https://datatracker.ietf.org/meeting/102/materials/sl= ides-102-core-consolidated-slides-10 [2] https://www.ietf.org/mailman/listinfo/dots -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: Monday, July 23, 2018 2:55 PM To: dots@ietf.org Subject: [Dots] 2nd WGLC on draft-ietf-dots-signal-channel-21 Hello! Consistent with our discussion at the Montreal meeting, we are starting a s= econd working group last call (WGLC) for the DOTS Signal Channel draft: DOTS Signal Channel Specification draft-ietf-dots-signal-channel-21 https://tools.ietf.org/html/draft-ietf-dots-signal-channel-21 Please send comments to the DOTS mailing list -- feedback on remaining issu= es or needed changes; as well as endorsements that this draft is ready. This WGLC will end on August 5, 2018. Thanks, Roman _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jul 24 13:43:16 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45462130DEA for ; Tue, 24 Jul 2018 13:43:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itron.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 L8Sxm7nF0iPc for ; Tue, 24 Jul 2018 13:43:11 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0050.outbound.protection.outlook.com [104.47.32.50]) (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 19DF01277C8 for ; Tue, 24 Jul 2018 13:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itron.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dMEHD5eWY9sb8P61y/EzkobsC6zHnzh5IjKUtJx3v/E=; b=LIsoOuUVqdG6RU0pSj87dNUj90gkK1tPI14N9aUveuS/25zxIIuU09+tmVu6s39eUMyEZGTYdVzgn/hLmGWoZCnX+FiHCeMc56LzMvRShdtLmzhhf3MYqHm+QgaEQRYuXHWyfxwjV/yewZ5qBFOPrzpCIhNlwP6VbDTwBLZ9OJM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Benjamin.Damm@itron.com; Received: from itron.com (173.227.225.6) by CY1PR04MB1963.namprd04.prod.outlook.com (2a01:111:e400:c5ad::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Tue, 24 Jul 2018 20:43:09 +0000 Date: Tue, 24 Jul 2018 13:43:00 -0700 From: Benjamin Damm To: core@ietf.org Message-ID: <20180724204259.GB674@itron.com> Mail-Followup-To: core@ietf.org References: <153244035927.22640.15207006290980496560@ietfa.amsl.com> <022f01d42362$12712880$37537980$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <022f01d42362$12712880$37537980$@augustcellars.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [173.227.225.6] X-ClientProxiedBy: BYAPR07CA0059.namprd07.prod.outlook.com (2603:10b6:a03:60::36) To CY1PR04MB1963.namprd04.prod.outlook.com (2a01:111:e400:c5ad::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 966fe359-6f8c-4991-4c50-08d5f1a61112 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:CY1PR04MB1963; X-Microsoft-Exchange-Diagnostics: 1; CY1PR04MB1963; 3:5beebEYlbHDkxIsuZmEqkWoiv3z9f0Q6hF4rBJtJrDHpGyeefDZfCTOi3ymyoMCrElppKTse6R6jNyc3354st6W+ki6X7pObWR+/zqlSgJcgOIc6lOcdbk1+nyIW0TzCuPd3q3rsiu4BjXz4fZW+Rd6caFmDl3JNrERoZs5uWthphxJ+0ihoBZOoBss35eqcn9uGIJAYo5st7CSsM3I4e5KNjX84Qidu65zqq5VF8FSItQj894bpvLtlJ5FqZVnq; 25:+yMpa7tzg+A+nYJK5Pk4F8agxwKtoAPvasXKR0ATj0esrsNr5UsyEsCZWs62tvNHux0qZhJ49WD313CgBDMD/YWqa9XjaI+zpNcg5SjGmQk4AydAaLF7Ra0Z1bM3bTrpl7wOi5a/j9WzDObzE4bs07OW5negE9klY8p2zZ2YEmN0AS7tNlLMIYzj/YoaDJa8oVxkq6QgMA4xvOtS29gNvsK8+nJYtiBrI47BamltAomLBR37d+z3V9wWTEY5GTE9XZ8w+DrpcDVKrBkkgci1f70/vri4/nFUzcIUUKlDfjIRGApBtDFzWsyxkleYqFCeLKNshMjXm3cQ180+iMnirw==; 31:/egfZz8nvBgQoWRGREIp72jkv3xWQQS+CkdN2DLo+fQBOFZCLffyTfKVHZ10P3m8/t4TBBvgW6qcTE07qJY7bZf9apzKdHqacVPtnuSY927ZmtOWwRXMVEQ5eIlLMPsEcyA5GIDu6eLUg3ka0kc4WErbWgllISxU4ljGuse+cSiT9p+CAXNNvCge+uGOHxMubup6cDlHgGHkb6nBrnDh9xSMJInbe/RtnSQ9IK98eFw= X-MS-TrafficTypeDiagnostic: CY1PR04MB1963: X-Microsoft-Exchange-Diagnostics: 1; CY1PR04MB1963; 20:AEUlV7dWgSCTN8uUpdcgwT7pCVVM1FZ4eyBjktJeve983g9+KM5b2xl2s2LJrOEwcc23SJNV0TVNG/8vqmkxPBYbeq6r+4al1/eNql7rjrmr3HnI0jpxJgXaWiRC5yG6/WwQJ4s8svT7eXpPRBPtcva6t+o3E099C4htTxZXtdx7UXq9Tzj+zFCmVSqINE1Modk2xoe8p88dtPqQCsL5IVO95jd4T7m51weNIgX3UYJRZ4Pd1GSKgd3UePlHf6uHTJo+pTnktIPAdx5zk7RdsH+jAPFP9MfUvB++BtlelhnIlQtXQsB603+8JpiLvujf8jYcT3x1I+eRjmnDQaTReGEUfHZXhz5bxvfPckE3A8ZoRNOHu7KkwryxhGgCZxZSux/eAvFtQgzZ8ehteUjUSVjQCTsOjQHUBSZjCFcKd4Zgi6MlziweIe70WuoDWFEOOm0aowD3sizdCTSwC3qHg6O0R0nlbqOAIRkf9MRGLa5aHBGe8bpmy0XR1qiSzRa/; 4:lvRxBRG8ItKixnoh0zHroUKo5E+u5KQFm78I7Bt+etjnd0Ps7U7VK5/7jArMIyf1liUH63FQIPts3aX6GJW1AeayvQp4jXpWGhc+a8Jam8v5rUi9Sy6qbWcsdiKl+wgzod+j90hM3I86y/FnSc1g+pLRWlCiD9Kalq3srkJ6OqAn4WXS4H19pwqXibJxpObfsbwxBfx4Yd5uPiYYqyQMPQg6PlPGXAYybS7qgP48Ajs7oLXb8Xz1jltq0KSG4VzLdrfnvRR6gmKjU95F0KmZQufY8RHucYV8Yxp7dATcFnlYFjdiBermRNEEiZ3MtrBITFLuCXbDHjsHBpf3tO+CMsiegblIAwnYY6o9wtm4vFk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(10436049006162); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY1PR04MB1963; BCL:0; PCL:0; RULEID:; SRVR:CY1PR04MB1963; X-Forefront-PRVS: 0743E8D0A6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(376002)(346002)(136003)(199004)(189003)(13464003)(6246003)(478600001)(76176011)(106356001)(23676004)(97736004)(7696005)(105586002)(186003)(11346002)(52116002)(446003)(26005)(52146003)(53546011)(386003)(66066001)(50466002)(2486003)(16526019)(2351001)(8676002)(8936002)(68736007)(2870700001)(14444005)(2361001)(55016002)(44832011)(6666003)(305945005)(575784001)(2906002)(6116002)(36756003)(3846002)(7736002)(47776003)(6916009)(58126008)(1076002)(81156014)(316002)(86362001)(53936002)(25786009)(966005)(956004)(2616005)(486006)(69596002)(476003)(229853002)(6306002)(5660300001)(21086003)(81166006)(72206003)(33656002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR04MB1963; H:itron.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: itron.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA0TUIxOTYzOzIzOnllRjFhTzRoVWx4RjZTcVJGaEh5QmpUTHFS?= =?utf-8?B?dXZGTUF4YTdsQThKaU5XOG5tRlZYZU5iWUdwQkFZWUZ4cGl2Y1RTTzJ6MzFV?= =?utf-8?B?NlEvQXRRaDlnNVJNd041ZU0zUEtKUjJNSTI4SG9BeW9DNTVsbXEzZ2E4b3hs?= =?utf-8?B?b2tJZXRDcm1iZjNQaDUyRXEweVhnbFFOT3pVb1NQZmhFeXlmM1BqakFzbEtS?= =?utf-8?B?VDJTbG9zL29RaGhlSzJMZ0MvTXAxSHhFTmRoZnVWcW5ENlkwMm56MjBGMEpG?= =?utf-8?B?bkNxMUh1eVh5cWFLemt4U0FYZ1paVGFvSFB2b2FkSWFxVjM0UVdIbE9Mcngw?= =?utf-8?B?UVZPQyt5WHBMeVdpZjhNSEduL3VNWWxxNFFMSDZOSWVwWCt6QWpMV0VGaUI1?= =?utf-8?B?SDhyVmxFMHdBdXBkdDlWYVl4Nnhvb1hTUk9zL0RiZHlzUkdjeERVYlVpbHA0?= =?utf-8?B?QkFpOGxrakhRSXpXREZUSWxwaTdJdXdqSHZscmNDSDhkT1ZFK2ZxS0Jsck5x?= =?utf-8?B?aVRVVVJScTlZajIvU3dHOVNDRCsxekhjK1ZlbjNGbE5DbW0xVXFJK3ZvYjBY?= =?utf-8?B?QjdCT1psK0lHQzFvcEVIT0kwUDY3YzExMlRYZnJsRHJxOWpCT2xvbkpVWi91?= =?utf-8?B?ekROZVUzWGFqeTBQaDFtbEhKSVVEdi9UZFh1bkFKckNsd2gvbXFtL0tNQ1Bp?= =?utf-8?B?VDI5ZXVJcmhXVzA4cXNFSFZuY3MrZVNkNGxCNDBiUldTazd3Yk1vTmVRaFM0?= =?utf-8?B?UUtzU0NVenoyUlV4RWlTQzl4TTMvQUd2V1FoSWpSQ0c0MFZmOGlXTGkyTmlj?= =?utf-8?B?OERLUHVNNEptemlUcUJyYm8rOVVpVEFpRHdBZHNtS3lTdTFqKzJoRmo0Mlpm?= =?utf-8?B?dTFKemFzZkRaR2tqeGxONWlZcDZ5QkVHSGxpWjU4ZG1TVTB3QTU3bFNLMTVn?= =?utf-8?B?SFIweGdRMTljeU15ZFlUV2R2UTljMDl2ZTNsWjR6bi9GZW85Yjd3YklPc0JJ?= =?utf-8?B?UXJ3M1k3THF6OGRsYWZFV3hBVzR6UTBXT1ZndEU2VlZzbjBlYlhrZ1pnVzF4?= =?utf-8?B?SndEWGYrWmVuYWRSMDZYcEpwL3dSMVpwZ2ZRYU15MzJPd0FaeHJacGV4c2Fk?= =?utf-8?B?RkVYdXdWVXluVjVTRUxKQlZwZDFxVGE0czJBTm9FdzJCNTM1YTc5REZzM0Rz?= =?utf-8?B?VWJ6dmQ2VUs1SDlMSW9zQ05OZC9SY3Zvb1FBdVpWdW9raGNSWVhHNUQzUlFO?= =?utf-8?B?ZjA1bXJoaGYvNXpQdE5OZTFNSlVVYmpycm1ESEgvUllnWFFaczJaeWtFWTVh?= =?utf-8?B?NHBKK1ppSGZzdkVvem0xQzRSMzdpUVZoNXVxMHlmOXZ1Y1gvck5uSytpU3lG?= =?utf-8?B?UEg3M1YzOWdtcGpTSTFDcGZkVXNVWjBRZWJiQ2xlQlRqWnRQZzRSbUc5cHFY?= =?utf-8?B?eEc0NS9ZVytiTkdoK0Jqc0VMNStCOWhsNnF3NVA5UUZJZ1hvMTlmOWFsdUE1?= =?utf-8?B?OWRFR090S2U4citldEFpcXpaUE8rZ0dSNHdKSkw0K0ZlRGFuWlArRUZhL25a?= =?utf-8?B?WlZMd2ZEZGtaMU5ZR3RsN0pmVzE0cnVheHZqbmVnTVhNNmZBU24zZTRMYUxP?= =?utf-8?B?SUlLUGNwVkgxM3YvbE5JRGtyb2VDa1ZYREEyQ3pqRk9aL3RnUEFCZkZHTkVF?= =?utf-8?B?V21KM0ZBb3IxanAvelFvUmdNUFdJdzlZaVpySWRhUjJUZmlIcnJQSE5mbmdK?= =?utf-8?B?UEJLdVJyVngzNVJFMXNFelNtcUdqS3c3SmFCSlFGQ2ljdGdXS1g1ZGFLQTVi?= =?utf-8?B?OXFVNkY0ZVV4Q2cxT0FVN0RKVDloZjBmb2RJZ3RoTit6T2dIU0daVjh6N2Nw?= =?utf-8?B?RVJkRmcyL2hYQkZLcTA4RmlvL3gzd2lMWVluMzlIczBtbSt4cXIvRUQ2c0NO?= =?utf-8?B?akJrdGxsMk4wcGR5emZJdlJDMFJmOTdRc2I4RmMwTkNyMTd4Mm1ndEV0Tk02?= =?utf-8?B?Smk1NnVFN3JjRGxRWFZlM3pSYUYva1VwdVNITjdMMTAxT2lnZHpSdllsZ1Zp?= =?utf-8?Q?MuOI=3D?= X-Microsoft-Antispam-Message-Info: 9X3znl/Jl7vahOSrk/G2BxEg4KWuQiA3AqrhOd3olDy26PQROiFfbmNzTdL6QVm059zQD3p31K/dtHgtBcfM2kbxeq/x0RdvQ6m/7qRpzpA3nsHvpFKWCoNJdwYYR289JVxAvpMOM+Ac9GckfvyxCBXn8m5RhzcEIuMPhSOpPELVoF5aM+nlQbmBkGNZDiW7qLTDJAYCWrWtN/b1kE0a5anQJyAsJA6Nz2Ohg+7oDyfaTLK1Oqs54RDRD1Z3PvQCbe01p9y0xR+Y439bBFUFvz4KdSDQHZ7tCBn99Hv5clOd0VpzbfcQPtCPvSZHEvNZHmZga+NLakNYeMM5Nvt1YszQxC2wmJz+kI2wHs043zM= X-Microsoft-Exchange-Diagnostics: 1; CY1PR04MB1963; 6:7LN5XbgXKrVq2EmlVFYQttDl+lWXmQXqXpSpQc+cg2agcfU5zrAG7rT2/v5ZczTTINgnd8Nhcm78P3xBOEijUMu/FMtMZLnk6giP/hmHFw0rUzYtNAVh8VyfOmKLGYdf4+vxHxwnEiuj6b/YuVu1CuvNTMUMhIo3KP3RRpMODydO5r+4yFBvt8Pw+B8ycQaaKmMLVOdV93RQ+3lTR/JaNUF+AM5KeHXI/cpJWor678fZvgHruTZUwwjmQXUpeEmYS3AHd32PZdEgv0xV0GOn3pV1fPn3Uj9DZvCrKxtwiy/GIaSW6NXNdQURr0I87UaLuk8ODyWpcjvi4r1s+15BU0l0217tVCijlbnA2MebTH4Lef6o5+XefzLu1Nvc5JCk5jPd9OCImiwvBD4Ro2j+9GU/PUOOVsfn9wOYsBFXfLWWBvM6oeUy5OWq0OQkSK4uK1EHaHchdLx5Mkyr+7BhQg==; 5:m04oTe4MCwE6kk1669xaTTZUtXKknoJMCRgpNaR5rL4Sj+r7V6dF1SfX+zNsKrwmuArRlVJVXlynXGggKqLjJBMsWDINddYaFDoElgrpD7+oi/O6hV8vVeoTU4Go5MEmr36oNx34nxuVSvysQVHF53FLhm0ltmT5QKLgk7/EWGA=; 7:N4OaDY1S/W2jP/H0hU6TE6rWS02hhh0VP48EEmrbpr3MAcFpkKuuO2AHbwpTCAajC5fsN86fR0ooc47wXYOovrYgJJXfn73Zkco4YonWk/0XFuzp3Q/RMIMVNFP3/ZA2O0S/+oUCbBO9oadRVeYlDGA8rtfLe3JwOFPiudz7NHX+h8kRiEeUsZJga2K0FhklzKEhjBDoKWQ+ZnFmU5Wp3WePHVlKSaAx+TDLJsOlPpZPbkUheDbzuevseunrn7C1 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: itron.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2018 20:43:09.4507 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 966fe359-6f8c-4991-4c50-08d5f1a61112 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5818bd20-bf25-47b1-b996-d419d7e6e8ba X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR04MB1963 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:43:14 -0000 +1 If this document was standard we'd be using it today. We have this problem is spades because proxy based throttling of CoAP transmissions is turning into a big focus for us. Today, we use 5.03 Service Unavailable to handle this case of a client pushing too many requests for a specific endpoint through a proxy. 4.29 is much preferred as it more accurately describes the reason for the error. The language added about the proxy is particularly relevant in our case. Thanks for adding it. -Ben The 07/24/2018 08:21, Jim Schaad wrote: > I believe that this document is ready to progress. > > > -----Original Message----- > > From: core On Behalf Of Ari Keränen > > Sent: Tuesday, July 24, 2018 6:55 AM > > To: core > > Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt > > > > This version addresses the WGLC comment from Jim about the potential > > "unexpected" 4.29 responses to first request. > > > > > > Cheers, > > Ari > > > > > On 24 Jul 2018, at 16.52, internet-drafts@ietf.org wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the Constrained RESTful Environments WG of > the > > IETF. > > > > > > Title : Too Many Requests Response Code for the > Constrained > > Application Protocol > > > Author : Ari Keranen > > > Filename : draft-ietf-core-too-many-reqs-04.txt > > > Pages : 5 > > > Date : 2018-07-24 > > > > > > Abstract: > > > A Constrained Application Protocol (CoAP) server can experience > > > temporary overload because one or more clients are sending requests > > > to the server at a higher rate than the server is capable or willing > > > to handle. This document defines a new CoAP Response Code for a > > > server to indicate that a client should reduce the rate of requests. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcore-2Dtoo-2Dmany-2Dreqs_&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=WlnpPmykhIa64yCk6yt8hI_ETb61GTJMFlr7rfT1KUE&e= > > > > > > There are also htmlized versions available at: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dcore-2Dtoo-2Dmany-2Dreqs-2D04&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=f2KxEosouR3KwV8Ob8hfhOMjVIGvPFmvZKie0mmgRgg&e= > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dcore-2Dtoo-2Dmany-2Dreqs-2D04&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=e1vsgQN0oLH15cyAn20MnMshBT70vPNOIkKe7-H28IM&e= > > > > > > A diff from the previous version is available at: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dcore-2Dtoo-2Dmany-2Dreqs-2D04&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=UC0sa1wd1p7ievcQI4Ow-So0Q4gnOKx_QRi_FmJ8FzY&e= > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=CPAcV557eRgvQ3JqSakUmqJSWTHI1iRRMiIe01r1T6g&e= > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_core&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=Twumogh3q7WSx2VRtnGlWUrd-ciuDcAa7POjM3YMuko&e= > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_core&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=Twumogh3q7WSx2VRtnGlWUrd-ciuDcAa7POjM3YMuko&e= > > _______________________________________________ > core mailing list > core@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_core&d=DwIFAw&c=pqcuzKEN_84c78MOSc5_fw&r=GYGBKg0XeEBnyXmKSs4zZ6DBOYB5tLwwWSrFtYahCvs&m=6u-_cWKLHAItbJXiNqhsNXhwd3RWx1Bvs4ORCvkvB2I&s=Twumogh3q7WSx2VRtnGlWUrd-ciuDcAa7POjM3YMuko&e= -- From nobody Tue Jul 24 19:32:37 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2817E130E9E for ; Tue, 24 Jul 2018 19:32:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taitradio.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 Nbh_qF3NylqH for ; Tue, 24 Jul 2018 19:32:34 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 DCB6C130F5F for ; Tue, 24 Jul 2018 19:32:33 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id f18-v6so6247824qtp.10 for ; Tue, 24 Jul 2018 19:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taitradio.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=t0dO/zoWDFGJ/QdJF8wP1RJCKuc0K4DL6Wz15YfbPuo=; b=ZHSqPXJ7SECv4otC+TsPuU12UHYul3pKOE1QgaFeEeorNu/DDWIfjdZODWQmc4JE4n r0xs4W1gKzNK9lmsdW8GQ0J74qFiX3OrOWyGEZbZNlzZVng897UCAEdNWUVfC9x3V4BX Y6yJAoFSE4FPfdeeXC6qStTEZw/G3WFCj9BIs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t0dO/zoWDFGJ/QdJF8wP1RJCKuc0K4DL6Wz15YfbPuo=; b=Oq4ptZPzXzB1a9KcPsUqngx8oIrYxwjXIq+4rLCAbTafYOvAQu77xTdrGfz3fCzlhZ kxJK36ov931qk90qym0rnZGVarf0SCQkCLuJXHUOF3M7+9mT9H7Vq6UEYSPEqFqam3Iv tsnN45S8/VADbOBTtq2h0MfEkcHsAVOHp/FjmD59eM2bSAparX+5ypbUPsoOfj4mYLLf xVPmGyRFeoGFzaHIbE8cvsDYYj+XV9W9g/6BdvNCnWsxn/y2btMjqNoaBLpyt0cNFKzC 5MwYsYBG0HOqNqm6EaoHJm3BGLV4W/YACenQw3/zgYztWq5wDRgNSWFxG0grE8PZEIse I0mw== X-Gm-Message-State: AOUpUlGF0PQAE70HsxhZ/7nhdaZl5MYBd68Sk5793K0iqgtX37JCJRNH eJcgcLth7+cg7SqMAgZTcGcOrsHcdWA23S5mZYb5wHzi+mWooFL/F6s5T90OcHWXGBFmH4jqSjr ocgyoQ+UukXvmQY0N2IMq X-Google-Smtp-Source: AAOMgpcsKFSRuh94bj2bAo15rxaOu1wkUopBJn3BPfJNP7jwsrHrwyNGq3Vfp/s/WCDDioFciojGl04m4My3zHzi5ek= X-Received: by 2002:ac8:3111:: with SMTP id g17-v6mr17963414qtb.312.1532485952583; Tue, 24 Jul 2018 19:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:f885:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 19:32:11 -0700 (PDT) From: John Carter Date: Wed, 25 Jul 2018 14:32:11 +1200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="000000000000d3d2af0571c9b0b5" Archived-At: Subject: [core] CoAP x HTTP Cross proxy (Was Re: CoRE Tools) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 02:32:36 -0000 --000000000000d3d2af0571c9b0b5 Content-Type: text/plain; charset="UTF-8" So I started to poke at what it would take to revive Copper addon for firefox.... Then I backed off and decided that is probably the _wrong_ approach. I now believe the correct approach is to use a vanilla web browser and a CoAP to HTTP cross proxy. This is likely to be the more compelling demonstrator. The CoAP.technology site doesn't list any implementations. I see rfc8075 exists which suggests someone has done it. I have found https://github.com/ibm-security-innovation/crosscoap which, unfortunately is the wrong way round.... ie. It presents a coap view of http services. Is anyone aware of any open source cross proxies that present a http view of coap services? Thank you, -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer --000000000000d3d2af0571c9b0b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I started to poke at what it would take to revive = Copper addon for firefox....

Then I backed off and= decided that is probably the _wrong_ approach.

I = now believe the correct approach is to use a vanilla web browser and a CoAP= to HTTP cross proxy.

This is likely to be the mor= e compelling demonstrator.

The CoAP.technology sit= e doesn't list any implementations.

I see rfc8= 075 exists which suggests someone has done it.

I h= ave found = https://github.com/ibm-security-innovation/crosscoap which, unfortunate= ly is the wrong way round.... ie. It presents a coap view of http services.=

Is anyone aware of any open source cross proxies = that present a http view of coap services?

Thank y= ou,


--
=
John Carter
Phone : (64)(3) 358 6639
Tait Electronic= s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0=C2=A0=C2=A0
PO Box 1645 Christchurch
New Zealand

<= /div>

This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--000000000000d3d2af0571c9b0b5-- From nobody Tue Jul 24 21:37:29 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAB4130F62 for ; Tue, 24 Jul 2018 21:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 A9JrIZzGe4c4 for ; Tue, 24 Jul 2018 21:37:25 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 AE824130DE6 for ; Tue, 24 Jul 2018 21:37:25 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id 125-v6so3156248vke.11 for ; Tue, 24 Jul 2018 21:37:25 -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=P1VnrLHKedBPxDHWvpqvNzJKWCvry8lFHQMToSgr4tc=; b=UjtYXGxfndO+3s3408io7KGrSvqb/NX9XAu8uRhcY9dArcT7L34rID8T4xQzHq4FEh oBqWw0U+EkVdyoDJOmBt+1+dF7BPkKa46O0i4WPZRAhQo9hhY7MUCHrQKnaY1/Vb03tp yhgB/q3lrDI1rn52Dk7ogYgbbTrjCqnA91B9dTwn46L5Q9QXtsdsXuS7A74xf6mDEdeP 5ZpLthwtqukaWtcX4U25j3rymk6FzvnLYSmRWdToGZTdSt7sVYNY9s922LNLbSxkjO19 RcnCS74P2Yal6kNoDIejNhPyA3VsFuet2gGu4N85zkue4cv625c7jW39useXAEnqtLG/ /Qjw== 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=P1VnrLHKedBPxDHWvpqvNzJKWCvry8lFHQMToSgr4tc=; b=GCEDyl73rEeeteVvvGhO+AOIK9YKtydoPGjolRriHten+dcyLBMVDDbUQgkfFsEgNa uairOvr5On+GTD/9+ve462IwZ8a9uSgkJd+M5cQOmsutOREMXwVsXZcrduwKik3PCpR6 mG/zc6J7ke+CVw42l/6qkEhc/4HeCv61xvsqNsuWW5liUM0f3Kxc4S1DFw+6BJScfNvU 5jV4glO3139XfD8u2DiXbH+wiLaKJUHF1pfBUFlhIqyq9QJdQ0s++JBkM4lEqfGMehd0 tlRSmxSVjiyzUScMLqXsIvUs83W1rGi/Scsf7RM1wSWsNPyQjYDTTM5C12Qbq6JA670i Jf4Q== X-Gm-Message-State: AOUpUlGi+uKH3pGXf1b48k3+sBzpfocwvkqSjtb7CJIabcSMujyt1Yt4 vje3bsL02mmfWS6Eu06E1jrSWP5EYZ6hvqVPbIU= X-Google-Smtp-Source: AAOMgpeWEs09zq7wAHWaxMcRZlzYY2OOwFiapPux20htsMlt1RKOn4tY5TOpASdZJNGTk6nNQW47lPCfsYSgk+KXqrY= X-Received: by 2002:a1f:25c8:: with SMTP id l191-v6mr12650070vkl.66.1532493444426; Tue, 24 Jul 2018 21:37:24 -0700 (PDT) MIME-Version: 1.0 References: <153244035927.22640.15207006290980496560@ietfa.amsl.com> In-Reply-To: From: Abhijan Bhattacharyya Date: Wed, 25 Jul 2018 10:07:13 +0530 Message-ID: To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Cc: core Content-Type: multipart/alternative; boundary="00000000000060308e0571cb6f6d" Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 04:37:27 -0000 --00000000000060308e0571cb6f6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, 24 Jul 2018, 19:24 Ari Ker=C3=A4nen, wro= te: > This version addresses the WGLC comment from Jim about the potential > "unexpected" 4.29 responses to first request. > > > Cheers, > Ari > > > On 24 Jul 2018, at 16.52, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Constrained RESTful Environments WG of > the IETF. > > > > Title : Too Many Requests Response Code for the > Constrained Application Protocol > > Author : Ari Keranen > > Filename : draft-ietf-core-too-many-reqs-04.txt > > Pages : 5 > > Date : 2018-07-24 > > > > Abstract: > > A Constrained Application Protocol (CoAP) server can experience > > temporary overload because one or more clients are sending requests > > to the server at a higher rate than the server is capable or willing > > to handle. This document defines a new CoAP Response Code for a > > server to indicate that a client should reduce the rate of requests. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-04 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000060308e0571cb6f6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

This version addresses the WGLC comment from Jim abou= t the potential "unexpected" 4.29 responses to first request.


Cheers,
Ari

> On 24 Jul 2018, at 16.52, internet-drafts@ietf.org wrote: >
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Constrained RESTful Environments WG o= f the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Too Many Requests Response Code for the Constrained Application Protoc= ol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Ari Keranen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-core-too-many-reqs-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-07-24
>
> Abstract:
>=C2=A0 =C2=A0A Constrained Application Protocol (CoAP) server can exper= ience
>=C2=A0 =C2=A0temporary overload because one or more clients are sending= requests
>=C2=A0 =C2=A0to the server at a higher rate than the server is capable = or willing
>=C2=A0 =C2=A0to handle.=C2=A0 This document defines a new CoAP Response= Code for a
>=C2=A0 =C2=A0server to indicate that a client should reduce the rate of= requests.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.i= etf.org/doc/draft-ietf-core-too-many-reqs/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/h= tml/draft-ietf-core-too-many-reqs-04
> https://datatr= acker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-04
>
> A diff from the previous version is available at:
> https://www.ietf= .org/rfcdiff?url2=3Ddraft-ietf-core-too-many-reqs-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf= .org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> core mailing list
> = core@ietf.org
> https://www.ietf.org/mailman/listinfo/core=

_______________________________________________
core mailing list
core@= ietf.org
https://www.ietf.org/mailman/listinfo/core<= br>
--00000000000060308e0571cb6f6d-- From nobody Tue Jul 24 23:06:31 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222FD130E2A for ; Tue, 24 Jul 2018 23:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgdzjkUyFPtq for ; Tue, 24 Jul 2018 23:06:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA65130DE2 for ; Tue, 24 Jul 2018 23:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6P66NEG008015; Wed, 25 Jul 2018 08:06:23 +0200 (CEST) Received: from [192.168.217.102] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41b4VR0j18zDXZ6; Wed, 25 Jul 2018 08:06:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 25 Jul 2018 08:06:22 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 554191580.024286-bd6b3df5b7337a1da102fa67ae0cf332 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Carter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] CoAP x HTTP Cross proxy (Was Re: CoRE Tools) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 06:06:30 -0000 On Jul 25, 2018, at 04:32, John Carter = wrote: >=20 > Is anyone aware of any open source cross proxies that present a http = view of coap services? I never open-sourced the code behind coap.me (which is just that) = because it is based on some highly outdated HTTP server libraries and = thus hard to install. (I also never updated the specialized CoAP = library behind it to what is now github.com/nning/coap.) (FYI, coap.me is about 1500 lines of code, about 100 of which is the = PCAP decoding support, plus some 400 lines of HTML templates.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 25 01:09:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED84130FB2 for ; Wed, 25 Jul 2018 01:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_QPPgnVW-Po for ; Wed, 25 Jul 2018 01:09:42 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC822130E4A for ; Wed, 25 Jul 2018 01:09:41 -0700 (PDT) Received: from si0vm1948.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 41b7Dc3BZPz1XLFh2; Wed, 25 Jul 2018 10:09:36 +0200 (CEST) Received: from si0vm2082.rbesz01.com (unknown [10.58.172.176]) by si0vm1948.rbesz01.com (Postfix) with ESMTP id 41b7Dc2nB9z4j4; Wed, 25 Jul 2018 10:09:36 +0200 (CEST) X-AuditID: 0a3aad16-137ff700000024a4-43-5b583031eefd Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by si0vm2082.rbesz01.com (SMG Outbound) with SMTP id 54.9A.09380.130385B5; Wed, 25 Jul 2018 10:09:21 +0200 (CEST) Received: from SI-MBX2032.de.bosch.com (si-mbx2032.de.bosch.com [10.3.230.35]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 41b7Dc0hXPzDcM6; Wed, 25 Jul 2018 10:09:36 +0200 (CEST) Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2032.de.bosch.com (10.3.230.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1466.3; Wed, 25 Jul 2018 10:09:35 +0200 Received: from SI-MBX2033.de.bosch.com ([fe80::d477:ebbc:f463:4ce4]) by SI-MBX2033.de.bosch.com ([fe80::d477:ebbc:f463:4ce4%4]) with mapi id 15.01.1466.008; Wed, 25 Jul 2018 10:09:35 +0200 From: "Kraus Achim (INST/ECS4)" To: John Carter CC: "core@ietf.org" Thread-Topic: [core] CoAP x HTTP Cross proxy (Was Re: CoRE Tools) Thread-Index: AQHUI7/FG2urnMvymE2qAJkPgLl5h6SfldNg Date: Wed, 25 Jul 2018 08:09:35 +0000 Message-ID: <63ab384538434c61b767198f5c56cb4c@bosch-si.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.81.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22TfUwTdxjH+d0d5eg4dlwtfSwt4i1u0UUK6DKiy+KWLTEBF03ccPaPrZUT OqFlvULExcWkCSNKkDGKUARZxlvqpJWXjG0E1yuZbMvEORWEYaIYhzhHiIOBCN0dV2z/2D9P vs/L53me33M5Eme6SC1psTo4u9VUwCqUhHLHBf3W9LQDxrTZug2ZA4+8eKbvQj++C9vd0rKI 7f5zoozYix1UvpbLFVhKOLvh9Q+V+WWDHkVRm/5oh9CoOIEGdSdRLAn0dqj3+KNPIiXJ0J9h 0NPzNOT0I5hu/TfkPEJQdue8QnZ+QNAUHCEkXkHvgOrmQIyk19Evg8//cFXj9AtwuSEQLWkV vQtWxoMKueYNqF1qDNVnwFdzVUjSBL0J3N1zuKQpeieMea6taobeC4+dNzBJx9L7YPJm52pP ROvB5xvG5VkaGLt3DpPfQ0NLvxwHWg0PJleiZb0BnKfnxbmkWL8ZvN8ZZHQj1Jy6EyOPTYCf 6u8RVUjjjujqDhPuCMIdQTQjwoPUvCWtpDAjLTMj1W7m+GNp6amHbIVdSP5YiX3I6c8VEE0i No4agANGJtpUwpcWCugVEmPVVMxijpGJN9tyS/NNfP4H9uICjme1FIqKimJUz8J8sbnQwvMW m1VAQOLsOuqtgMhRuabSY5zdJmMCSiIJVkNhy+8ZGTrP5OCOcFwRZ1/L7iRJFqi/U8UdEuxc Hnf0sKXAsZZm9fLMxMhM5FiMjBXQNjJOnG2WWlB8kamQt+SF8PUyzqxFw+jPyEiOOSuqcbLi do1on864RDtwqla0f0iWIaw2K6fVUC8axL601CG/2PpsM62O6lCJCXVEItx9Gt1C4m1V1B4J jhP/lfBOQPWpzr7PJISCYSijVWToxwxM3Z3CYGmxF4dyYRoHoW2EgODkDAFTfQMx0OOvU4I3 WP4cXGqojoerNU3x8KTe9Txcvf4bDUNdbSr4vrJTBaN/BdTwhWsmEeY6gonQNObVwHTQr4GV uusArotX1sNt75IWhpdbk2CpdV4HlWf79TC1cF8PXbOuZOj2dCbDxYXBZFj4+nQKXLo/lAIP PDdSpsWDY+LB1YfelQ7uMDn+5+ChaPh12hNoi9tacfOgYpNvfPSw4eNhnfVTpy7HmqJddOTs f9vbnnXm1faMz5+wPwqXsxK2E/P/XMOOWJHpzPGPRl76feKbwK/+T7Kzf9la0jwaW9FtaGpH xbO12yq/HOQfLvsmshKyx6sCDUlkeWPWlXeOC/v3+TYPfXuutrnXfJewVL55qzevniX4fFP6 FtzOm/4DqxJkcsUEAAA= Archived-At: Subject: Re: [core] CoAP x HTTP Cross proxy (Was Re: CoRE Tools) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 08:09:46 -0000 SGkgSm9obiwNCg0KdGhlIGNhbGlmb3JuaXVtIGVjbGlwc2UgcHJvamVjdCBpbmNsdWRlcyBhIGNv YXAtaHR0cCBwcm94eS4NCkl0IGhhcyBiZWVuIHVwZGF0ZSB0byB1c2UgbmV3ZXIgaHR0cCBsaWJy YXJpZXMgbGFzdCBhdXR1bW4sIHNlZS4NCmh0dHBzOi8vZ2l0aHViLmNvbS9lY2xpcHNlL2NhbGlm b3JuaXVtL3B1bGwvNDc5DQoNCklmIHlvdeKAmXJlIGludGVyZXN0ZWQsIHlvdSBtYXkgc2VhcmNo IGZvciByZWxhdGVkIGlzc3VlcyBlLmcuDQpodHRwczovL2dpdGh1Yi5jb20vZWNsaXBzZS9jYWxp Zm9ybml1bS9pc3N1ZXMvNjc4DQpvciBjcmVhdGUgbmV3IGlzc3VlcyBvbiBnaXRodWIsIGlmIHlv dSBuZWVkIHN1cHBvcnQuDQoNClNvbWUgImV4b3RpYyBpc3N1ZXMiIGFyZSBub3QgYWRkcmVzc2Vk IHJpZ2h0IG5vdywNCmJ1dCB0aGF0IHNob3VsZCBub3QgYmUgYSAidG9vIGxhcmdlIHJlYWwgd29y bGQgcHJvYmxlbSIuDQoNCmUuZy4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUy I3NlY3Rpb24tMTAuMi4yDQoNCuKAnENvbmRpdGlvbmFsIEhUVFAgR0VUIHJlcXVlc3RzIHRoYXQg aW5jbHVkZSBhbiAiSWYtTWF0Y2giIG9yICJJZi1Ob25lLU1hdGNoIiByZXF1ZXN0LWhlYWRlciBm aWVsZCBjYW4gYmUgbWFwcGVkIHRvIGEgY29ycmVzcG9uZGluZyBDb0FQIHJlcXVlc3Qu4oCdDQoN CkVpdGhlciB0aGUgaHR0cC1vcHRpb25zIGFyZSBtYXBwZWQgdG8gdGhlIGNvYXAtb3B0aW9ucywg d2hpY2ggdGhlbiBjYXVzZXMgY29uZmxpY3RzIHdpdGggdGhlIGRpZmZlcmVudCBkZWZpbml0aW9u cyBvZiAiIElmLU5vbmUtTWF0Y2giIChodHRwIHdpdGggYXJndW1lbnRzLCBjb2FwIHdpdGhvdXQp LiBPciB0aGUgcmVxdWVzdHMgYXJlIG1hcHBlZCwgcG90ZW50aWFsbHkgZXhjaGFuZ2luZyB0aGUg b3B0aW9ucyB0byBhY2hpZXZlIHRoZSBzYW1lIGVmZmVjdCAoYnV0IHRoZW4sIEkgd291bGQgcHJl ZmVyIHRvIGhhdmUgdGhhdCBtYXBwaW5nIG1vcmUgZXhwbGljaXQpLg0KDQpTZWUgaHR0cHM6Ly9n aXRodWIuY29tL2VjbGlwc2UvY2FsaWZvcm5pdW0vaXNzdWVzLzY2NCNpc3N1ZWNvbW1lbnQtMzk5 MDIxNDY3DQoNCk1pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4gLyBCZXN0IHJlZ2FyZHMgDQoNCkFj aGltIEtyYXVzDQoNCihJTlNUL0VDUzQpIA0KQm9zY2jCoFNvZnR3YXJlIElubm92YXRpb25zwqBH bWJIIHwgU3R1dHRnYXJ0ZXIgU3RyYcOfZSAxMzAgfCA3MTMzMiBXYWlibGluZ2VuIHwgR0VSTUFO WSB8IGh0dHA6Ly93d3cuYm9zY2gtc2kuY29tIA0KDQpTaXR6OiBCZXJsaW4sIFJlZ2lzdGVyZ2Vy aWNodDogQW10c2dlcmljaHQgQ2hhcmxvdHRlbmJ1cmc7IEhSQiAxNDg0MTEgQg0KQXVmc2ljaHRz cmF0c3ZvcnNpdHplbmRlcjogRHIuLUluZy4gVGhvcnN0ZW4gTMO8Y2tlOyBHZXNjaMOkZnRzZsO8 aHJ1bmc6IERyLiBTdGVmYW4gRmVyYmVyLCBNaWNoYWVsIEhhaG4NCg0KDQoNCkZyb206IGNvcmUg PGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gQ2FydGVyDQpTZW50OiBN aXR0d29jaCwgMjUuIEp1bGkgMjAxOCAwNDozMg0KVG86IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6 IFtjb3JlXSBDb0FQIHggSFRUUCBDcm9zcyBwcm94eSAoV2FzIFJlOiBDb1JFIFRvb2xzKQ0KDQpT byBJIHN0YXJ0ZWQgdG8gcG9rZSBhdCB3aGF0IGl0IHdvdWxkIHRha2UgdG8gcmV2aXZlIENvcHBl ciBhZGRvbiBmb3IgZmlyZWZveC4uLi4NCg0KVGhlbiBJIGJhY2tlZCBvZmYgYW5kIGRlY2lkZWQg dGhhdCBpcyBwcm9iYWJseSB0aGUgX3dyb25nXyBhcHByb2FjaC4NCg0KSSBub3cgYmVsaWV2ZSB0 aGUgY29ycmVjdCBhcHByb2FjaCBpcyB0byB1c2UgYSB2YW5pbGxhIHdlYiBicm93c2VyIGFuZCBh IENvQVAgdG8gSFRUUCBjcm9zcyBwcm94eS4NCg0KVGhpcyBpcyBsaWtlbHkgdG8gYmUgdGhlIG1v cmUgY29tcGVsbGluZyBkZW1vbnN0cmF0b3IuDQoNClRoZSBDb0FQLnRlY2hub2xvZ3kgc2l0ZSBk b2Vzbid0IGxpc3QgYW55IGltcGxlbWVudGF0aW9ucy4NCg0KSSBzZWUgcmZjODA3NSBleGlzdHMg d2hpY2ggc3VnZ2VzdHMgc29tZW9uZSBoYXMgZG9uZSBpdC4NCg0KSSBoYXZlIGZvdW5kIGh0dHBz Oi8vZ2l0aHViLmNvbS9pYm0tc2VjdXJpdHktaW5ub3ZhdGlvbi9jcm9zc2NvYXAgd2hpY2gsIHVu Zm9ydHVuYXRlbHkgaXMgdGhlIHdyb25nIHdheSByb3VuZC4uLi4gaWUuIEl0IHByZXNlbnRzIGEg Y29hcCB2aWV3IG9mIGh0dHAgc2VydmljZXMuDQoNCklzIGFueW9uZSBhd2FyZSBvZiBhbnkgb3Bl biBzb3VyY2UgY3Jvc3MgcHJveGllcyB0aGF0IHByZXNlbnQgYSBodHRwIHZpZXcgb2YgY29hcCBz ZXJ2aWNlcz8NCg0KVGhhbmsgeW91LA0KDQoNCi0tIA0KSm9obiBDYXJ0ZXINClBob25lIDogKDY0 KSgzKSAzNTggNjYzOQ0KVGFpdCBFbGVjdHJvbmljc8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg wqAgwqAgwqDCoMKgIA0KUE8gQm94IDE2NDUgQ2hyaXN0Y2h1cmNoDQpOZXcgWmVhbGFuZA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIENvbW11bmljYXRp b24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhl DQpiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCBodHRwOi8vd3d3LnRhaXRyYWRpby5jb20v ZW1haWxfZGlzY2xhaW1lcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0K From nobody Wed Jul 25 01:35:17 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC22F130E4A for ; Wed, 25 Jul 2018 01:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nTMs9fiFsa2 for ; Wed, 25 Jul 2018 01:35:12 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9025C130DC6 for ; Wed, 25 Jul 2018 01:35:12 -0700 (PDT) Received: from wangari.tzi.org (dynamic-218-c.informatik.uni-bremen.de [134.102.218.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 2D03C24DFF; Wed, 25 Jul 2018 10:35:10 +0200 (CEST) From: Olaf Bergmann To: Carsten Bormann Cc: John Carter , core@ietf.org References: Date: Wed, 25 Jul 2018 10:35:10 +0200 In-Reply-To: (Carsten Bormann's message of "Wed, 25 Jul 2018 08:06:22 +0200") Message-ID: <87k1pjlnlt.fsf@tzi.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] CoAP x HTTP Cross proxy (Was Re: CoRE Tools) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 08:35:15 -0000 Carsten Bormann writes: > On Jul 25, 2018, at 04:32, John Carter wrote: >>=20 >> Is anyone aware of any open source cross proxies that present a http >> view of coap services? > > I never open-sourced the code behind coap.me (which is just that) > because it is based on some highly outdated HTTP server libraries and > thus hard to install. (I also never updated the specialized CoAP > library behind it to what is now github.com/nning/coap.) Actually, the david fork in [1] might be useful here as it now supports multiple sockets (i.e., you do not have to choose between HTTP and CoAP exclusively). The CoAP client side is missing, though. [1] https://github.com/ruby-dtls Gr=C3=BC=C3=9Fe Olaf From nobody Wed Jul 25 02:40:03 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0212DD85; Wed, 25 Jul 2018 02:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyw_0DBJ_Nfp; Wed, 25 Jul 2018 02:39:58 -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 9BA7C126DBF; Wed, 25 Jul 2018 02:39:57 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3ED1440949; Wed, 25 Jul 2018 11:39:56 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E73C926; Wed, 25 Jul 2018 11:39:50 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c11f:111d:9050:bbf7]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7632B79; Wed, 25 Jul 2018 11:39:50 +0200 (CEST) Received: (nullmailer pid 31375 invoked by uid 1000); Wed, 25 Jul 2018 09:39:49 -0000 Date: Wed, 25 Jul 2018 11:39:49 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Francesca Palombini Cc: Jim Schaad , "draft-ietf-core-object-security@ietf.org" , 'Core' Message-ID: <20180725093948.GB16887@hephaistos.amsuess.com> References: <053f01d4193d$0a72c460$1f584d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Reading -13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 09:40:02 -0000 --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Francesca, this all looks very ready to me, especially with the changes after Jim's comments. I very much appreciate dropping the request_piv carry-over to cancellations and the option to send first responses by using the request PIV (minute comments sent directly to the PR). Looking forward to updating my implementation, the next interop, and the publication of OSCORE Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAltYRWAACgkQOY0REtOk veHITRAAphPTuQi9nBo8uTYscpj75b5BvN+wpz/7nJHMNv6NCoHK59a1Zc9HrVFH jB462VEHKPrrkthOoYUrO2DTG4WygLCDe8pIwSIlZzP5CC3JXQEsqCifU1RPuVRY F7cFNNQce4U0P7TNJrgTYOd+QExAn7Lotobg0/sN4te2u99ZxIjKi+YdGdP6NojB kDV0F0UgkeaIa+lk9EbEF9hadTYWEK9lJOrjbJBFtWr8AkUIKs8vbs91cEnnVPoc 0VT9UJXtG9R1NZX30Hj9R29OpK/vV8gO3vDbkm7Aat+EbSd+Db55tSeELExrFPwc M1VX0wG9kx+OcYZ/oaVOdtygi0EsUfYoh+UJMgQmTU3xgMGt9s4XJGXLfpdWmqzn dkKO0yNV+g1JaQqB+N3UdjaFzQVzOClZvTZNGca2n+ypWPExPLFn4RTMIFwKly53 S2GumXb6RBwqLSpXeUVZxXTDoCtmuNhQnnHeKEo0LjUjwIedovtXwy24vXT0tN7f Tks4QCbpppxOcYAP5yfJ9LVD/nJ9syP/4V+D/cVITidIKDHB/aZa6YZchgFK1egB jNvo3LLgS2zjTMOYv2I/qOHVH3t/6zD9J8qTWhnEHq9m2Kt2fgQH+IrZdn4eMvUh nLAPHv4IdKF3J1eSmzOmZolV4rFMM1NztLNY+/IlX7mSNogIJWM= =TIVR -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From nobody Wed Jul 25 10:22:12 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C007C130F3B for ; Wed, 25 Jul 2018 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=UaMQpwLL; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jlxGcbo4 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 DOM8IJBFRaP0 for ; Wed, 25 Jul 2018 10:21:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D58D13106A for ; Wed, 25 Jul 2018 10:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532539317; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bwMWoDQe0C7zIe5lXkAncsguLVEskc3A3lI2+H0+C1E=; b=UaMQpwLLmYJWIvAWOSBgS5E4ORAB+WUEss/WvblSU4IrUlIQPoMtwTAmvR/qDNxk ZslAVTX+mHCuMX0xUSv8ZWf0nBgDQaXwdeRQdYgJjlurWkEAedYqgTj04aV+pQHy FmCxNSp2V2d64TpfqyAbtzXmNwSJbqJkgmQ2fVqs+FA=; X-AuditID: c1b4fb25-b05ff70000006cb9-e6-5b58b1b581f8 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.27.27833.5B1B85B5; Wed, 25 Jul 2018 19:21:57 +0200 (CEST) Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 25 Jul 2018 19:21:56 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 25 Jul 2018 19:21:56 +0200 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 25 Jul 2018 19:21:56 +0200 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=VI4M4yvAV3Hch/J7sZja7wx1ZPQySGoKpLtUSnlY0O8=; b=jlxGcbo41UNb10utW8j7vvKf4fdjmgLTyz3kTPKjhgVC+MCe7BpyL+YegnSzmONOnKpwg4fYKOEyN/Fjtgu07/D4ZkHtegGsdt5cVzO7Zx9hcrz3YC+T3gZVCrleramCAuTC0glW5EMYYH/HLv13qTtVfvWzqMQOSm5mmgiMQS8= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2788.eurprd07.prod.outlook.com (10.173.94.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.13; Wed, 25 Jul 2018 17:21:55 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11%3]) with mapi id 15.20.0995.008; Wed, 25 Jul 2018 17:21:55 +0000 From: Francesca Palombini To: 'Core' , "draft-ietf-core-object-security@ietf.org" CC: Jim Schaad , =?iso-8859-2?Q?Christian_Ams=FCss?= , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= Thread-Topic: OSCORE Interop Thread-Index: AdQkOz/vbSMg/mrtRzutYnoaxAKVng== Date: Wed, 25 Jul 2018 17:21:55 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2788; 6:HT1u/PnlzK9rO7Gn5IxDPTiXq+B5TUUx1AUKayuOEaWwVhOVOv1axmD2fTF/2fyNAehW4bJLojtbma6e/QQF9UJzqVcTS8BMRkdImnsDaozKNzt/ly3pNnfhF0HJtEWrtMPl90q1sPaUPVQUQZ57+z7SKq8rn+pu6ysKahea6XhUCijv52irvJ3mrXDleSii0p4wLzV7DeKBOmWo/v9y7NIKaIv6Na6LCwJ+yOyoCNvMHBZC+0Sciby6pbzFTxKHedh2E8cNivlkJWvf6FnX2DZ2XqxVw+QSJJbwllYQYgKv7o990oTDEjhPBLLZffBpyeQiwyRoZv8pL0+tlsqGkYmW/PEdQPUcSxW/3HCDZiaYkDl1v6YC8DfkrS4leb3G8ILte7gRUqXctLeawp79BZlruqLMO85wfh9uCveyAJ7tiz43keUp6r3bY/ZI0Uask35oUoWnUNiViMC6Slq5XQ==; 5:hOQZO08AiAvQl3fgAc3EbiCxbkcwcJDM6iJfL06ImV97Kk++qagV1C+iM3Z4CosmPAo52XxFSAooNezrlnVWTTYc6/EgBC0LcVZGF88GXw1xZ0cEWRJ04029+mEuEG0ufgIDnSLRvP6yloPh5kXipKUHuMP8v+xAsDGgo601Rjo=; 7:6rLEq0hb8ZnZQ2WbEBPAfgqii54MRKx9PLP3d1fv99EwuzaXqmOm6jWImnRYwW5ugum6/OOiWzC6uFhpvIXPSTTnc896JRyDkrdqmaUV4+TdeBfAfXIg/ISoaKeHa7H5PsBl7bFMZ/mztbl4SMoqhJaxNnFS3+TC66OTUvj5tV0e7J77YpF8Zw1JaQaBK1x/uDDGAp+FHTlugfEXHcp8bkKd190XxC8Gqjy1sQomU/jwCbpWKN6sXtGg8KDmj8QZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5ff28107-fb7b-4740-2bd9-08d5f2531ebe x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2788; x-ms-traffictypediagnostic: AM5PR0701MB2788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2788; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2788; x-forefront-prvs: 0744CFB5E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(366004)(136003)(39860400002)(199004)(189003)(53754006)(2900100001)(21615005)(86362001)(66066001)(966005)(221733001)(478600001)(6116002)(3846002)(2906002)(486006)(7116003)(55016002)(19609705001)(81156014)(81166006)(68736007)(97736004)(476003)(8936002)(9686003)(790700001)(54896002)(6436002)(236005)(6306002)(186003)(99286004)(105586002)(110136005)(4326008)(54906003)(256004)(74316002)(53936002)(7696005)(33656002)(316002)(26005)(6506007)(14454004)(8676002)(102836004)(3480700004)(5660300001)(5250100002)(25786009)(44832011)(606006)(7736002)(2501003)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2788; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nVHt7pZR3e3hll8+JBzaqwkkhCKQcjk/BDd5H19IG6f1vcelJnWuTK3gtnOuVve8vk8bMDyANsPRqQhrewMk0k00uRsRxjUjhrh+WL179hpqUC55YBPZHLYrimR/GBQvaoWYGUg/npQZNTnGS2ucumOt0817+gMaUqB+nmBpIlLdS/PS8pAsKjdgt6H8KLcPWH8Yg0M0cV6YbaQbPb3dGWAAfViL2bcZXsOZF/rjP+Zd/GWQhUQnZ/M3FZgE71sKFoxRVhfLfdAI5vmf2tW809XMY8ufBe8cR3skSB4pZdtBLBygFMA76v7mxXgGnaerCZ2Q7gR03WaUqfz2IG97+znZd3DsLJ1t78cxI+6xR30= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2737E1C88A121093F82C3C5498540AM5PR0701MB2737_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5ff28107-fb7b-4740-2bd9-08d5f2531ebe X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2018 17:21:55.3509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2788 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+e3ebdfZ4DY1Tz5KRlJoc1pG+8MiIdACsUBRNMilNzXnlF0V J/1hRH80zdRQ0R4+mJnv1EornTofYayZU8kKi6lZvkistHys3O4N/O9zzvl8z+9cuAQm6ue6 EInKNEqllCvEPAFeGtmeJXnaEhntu/bIXqbryMNluqVmTFZsMeCy+pI1nuz58CjnFDdY07vO DW65V8IL1mr/cIILv+nxc3iUICCOUiRmUCrpyRhBgrGwDk997J65NdjAyUZdezXIjgDSHz6v GHkaJCBE5ACCxkUjxhSrCD41NeJWy1ZszrkxAy0HNAOvbBZO5mOwWbvA5os4UDU/z2eKKQTj jXe41jyPDIC35u82diRp6KwYxK0SRtYiaLV0YdaBA+kMDVoN0iBiW3KDFksEgz7QvpJpNXDS E/qmxmxrhGQMjL5rsp2HSHf4ea3etgXb3vJhppzDfBwJ2s5hjGEnmJu2cBk/FsY+5vGZvhhM m5Ws4w6m8hxkPQ3IHj4s19SwiySwXFTESiEw11yNMdIQgl+mXFY6DIPdrYjhFPhqXGdfOAt/ DbfZ8D6ou2XGmbAeg5qcAjwfSct2XM5wChTmVNtYSO6GodIZnOn7wOzrMpa94WHlAsawBEzm Ju7OfgXi1yEnmqIvJccfOepDqRJjaTpF6aOk0lrR9r/V+2TDswONLgbqEUkg8S7hUlVktIgr z6DVyXoEBCZ2FJ7ui4gWCePk6ixKlXJRla6gaD1yJXCxs9B8vC1KRMbL06gkikqlVP+nHMLO JRv5jp8xjVzJ5Pf4e8yrRyd1lZa+jfeGyetfbhyc3p9w/xjp9Wb1qmEyTj+hq23YcpU5hSmk I3sKDvh2FsjSX9z0r1q/e96+ILe07UdxaPgJ78DxIr9YmfTy7HDS1sTvJrVDuEDzwD7sUF3Q hbIgpWT39MvQ7rV+5yiP8vlnimqTKUSM0wlyPy9MRcv/AZv+kZtXAwAA Archived-At: Subject: [core] OSCORE Interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:22:09 -0000 --_000_AM5PR0701MB2737E1C88A121093F82C3C5498540AM5PR0701MB2737_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi all, We are preparing for the interop of OSCORE v-13 (with updates from review c= omments). The test spec for this coming interop are available here: https://ericssonr= esearch.github.io/OSCOAP/test-spec5.html Thanks Malisa for pointing out 2 issues with the previous spec! They should= be solved now. A couple additional tests are added as well (Observe and ID= Context), while some other are slightly modified (Observe) If you are interested in participating, let me know, the interop will happe= n either at the end of this week or the week of the 6th of August. I will s= end more details when the date is set. Thanks, Francesca --_000_AM5PR0701MB2737E1C88A121093F82C3C5498540AM5PR0701MB2737_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are preparing for the interop of OSCORE v-13 (wit= h updates from review comments).

 

The test spec for this coming interop are available = here: https://ericssonresearch.github.io/OSCOAP/test-spec5.html

 

Thanks Malisa for pointing out 2 issues with the pre= vious spec! They should be solved now. A couple additional tests are added = as well (Observe and ID Context), while some other are slightly modified (O= bserve)

 

If you are interested in participating, let me know,= the interop will happen either at the end of this week or the week of the = 6th of August. I will send more details when the date is set.

 

Thanks,

Francesca

--_000_AM5PR0701MB2737E1C88A121093F82C3C5498540AM5PR0701MB2737_-- From nobody Thu Jul 26 00:41:58 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F13130E47 for ; Thu, 26 Jul 2018 00:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Hiok8rfL; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Qx/tGz2K 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 PO_3OpUccyj6 for ; Thu, 26 Jul 2018 00:41:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B42130DF2 for ; Thu, 26 Jul 2018 00:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532590905; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Tyv4o98UTEoDrxfHs87Y3h2oC7aV9tMWohf06P56NM8=; b=Hiok8rfLyrZ1DKNKmPiZuD9fsD6w1rI+oMqWA2779P0msHF/lRoZstEQNvb75qdV 2KiL1UTfOpqkUAm2Khup6nOAXHcty3cnCpUz4Uvkg9sWsSMVCkj4S7ActP8osgzE n3JHydhc+tKjQNUr8AiUdw8lw54s7GbQQebpTk5NU/Q=; X-AuditID: c1b4fb30-5cb039c0000059c2-12-5b597b398ed2 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.44.22978.93B795B5; Thu, 26 Jul 2018 09:41:45 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Jul 2018 09:41:39 +0200 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 26 Jul 2018 09:41:39 +0200 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=lbUycnjywGcudeBXwU3T4TmdS0tDbtoPSxP4LcK17tw=; b=Qx/tGz2KhEMrZnQ2+ROF33J8oIBtZ8N/AsLmCboPcjd4YII+7/AU/Nki5jXUVO9QJiFRrvDzHU914MwMds3Zvbkv1LROACkZzcIEaxwKAUKDwMUgZJW/7eafUdSnOY90UCAbihf8i12Ou8BAKsLLul1qG5fYbYUxrMxQGDG6Em0= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2674.eurprd07.prod.outlook.com (10.173.93.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.10; Thu, 26 Jul 2018 07:41:39 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11%3]) with mapi id 15.20.0995.008; Thu, 26 Jul 2018 07:41:38 +0000 From: Francesca Palombini To: Joel Halpern , "gen-art@ietf.org" CC: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" Thread-Topic: [core] Genart last call review of draft-ietf-core-object-security-13 Thread-Index: AQHUH86Kl+EdeXBIlUeFKF12MHUt86ShJn6Q Date: Thu, 26 Jul 2018 07:41:38 +0000 Message-ID: References: <153205248660.10636.17459130896592894639@ietfa.amsl.com> In-Reply-To: <153205248660.10636.17459130896592894639@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2674; 6:rosRGnHCzkRtY5tsend0mPmvTbghhAoPyDaIFtTQTaWYLy0tjofVc19mdSnaMs3zV5SIQz14eWC8eLb6qgPgQi9RVIlnC7QRcasyy80XN9tGjIj5ueXFg3JFG1A34psqRIv7mKRIPQqx6I2q5bPR8M84rgvvIm02k47j6GD5kS9wUdFET1WGor+YlhhNjR62NFedu2toydv056jdVeKSu0cLVJqshERuCICqcXWisVUMWExwikLgg314UqSI8r+the84BCkY9/uzl4NT8Xa+GLAnSn9Wbtksfw/6SgDcW4FAtGVIOzENelS3O+CzyusEwbGsmmV5vXKAZE30++96xc9jMA2+eic910hH2pfdLQNbOnoS/DtqtTtKa/lV5E644gj0cp78MgqOzp6cu+j+8DPtpAxAiupX2Wf3qg1u/97yBOK3x1Z23ipZpziTluQHDrHotxkN4Du1n65wM8QALA==; 5:dcdz6F4uySEDHC2Fz77tluiCSJF4cbtwbIXfuxEPz6FZvDkmL85QwaHfdss+WogLQOu/cx/oeqYPll25PW00u/wKoGX6XbPmWeFHJplAvxPCWUiHvFW+bf9c/ZYZDEAa0meggmMCaGJnaEqKxjj7R2aruBOjcW45rqAzfPUluq0=; 7:RfgieNWqCyfMXnOkozJ1UxoKT6+ixOezwgdGNaw/2Idwp90/gFn9GYgcieUYuwgw2QCi30tYmIQ0KElZkAuUyOrlEs/tWlDNJbU22tWLGZC2rHqmEmat14ZtZ16PQYQ32Kv1ONIYVhHErNiKheyl6kSK7i5Mkq4OnDuiSRXGubkvhp2tPWylO61zpmLmAFH8C1tpPaykqdUxaEHcL08MFz/Mkh9DEor4p0wgdMI6zcHDyrtNR8dveMYLC7f97moK x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f463cff5-7171-4421-549c-08d5f2cb38e2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2674; x-ms-traffictypediagnostic: AM5PR0701MB2674: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2674; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2674; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(39860400002)(136003)(13464003)(199004)(189003)(33656002)(186003)(26005)(5250100002)(102836004)(6436002)(2900100001)(81166006)(2501003)(44832011)(105586002)(6506007)(53546011)(68736007)(66066001)(8676002)(6306002)(55016002)(2906002)(7736002)(106356001)(76176011)(74316002)(110136005)(54906003)(486006)(476003)(229853002)(7696005)(14444005)(6246003)(446003)(256004)(11346002)(316002)(305945005)(15650500001)(9686003)(25786009)(478600001)(86362001)(97736004)(4326008)(966005)(53936002)(14454004)(8936002)(5660300001)(6116002)(99286004)(81156014)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2674; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LNbS+opX7HK7a45h8gjx/iGSNbmxhI+QKIy1Dd0FDkNQuBRQt3puLkfz2svga8kV7xanwWjoLX1iIphtWPDfar6VHNaP8DEQIRRfKa4vgt1+igVFeehSyx2fC24udInzXCc3OeLFV0VJJcP0LGnHlxwFSCeMAONGS1RzO1UgVJwM168jzcjYu5MQdRWsg116+O9WHUVZGPd8AZtYFfYfxUd2VtxJSLsEUuJ0oDIpLRNcFm5aznvgtz1PhWJq+vqDQwllAzbArV3YyiRRHtZoMgkjGWRYAbEUXDSsMO9zjhTATjcZL40nb3EUnoQV5TzcDNiP7wvs/oapm1fiJ9lz19E1zYlGVjhZON0ABfTb/Dg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f463cff5-7171-4421-549c-08d5f2cb38e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 07:41:38.7941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2674 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85m2fDwetUfNKMGARhzrz0YZFdSdDAENLyFrn0qEPdbEdn GtT2IZSlYjEJbaXicmqgpImh4a2LN7xgGplBaSOzJqnlTEXN7Szo2/95/r/nff4PvDQpNvC8 aYUyh1Er5ZkSvpCqiG3PlR69EZcQaJwhZF2LzaTMVvyIJ5v6/ouSfX1aRcmWh6zEKV64ybRO hI8a1lAUES8MTWEyFRpGffhEkjB9XrfKz170ut5UvMHToiJ3PRLQgI/A8mcrpUdCWoxfI9De M/K4woagZ8jgwhUmAvRj7x0YhctIWHq4zbPPi3E5AVPfMjhqDkFhfw1hN/g4FMZnfzogDxwJ /VsthB0isRnBgG7NAbnjCzAyPbO7g96FomGlIZHjg6F++wlp1xQ+AK/MRciuRTgJiua2nIvP wtZwl4tdC3AYFC/pHX2EfeG3jpslsRd8sFQR3KEYTC/GSE57wsKXbSefDJMzpY4IgPdDydt4 DvGFiao7yB4ZcI8L7EybKc6QwlJ5ufOdSDDoG0gOGkQw3WPkcYY/TLX+cQ6ooG1jx6mPwcJo p5PZB40ls1QZCqr8Lyun/aG6c4XP6UNQV/ODrHTc7waDFRaqGlGNyJNl2KtZacHBAYxakcyy KmWAkslpQbt/pffZZuBztDB/ug9hGklcRca8uAQxT65h87P6ENCkxENkTt1tiVLk+QWMWnVF nZvJsH3Ih6YkXiLZ+dZ4MU6T5zAZDJPNqP+5BC3w1qJ2S6V0Y0GY4V7vfXHPcu2bux03C3yj h2/Tl7Qjrh8fUENEqnm4nr9WxnavCzVhUeOFhW0xA9fSYktt726FRAjCbZdTEs+tW+/bOiY1 jNvEZHKI0tpbu9kU08x/GXWm0DAq2Zun2VDVRfg0C1b9+ld1ipNVBz89Pm6yCKJru6USik2X B/mRalb+F6HREuEnAwAA Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 07:41:51 -0000 Hi Joel, Thanks for your review! I now have updated the draft with improvements from= your comments, see inline. Hope this clarifies. Thanks, Francesca > -----Original Message----- > From: core On Behalf Of Joel Halpern > Sent: den 20 juli 2018 04:08 > To: gen-art@ietf.org > Cc: draft-ietf-core-object-security.all@ietf.org; ietf@ietf.org; core@iet= f.org > Subject: [core] Genart last call review of draft-ietf-core-object-securit= y-13 >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area Revie= w > 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 cal= l > comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-object-security-13 > Reviewer: Joel Halpern > Review Date: 2018-07-19 > IETF LC End Date: 2018-07-30 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: this document is ready for publication as a Proposed Standard > RFC. > My minor concerns from draft -08 have been addressed. >=20 > Major issues: N/A >=20 > Minor issues: > Section 7.2 is about sequence numbers. The first sentence in 7.2 dis= cusses > Nonces. Then the discussion switches to sequence numbers? My guess = is > that the Nonce is left over from previous text? >=20 Actually, the first sentence discusses nonces since they are constructed fr= om Partial IVs, which are basically the Sequence Numbers. I added this prec= ision, at the end of the second sentence. OLD: An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqu= eness of (key, nonce) pairs is shown in Appendix D.3, and in particular dep= ends on a correct usage of Partial IVs. NEW: An AEAD nonce MUST NOT be used more than once per AEAD key. The unique= ness of (key, nonce) pairs is shown in Appendix D.3, and in particular depe= nds on a correct usage of Partial IVs (which encode the Sender Sequence Num= bers, see Section 5). > Nits/editorial comments: > In the first paragraph of 3.3, the text reads: > The requirement that Sender ID SHALL be unique in the set of all securi= ty > contexts using the same Master Secret, Master Salt, and ID Context > guarantees unique (key, nonce) pairs, which avoids nonce reuse. > Unfortunately, that is not a grammatical sentence. >=20 >=20 I think this sentence was too long to be readable, so I tried to split it u= p. Hopefully it makes more sense now. NEW: This means that Sender ID SHALL be unique in the set of all security c= ontexts using the same Master Secret, Master Salt, and ID Context; such a r= equirement guarantees unique (key, nonce) pairs, which avoids nonce reuse. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 26 01:03:52 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1843130DF2; Thu, 26 Jul 2018 01:03:49 -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: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <153259222993.25982.3184787220998016949@ietfa.amsl.com> Date: Thu, 26 Jul 2018 01:03:49 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 08:03:50 -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 : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-14.txt Pages : 81 Date : 2018-07-26 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-14 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 26 01:18:02 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0A130F36 for ; Thu, 26 Jul 2018 01:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=F5NKWMnA; dkim=pass (1024-bit key) header.d=ericsson.com header.b=mLNnhDWT 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 pepkPh03q8yi for ; Thu, 26 Jul 2018 01:17:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DFE130F79 for ; Thu, 26 Jul 2018 01:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532593075; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Obhm3ghHgZ4eDvcYYSePFji/U91Ys9BYdtr/LwuGTtA=; b=F5NKWMnAQUAySEryIuCy8tv91oFkDg1UK3LYahE/MjsU0d7lfM2XiTWkROD7gpih Ky0OTAi925LYvKebDuI+ltrcOz3Om21XwzsfFTCy4nEkIrQcV8WYwIpRXAtFKJ2S +cid76RlUElt7yihQFOY0oko2Inh7NVgJ0vDMoKjgA8=; X-AuditID: c1b4fb30-1dfff700000059c2-50-5b5983b3b09a Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.8C.22978.3B3895B5; Thu, 26 Jul 2018 10:17:55 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Jul 2018 10:17:55 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 26 Jul 2018 10:17:54 +0200 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=Obhm3ghHgZ4eDvcYYSePFji/U91Ys9BYdtr/LwuGTtA=; b=mLNnhDWTDklbtjER5uigy3+hg7NJR8lweUSbMRCP0/vFeeYyt+/fYDhx9kFzDtl3uaVnGhYHitV7WFI52ZfaGzAhAmxohh+slTR/2uqUnbc0adFUPXBEKdORzG5WB2Q3vmks0W5T/7OYcCKQuRxCgaBTLVjVpLt3kKm3Kav+yPM= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB1778.eurprd07.prod.outlook.com (10.167.215.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.12; Thu, 26 Jul 2018 08:17:54 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11%3]) with mapi id 15.20.0995.008; Thu, 26 Jul 2018 08:17:54 +0000 From: Francesca Palombini To: "core@ietf.org" CC: "draft-ietf-core-object-security@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-object-security-14.txt Thread-Index: AQHUJLdESWLwpdQh9Eeo5HIQgDpyn6ShJung Date: Thu, 26 Jul 2018 08:17:54 +0000 Message-ID: References: <153259222993.25982.3184787220998016949@ietfa.amsl.com> In-Reply-To: <153259222993.25982.3184787220998016949@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1778; 6:IC6I+2/OwPt07VKmS8RaZC+kZZl0YFFQXmiu5Zc3TtD517lVXadivOq2aGYCrPue0HuqDSQafDhhOyE8d9YWuTt2oJaqlU5G8v0gavaomgoF6Aj8TB2stGPtjeXicp2ztQspy/f+cXWdIpUpPZ3DY2m9V1L9/eGD/z1QZw5Fl+L667jzP4fbmU7Q+Im4pQPExR+spNFsE5WxOAcQbxFq8N+CNohOUuKb4kKC4gMbw6714EvA5ubJiSSddYJ4ukxC8W+N1+xK4bPuBxulPGpQJYMs1OotWATBJ1Ik5yFahgxi551LS62ryRZwrJxHKmFdBqv0MoZEWvQJjV9gYjjZKDOxO1LQ87tKqhnkQB74INWEv6qy+8jNJRvkyqqlZUqCcK/kARfVglbLtXKscyjrn5cUd9FTJPvlulG0AD2wj/OY0ZevVsoYsbid2ufOfeoJ9ia8OIG+iEeI3VYBO5HiQA==; 5:0389t6sE6f5GH1Ewa/ER3pQWwg4cD9XrAYC91Y2xzLudHgIvVvYGt0Qleb36NOBPYfL5H2MEOe2QcN/jXGzMkkRJHOrkX1R/VCecFWfc936y7BsV6wIQAXwwZCjDUTovad70lDzUqgzU7iSPHKRQZWagc4OZ6Qm92wPccxZbj+o=; 7:Le7alTJ1PE2gBPF1cPVe+nlk8aX/usGavyCEZiFysgxlqHJjLXxG1fbtSqc6SjrCxoDRn6eJZTHcOxvlP5PEhl5MWevSlwiD5wQpJzYNSdXuqFDNMyC1Zis8BKbB94moqjVDhj1Y0Iabxros4Tw/IAGHPS2KHLQdXXDZfPHUom7kC8BQBBAZGwl0EQ8hpwnGPvsCF6qsYhIOhBRU+Old+lzn1jBqq91Hl8sw5keKdddWAfgZGtQYqQYnJJRt3fmr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d92621b5-7da4-4ceb-822e-08d5f2d04975 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB1778; x-ms-traffictypediagnostic: AM5PR0701MB1778: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(120809045254105)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB1778; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB1778; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(396003)(346002)(39860400002)(189003)(199004)(53754006)(13464003)(25786009)(2351001)(256004)(316002)(2900100001)(4326008)(6246003)(53936002)(5660300001)(446003)(478600001)(11346002)(476003)(7696005)(33656002)(97736004)(8676002)(15650500001)(450100002)(99286004)(74316002)(2906002)(76176011)(81166006)(68736007)(6506007)(9686003)(186003)(305945005)(3846002)(7736002)(66066001)(106356001)(8936002)(5250100002)(55016002)(81156014)(6116002)(14454004)(86362001)(2501003)(53546011)(5640700003)(966005)(6436002)(26005)(1730700003)(14444005)(486006)(105586002)(229853002)(102836004)(6306002)(44832011)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB1778; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lPHu/GQpKS2XGK7IYdYJ2EtVb38QJJSsYGq+Unl6ZVeYFepYq+JQhVtCFLQ6TAZwNSpnlQztpd0mY2CKzqrUm9+Fonh0fU8EMj2BfhVFxgQURynnbu+wxBVNXY6oeD9BufLDENCCk0IMMk9vsufLT79MrhFG8bmDOX3aEn9ICURvavJeqxf610izx1UX7lCjnrdXPA6g/JOwl6yvSiF4x77MdxGKcfB3X+YFm8y9TMwNLu6B9eMAW/rglvJBfRfGMAqfP25tKE0kZuveU2ZdDVmQTBSDSweW0fpLk1BhV+/izF0QKFhzedi7Rk0LmH5T52yTm7xP3pMwyZx0dKSSjH3My7iuvQX/4d0q3OycRBg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d92621b5-7da4-4ceb-822e-08d5f2d04975 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 08:17:54.0779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1778 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUyM2J7me7m5shog3l3FC32vV3PbDHt3xkW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl/J+/iaXgl1zFn7YtLA2MU+S6GDk5JARMJHZOOcfS xcjFISRwlFFi8bl+dpCEkMA3Rom1+wwgEkuYJDY+/8wGkmARmMAssfKJH0RiOpPEowvdrBDO I0aJv0fOsYJUsQnYSFx4+B7MFhFQlth85jUjiM0sEC1xbV4DE4gtLOAmsWDXUTaIGneJ/rYj LBC2kcTenxuZILapSkzpOw3WyyuQIPH0/z4miPOcJU4fvgNWzyngIrFhxj4wm1FAVuJL42pm iF3iEreezGeC+FNAYsme88wQtqjEy8f/WCHqkyWu3O4DepkDKK4g0Xs5CqJEVuLS/G5GkL8k BA6wS/Tv3QDVqyvxYepUKNtX4uOLJmaIopOMEof+3GWBSOhIvPrZyQwxNF/i5k5XiHCsxKqr c6F65SRW9T5kmcBoOAvJqbOAOpgFNCXW79KHCCtKTOl+yD4L7HtBiZMzn7AsYGRZxShanFqc lJtuZKSXWpSZXFycn6eXl1qyiRGYKA5u+W2wg/Hlc8dDjAIcjEo8vHPKI6OFWBPLiitzDzFK cDArifAuTwMK8aYkVlalFuXHF5XmpBYfYpTmYFES57Xw2xwlJJCeWJKanZpakFoEk2Xi4JRq YJReruC48+9C3TfiL3t41jhma3WdylvSkSIYYZx850H0kpm3/U/YlLbct44Ifv/kpW1YbMrZ mwZch/j2JBvyfph7ddn5w9wJ1pPbl+rVf24+e6me37nCKqxeTat8Yfbf4AOhVq0ZZi8Wm3Hc eNtRdeTGxbSVZdMuGAgnfJQp9WVIX3VQTzvgqBJLcUaioRZzUXEiAFQmo5UQAwAA Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-object-security-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 08:18:00 -0000 SGkgYWxsLA0KDQpXZSd2ZSBqdXN0IHVwZGF0ZWQgdGhlIE9TQ09SRSBkb2N1bWVudC4gVGhlIGNo YW5nZXMgY29tZSBmcm9tIHJldmlldyBjb21tZW50cyBmcm9tIHRoZSBpbXBsZW1lbnRlcnMgKHRo YW5rcyBKaW0gYW5kIENocmlzdGlhbikgZm9yIHYtMTMsIGFuZCBmcm9tIHJldmlldyBjb21tZW50 cyBmb3IgSUVURiBMYXN0IGNhbGwgKHRoYW5rcyBKb2VsKToNCg0KKiByZXF1ZXN0X3BpdiBkb2Vz IG5vdCBoYXZlIGEgc3BlY2lhbCB2YWx1ZSBmb3IgT2JzZXJ2ZSBjYW5jZWxsYXRpb25zDQoqIGFk ZCBhbiBJQU5BIHJlZ2lzdHJ5IGZvciB0aGUgT1NDT1JFIGZsYWcgYml0cyAoYW5kIGEgc2VjdGlv biBmb3IgZXhwZXJ0IHJldmlld3MgZ3VpZGVsaW5lcykNCiogZm9yIG9ic2VydmF0aW9uczogdGhl IGZpcnN0IG5vdGlmaWNhdGlvbiBpcyBhY2NlcHRlZCBldmVuIGlmIGl0IGRvZXMgbm90IGNvbnRh aW4gUGFydGlhbCBJVg0KKiBtaW5vciB1cGRhdGUgdG8gdGVzdCB2ZWN0b3JzDQoqIGNsYXJpZmlj YXRpb25zIGFuZCBlZGl0b3JpYWxzDQoNCk5vdGUgdGhhdCB0aGlzIHZlcnNpb24gd2lsbCBiZSB1 c2VkIGZvciB0aGUgY29taW5nIGludGVyb3AgKGFubm91bmNlZCBpbiBhIHNlcGFyYXRlIGVtYWls KS4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IGRlbiAyNiBqdWxpIDIwMTggMTA6MDQNCj4gVG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiBDYzogY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBb Y29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0xNC50eHQN Cj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIENvbnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIFdHIG9mIHRoZQ0K PiBJRVRGLg0KPiANCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBPYmplY3QgU2VjdXJpdHkg Zm9yIENvbnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzDQo+IChPU0NPUkUpDQo+ICAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogR8O2cmFuIFNlbGFuZGVyDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgSm9obiBNYXR0c3Nvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5j ZXNjYSBQYWxvbWJpbmkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBMdWR3aWcgU2VpdHoN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTQu dHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiA4MQ0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxOC0w Ny0yNg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBPYmplY3Qg U2VjdXJpdHkgZm9yIENvbnN0cmFpbmVkIFJFU1RmdWwNCj4gICAgRW52aXJvbm1lbnRzIChPU0NP UkUpLCBhIG1ldGhvZCBmb3IgYXBwbGljYXRpb24tbGF5ZXIgcHJvdGVjdGlvbiBvZg0KPiAgICB0 aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLCB1c2luZyBDQk9SIE9i amVjdA0KPiAgICBTaWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKS4gIE9TQ09SRSBwcm92aWRl cyBlbmQtdG8tZW5kIHByb3RlY3Rpb24NCj4gICAgYmV0d2VlbiBlbmRwb2ludHMgY29tbXVuaWNh dGluZyB1c2luZyBDb0FQIG9yIENvQVAtbWFwcGFibGUgSFRUUC4NCj4gICAgT1NDT1JFIGlzIGRl c2lnbmVkIGZvciBjb25zdHJhaW5lZCBub2RlcyBhbmQgbmV0d29ya3Mgc3VwcG9ydGluZyBhDQo+ ICAgIHJhbmdlIG9mIHByb3h5IG9wZXJhdGlvbnMsIGluY2x1ZGluZyB0cmFuc2xhdGlvbiBiZXR3 ZWVuIGRpZmZlcmVudA0KPiAgICB0cmFuc3BvcnQgcHJvdG9jb2xzLg0KPiANCj4gDQo+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5 Lw0KPiANCj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1 cml0eS0xNA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTQNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMTQNCj4gDQo+IA0KPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Thu Jul 26 01:57:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24517130FB2 for ; Thu, 26 Jul 2018 01:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=AEOZQXIs; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Oxp0yTY7 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 9EFfbKh0WJwx for ; Thu, 26 Jul 2018 01:57:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21595130E68 for ; Thu, 26 Jul 2018 01:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532595435; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pnSyK3RAnGWSkQsabsntX1xojQNZfC09Vd9x36LkvNQ=; b=AEOZQXIsz1nffSNYbQ02aa/G8sH11Q0ip8XvOuwhaF79lFfnBc6KEtwDWVotmsbD CfAPC0S2Bg3v6r+S2f4if9U+ExORGQ/hVlnMPI6H5QyMQ4sOfBjGPWSfTgRktLcM NmbrMRU+nBoyE4g4z3XmoN9og7U31EA18/bhTNGiihI=; X-AuditID: c1b4fb25-ee5789c000006cb9-30-5b598ceb51cf Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.45.27833.BEC895B5; Thu, 26 Jul 2018 10:57:15 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Jul 2018 10:57:00 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 26 Jul 2018 10:57:00 +0200 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=nbgJHEGaIra+3ZikQQQCswlIjV6LaFWEe5Y5GSQjnpc=; b=Oxp0yTY7RBkNZXOWfWxLX1U0pR9OFDEQL/sU231f/h9eCmSU2bfa1zK4Pay54rQWjhuFb0lcHK8px+HwnHpWdlCTv1/9iYZWnVKTM5ZlRnuZodyQ1XQcS/vlpbAEc4KwwLkbz4L9MZmgLS4c/xyvi5RceeHx37zxBSZTRu5EoSU= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2819.eurprd07.prod.outlook.com (10.168.155.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.5; Thu, 26 Jul 2018 08:56:59 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11%3]) with mapi id 15.20.0995.008; Thu, 26 Jul 2018 08:56:59 +0000 From: Francesca Palombini To: 'Core' , "draft-ietf-core-object-security@ietf.org" CC: Jim Schaad , =?iso-8859-2?Q?Christian_Ams=FCss?= , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= Thread-Topic: OSCORE Interop Thread-Index: AdQkOz/vbSMg/mrtRzutYnoaxAKVngAffXtg Date: Thu, 26 Jul 2018 08:56:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2819; 6:uqzyRRQiJVR7IIv3gQ8//7tQKs6VnnPH53qmcslDhel2FDNX+3WOW58F0tovS3R9+LG17/KPMI7qSbX6hkJ/rSHwRq0ARXrSr8rIDo4bbNkCqGheog9n2t23vD/f/WaaIm4sOZnMaMv5+ZSxfdwhWqQsM4ZpJg1Jp5tWyXwr01N8wGB/tJ4f9powVFOdqvOed3WmeowQ4yWOhZVnFW+bCc2kbSglYayuKn/he1MHree3sIo4CQxeRNG5VlxquZB1zK9Kv8DCAzn1vOVwg/JF71n2/fd0m0UR1erxuYBOoy4QjGfQVHtZT97wOBMLy3Uhnc+jBYiM/K5m0/ydFRxJNwsSpgblIQHkkAacvQWHd5kX5cAhmYTGgpm/ESe3nFt3NopHBEHjHHFXAUvEtT19Kf04ntukVNFGXM265aJQnRpVXlQJSt+jPWz1fiPgirQI7mkLHGb0aMcHTwke0ODc7w==; 5:u5cp0jOdSMvrN+auN7XyA5OKZEsd+ElpnFCtKV8oAo/mSYcZ/GZmb0obg5mvP/pfRTJbSrn8+8aoQnc/d3NsPVSrAJXwLqzZN9VjYK8Z9efDRPLji8/aVjpcVswjvLUkx0IUrjUnt4lvHV5ycQemoM2pyy1ZSb5ZTI1nvE64l8g=; 7:HcbKKfxaAdRg/VQsxAfd/hsshrg9BWstd8KtjbKird1cDMEIBfTtDAZoFs1haf2eCMcMLYzjSB2l+h63AHhdRTP0EgpOyUdXkBErE6fY02s27iWyC7EfH1SyRtIlucqI+66t5EAAm7+Crn2GCcuc8NPSyXqljFA0A28N71uIUiVf55RSziW2IE8t+8BmVt6FYzC4p8+3/tqgMT8DOtijiZ2UvpZLGXbBmoPnE9d/UolOjoLP1aiXFtnaAYb0N0Jm x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: db596994-9072-457c-0a87-08d5f2d5bf50 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2819; x-ms-traffictypediagnostic: AM5PR0701MB2819: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(162968082949237)(211936372134217)(21748063052155)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2819; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2819; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(366004)(136003)(199004)(189003)(53754006)(7116003)(44832011)(966005)(66066001)(5660300001)(105586002)(53936002)(6436002)(5250100002)(2501003)(14454004)(99286004)(221733001)(4001150100001)(97736004)(21615005)(476003)(54906003)(110136005)(316002)(486006)(106356001)(3846002)(790700001)(6116002)(478600001)(7696005)(446003)(7736002)(14444005)(256004)(53546011)(6506007)(102836004)(9326002)(3480700004)(74316002)(76176011)(81166006)(81156014)(8936002)(11346002)(8676002)(86362001)(186003)(68736007)(606006)(26005)(2900100001)(54896002)(6246003)(9686003)(6306002)(4326008)(19609705001)(25786009)(2906002)(236005)(229853002)(33656002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2819; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LJbOQsRMo77W075fhAHegGnlTaNOJOogBdt0vRfH4+kL267ULCnP3hwXao85+xsyuHMxdvV+kknZQGCfcn6pIJwIymOS7kAnv0+xeA67XtI7b3oUwAYLUHOdMdkrOR7MybP6ArnHdGnmbDaH3DGARJ4UyOQVq165rTRw6G1Zi+sQ1Y7ps4gYgCVdnhJqPwcAn5/saWzUWJKCcP2r3TLb+mjLQFH5oWzw1w5+ZYRTt28q0Hq6EyINUWjCKBm2QkTxVHw2Fwdvemb3fdJ7zuXj0JeW/A2RyHWrDAc3L7YeuvBuMpFLS61qa2MBcArBpnYfZo7CzEG7iBbYQsYFUQ/F8g/2/iHHxayr4eolFs/GrkE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2737C441E1C1C453BEC8942B982B0AM5PR0701MB2737_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: db596994-9072-457c-0a87-08d5f2d5bf50 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 08:56:59.3191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2819 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+d17t11ns59L8eCjdGFFPjIrGiGRFDGDRMTIB6FTr4/STXbN 0iIKkXQ+iERFkVScllrK1iQtW3PiKwvLFUFWMpNINEwRtaKZ17vA/z7ne77nyzlwaFL6QuBJ Z6pyGY1KmSUTiqna2CdXgubK4hJCZvV+clNPBSU3/egi5dX2V5S8o2ZVKO8dtxInBApt/2+B Ql9fI1TodL8Ixd3vFiqKiheHpTJZmXmM5sDxJHFGd92AMKco7OqjKdlNpDuiRU404MMwZW8V aZGYluJBBM3aQoovVhAMdJUI+UJHwIjuk4ArKHyHhN6mKsdMNQGLVotjZhqB8a2Z4JKFOAze 2BYEHLthFvoahzZNJG5DYLA/J7WIpndgL2hZP8OhG/YGvf08j6HQs6jgkML+sDYfzYVIcBKU mN4TnCzdYPv6KU52wkr4rR8ScoywDyzf6iA5JrEHfJxpIPgrMej6xkme3WH2q13A+1Pg3WSF iIsE7Avl1nje4gMTDaWIWxewWQT9g8MU3wiCn1VVjpyzMKc1OkyjCCqHJh2NQChZqXUMqOFZ +QjFm8oR2PtMDtNOaC+3UXdQSN2WZXlWw8OZblS3ebMrjNbOULweDN9e1jk4AFqb5kieg2DC 1inYqjciUTtyZxk2OTs99FAwo8lMYVm1KljF5BrQxlv1G//49yDrfLgFYRrJtklul8YlSAXK PDY/24KAJmVukvtpG5IkVZlfwGjUiZrLWQxrQV40JfOQ2I4+jpfidGUuc4lhchjN/y5BO3ne RDcqEyMian2Ll9aYe4Ve8soFl2XLQOwH/wcXphsK0pJS0/4mX3R/WlSs99t5em9AZ6KX5Ms5 k9jgHW3OM1KfTxlLx8xlotUYNdozXXqtpaim+eRS+MhKhesxw9iudELVRn/cHVU/SIKzi7Oz LmYYXb/1OrI50RaogWvbI1P31csoNkN5cD+pYZX/ALXW+lRSAwAA Archived-At: Subject: Re: [core] OSCORE Interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 08:57:21 -0000 --_000_AM5PR0701MB2737C441E1C1C453BEC8942B982B0AM5PR0701MB2737_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, So the OSCORE interop will take place tomorrow 27th of July at 17:00 CEST (= 8:00 PDT, 11:00 EDT): https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,= 5,8&h=3D5&date=3D2018-7-27&sln=3D11-12 The implementation draft is the newly submitted v-14: https://tools.ietf.or= g/html/draft-ietf-core-object-security-14 The test specifications are here: https://ericssonresearch.github.io/OSCOAP= /test-spec5.html We will use Jitsi: Link: https://meet.jit.si/OSCOREinterop (Dial-in: +1.512= .402.2718 PIN: 4021790411#) (Hangout link for backup: https://hangouts.google.com/call/uddAQ95d1wmuxZKd= W-VKAAEI ) Thanks, Francesca From: Francesca Palombini Sent: den 25 juli 2018 19:22 To: 'Core' ; draft-ietf-core-object-security@ietf.org Cc: Jim Schaad ; Christian Ams=FCss ; Mali=B9a Vu=E8ini=E6 Subject: OSCORE Interop Hi all, We are preparing for the interop of OSCORE v-13 (with updates from review c= omments). The test spec for this coming interop are available here: https://ericssonr= esearch.github.io/OSCOAP/test-spec5.html Thanks Malisa for pointing out 2 issues with the previous spec! They should= be solved now. A couple additional tests are added as well (Observe and ID= Context), while some other are slightly modified (Observe) If you are interested in participating, let me know, the interop will happe= n either at the end of this week or the week of the 6th of August. I will s= end more details when the date is set. Thanks, Francesca --_000_AM5PR0701MB2737C441E1C1C453BEC8942B982B0AM5PR0701MB2737_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,

 

So the OSCORE interop will take place tomorrow 27th of July at 17:00 CEST (8:00 PDT, 11:00 EDT): https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8&h=3D5&= date=3D2018-7-27&sln=3D11-12

 

The implementation draft is the newly submitted v-14= : https://tools.ietf.org/html/draft-ietf-core-object-security-14

The test specifications are here: https://ericssonresearch.github.io/OSCOAP/test-spec5.html

 

We will use Jitsi: Link: https://meet.jit.si/OSCOREinterop (Dial-in: +1.512.402.2718 PIN: 40= 21790411#)

(Hangout link for backup: https://hangouts.google.com/call/uddAQ95d1wmuxZKdW-VKAAEI )<= /p>

 

Thanks,

Francesca

 

From: Francesca Palombini <francesca.palom= bini@ericsson.com>
Sent: den 25 juli 2018 19:22
To: 'Core' <core@ietf.org>; draft-ietf-core-object-security@ie= tf.org
Cc: Jim Schaad <ietf@augustcellars.com>; Christian Ams=FCss &l= t;christian@amsuess.com>; Mali=B9a Vu=E8ini=E6 <malisa.vucinic@inria.= fr>
Subject: OSCORE Interop

 

Hi all,

 

We are preparing for the interop of OSCORE v-13 (wit= h updates from review comments).

 

The test spec for this coming interop are available = here: https://ericssonresearch.github.io/OSCOAP/test-spec5.html

 

Thanks Malisa for pointing out 2 issues with the pre= vious spec! They should be solved now. A couple additional tests are added = as well (Observe and ID Context), while some other are slightly modified (O= bserve)

 

If you are interested in participating, let me know,= the interop will happen either at the end of this week or the week of the = 6th of August. I will send more details when the date is set.

 

Thanks,

Francesca

--_000_AM5PR0701MB2737C441E1C1C453BEC8942B982B0AM5PR0701MB2737_-- From nobody Thu Jul 26 05:26:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0D13110F; Thu, 26 Jul 2018 05:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 zboIEgSoYV5q; Thu, 26 Jul 2018 05:26:46 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1711F13110C; Thu, 26 Jul 2018 05:26:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E9371250FFE; Thu, 26 Jul 2018 05:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1532608005; bh=56uammgHeMwp2DxYQG2/IMImAAprkl+5nnED2ldZ9jE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fUo7V4sZ9kMnRKKivWslmPlC1MReXVEELMEz6Wqf9TGFnPAqmtWwgVbrFXgPYZz8D srBPJ3Do0lg3r8JhllLIiw8S5tknpxrA4LurdPupt7uxSvH407NJxDuBoG0xfcGYBt HJvg4axtspHl12jRuHNOoGJqEaNazzn+DN1QdmgM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [66.194.108.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 472E4250D02; Thu, 26 Jul 2018 05:26:44 -0700 (PDT) To: Francesca Palombini , "gen-art@ietf.org" Cc: "draft-ietf-core-object-security.all@ietf.org" , "ietf@ietf.org" , "core@ietf.org" References: <153205248660.10636.17459130896592894639@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 26 Jul 2018 07:26:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-object-security-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 12:26:48 -0000 Thank you. Those changes nicely address my concerns. Yours, Joel On 7/26/18 2:41 AM, Francesca Palombini wrote: > Hi Joel, > > Thanks for your review! I now have updated the draft with improvements from your comments, see inline. Hope this clarifies. > > Thanks, > Francesca > >> -----Original Message----- >> From: core On Behalf Of Joel Halpern >> Sent: den 20 juli 2018 04:08 >> To: gen-art@ietf.org >> Cc: draft-ietf-core-object-security.all@ietf.org; ietf@ietf.org; core@ietf.org >> Subject: [core] Genart last call review of draft-ietf-core-object-security-13 >> >> Reviewer: Joel Halpern >> 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 treat these comments just like any other last call >> comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-core-object-security-13 >> Reviewer: Joel Halpern >> Review Date: 2018-07-19 >> IETF LC End Date: 2018-07-30 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: this document is ready for publication as a Proposed Standard >> RFC. >> My minor concerns from draft -08 have been addressed. >> >> Major issues: N/A >> >> Minor issues: >> Section 7.2 is about sequence numbers. The first sentence in 7.2 discusses >> Nonces. Then the discussion switches to sequence numbers? My guess is >> that the Nonce is left over from previous text? >> > > Actually, the first sentence discusses nonces since they are constructed from Partial IVs, which are basically the Sequence Numbers. I added this precision, at the end of the second sentence. > > OLD: An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in particular depends on a correct usage of Partial IVs. > > NEW: An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in particular depends on a correct usage of Partial IVs (which encode the Sender Sequence Numbers, see Section 5). > >> Nits/editorial comments: >> In the first paragraph of 3.3, the text reads: >> The requirement that Sender ID SHALL be unique in the set of all security >> contexts using the same Master Secret, Master Salt, and ID Context >> guarantees unique (key, nonce) pairs, which avoids nonce reuse. >> Unfortunately, that is not a grammatical sentence. >> >> > > I think this sentence was too long to be readable, so I tried to split it up. Hopefully it makes more sense now. > > NEW: This means that Sender ID SHALL be unique in the set of all security contexts using the same Master Secret, Master Salt, and ID Context; such a requirement guarantees unique (key, nonce) pairs, which avoids nonce reuse. > >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 26 09:06:56 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 901FF1311E6; Thu, 26 Jul 2018 09:06:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153262120457.26003.10219357966542841070@ietfa.amsl.com> Date: Thu, 26 Jul 2018 09:06:44 -0700 Archived-At: Subject: [core] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 7959 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 16:06:50 -0000 Dear Carsten Bormann, Zach Shelby: An IPR disclosure that pertains to your RFC entitled "Block-Wise Transfers in the Constrained Application Protocol (CoAP)" (RFC7959) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3241/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 7959" Thank you IETF Secretariat From nobody Thu Jul 26 20:44:42 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C24B7130E3C; Thu, 26 Jul 2018 20:44:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153266307973.24794.13798561566596638515@ietfa.amsl.com> Date: Thu, 26 Jul 2018 20:44:39 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-object-security-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 03:44:40 -0000 Reviewer: Joel Halpern 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 treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-object-security-14 Reviewer: Joel Halpern Review Date: 2018-07-26 IETF LC End Date: 2018-07-30 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standqrd RFC My thanks to the authors for addressing my minor concerns. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Fri Jul 27 01:03:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41812F295 for ; Fri, 27 Jul 2018 01:03:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvmZNRsaAZee for ; Fri, 27 Jul 2018 01:03:12 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E191130DC9 for ; Fri, 27 Jul 2018 01:03:11 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 8D64718016111; Fri, 27 Jul 2018 08:03:10 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:2:4:41:72:152:355:379:582:800:920:962:967:968:973:982:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2196:2198:2199:2200:2525:2527:2553:2561:2564:2682:2685:2692:2693:2731:2737:2829:2859:2894:2895:2898:2902:2911:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3586:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4051:4250:4321:4418:4419:4425:4557:4659:4860:5007:6119:6261:6298:6659:6678:7464:7774:7875:7903:7974:8603:8957:9010:9015:9025:9177:9388:9389:10848:11232:11657:11658:11914:12043:12219:12291:12295:12438:12555:12663:12679:12683:12895:12903:12986:13139:13144:13160:13161:13199:13229:13230:13548:13846:13869:13972:14096:14110:14149:21060:21063:21080:21433:21451:21525:21625:21691:30005:30025:30029:30034:30041:30045:30048:30054:30070:3007 X-HE-Tag: grain43_55dbc09653625 X-Filterd-Recvd-Size: 17598 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf11.hostedemail.com (Postfix) with ESMTPA; Fri, 27 Jul 2018 08:03:09 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_443054dde2bf2f6f95960b9417c23da4" Date: Fri, 27 Jul 2018 10:03:09 +0200 From: Peter van der Stok To: Michael Koster Cc: Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl Mail-Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl Message-ID: <04f8af968af10d46c69c46aa1a437ddb@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: [core] pubsub draft review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 27 Jul 2018 08:03:17 -0000 --=_443054dde2bf2f6f95960b9417c23da4 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Michael, below my review of the pubsub draft. My main focus was the alignment with RD draft, internal terminology and alignment with pubsub security draft. Please do not hesitate to question my suggestions. Hope this helps, Greetings, peter __________________________________________________________________________________ Review of PubSub broker for coap Section 2, Publish-Subscribe: OLD: The publishers do not (need to) know where the message will be eventually sent: the publications and subscriptions are matched by a Broker and publications are delivered by the Broker to subscribed receivers. NEW: The publishers do not (need to) know where the message will be eventually sent: the publication-messages and subscription-messages are matched by a Broker and publication-messages are delivered by the Broker to subscribed receivers. OLD: CoAP pub/sub Broker: A server node capable of receiving messages (publications) from and sending messages to other nodes, and able to match subscriptions and publications in order to route messages to the right destinations. NEW: CoAP pub/sub Broker: A server node capable of receiving publication-messages and subscription-messages and sending publication-messages to subscribing nodes, and able to match subscription-messages and publication-messages to route messages to the right destinations. What are notifications? They appear more often in the text. Are they observe messages? If so, introduce that in this section OLD: Topic: A unique identifier for a particular item being published and/or subscribed to. NEW: Topic: A unique message-identifier to match publication-messages and subscription-messages. Section 3.2 /clients to use to/clients to/ Section 3.3 Why introduce data-sinks and data sources. Not used anywhere else. Suggestion rephrase section 3.3 with other already introduced terminology. Section 3.4 The representation text is not very clear; do you mean: "The links of every topic are represented according to one or multiple content-formats" A suggestion to rephrase the topic name space: The topic name space is structured as a tree expressed as a resource path. The topic hierarchy is structured identically to the hierarchy of the URI path. Section 3.5 I don't understand. I do see brokers in Figure 2. How are they different from Figure 1? The location? IF yes, please clarify. Section 4.1 /the link relation rt=core.ps/the resource type value rt=core.ps/ 2nd al: …. a topic discovery entry point, called DISCOVER,…. Can figures 3 and 4 be moved up the text? Please use rt=ps.temperature instead of rt=temperature Everywhere: .well-known/core -> /.well-known/core Page 7: /{create}/{{create}} /limit amount/limit the amount/ OLD: The client can then perform discovery for the parent topics it wants to discover the sub-topics. NEW: The client can choose to discover the sub-topics from the discovered topic list. Everywhere: In URI template variable; please use same terminology and constraints as for RD. For example, /ps cannot be prescribed. It should be an example value used in the draft. Content-format: here only one is specified, where later in the text, and earlier multiple content-formats are allowed. "Success 2.05: SHOULD use the value /ps"; NO, Never SHOULD. /ps is an example path. Fig 3-5 two cts are allowed here?? 4.2 Create: /the target of the link/the reference of the link/ /for publishes to the topic/ to represent the topic links/ Page 9: "If a topic .. Figure 7"; I don't understand this sentence. /Ony one/Only one/ /used in the link target/ used in the URI reference of the link// /exactly one content format/at least one content format/ unless I have not understood anything earlier. /publishes to the topic/receiving any publication-messages for this topic/ /elided/not present/ ; elide is an action not a state. ".. with a target of an existing topic"; Don't understand this phrase. 4.3 PUBLISH "PUBLISH to topics on the broker" This is new not-introduced terminology; please continue with terminology of section 2. Concerning the paragraph: "A Broker MUST .. PUT requests": - Links are replaced not representations. - What is "resolution of notifications"? Page 12: do the figure 9 and 10 references in the text match the figures? Figure 8 and 9 Do "1033.3" represent the payload? Please explain. Does not follow from the template. Fig 10: no value in return of GET? Page 16: It only becomes clear now that the observe numbers 0, 1, etc have a meaning. It would be beneficial to explain that earlier with a table. 4.7 REMOVE; Is there a restriction on removal, like only the creating client can remove the topics it has created. To be enforced with PubSub security. Page19: OLD: A client which registers pub/sub Topics with an RD MUST use the context relation(con) [I-D.ietf-core-resource-directory] to indicate that the context of the registered links is the pub/sub Broker. NEW: A client which registers pub/sub Topics with an RD MUST use the Registration Base URI parameter (base=) [I-D.ietf-core-resource-directory] to indicate that the Registration Base URI of the registered links is the pub/sub Broker. OLD: A CoAP pub/sub Broker may alternatively register links to its topics to a Resource Directory by triggering the RD to retrieve it's links from .well-known/core. NEW: A CoAP pub/sub Broker may alternatively use "Simple Registration", section 5.3.1. of [I-D.ietf-core-resource-directory], by triggering the RD to retrieve it's links from its resource /.well-known/core. Remove: "the pub/sub broker triggers .. further details" 6 Sleep-Wake operation I assume this section is about sleepy nodes and how to handle them. I don't think the statement that the broker keeps the state is correct. The Broker keeps publication messages which contain part of the state. Combining multiple messages about different topics from the same sleepy node may reconstitute the state. I recommend to change this section and write that for sleepy nodes it is recommended that a sleepy node provides only one topic that covers the whole state of the sleepy node. The draft should also point out that the update of the sleepy node or its reconfiguration is not covered. 7 Simple flow control /publish messages/publication messages/ 8 security considerations I don't think that end-to-end security solves your problems of the second paragraph; You also need Proof of possession. I don't understand the last paragraph: "Depending on the level .. to the subscribers". I am missing security objectives; see an example described in appendix A.2 of core-oscore-groupcomm. Once these objectives are described, it can be verified in pubsub-profile draft that they are realized. For example, I don't see any statement about which clients are authorized to delete topics. Probably section 6 followed by section 6.1 in ace-coap-pubsub-profile is closest to what is needed, but with much more pubsub functional details. -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_443054dde2bf2f6f95960b9417c23da4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Michael,

below my review of the pubsub draft.
My main fo= cus was the alignment with RD draft, internal terminology and alignment wit= h pubsub security draft.
Please do not hesitate to question my suggest= ions.

Hope this helps,

Greetings,

peter________________________________________________________________________= __________

Review of PubSub broker for coap

Section 2, Publish-Subscribe:

OLD:
The publishers do not (need to) know where the message will be= eventually sent: the publications and subscriptions are matched by a Broke= r and publications are delivered by the Broker to subscribed receivers.

NEW:
The publishers do not (need to) know where the me= ssage will be eventually sent: the publication-messages and subscription-me= ssages are matched by a Broker and publication-messages are delivered by th= e Broker to subscribed receivers.

OLD:
CoAP pub/sub Broker:  A server node capable of receiving = messages (publications) from and sending messages to other nodes, and able = to match subscriptions and publications in order to route messages to the r= ight destinations.

NEW:
CoAP pub/sub Broker:  A server node capable of receiving = publication-messages and subscription-messages and sending publication-mess= ages to subscribing nodes, and able to match subscription-messages and publ= ication-messages to route messages to the right destinations.

What are notifications? They appear more often in the text. Are they obs= erve messages? If so, introduce that in this section

OLD:
Topic:  A unique identifier for a particular item being p= ublished and/or subscribed to.

NEW:
Topic:  A unique message-identifier to match publication-= messages and subscription-messages.

Section 3.2
/clients to use to/clients to/

Section 3.3
Why introduce data-sinks and data sources. Not used any= where else. Suggestion rephrase section 3.3 with other already introduced t= erminology.

Section 3.4

The representation text is not very clear; do you mean:

“The links of every topic are represented according to one or mult= iple content-formats”

A suggestion to rephrase the topic name space:
The topic name space= is structured as a tree expressed as a resource path. The topic hierarchy = is structured identically to the hierarchy of the URI path.

Section 3.5 I don’t understand. I do see brokers in Figure 2. How = are they different from Figure 1? The location? IF yes, please clarify.

Section 4.1

/the link relation rt=3Dcore.ps/the resource type value rt=3Dcore.ps/

2nd al: …. a topic discovery entry point, called DISCO= VER,….

Can figures 3 and 4 be moved up the text?

Please use rt=3Dps.temperature instead of rt=3Dtemperature

Everywhere: .well-known/core -> /.well-known/core

Page 7:

/{create}/{{create}}

/limit amount/limit the amount/


OLD:
The client can then perform discovery for the parent topics it= wants to discover the sub-topics.

NEW:
The client can choose to discover the sub-topics = from the discovered topic list.


Everywhere:

In URI template variable; please use same terminology and constraints as= for RD.

For example, /ps cannot be prescribed. It should be an example value use= d in the draft.

Content-format: here only one is specified, where later in the text, and= earlier multiple content-formats are allowed.

"Success 2.05: SHOULD use the value /ps"; NO, Never SHOULD. /ps is an ex= ample path.

Fig 3-5 two cts are allowed here??

4.2 Create:
/the target of the link/the reference of the link/

/for publishes to the topic/ to represent the topic links/

Page 9:

"If a topic .. Figure 7"; I don’t understand this sentence.

/Ony one/Only one/

/used in the link target/ used in the URI reference of the link//


/exactly one content format/at least one content format/

unless I have not understood anything earlier.


/publishes to the topic/receiving any publication-messages for this topi= c/

/elided/not present/ ; elide is an action not a state.


".. with a target of an existing topic"; Don’t understand this phr= ase.


4.3 PUBLISH

“PUBLISH to topics on the broker” This is new not-introduced= terminology; please continue with terminology of section 2.


Concerning the paragraph: “A Broker MUST .. PUT requests”:

- Links are replaced not representations.

- What is “resolution of notifications”?


Page 12: do the figure 9 and 10 references in the text match the figures= ?

Figure 8 and 9 Do “1033.3” represent the payload? Please exp= lain. Does not follow from the template.

Fig 10: no value in return of GET?

Page 16: It only becomes clear now that the observe numbers 0, 1, etc ha= ve a meaning. It would be beneficial to explain that earlier with a table= =2E

4.7 REMOVE; Is there a restriction on removal, like only the creating cl= ient can remove the topics it has created. To be enforced with PubSub secur= ity.

Page19:

OLD:
A client which registers pub/sub Topics with an RD MUST use th= e context relation(con) [I-D.ietf-core-resource-directory] to indicate that= the context of the registered links is the pub/sub Broker.

NEW:
A client which registers pub/sub Topics with an RD MUST use t= he Registration Base URI parameter (base=3D) [I-D.ietf-core-resource-direct= ory] to indicate that the Registration Base URI of the registered links is = the pub/sub Broker.


OLD:
A CoAP pub/sub Broker may alternatively register links to its = topics to a Resource Directory by triggering the RD to retrieve it's links = from .well-known/core. 

NEW:
A CoAP pub/sub Broker may alternatively use “Simple Regi= stration”, section 5.3.1. of [I-D.ietf-core-resource-directory], by t= riggering the RD to retrieve it's links from its resource /.well-known/core= =2E


Remove: “the pub/sub broker triggers .. further details”


6 Sleep-Wake operation 

I assume this section is about sleepy nodes and how to handle them.

I don’t think the statement that the broker keeps the state is cor= rect. The Broker keeps publication messages which contain part of the state= =2E Combining multiple messages about different topics from the same sleepy= node may reconstitute the state. I recommend to change this section and wr= ite that for sleepy nodes it is recommended that a sleepy node provides onl= y one topic that covers the whole state of the sleepy node.

The draft should also point out that the update of the sleepy node or it= s reconfiguration is not covered.


7 Simple flow control

/publish messages/publication messages/


8 security considerations

I don’t think that end-to-end security solves your problems of the= second paragraph; You also need Proof of possession.

I don’t understand the last paragraph: “Depending on the lev= el .. to the subscribers”.


I am missing security objectives; see an example described in appendix A= =2E2 of core-oscore-groupcomm. Once these objectives are described, it can = be verified in pubsub-profile draft that they are realized. For example, I = don’t see any statement about which clients are authorized to delete = topics.

Probably section 6 followed by section 6.1 in ace-coap-pubsub-profile is= closest to what is needed, but with much more pubsub functional details.

--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanders= tok.org
tel NL: +31(0)492474673     F: +33(0)= 966015248
--=_443054dde2bf2f6f95960b9417c23da4-- From nobody Fri Jul 27 11:12:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3E0130E64 for ; Fri, 27 Jul 2018 11:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PhC9Q/n4; dkim=pass (1024-bit key) header.d=ericsson.com header.b=KrG3caP0 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 TB4duI3MZd70 for ; Fri, 27 Jul 2018 11:12:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC59130DD4 for ; Fri, 27 Jul 2018 11:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532715128; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bZ2tCM3NAjkMoCPagrug8lNq9vgTtwKWm8ydikAQDIw=; b=PhC9Q/n40LPGK5QL3qMh6ZKu+cnQoiQ1OkDx8JI/gQNk6sGUPrsJWzaVYMyqQMfu 7Dq9y+pqcS25XK/2FI3TTpTBn8XW+jUdoZO4Ni4EebdnNvnmEGm1KXXBRUAa5c46 BkoJI6hm7St3Qb6D4sj3aorK+a2G9BkrBdU8fNRKoKA=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-0d-5b5b60784012 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.E0.22015.8706B5B5; Fri, 27 Jul 2018 20:12:08 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 27 Jul 2018 20:11:18 +0200 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 27 Jul 2018 20:11:18 +0200 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=oSPCazYG8qF11FBLMAfRZTsppU48QH+yM+pd/4k47rE=; b=KrG3caP0GH4swlNpISz2q93gTU1X+6Zx11m9J9nJIDVNUzHLmcCaLTT5AwhErzoiJ1oQhV8phi5iGKtI28RvNfI22ZaRVv8sxGMRHMpAvWUrgbHq/APe/StLq4aeilzviKqw1TSMNmrNqAwddwod2lV5l7R8yV40ab6VXkFLTUw= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2996.eurprd07.prod.outlook.com (10.168.156.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.8; Fri, 27 Jul 2018 18:11:17 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11%3]) with mapi id 15.20.0995.008; Fri, 27 Jul 2018 18:11:16 +0000 From: Francesca Palombini To: Francesca Palombini , 'Core' , "draft-ietf-core-object-security@ietf.org" CC: Jim Schaad , =?iso-8859-2?Q?Christian_Ams=FCss?= Thread-Topic: OSCORE Interop Thread-Index: AdQkOz/vbSMg/mrtRzutYnoaxAKVngBmQSrw Date: Fri, 27 Jul 2018 18:11:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.31.165.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2996; 6:BZRiM6p8nsSeTMSf50pNdsZFBUKH8lP9Mmv9iCn+SnPWcw09+CoqbIdG+s+18qGRKf0lgh2F2goBLWjYjoFoyeN3RYPn38sadzKI2e9RqSClRbPPWL1qUcaBhhp/3o2HWAFqSy2sxHkU6b7Yf+X9BB5RHj1LpdcEXyP3cLrd4LPGb59rbDumeScXNXYWdTLIAhE6QzEsYjPOOFC8wOK7jTtyN/D+QmUmVjUKQsc+DxnVVbsnom9Lb6D73vlnnaRVIWMhU1Zyzw/xJ6kN47hfX3KwvdQswB2pv6Uln83DYOelN7h7jITXoPcoe2JsszQBituHLnCKxSJY42lIiatbv8p8l+RfITz/vOask+qEvw0qsHoUqGVzaC48JF66go4BlOki4KNEqlkGFTUDKErMDNTEvw0y/M0K6BoVaMYHnkci9kJJLSEjvFgKKPbV3dnEMsx+zDMBXfBFBxDt4y2F3g==; 5:5liXfuLw7QTkvzNAidxhancL2ndzw2tEu9+7ufkgW1Gtp31ADiSf8n7HFG66cMpCR9I8O3hyXTVTF1W1Xseg1qPU9K0yNm3tc3xaMkf3USPW41iKVSTc2gnfXs7hOOxBOR2qhHj+gDfgKD42S50UBM/yrHv88w0E4agxTNOTIkU=; 7:/PQ5AGvUG7PP/VmeYnm82U+JilG6xYN9mTZUL8jzc5iB4rz6WVRsFbjX6uJLa1HeG83ibuYvmdxNBxBVHU6oKoR320GL+IcOjkpw+hsm97ZMdkdyfypz9VMZxLgK/H2OIYstxM9/y5Q9+VCabEyGyW1OtwHOJYBLcJN8/xn/l/Ggg2FrPBIBqHW6VI1G3uY2DVj5UW/F7+0nHtdTAL7ScO4IEN2+HBbg8K/VOf0yERQacJ9R1JeT+pmgW8nupPo0 x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(376002)(346002)(136003)(189003)(199004)(53754006)(6246003)(53936002)(5660300001)(7116003)(25786009)(97736004)(256004)(8936002)(7736002)(74316002)(486006)(8676002)(476003)(81156014)(81166006)(14444005)(44832011)(21615005)(6436002)(66066001)(221733001)(86362001)(6116002)(3846002)(4326008)(9686003)(55016002)(6306002)(54896002)(606006)(236005)(229853002)(790700001)(19609705001)(2501003)(2900100001)(5250100002)(105586002)(106356001)(33656002)(966005)(14454004)(53546011)(6506007)(2906002)(102836004)(26005)(11346002)(446003)(478600001)(7696005)(76176011)(68736007)(110136005)(316002)(54906003)(3480700004)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2996; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-office365-filtering-correlation-id: eb9003ae-5a5c-41bf-713f-08d5f3ec58b2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2996; x-ms-traffictypediagnostic: AM5PR0701MB2996: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(190756311086443)(166708455590820)(254730959083279)(21748063052155)(248295561703944)(91638250987450); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2996; x-forefront-prvs: 07467C4D33 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5skoBybMzogvIsrGSs8hXM6TXzqH/+gEhMAw4dd0y5mjgv6r3t4yyBiWW4Nzq8/w9TU2h7oU0KcbYMgFmaAAo+z8tseSjpTQk+EdOLxXaK2MZrQdBDGCV1KBiakis4Cy6VweTL8aZcvrxj3kWkKw7c6A79lCUxDqknG+py1jHESh7glaGynqiZpMqFsfOywp/P9M6oiq6lVhrwvDlwekvexeoFSqyk68ML81o9tdSaROav65LJBzMyz8Ov0HOGuBEMkb9Gr0wLYUByggq8AtG0L64wMgYywyy8mvK6fk4h75IxZoUSO91KkSyRC6lv9OsWGthPzKyMxbSYkF3HPwqc4hgU4arnpqHyYvzNCVQiU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB27374D38D9C78E7C29A53BB8982A0AM5PR0701MB2737_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eb9003ae-5a5c-41bf-713f-08d5f3ec58b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 18:11:16.7613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3bO2Y7m6NvUfNGEWCZRal5pkYVBkVhBEKQ4IoceL+Q2O8dr UJiZf6wSjXDMyktYkKKpmYmZOkVlI7zhhVQwS4oyi1QUtWY7fgb+93uf5/neC3wspWxmPNkU fTrH67WpKqkzbY55k+WfHafRBH4weavbWwppdfv8S0pdYn9Pq2tMK9IIOtJoWWMiGx6bpJFV VauSC1Ssc3gCl5qSyfGHT8Q5J89+t8rS+iOybVOrslzUqDYiJxZwKAw1LjIiK3EPgt8LIUbk 7OBlBANvnzCkqJLASPE4EgsaF1FgL6mgiWOSQOtSMyLFJwRj1n4kNpPicBic+bX53g3XIljq nZCKBoUTYXqqw2GwrCv2gmcbUSK64T3QYI8mGAwDi0limMb7YXL9tUxkOY6DMVsHEiNKB9s3 TomyE9bCWkPvZm+EvWHpVg1F5njAxGy5hFyJoaptgCLsDt8+2xnCKhj+U7mle8Nw+V1EuFMG eZYzhIOg70UHJR4CeEgK849Wt0Lnob5ilCbGPQS2gW6JuBxgPzCWZZGF4mFkslBG8gYoW15g SL4OQUXTU2kRCizdtixhA7TmDaHSzZsVYDXP0kQPgC+20i0+BM8r5yjC/jA8U8ds1yuQrBq5 C5wg6JKCQwI4PiVeEAz6AD2X3ogcv8nStO7fgmrmTnYhzCKVi/xVtEajZLSZQo6uCwFLqdzk rj4OSZ6gzbnO8YYrfEYqJ3QhL5ZWecgDqttilThJm85d5bg0jv/vSlgnz1x0yfehoTrq2r54 Rd6OxLN3Yo761BbUdy7LS02e5jX3kW7z1OW8UI2wtjfuQNRNvTnaWJnZknZ/p/+xsN2eIbt6 f9af093O9htd/KugTmcs+B7XTfSt1Fp4ew9f97VyNj5/sfhjY9/gj4suR8Lzx0LD/DasRQ+S Nm5MWyWK9QJm/J2KFpK1QQcpXtD+A0AOeEdJAwAA Archived-At: Subject: Re: [core] OSCORE Interop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 27 Jul 2018 18:12:14 -0000 --_000_AM5PR0701MB27374D38D9C78E7C29A53BB8982A0AM5PR0701MB2737_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi all, The 6th interop for OSCORE was run successfully, big thanks to Jim and Chri= stian for participating, short notice and all! I compiled a report: https://ericssonresearch.github.io/OSCOAP/interop6.htm= l Moreover, I also recorded the session that can be now "seen" (it is actuall= y audio only, you will need the test specifications to follow) on youtube: = https://www.youtube.com/watch?v=3Duf4sBRlEYH0 Thanks to Jim and Christian for providing the pcap files, as usual you can = find all of it in the "OSCORE interop" github: https://github.com/EricssonR= esearch/OSCOAP There will be a (possibly shorter) follow up interop later in August to tes= t the last Observe code, that was not functional yet. I will announce it he= re, but let me know if you'd like to participate, so that we can decide a t= ime that fits. Have a good (although burning hot) summer, Francesca From: Francesca Palombini Sent: den 25 juli 2018 19:22 To: 'Core' ; draft-ietf-core-object-security@ietf.org Cc: Jim Schaad ; Christian Ams=FCss ; Mali=B9a Vu=E8ini=E6 Subject: OSCORE Interop Hi all, We are preparing for the interop of OSCORE v-13 (with updates from review c= omments). The test spec for this coming interop are available here: https://ericssonr= esearch.github.io/OSCOAP/test-spec5.html Thanks Malisa for pointing out 2 issues with the previous spec! They should= be solved now. A couple additional tests are added as well (Observe and ID= Context), while some other are slightly modified (Observe) If you are interested in participating, let me know, the interop will happe= n either at the end of this week or the week of the 6th of August. I will s= end more details when the date is set. Thanks, Francesca --_000_AM5PR0701MB27374D38D9C78E7C29A53BB8982A0AM5PR0701MB2737_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The 6th interop for OSCORE was run successfully, big= thanks to Jim and Christian for participating, short notice and all!<= /o:p>

 

I compiled a report: https://ericssonresearch.github.io/OSCOAP/interop6.html

 

Moreover, I also recorded the session that can be no= w “seen” (it is actually audio only, you will need the test spe= cifications to follow) on youtube: https://www.youtu= be.com/watch?v=3Duf4sBRlEYH0

 

Thanks to Jim and Christian for providing the pcap f= iles, as usual you can find all of it in the “OSCORE interop” g= ithub: https://github.com/E= ricssonResearch/OSCOAP

 

There will be a (possibly shorter) follow up interop= later in August to test the last Observe code, that was not functional yet= . I will announce it here, but let me know if you’d like to participa= te, so that we can decide a time that fits.

 

Have a good (although burning hot) summer,

Francesca

 

From: Francesca Palombini <francesca.palom= bini@ericsson.com>
Sent: den 25 juli 2018 19:22
To: 'Core' <core@ietf.org>; draft-ietf-core-object-security@ie= tf.org
Cc: Jim Schaad <ietf@augustcellars.com>; Christian Ams=FCss &l= t;christian@amsuess.com>; Mali=B9a Vu=E8ini=E6 <malisa.vucinic@inria.= fr>
Subject: OSCORE Interop

 

Hi all,

 

We are preparing for the interop of OSCORE v-13 (wit= h updates from review comments).

 

The test spec for this coming interop are available = here: https://ericssonresearch.github.io/OSCOAP/test-spec5.html

 

Thanks Malisa for pointing out 2 issues with the pre= vious spec! They should be solved now. A couple additional tests are added = as well (Observe and ID Context), while some other are slightly modified (O= bserve)

 

If you are interested in participating, let me know,= the interop will happen either at the end of this week or the week of the = 6th of August. I will send more details when the date is set.

 

Thanks,

Francesca

--_000_AM5PR0701MB27374D38D9C78E7C29A53BB8982A0AM5PR0701MB2737_-- From nobody Mon Jul 30 03:45:34 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3C413102A; Mon, 30 Jul 2018 03:45:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdGHrxpVc2Wb; Mon, 30 Jul 2018 03:45:27 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9726C130EEF; Mon, 30 Jul 2018 03:45:27 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id E6470100E86C1; Mon, 30 Jul 2018 10:45:25 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:2:41:72:152:355:379:582:800:871:920:960:962:967:968:973:983:988:989:1000:1152:1189:1208:1221:1260:1263:1313:1314:1345:1381:1431:1432:1436:1437:1516:1517:1518:1573:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2196:2198:2199:2200:2525:2553:2561:2564:2682:2685:2692:2737:2829:2859:2892:2897:2901:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3366:3586:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4250:4321:4419:4425:4511:4513:4557:4641:4659:4860:6117:6119:6261:6298:6353:6354:6506:6659:6747:6748:7281:7398:7464:7774:7875:7903:7904:7974:8526:8603:9015:9025:9177:9388:9912:10004:10376:10848:10945:11026:11232:11604:11657:11658:11914:12043:12114:12291:12295:12296:12438:12555:12663:12679:12683:12895:12986:13139:13144:13161:13181:13199:13200:13229:13230:13236:13439:13846:14096:14149:21060:21080:21324:21433:21451:21625:21691:21703:21740:3 X-HE-Tag: cap00_4c782bae7c704 X-Filterd-Recvd-Size: 60486 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Mon, 30 Jul 2018 10:45:25 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f84ee3b034e6761fcf18e41dc87185bf" Date: Mon, 30 Jul 2018 12:45:24 +0200 From: Peter van der Stok To: Ace , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl Mail-Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl Message-ID: <23af2ffc9ec791bec0653d4a5baab467@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: [core] review of palombini-ace-key-groupcomm X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 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, 30 Jul 2018 10:45:32 -0000 --=_f84ee3b034e6761fcf18e41dc87185bf Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi key-groupcomm authors, To start the review I have looked at the dependencies between the different involved drafts and came up with the figure below. The arrows indicate that a draft references another draft. The dots reference arrow means Informative reference. According to me, this means that the work on CORE can proceed independently of the work in ACE. The oscoap-join and key-groupcomm can proceed together to their conclusion without other dependencies. That guarantees that we can develop the group communication drafts in ACE without unwanted dependencies on pubsub. The pubsub-profile depends on core-pusub and key-groupcomm, which does not bother me too much. Keeping this in mind, I have reviewed the key-groupcomm draft. BTW, it might be helpful to include a similar overview in the oscoap-join draft. ________________________________________________________________ Abstract OLD:This document defines a message format for distributing keying material in group communication scenarios (such as based on multicast or publisher-subscriber model) using the ACE framework. NEW:This document defines a message format for distributing keying material to groups to protect the communication between group members using the ACE framework. Introduction OLD: Profiles that use group communication can build on this document to specify exactly which of the message parameters defined in this documents are used, and what are their values. NEW: Profiles that use group communication can build on this document to specify a selection of the message parameters defined in this document and their values. At the end of section 1: .... [RFC8152], like Authorization Server (AS) and Resource Server (RS). Figure 1 is not referenced in the text. I suggest a slightly different figure where dispatcher and KDC are endpoints of the RS, and for multicast the communication is directly between Client and group members without passing through the RS. Key Distribution Center (KDC): Maintains the keying material to protect group communications, and provides keys to clients authorized to join the group. It corresponds to an endpoint of the RS in the ACE Framework. Dispatcher: this is the entity the Client wants to securely communicate with and is responsible for distribution of group messages. Example dispatchers are the Broker in a pub-sub setting or the generator of unicast messages to all group members for group communication. Alternatively, Group communication is done by transmitting to a multicast IP address, and entrusting message delivery to the transport channels between Client and Group members. What is the difference between "adding node to group" and "distribution of keying material". I find the phrase difficult to understand. Figure 2 : I suggest to add Group Member (GM) as communication entity. At the end of section 2, I suggest some text on group identifier and role identifier, such that these terms can be used independent of the application profiles specified in other documents. Section 3. Remove: "where the RDC takes the role of RS". Suggest to add the message exchange before section 3.1 POST --- Authorization Request (application/CBOR) ----> <-- Authorization Response (???? ) ----- It would be nice if here the use of DTLS (or not) and the content format is specified: application/cbor or application/Cose+cbor section 3.1 scope: with as values the group identifier and optionally the role .... "The encoding of the group identifier and the role(s) is application specific." cnf: Optionally, the public key or the certificate of the client Question: is this a certificate identifier, or the public key extracted from the certificate, or a hash????? section 3.2: 0 access token containing all the parameters defined below; This is very confusing. I understood that access token parameter is at same level as cnf, rs_cnf, and exp. And here you write that they are contained in access token. If that is true, I suggest to make the other three parameter sub-bullets of access-token bullet. For topic and role see section 3.1 section 3.3: same request response figure as suggested in section 3 before section 3.1 "a different endpoint" is very vague. Please explain. section 4: /The same types of messages can also be/the same set of messages is/ just before section 4.1 same figure and information as requested in section 3 before section 3.1 section 4.1 "....request to the endpoint in the KDC associated..." Not clear what is meant: - one endpoint for all groups? - one endpoint per group? - one endpoint per subset of groups? scope: remove topic; what resource is referred to? get_pub_keys: Instead of empty CBOR array, an empty payload is also possible? client_cred: same question on certificate as for section 3.1 below figure 3 /additionally/Optionally/ The parameters group_policies and mgt_key_material are not specified in pubsub-profile draft. Do you ever use them? Section 5.2 "NOte that .... leaving node" It is not clear if the client has left the group in this case, and what that means. The actions look quite contradictory to me. section 6 /not able to participate to/not able to receive or decrypt/ section 6.1 scope: same remarks about topic and group identifier. "In some cases ... same KDC". Suggest to remove. In a fast changing environment, this may lead to many error messages if not wrong behavior; Imagine group GA is the only group. C is member of GA. GA is removed and GB is entered as the only group. C wants to leave/join GA, and accesses GB. Section 7 Again suggest to add figure with request before section 7.1 scope: same comment on group identifier and topic. _____________________________________________________ Hope this helps, greetings, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_f84ee3b034e6761fcf18e41dc87185bf Content-Type: multipart/related; boundary="=_7036e5c6d63374b3b4229db8f2674fcc" --=_7036e5c6d63374b3b4229db8f2674fcc Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi key-groupcomm authors,

To start the review I have looked at t= he dependencies between the different involved drafts and came up with the = figure below.


The arrows indicate that a draft references another draf= t. The dots reference arrow means Informative reference. According to me, t= his means that the work on CORE can proceed independently of the work in AC= E. The oscoap-join and key-groupcomm can proceed together to their conclusi= on without other dependencies. That guarantees that we can develop the grou= p communication drafts in ACE without unwanted dependencies on pubsub. The = pubsub-profile depends on core-pusub and key-groupcomm, which does not both= er me too much.

Keeping this in mind, I have reviewed the key-gr= oupcomm draft.

BTW, it might be helpful to include a similar ove= rview in the oscoap-join draft.

________________________________= ________________________________

Abstract
OLD:This document= defines a message format for distributing keying
material in group co= mmunication scenarios (such as based on multicast
or publisher-subscri= ber model) using the ACE framework.

NEW:This document defines a = message format for distributing keying
material to groups to protect t= he communication between group members using the ACE framework.

= Introduction
OLD: Profiles that use group communication can build on t= his document to specify exactly which of the message parameters defined in = this documents are used, and what are their values.

NEW: Profile= s that use group communication can build on this document to specify a sele= ction of the message parameters defined in this document and their values= =2E

At the end of section 1: .... [RFC8152], like Authorization = Server (AS) and Resource Server (RS).


Figure 1 is not referenced in th= e text. I suggest a slightly different figure where dispatcher and KDC are = endpoints of the RS, and for multicast the communication is directly betwee= n Client and group members without passing through the RS.

Key D= istribution Center (KDC): Maintains the keying material to protect group co= mmunications, and provides keys to clients authorized to join the group. It= corresponds to an endpoint of the RS in the ACE Framework.

Disp= atcher: this is the entity the Client wants to securely
communicate wi= th and is responsible for distribution of group
messages. Example disp= atchers are the Broker in a pub-sub setting or the generator of unicast mes= sages to all group members for group communication.
Alternatively, Gro= up communication is done by transmitting to a multicast IP address, and ent= rusting message delivery to the transport channels between Client and Group= members.

What is the difference between "adding node to group" = and "distribution of keying material". I find the phrase difficult to under= stand.

Figure 2 : I suggest to add Group Member (GM) as communic= ation entity.

At the end of section 2, I suggest some text on gr= oup identifier and role identifier, such that these terms can be used indep= endent of the application profiles specified in other documents.

Section 3.

Remove: "where the RDC takes the role of RS".
S= uggest to add the message exchange before section 3.1

POST --- A= uthorization Request (application/CBOR) ---->
<-- Authorization= Response (???? ) -----

It would be nice if here the use of DTLS= (or not) and the content format is specified: application/cbor or applicat= ion/Cose+cbor

section 3.1
scope: with as values the group = identifier and optionally the role ....

"The encoding of the gro= up identifier and the role(s) is application specific."

cnf: Opt= ionally, the public key or the certificate of the client

Questio= n: is this a certificate identifier, or the public key extracted from the c= ertificate, or a hash?????

section 3.2:
0 access token cont= aining all the parameters defined below; This is very confusing. I understo= od that access token parameter is at same level as cnf, rs_cnf, and exp. An= d here you write that they are contained in access token. If that is true, = I suggest to make the other three parameter sub-bullets of access-token bul= let.

For topic and role see section 3.1

section 3.3: =
same request response figure as suggested in section 3 before section= 3.1
"a different endpoint" is very vague. Please explain.

= section 4:

/The same types of messages can also be/the same set = of messages is/

just before section 4.1 same figure and informat= ion as requested in section 3 before section 3.1

section 4.1
"....request to the endpoint in the KDC associated..." Not clear what is = meant:
- one endpoint for all groups?
- one endpoint per group?- one endpoint per subset of groups?

scope: remove topic; wh= at resource is referred to?

get_pub_keys: Instead of empty CBOR = array, an empty payload is also possible?

client_cred: same ques= tion on certificate as for section 3.1

below figure 3
/addi= tionally/Optionally/

The parameters group_policies and mgt_key_m= aterial are not specified in pubsub-profile draft. Do you ever use them?
Section 5.2
"NOte that .... leaving node" It is not clear if = the client has left the group in this case, and what that means. The action= s look quite contradictory to me.

section 6
/not able to pa= rticipate to/not able to receive or decrypt/

section 6.1
s= cope: same remarks about topic and group identifier.

"In some ca= ses ... same KDC". Suggest to remove. In a fast changing environment, this = may lead to many error messages if not wrong behavior; Imagine group GA is = the only group. C is member of GA. GA is removed and GB is entered as the o= nly group. C wants to leave/join GA, and accesses GB.

Section 7<= br />Again suggest to add figure with request before section 7.1

scope: same comment on group identifier and topic.

____________= _________________________________________

Hope this helps,
=
greetings,

Peter


--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanders= tok.org
tel NL: +31(0)492474673     F: +33(0)= 966015248
--=_7036e5c6d63374b3b4229db8f2674fcc Content-Transfer-Encoding: base64 Content-ID: <352daccb51b4c6a75886160adc91720b@bbhmail.nl> Content-Type: image/png; name=352daccb.png Content-Disposition: inline; filename=352daccb.png; size=18642 iVBORw0KGgoAAAANSUhEUgAAAkQAAAEyCAYAAAAbc88bAAAgAElEQVR4Ae3dD3xT9b0//ldC5aK0 pVZ6JUGEB+0qOLhutL+6DXdpi8J3A/98i+LviiYTHndlY/y9hfJnzi+boJg8QECmzG8rgckdaHJR dBtgC2w6pb+EjYsCzToeApLWC2JpiyJt8/k9TnKSnLRpSdr8z4vHg0dOz/mcz5/n5+Scd875JB+V EEKA/yhAAQpQgAIUoEAKC6hTuO1sOgUoQAEKUIACFHAJMCDigUABClCAAhSgQMoLMCBK+UOAABSg AAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOA ABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK +UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoL MCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSg QMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCA AhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUABClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCDiMUAB ClCAAhSgQMoLMCBK+UOAABSgAAUoQAEKMCBK9GOgwwZjngoq1VxYGjui0poOmxF5KhVUegsao1Ii C6EABShAAQpEViAtstkz94gLpBWg4pQVGPNKxIvyFJBWUAFXkZs8a/hKAQpQgAIUSGwB3iFK7P5j 7SlAAQpQgAIUCIMAA6IwIIaahe+R007Y6rZAr5Ueeamg0uphtNjQ6HTn6EvneTTVBpuxxJ020OOq 1lOwVE51b1eNh964D/Y2OTO5ks7GOpi8abQoqVyDypKfeR+3hVamE612CypLtL76H7CjLVQQpqcA BShAgagI+F8DVNDqN+CAvaVL2dfQaNvhO7erpqLS+B8o6XbdaYH9wAbfNUxKV/0yKqdvgE0xguP6 ZUrlvY1qv2vTK3jT1gjPFcx3ber9utmlISH9yYAoJK7wJHY/cjIgt8GETXsyscD2NYQQEI7NeABv Yvn6OldQIaVrcJih8xabjoKKgxB+6zwbrdg8/0WcmbENnVJe4n2suusE1szYCJs3KLqIQy9sxIm7 N6LVleZT7J0z1pOB6zWkMhu2YP66RszY+Ym7/vZVuOvYOswwuuvvlzH/oAAFKECB2Aq01WH98gMY sWiv+5wtBByvzsSAbSthtDX76tbyHl5YeRJ3bz0lp3sdc0b/k2+7a+kazlt+gfnvjsQqe6ecbi8W jetE05lOX9qgyhyIW7Wj8G1vvT7F3icHwvLoZhxqcYdEwV43fQWHvsSAKHSz8O2R/ihWPfMECjQD 5Twzkf/QY5h06G3UyQdB8IUNw7S1z2FxkQbuTs1E/n0/wapH67G77pKczVdobvpSkaUa6fllWHfw RZRp+jCcbOADWLvxJyjy1D89H/ctWYpH+1R/RbW4SAEKUIACYRa4CvvualzQl6PUc86WSlAPR+n8 UpzcfRTe+0RXmtF0TVl8JvLL1uKgqQwaz+qO4/jPp29C5aqHkJ/uCSUGQlM0D6bjFShwXVKCL1Ot GYdve+ulRvqYUjw48Us0X/HcI5ILDut109MY96unFf5r+Vd0BIZlIaNrD6gHI+uWlu4HwXVrdBtG a9O7pEpDRtYgNDV/Ja8fjimrngA2lyJDekQn/S+pRHVtHx9z3T4SWu8bQS6iz/XvUnX+SQEKUIAC YRToQOulr5AzZFD3PHNGYmzNUfzd85hLcy9WzQc23zFEHoIhDa+oRq3y0dqFMzg+oRBjM7texJTZ B1um9MjMAqN+vFyedH26HTO2X1Vm5l4O63XTP/veWuKfkn+FX6CpGa1dgl84r6D580xkDe65a5yt zWjqVptPcdrRdfROB1qbr2JY1o1yas8dIYd8e/NrOIx345JpPn5Ve7FbjsoVAcs8ewYO7+M4OXUQ 9Vfmy2UKUIACFIiGQBoysm/Ehcvdgwzn6WM4NHkCvuF9UCDfEXINrRAQnTYY774E0w+fQ63n6cXg LAx734qTnr8DNiG4Mp323+LfN53BXave9z7KE+IszLoAwVsfr5sBq9dlZc9X3S4J+WcEBNp2Yc3P d8DW6Lk32QL7HjPqy2aiyBN1Swdd03GcdKVxD2B7sngO9nerThPeWbkcG+rkQWjORthMT2P+4e/i yaJsV2qnvRpTS1bC4o3ypee2t2JA17yCLfPaW1i58CXUyfV3DZxb8QscVta/a978mwIUoAAFYiAw CPkzZyPHtElxDQDQdgp7qo6ieOYEZLpqdRX26lkoqbT4vpSjvgXa2zwfrOWqZ96DBc9/iXVr9vjS oQX22l0w6ueg2i4FXsGV6Wy9hDNpI3FnnrsGaLOj9o1dePNA9+ANwVw3+6or+C8mAu1Wg8jVvS7q 681iWbFGABDQ6IRhf71o9avRZVFvXiGKpe3QiOJl24XV+prQSX/rzMLRbhWGXGlbuTDXHxfmZVPc eWGc0Bn+KOpbO725ddZXiWk6g/idQSc0rvz6VuZZqe6u8oOpv7d4LlCAAhSgQIwFOh1HxDbvdQJC o1sv9tdfVtTqK1FfNVvoDFXCoBsnX08CpZN2uSzq968XOo10DZL+S9ed34kav/yEuG6ZnQ5xZL3i ulS8TFTV/FFU6XIFUCwMVvdVMfjrpqI5ISyqpLR9Daa4X98FpK8Qjtk0Gn9WDlLre3bckwIUoAAF KJDUApG+bvKRWVIfPmwcBShAAQpQgALBCPAOUTBKYU7jinILl+Ifnnx1Zjh4p8ijwVcKUIACFKCA n0A0rpsMiPzI+QcFKEABClCAAqkowEdmqdjrbDMFKEABClCAAn4CDIj8OPgHBShAAQpQgAKpKMCA KBV7nW2mAAUoQAEKUMBPgAGRHwf/8BPosMGYVwKjresvYPul4h8UoAAFKJBoAmE8v0sDnvPyjH4z 3Ccah1RfBkSJ2Gv9rvM1NNZtgV4rz2fmmtNsA2xdp+HotZw22Iwl3nln8ow2eKbB6XU3bqQABShA AQrEoQC/ZRaHnRLxKrXUonLCa7jj7Q2YPUb+qfR+FCp9OvjOwRJ8WFEA71Q4/ciPu1KAAhSgAAWi LcA7RNEWj4fyrjSjaeI0/CAMwVA8NId1oAAFKEABCvRXgAFRfwX7sL/reav0mEq/EzbloyutHkaL DY1OT6YdaLTMlR9LzYXl/DnYTJUokfZVTcXK2vPwJnVN5urZpoJKyuuAHX6jf1zPjKVtM7B9+wxo XflIeXUZJ+RJ59reZZunasG+OhtRt0GvKGsqKqtrFZMBBpsR01GAAhSgQH8EvNce77lfBVXAsT/X 0GjbgcoSrXz9GQ+9cV+387ZffgHzOQeLPg8q1VxY7H9FtX68Oz+t3jcReX8aFOZ9GRCFGTSY7NIK KnDKakBugwmb9mRige1rSFPKCcdmPIA3sXx9nRzIpEFT9jKEOAuzrh6bH/8hKk6Mg9HxNUTrZtyL K/jSVWAzbOvXwDxiAWqkfFx5vYJZA17HPKMnLwBpBahokMoxQyf9OrYnrTiIioJ0X9U96UQrrIbb fetDXpLqVYEt+DFsnXK9xOuYM+IY1lXswXlvNBdyxtyBAhSgAAVCFJCuPQ3e8758LeiWhxNttpex 3DwMi2oc7uuJOI5XZ6mxbd6LfmNNvfm1W2HI6pYRgBEoMx10X7/Kf4kG/R/RKTrRWluKvz22GYda 4usiwIAoUB9Ga136o1j1zBMo0AyUS8xE/kOPYdKht1HX7UDJwnef+iNq1snp0/NRWpoPKYxx2i14 +kIZlpcOV4ySHwhNqQ4PnvxDgLyi1MCWo9h9aDJWLZwIjfdIy0T+fT9BZdHfsK/hapQqwmIoQAEK UCAoAacdu5++CP3yyYrzNqDWlGD+g+exu+5SUNn4J7qG0fNfwDOua5Qa6WNK8eDEL9F8hQGRv1Mq /zUsCxneQEGGUA9G1i0tAQ6UkSgce6si4PHBOVsvoSlnCG7yrZKXbsbIsadx9O/u+0jdNkd6hTRW 6Z05uGOA4ttsrlu1N+KOOTtx+KMLka4B86cABShAgVAEnFdwqSkTQ27qenFKQ87IHNQcPdOHbxT/ P5j2XeUH9lAqFL20XVscvZJZEtDUjNauAbLzCpo/z0TW4OC7Rp2RjWEXLsuPzxSwzk9x7NBITPhG 91BJkSpyi7feiUnl21DvfVzmeWwmvTbAVDYicmUzZwpQgAIUCF1APRjZw1pw+cuuF6erOH2sAZMn jEzabxMHf9UNnZV7XE+gbRfW/HwHbI3X5JQtsO8xo75sJooyg+8adX4ZVudYsMZySjGIWsprJw4X Tw8pr+tVOaTt6tH4wcwLqFpvUbQRQNspWCpnobL2YkjZMTEFKEABCkRYQJ2PmauHwrRmj2IQtRNt 9t+j6vCdmFmUHeEKxDB7wX8xEWi3GkSu7nVRX28Wy4o1AoCARicM++tFq7dGZ4VZl+veJm33/s8V OvNZbyrXQqdDWLctE8WeNN3yEkI4zELn2e73Wi7MjnY5v1ZhNRQrylKWWywMVnftXPX3y8OXLtdg FZ7chPhaOKxmYdCN8+ap0RmE2eoQnf4t4F8UoAAFKBBNAemakGsQVt8JWy5dOm9v912bME7oDH8U 9a2Ks3a7VRhyfed93/UJAt48ldcw+frht5/vmhLNZvdUFn+YMUbBqPR1xTGbRuPPpjJoYlQHFksB ClCAAiksIP3EyiPH8IB5NvKDfyiRtGAkSNquZcMoQAEKUIACPQlcQ+Of3saB/FEYxkjAhUSGno6V CK533R0qXIp/eH4cUW9BYwTLY9YUoAAFKEABvx9SVI3CY/tGY+2ie9D/CZySw5aPzJKjH9kKClCA AhSgAAX6IcA7RP3A464UoAAFKEABCiSHAAOi5OhHtoICFKAABShAgX4IMCDqBx53pQAFKEABClAg OQQYECVHP7IVFKAABShAAQr0Q4ABUT/wortrG2xGPYy2tigWG4syo9g8FkUBClCAAr0IhPcaIH3L rdBo68NcaL1UMYybGBCFEZNZUYACFKAABSiQmAIMiBKz31hrClCAAhSgAAXCKMCAKIyYzIoCFKAA BShAgcQUYECUmP3GWlOAAhSgAAUoEEYBBkRhxGRWFKAABShAAQokpgADosTsN9aaAhSgAAUoQIEw CjAgCiMms6IABShAAQpQIDEFGBAlZr+x1hSgAAUoQAEKhFGAAVEYMZkVBShAAQpQgAKJKcCAKDH7 jbWmAAUoQAEKUCCMAgyIwogZ+axuRnZGWuSL8SshFmX6VYB/UIACFKBAzATCeQ0YgBHZgxGvgYdK CCFi5syCKUABClCAAhSgQBwIxGugFgc0rAIFKEABClCAAqkiwIAoVXqa7aQABShAAQpQoEcBBkQ9 0nADBShAAQpQgAKpIsCAKFV6mu2kAAUoQAEKUKBHAQZEPdJwAwUoQAEKUIACqSLAgChheroNNqMe RltbwtSYFaVAtAQ6bEbkqVRQ5Rlh64hWqSyHAhQIRUB6nxYabYjXtygDolB6M+XSMghLuS6PWoPP waKfCP2G99Ho7H+haQUVaHCYoet/VvGTQ5sdB4x6aKdWwx4Go/hpGGuSOAKpdQ1gQJQ4RyZrSoEk EhiBslffwDz8BgWTK2GyNYLXfE/3tsB+YAP0+fPxbs482P4wG/k8U3tw+EqBiAnwbRYxWmZMAQr0 KqDWoGjxq7BvLcWFTfdjcuUO2Bqv9bpLsBu9j9Ckx2iqEt+jZmcj6jbooXWtl7ZNRWV1LextnnBM unOVB1XX/Rot0LvW5UFvORdsNUJO52ysg6nyMZS/OxQLbHuxTl8EDc/SITtyBwr0RYBvtb6ocR8K UCBMAmqk509FhakWW++9iE0F96PSVNfPx2hOXM0YjRm6p2CuvwwhDqKiIB1AM2zrK7AFP4atU0D6 kX4hXsecEcewrmIPzrtiIunO1duomvI9LKt5Xd4PgOYhbLGux5Rlv8HmshFharsiG2cjbKZKTC7Y ggv3rsfedU+gQDNQkYCLFKBAxAWkqTv4LxEEWoXVoBMGa2tkK9tuFYZcSNO5BPyfa7CKdiFEu9Ug cq+TRgipzsUB8wGKfW3prcxcg7BKBaZMmali1sNh7DALHSA0s83i084e0vS0Wto3d4mo+t0KMUX3 ojji+No/5eUasWxalajvlu9Xor7qKVFV/5WcvlNcrlkhNFMUaTs/EebZsxVp/LPu11+dJ0XVFI0A yoXZIR/sATNM9GMj0esfi/NeDMx6Ox8DwnMNCHiIXmeldN0okK8h10kak83SpyT+SwgB6Y0RhYDI zyIWZfpVgH+kjMBlUb9/vdBppohl244IR7egJQgIVzA1Tjyme0RMWbG/ex5ysBU42M8VOvNZXyGu IOV7YlnNBSFEp2i1bhQ6wxERsY8jnQ5h3bZMFGt0wrC/PnLl+FrIJQoEIRDea0C8B0R8ZBbxe3As gAIU6FnAiTb7Phj1peEZN5Orx5Kq/4uNeWb86OcH/B+93XonJpVvQ733cZnnsZn02gCT8lGYOh8P V07CjnVvwd5xDvtfOY8H/+1bkB68ReSfWoMC/TrU2OYh5935yNdvQV2YxlNFpL7MlAJJKMCAKAk7 lU2iQEIIuAY4P4n88lrkLNiLmrCNm8nEmNnPY2PeO/j5to/g/eUu9Wj8YOYFVK23+A/ebjsFS+Us VNZeVLCpkVmswzP4Ndas2oA382ZgyvDIj+lRa4qgX/c6Dj1+DVvCMp5K0SQuUoACvQowIOqVhxsp QIGICDhPofoH97sHONesg75Ag/6cjFzfKtPOwHZvZS/jxOG3UT1nPDJUnm+GDYSmdAEWlQAHlxfI 3yRTQTvvbWCmEc+WDvXu7VpQ52Pm2lk4u6MjsneH/EsFkIn8+xbDZN+Mey9swfdX1KKlWxquoAAF wi2gkh4ihjtT5hcJAekHsubhYMkW3zdfIlEM86QABWQBJ9psL2Lewe9gS0VR5B6X0ZsCKSIgfXD5 zsESfFhRgLQ4bHN/PpTFYXOSvUo3IzsjHg+jZHdn+1JSwBmFsUMpCctGp67AAIzIHtyvu8GRtOMd okjqMm8KUCDBBDrQaPkZtDO2KupdDIN1L+/MKkS4SIFkFGBAlIy9yjZRgAIUoAAFKBCSAB+ZhcTF xBSgAAUoQAEKJKMAA6Jk7FW2iQIUoAAFKECBkAQYEIXExcQUoAAFKEABCiSjAAOiZOxVtokCFKAA BShAgZAEGBCFxBXLxNLvEOlhtHl/dzeWlWHZFKAABShAgZAEpN8hKjTa0BHSXtFLzIAoetYJWBKD sATsNFaZAhSgAAX6IMCAqA9o3IUCFKAABShAgeQSYECUXP3J1lAgcQScjbCZKlGiUrnmFdNKM7zb dkIv/Z1nhM11X/0cLPo897xjegvON9bBVDnV/XfJatR6Z4S/hkbbDlSWaOU5ysZDb9wHe5tT9pDu dpZA5Z3XDECHDcY8qWzPXGfSKiPypPL1O2Gr2wK91l03lVYPo8WGRk92rlydaLPvg1E/Xi5Ti5LK l1FdOcf/0XaXdrryOmCXJ5311Gs89M+tdpWn1Ztwwr4PK11tmYqVtefh9NRVq8dzz+mhVY2HvtoG e+1qt5+fReIcAqwpBeJJgAFRPPUG60KBlBFowalt6/DrSw9gZ6eANKXip899C+9vehbbdWY4GipQ 4JqlZgTKTA0QDjN0DZvxeMFTOHHnr+Do7ETr1lKg9SoAac6xl7HcPAyLahyuvIQ4jldnqbFt3ouw uYKidBRUHIDDPN0nnFaAioZ2v3VpBRU4ZTUgt8GETXsyscD2tTs/x2Y8gDexfH2dHMgAzvN7sHD+ YYxe9b5cpgM1i8bjctMlXxlohm39GphHLECNcLdTOF7BrAGvY55Rykuq115YDUOxfR+gt13GoUnv 4JvFu5H30gm0Wv8XPjAdwWdSXU9ZYbjpAPa1PA5b++uYtOt+FJtG4aXWz2Gd9jFMH3ymKJeLFKBA qAIMiEIVS/b0nk+irk/tGShcuh1LCzPkT8Aq5MXxgLhk75qkal+LFa9a/gWVCydCI5+F1JqJWLhq Mab01NCBxXjKthfr9EXQqNVIz/8+SvMzAacdu5++CP3yyd68pCzUmhLMf/A8dtcpA5SeMu+yPv1R rHrmCRRoBsobMpH/0GOYdOht1LVIt4na8Nf//B2GVi5BmVQH+Z/UhsWm//JO8+G0W/D0hTIsLx2u mL9pIDSlOjx48g9yXtLOt8Ng/A+UajIx+q4iFCz5KXRjspCuHYnbPZlLr1lLYPzlfdCk3Ya77rsP SxbMwJj0TGhHa5WpuEwBCvRBgAFRH9CSehfXp2b5k6xohdWgg8HaKn8CFmiI01mKk7pPkrFxV5rR dEsWMrqcgdQZWRjWU3tvH4+x3gBFkch5BZeaMjHkpi6ZIQ05I3NQc/RM6N9qGda9blAPRtYtLWi+ IgVEX+DMcS3uHpulqEj3RWfrJTTlDMFN3TbdjJFjT+Po37/stoUrKECB2Ah0PYPEphYslQIUSC2B wVkY9nkzWruOyXGcwdlQJdSDkT2sBZe/9MsMwFWcPtaAyRNGwvX0LWC+HWht/qL7lqaudZOezF1B 8+eZyBosnTZvRNawBhw52dx9X8UadUY2hl24jG5hj/NTHDs0EhO+0T1UUuzORQpQIIoCDIiiiJ2U RbXVwega/DkdRltPFwdpjMcGefDnBnlMRyCNZtiM06FSaVHiGl8RKI30tCIVykwCsx66z7U6sxBP lv031m18Xx6oLA1Q3oNfVRhwqLf9Am1T52Pm6qEwrdmjGEQt5fd7VB2+EzOLsuW91BiclYkm6yl3 mW12HDCWo3jO+91zbduFNT/fAZt30HYL7HvMqC+biaJM6bQ5FMULZuPiuvWw2Fvk/aUyD+EN4xxM rz4FKTxT55dhdY4FayynvGOPACmvnThcPF3Oq3vxXEMBCkRfgAFR9M1ZIgUogEyMmf1LVI58B48N kL7JNQD5axoxw2iETqnTaHF/60w7A9u3z4BW/kaaSjUXlkbPz7upkV4wF8/NvIKq+2+Tx7vdhXlv DcacLT9DQbrnNKdGZtFjKO80QiuVmTEf7+b8GHtfvxfbZ5RAbznnKznv37HqR4Ox+7FR7vy08/FW xiN4avY4pMup1MMfwsbNk3B6zUS5TKkNVmBCJX43e4w8ZigLBUtWYWbrq7jfU3dXXo9jS0UR0iF9 y+x+eazet7x1aF5aiDGe8Xqedt9QiKW2pSi8wdP2s1haeL/8jbar2D7jdo7x8/UglygQsoBKSF/v 4L8EEJBOnPNwsGSLd8BmAlSaVaRAaAJSALQceM5UBk1oe4YttfTV+zGbRuPPMaxD2BrDjCgQRwLS e+s7B0vwYZyORfV8dIojMlalZ4GbkZ3R82iInvfjFgokgIDzPGo3V+Ps+NuQkQDVZRUpQIFQBQZg RPZgxTcuQ90/sul5hyiyvsydAhToUaADjZafQTtjq5xiHHTrX8Zziq/i97hrhDa47g4VLsU/PPlL v4nEO0UeDb5SIKkFGBAldfeycRSgAAUoQAEKBCPAR2bBKDENBShAAQpQgAJJLcCAKKm7l42jAAUo QAEKUCAYAQZEwSgxDQUoQAEKUIACSS3AgCipu5eNo0CqCUg/jnhM8QONqdZ+tpcCFOirAAOivspF fT/pd4j08o+wRb1wFkiBhBBwzUBf/AOUv2xV/DJ0QlSdlaRA0gtI3+Is9PzgaBy2lgFRHHYKq0QB CvRBwHkGe36xGdj0W8w7WYmFljOu6TP6kBN3oQAFUlCAv/KXgp3OJlMg+QSaYVu/CJvHrsPeh4tw 08ROHP3Rs9h25/OYPSYz+ZrLFlGAAmEX4B2isJMmS4bBTi6aLO1lOxJZwGm34OnjD+GluYWuucbU mslYufYO7Fj4BuzSLKv8RwEKUOA6ArxDdB0gbqYABeJfQJ0/G2+blPWUJnxdjIP7lOu4TAEKUKBn AQZEPduk+Bb5giIWp7gDm08BClCAAqkgwEdmqdDLbCMFKEABClCAAr0KMCDqlYcbKUABClCAAhRI BQEGRKnQy31qIwdV94mNO1GAAhSgQEIKMCBKyG5jpSlAAQpQgAIUCKcAB1WHUzOp8uKg6qTqTjaG AhSgAAV6FeAdol554m3jzcjOYAwbb73C+lCAAhSgQDACAzAiezDiNfBQCSFEMM1gGgpQgAIUoAAF KJCsAvEaqCWrN9tFAQpQgAIUoEAcCjAgisNOYZUoQAEKUIACFIiuAAOi6HqzNApQgAIUoAAF4lCA AVEcdgqrRAEKUIACFKBAdAUYEEXXm6VRgAIUoAAFKBCHAgyI4rBTWCUKUIACFKAABaIrwIAout79 KK0NNqMeRltbP/LgrhSgAAUoQAEKBBJgQBRIhesoQAEKxLUAPyDFdfewcgEFOmxGFBpt6Ai4NfYr GRDFvg9YAwpQgAIUoAAFYizAgCjGHRC/xXO2+/jtG9YssACP2cAuXEsBCgQjwIAoGCWmoQAFKEAB ClAgqQUYECV19/ancZ7Z7gXEwcUoSOeh0h9N7hsNgSQ/ZjtsMOapoFJJ/zNQuHQ7lhZmyH+rkOcZ m+GXzpNefs0zwiYP4JDGc+S58uqSRqXIC9JYpRJvGe6yPelLfF/yCKrMcOYFRL/+sSgz0c38639D 4VLYlhbiBs9xpzgeo3GGuF4ZnNz1ekJxs106sObhYMkWVBSkx02tWBEKUCAWAjwfxEKdZfZPQApi v3OwBB9WFCCtf1lFZG9+7I8IKzOlAAUoQAEKUCCRBBgQJVJvRbWuHKAaVW4WFgYBHrNhQGQWFEhZ AQZEKdv1bDgFKEABClCAAh4BjiHySMT9KxbfNPcAACAASURBVMcMxH0XsYIUoAAFKJCwArxDlFBd dzOyM+JxKFpCIbKyFKAABShAgW4CvEPUjYQrKEABClCAAhRINQHeIUq1Hmd7KUABClCAAhToJsCA qBsJV1CAAhSgAAUokGoCDIhSrcfZXgpQgAIUoAAFugkwIOpGwhUUoAAFKEABCqSaAAOiVOtxtpcC FKAABShAgW4CDIi6kcTrCul3iPS+yRTjtZqsFwUoEAUBng+igMwiwiwgzWVW6JmEOMx5hyM7tXv2 Yi1KjHVoC5SjsxE2ixF6rTzDcUklTLYP8YZ+ESyNHdL0v4oZmD2zIHte86C3nAuUK9dRgAIUoAAF KECBuBFQf2pehvLXf4PHDr2NuhZnl4o1w7bxNzh2549hcggIISBqFmHsn17Cgu1X3WnTClDRcBZm 3UKYHe3uNFI60Q6HeXqX/PgnBShAAQpQgAIUiD8B9b7qf8LMKaWYVPY/2Ge95FdDp92Cp5u+j4fH ZPrWqzUoWrgCz0zhLyb7UJJxiRNlJmOvJnebeMwmd/+ydRSIrIDa8s1iFGbehPyHZ2LA7j/hvPcm UQc+++i/ccvd34AiHHLXRj0Gs/e9iDJNoKDoHCyux2mApuwFmMpGRLYFzJ0CFKAABShAAQr0U0Bd Nud77oAn819w75D92NcgPwoLOeO3MUN7A1Sq2zHD8zgt5Dy4Q/wIqJFesBgHpcefBxejIJ3j7+On b1iTwAI8ZgO7cC0FKBCMgHrOHTfCPbA6B5Offwu73vsE3ptE6EBT8xXF371lOV0eQySNJxrUW0Ju owAFKEABClCAAnEloO50DYCWB0x31uJRy04ccg2uTsOtd5fiNstf0OCLkIKo/AiUmV6QH6edw5vV f0ZLEHsxCQUoQAEKUIACFIiVgNrvQYh6FO5RDK5WD5+OZ5Y0Ys0KC+xtnqioBfbaXTDqZ8Foa+69 3o3/Hyxrj+DvHb0n49Z4FOAA1XjsFdapNwEes73pcBsFKNC7gDrP8yNJrt8TuhF3zNmK5yfnwL1+ IDSlS/HcTOCteXfJj9bGoHzfFUxY9RIqCrLk3yGSxg1tlMcQeX6DSAWVdga2914+t1KAAhSgAAUo QIGYC6iE9ONC/JcAAtIv087DwZItqChIT4D6sooUoEDkBHg+iJwtc46UgPRL1d85WIIPKwoQ6Dvq kSo32Hz9npgFuxPTxUrgZmRnxONhFCsPlkuBVBbg+SCVez8x2z4AI7IHI14DD94hSsyjirWmAAUo QAEKUCCMAvEaqIWxicyKAhSgAAUoQAEK9C7AgKh3H26lAAUoQAEKUCAFBBgQpUAns4kUoAAFKEAB CvQuwICodx9upQAFKEABClAgBQQYEKVAJ7OJFKAABShAAQr0LsCAqHefONoq/e6IHkZbWxzViVWh AAViI8DzQWzcWWp/BKTfISr0/Bh0fzKK0L4MiCIEy2wpQAEKUIACFEgcAQZEidNXrCkFKEABClCA AhESYEAUIdjEz5YTZSZ+H6ZaC3jMplqPs70UCKcAA6JwajIvClCAAhSgAAUSUoATYyVkt0Wj0mqk FyzGQbE4GoWxDAqEQYDHbBgQmQUFUlaAd4hStuvZcApQgAIUoAAFPAIMiDwSfKUABShAAQpQIGUF GBClbNdfr+EcoHo9IW6PNwEes/HWI6wPBRJJgAFRIvUW60oBClCAAhSgQEQEOKg6IqzJkCkHqCZD L6ZWG3jMplZ/s7UUCK8A7xCF1zPCud2M7AzGsBFGZvYUSBABng8SpKNYTa/AAIzIHox4DTxUQgjh rSsXKEABClCAAhSgQIoKSAER/8ebQa5BWNulcLW3f+3CYS4PW9/lGqziukWKs8Ksyw1bmTz2+N7r 3zFQLAzW1t7eJEKI8L5P+lffPvZ3DM4HMWlnvJ2HWZ9+nOtj8N7MfUToHun79Yl3iFI0CmazKUAB ClCAAhTwCcTrozxfDblEAQpQgAIUoAAFIizAgCjCwMyeAhSgAAUoQIH4F2BAFP99xBpSgAIUoAAF KBBhAQZEEQYOX/ZtsBn1MNrawpclc6IABRJUgOeDBO24lK52h82IQqMNHXGqwIAoTjuG1aIABShA AQpQIHoCDIiiZ82SKEABClCAAhSIUwEGRHHaMbGvFifKjH0fsAahCfCYDc2LqSlAAaUAAyKlBpcp QAEKUIACFEhJAU6MlZLdHkyjOVFmMEpME08CPGbjqTdYFwokmgDvECVaj7G+FKAABShAAQqEXYAB UdhJmSEFKEABClCAAokmwIAo0XosavXlANWoUbOgMAnwmA0TJLOhQEoKMCBKyW5noylAAQpQgAIU UApwULVSg8sKAQ5QVWBwMSEEeMwmRDexkhSIUwHeIYrTjglcrZuRncEYNrAN11Ig1QR4Pki1Hk/8 9g7AiOzBiNfAQyWEEImPzBZQgAIUoAAFKECBvgvEa6DW9xZxTwpQgAIUoAAFKBCiAAOiEMGYnAIU oAAFKECB5BNgQJR8fcoWUYACFKAABSgQogADohDBmJwCFKAABShAgeQTYECUfH3KFlGAAhSgAAUo EKIAA6IQwWKXvA02ox5GW1vsqsCSKUCBOBHg+SBOOoLVCEGgw2ZEodGGjhD2iWZSBkTR1GZZFKAA BShAAQrEpQADorjsFlaKAhSgAAUoQIFoCjAgiqZ2QpXFiTITqrtYWQA8ZnkYUIACfRdgQNR3O+5J AQpQgAIUoECSCHBirCTpyPA3gxNlht+UOUZWgMdsZH2ZOwWSW4B3iJK7f9k6ClCAAhSgAAWCEGBA FAQSk1CAAhSgAAUokNwCDIiSu3/70ToOUO0HHneNiQCP2Ziws1AKJIkAA6Ik6Ug2gwIUoAAFKECB vgtwUHXf7ZJ8Tw5QTfIOTsLm8ZhNwk5lkygQNQHeIYoadTgKuhnZGYxhwyHJPCiQ+AI8HyR+H6Za CwZgRPZgxGvgoRJCiFTrEraXAhSgAAUoQAEKKAXiNVBT1pHLFKAABShAAQpQIKICDIgiysvMKUAB ClCAAhRIBAEGRInQS6wjBShAAQpQgAIRFWBAFFFeZk4BClCAAhSgQCIIMCBKhF5iHSlAAQpQgAIU iKgAA6KI8jJzClCAAhSgAAUSQYABUSL0EutIAQpQgAIUoEBEBdRG/XioVCqoVFNRaXoftjcWQW85 5yvU2QibxQi9Vkqjgkqrh/GAHW2eFI0W6F37y9s9yyWVMNka4ZTTddiMyPNs6/Y6F5bGDk+OfKUA BShAAQpQgAJRFVDPNR2H9NuMQuzForF/w6YFbysq0Azb+p+i4sitWGD72pWu0/ZjDPjtY7jfWOcO ijRlMLVbYcgth9nRLuf1NRzGcThRUYFt9quu/NIKKtDgMEOnM8PhKk8qU/p/FmbdIEWZXKQABShA AQpQgALRFVCne8sbCE3RHKx6ZqK8Rpo5+lWsPPkEfvvsEyjQDHStV2smYvGWX2PaOxuxWw52vFl4 FwZCU/AI5jyRhsMfXfCu5UIoAm2wGUvku3cqqPKMsHV0oNEy17dOVQKjzXuvLpTMe0gbizJ7qApX UyBkgWSe7Z7vzZAPB+4QcwH/J0Py9arLU6U8ow1x83xImroj8L+vRH1VuVhWcyHA5nbhMM8TU6pO ik5pa7tVGHLLhdnRLqe9LOr3rxe6Kf9H1Di+9u3vMAudziwc0hrlsi8Fl/wEOkWrdb2YsqxGXFas 7/zULGZPqxL1LnzFhrAsxqLMsFScmaS8gPvYLQYEitcLa2tE3iAxVOZ7M4b4LLqvAq1HhGHKU6Lm suL92PmJMM+eLarqv+prrhHZr5dB1R1ovfQVcoYEepyVhpyRo/D5pSveMULAVszQ3iDfvZiINcdG YsG2FSiV7yx5Q9XtM6CVxhBpZ2C7dyUXAguokf7tMpRffA1veO/GXUXDvv0YuuQB5PfSe4HzC2Zt LMoMpl5MQ4HrCXhmuxcQBxejID0ib5DrVSKC2/nejCAus46UQPq38G/lLVj/ht0bLzgbalA9dBYe zg8UX0SqItfPt5czRhoysm/EhcvuMUD+WXXgwplPcIvfrLWeMUSdaK1fjWEH9uNYoH09Y4ik8UT+ mfKvQALqEbh31nDseuu/3WO2Wv6Cql13YGZRdqDU4VkXizLDU3PmQoHkFuB7M7n7NylbNxDD730A 39z1B/y1Tfqa1UUcqjqM4pkTkBln7e0lIBqEvHuK8PFrf8J5z1fFPJVvO4rXNn+BR+8Zhe4ZqJGe X4Znq6fg/YUbUNt4zbOX/6s0GNtUBo20tnEfqmsv+m/nX7KAGpnFj+HRQzux/3wL7G+8hovlZfh2 RD/9xqJMdjgFKHB9Ab43r2/EFHEnkPk9zHn0I/x6/zl02N/C+osP4t++nRV31VRb7C1ypZxosx/C G8Y5mCp/g0ydX4bVY3fg8RU7YJMDG2fj+9gw76d4Z9pCzOzldpd6+HT8svwCfvzCe/CUELj1HWj8 4L+w9uiZ+BlYFbiisVurzsfDSzJR/Z87Ydk1HLPuHREgEA1z9WJRZpibwOxSTSCZB1Ur+pLvTQUG FxNDYBDyH56FodW/xXbLYXxz1r9iePe7KTFvihpvzXeP6VENQEb5H9AyoRLmiiK4v32WhYIKE7be exGbCv7JNT5oQMFv0Pn4Tuz1pJFGjN9QiKX/kMcQ6S1odDVrIIY/9DOs/NvjGJJnxIcfGpEnjRvy jCHy/hbRDdDO2BpziPiugBqZRdNR/I4RBx99DMWZ0TiSYlFmfPcCa0eB+BDgezM++oG1CEkgcwJm Fn+AOQcnYU7x0JB2jVZilTRUO1qFsRwKUIACFKAABSgQjwLRuNUQj+1mnShAAQpQgAIUoIBXgAGR l4ILFKAABShAAQqkqgADolTtebabAhSgAAUoQAGvAAMiLwUXKEABClCAAhRIVQEGRKna82w3BShA AQpQgAJeAQZEXgouUIACFKAABSiQqgIMiFK159luClCAAhSgAAW8AgyIvBRcoAAFKEABClAgVQUY EKVqz7PdFKBAdAScjbBZjNBrVa5f+1dp9TAesLsna1bWoO0ULJVT3WlUWpRUVqO6chaMtjZFqmto tFlg1I+X001Fpel92N5YBL3lnC/d9cqUZhjwzhYg10v6u6QSJlujPCt5G2zGErkcRRrPft5ZCXzF cokCiSzAgCiRe491pwAF4lygGbb1P0XFkVuxwPY1pIkBOm0/xoDfPob75TkjXQ1wnoFl4S9gnVqN TiEgxClsvbsBO553KNonzdVWjReO5WOu6bgrLyH2YtHYv2HTgrcV6YIoU5pcu90KQ245zI52Oa+v 4TCOw4mKCmyzXwWQjoKKA3CYF0JnPiunkeomIBxm6BQlcpECySDAgCiWvdhmxwGjXp5Lzv3prLq6 EtONNsVEt9Inwh2oLNHKn9TGQ2/cB3ubU1Hzc7Do89zb9Racb6yDyfNJs2Q1auWJeYFraKzb4vuk Kn8KrfVO8KvIkosUSDiBeJvcVarPq1h58gn89tknUKAZ6BJVayZi8ZZfY9o7G7HbFXgAcF7E6WNF mPGvw+WJmzORX7YETy3L8fWC047dTzsw9eE75bkmpU0DoSmag1XPTJTThVCmL2d5aSA0BY9gzhNp OPzRhW5buYICyS7AgChWPez6RPhzvDt6BeyuT4QComYRxl1uwhlvnaST28tYbh6GRTUO+RPacbw6 S41t816EzRsUjUCZqcH9qa1hMx4veAon7vwVHJ2daN1aCrRKn/akvLbgR1uAefInVSE+xd45w3F0 3RpYzl/zlsoFClAgHALX4DhWj28Fmtk7fQJmzb8Zu977xP14Sj0Uo+96B5teUH7YGYrSdbtRUeCe ahufncDhW76Fsd0mdx6E/NkmmMpGQPrQE3SZ3ZrYAvuBl7Bm12jov3trt61ABxot8qM56Q6TqQya AKm4igKJKsCAKEY91/HX1/H00LlYVTbG92lPrUHRYhOOVxQgTaqX6xPhReiXT4ZG0VNqTQnmP3ge u+suda/9wGI8ZduLdfoiaNRqpOd/H6X5mQAuoW53PR5dNQdF8idVQNo+FUsq78T+faflcQPds+Qa CiSGgBrpBYtxUPqAcXAxCtIVb5qYNKADrZe+Qs6QQQFKT0POyFH4/NIVOSAaibKNW6EfdRxr8gdA 5bp7+wostQHGGgXIzbcqhDJdO23FDO0N8t3niVhzbCQWbFuBUu85Qkp0Fdtn3A6V6gZoZygfzflK 5RIFkkEg1meMZDDsQxs6cOHMp5hw9zcghSo9/nNewaWmTAy5qWs3SSfTHNQcPaN4tCbncvt4jPU7 mXly/wrNTe9izh03dhskOeCOH2Hr4RP4zJOUrxSgQBgE0pCRfSMuXJbu0Hb9J50DPsEt2YPlR2TS kJ18lD5cAZNDGqcj3b29HadN5VhoOeP7sNLUjFbl0/Ku2SLEMuEZQ9SJ1vrVGHZgP451q+8geQxR Oxzm6d1K5AoKJItA1yttsrQrztuhxuCsm/D+kb+jpbeaqgcje1gLLn/Z9Qx4FaePNWDyhJHuO0m9 5eHdloNxkx5DVf1X/oMjPY/rePvbK8UFCoRHYBDy7inCx6/9Cee7voXbjuK1zV/g0XtGQQ0nWmp/ genVp3yBj3z3dtGCaTh2+qJ7/a0FePC29/FeQ6AAy1PjYMv0pPe8SneLy/Bs9RS8v3CDYtyhZ7v0 mgZN2Qvyo7kONL65E7UtXRumTM9lCiSWAAOimPSXGpnF5Xj+4stYYznl+/ptmx21bxihn14Nu3Se Uedj5uqhMK3ZoxhE7USb/feoOnwnZhZlh1D7Qcj7wffxSdVLsHi/Vivt3gK7ZSWmVtb2HpyFUBKT UiA2AtI4uQ0ocX19fINijF1saiOVqs4vw+qxO/D4ih2wyV9ucDa+jw3zfop3pi3EzHzpcZoTV5r/ B+/8/Fms9/s6fjOOHTzu++CjHomHnvl/0bBmLSzeL0JI54NDeMM4B1Plb60FV2ZgE/Xw6fhl+QX8 +IX3rnM+aMQHlp04+vcvA2fEtRRIRAHBf7ETaK0X+w06oQEEpP8anTC8flDUt3Yq6vS1cFi3i2XF GncajBM6wx/90zjMQufJw++1XJgd7Yq8hOh0WIW5a5lmq3Aoi/Tbg39QIFEEOkWrdb0olt4DxeuF 1e99FMs2XBb1+9cLnUbxPt9fL1q9VeoUl2ueEtMMr4s/Kt+bxctEVY0ynXuHbu/hgOmuU2bXc4bO LBye+nSeFFVTNAK5y4ThmWL5vCPX3e/8UiwMVl8rPLvzlQKJKqCSKp6IgRzrTAEKUIACFKAABcIl wEdm4ZJkPhSgAAUoQAEKJKwAA6KE7TpWnAIUoAAFKECBcAkwIAqXJPOhAAUoQAEKUCBhBRgQJWzX seIUoAAFKEABCoRLgAFRuCSZDwUoQAEKUIACCSvAgChhu44VpwAFKEABClAgXAIMiMIlyXwoQAEK UIACFEhYAQZEcdt1bbAZS6BS5UFvORelWsaizCg1jcVQgAIUoAAFehFgQNQLTmw3paOgYi+shjFR rEYsyoxi81hUCghIQb0eRltbFNoqTZuxD0b9eHnC5PHQG99GbfXPovghpn/NdDbaYDHqoZWmO1Fp UVK5AzbbTuj1FjT2L2vuHRaBDjRa5kKr34I6eeqX/mbr3+cqaPUbcMA7FYwnd+nYtqCyRCsf21NR uesVVBYaYevwpJFmnWmEzWKEXisdPyqoSiphsn2IN/SLYGn0Jey9THcbXfu7jkM5L8/x6G235wO7 Z3uX1zAcswyIFH3LRQpQgALBCUjzpm3EjDVNmL7lmDxh8nGY5o7CJ4f/GlwWsU7VVoeNL5zAnXNf hcM1ybMDNYtG40+bnsX2WNeN5csC0oS6m2CbB2wpuB+Vpjo09mc+3bY6rH/saRzJmQdbp4AQX8M2 byB+W/wYjLZmr7rz/B4snH8cU3d+4j62Wzfi7qNv4HlfEgDNsG38DY7d+WOYHFJeAqJmEcb+6SUs 2K6YgPi6ZUptfBntVgNydWb5WBQQnTYY7/wIFT/6rXtuT0gf2A/AYV4Infms/yTlDjN03tr3fYEB Ud/tuu/ZYYMxT4pa5+IN2yFs8PvkaPFO7ghFOk8U3WEzIs8VHc/1i6zdhVx2TcDqmrRS1UNEL0Xq pkr3xJauSP0/YKz8375PqpEos7sA11AgNQScdux++gzK1/4bxqQrTqPp4zDb9L48I7xEcQ4WfZ77 07PegvONdTBVTpU/Ta/2m1XeqdwW4H3uPUd4PwkrPjF71ine572eg3AV9t3VaJr6A7/6qzUTsXDV YkxR9mLXc4tWD6N3ElpPHcZD/9xq150Crd6EE/Z9WOm6uzAVK2vPw+mpl1aP556T7kiNh77aBnvt ankyXn8LZfFcHghN0TyY7Jtx74UtKJgs3YVpROhxUTNsL2/Eyflb8Ky+CBrXYSvl/RNs2TsZ76y0 yIEH4Gw6jWP3Tce/aga6+dPHoGxVJZbd6OsNp92Cp5u+j4fHZPpWqjUoWrgCz0xJk9cFX6YvE3lJ rUHBE0/iCRzFR5/57jZ1SxfGFYp3chhzTdWs0gpQccoKQ64VWzbVInvBfnS6Pnkdw5YHgN3LX3bP wC2lazgLs06a6dr9L62gAg3Cf517SzsaNi/HujPTsNMV0XfCvupOHFvzE0VE70TLoZew8sTd2Nra 6Y6c9/47Rnsyl17DXqYycy5TIMUEPjuBw+3/gnGeC0aPzR+BMlMDhPQJtmEzHi94Cifu/BUcnZ1o 3VoKtMqfpKVP0csPYMSivd5Pvo5XZ2LAtpXe97nrHOH3SVj6xHzQnben/GDPQbiAjw4Pwt1jszx7 el/V+bOxz1QGjWtNM2zr18A8YgFqXOcyAeF4BbMGvI55xjq0uT61S4/2h2L7PkBvu4xDk97BN4t3 I++lE2i1/i98YDqCzzz1uukA9rU8Dlv765i0634Um0bhpdbPYZ32MUwffOatAxcCCKTn476KV2Hf WooLm+7HZOnxpvdxUoD0XVc5m3DsUC5m3TsC/hd+NdILHsb8YYfxXoP7eFQPG427Xt6EF7yBL4DM Uqw7XoECV6zTgc8++m/ccvc3oAiH3CWqx2D2vhdRpkmTIqugy+xaXbTZcWC9AbsKHsR3b/UEWMpU 0qO2Re4P/ZoymLzHrDJNaMv+LqHty9Q9CozGE6tWQl+gkQ88NdLzf4g5k05gd92lHvfqacPAab/A xsUT5YheymsqlqyajEO7j6LFtZMTV5ov4ZoyAymiX/dfik+qyo3XX75+mdfPgykoEBUBz90H1x3W DBQu3Y6lhRny2AcV8ow2ROTz5bAsZIRyBh1YjKdse7HO9elceh9/H6X50uXEfbfmgr4cpcoASz0c pfNLcdL7Pg9FMzznINddgAtlWF46XHERHQhNqQ4PnvwD6lo89yluh8H4HyjVZGL0XUUoWPJT6MZk IV07Ercrq521BMZf3gdN2m246777sGTBDIxJz4R2tFaZKqhl7x0zv3En7nElvj733MHqMt7EtU+J b6yZ3zHUJW2eb9xMLMr0x3Cf/ytM/4X5TatRWLAElvN+Z37/5Mq/nFdwqSkTQ24KdNDejJHjgUut 7neKevhD2Pj7JzHq2Brku6ymorLagtpuY42UBQRYDqFM197bZ8jj2VRQ5a/BsdE/xbZn7pOvfZ78 r2L7jNuhUt0A7Yy3PSvD8hpIJiwZp3Ym2cjK6BrRpiEjaxCamr8KkeYG3D5ag/Que6kzsnBLUzOu uNanQTPlZ5iPrbgjY4B8IZAO4FrY2zwnrC4Z9PpnMGX2mgE3UiB6Aq67n/IYBtEKq0EHg7XVe6el oaIAXd+NYa9cowV6vwtzgEfft4/HWGXA461EB1ovfYWcIb47xt5NOSMxtuYo/h5yRBfMOegLNMsX QG95XRacrZfQlDMEN3VZD9yMkWNP4+jfv+y2JVor3HfVPf3u/+rrc/kumufult/rQVQUyGdWv2PI Py/R4LkrIt1ol+7kd9ku/x2pMv09PQP5/zc2D3saVtt6lA2XH2v5J+z+l3owsoe14PKXga4JX+DM cSDbe92SAq9iPFxhksf0vI45I87A9MOVigCsA03NV3p/dBdSmQC8Y4guo/7F4Tjw5kcB6jtIHkPU Dod5evd29mMNA6J+4PW866UAJ5oOtDZfxbAsxUPYrhk4r6C5qeuZrx1nTzei63dmnK3N+HxYFgZ7 8nDdEdrnvQh0Otbi7ksm/PBXh+S7SJ6EXV77U2aXrPgnBVJG4NY7Menzv+Gk5w6JdMvedWGUTtLS oM9V7kcGQYGkISP7Rly4rBiIKu/nPH0MhyZPwDd6ieikc0FTt3Kudw66FXc/eDMs733S6wVNnZGN YRcuo1vY4/wUxw6NxIRvdA+VulWFK8IjID1CMj6J/PJa5CzYi5p1T6AgYIDdQ3HqUbin7Dxee/dc lz6XviDwBjY3TcI9eVJQfhG1lXNRbVcej5nIv+/fsWBuK043SXek0nDr3aW4zfIXNASKrzxVCLpM zw6e10zkl/0fVD/4VyxcW9PDQHJpMPYL8lOQDjS+uRO1nvejJ5sQXxkQhQgWXPLT2LFmrWLgmxTV /x7b6ifiyaJsOYsbkTXsAqwnP4MTctT/5COYs79rQARce+eXWLjhffmguIZG2w6smF+HsicL3c9v nadQPXU6Ki2nvIGT+lYtbhvQtbZhLLNr1vybAgkj0Aybcbr7a+aucTA9VLytDkbXwODp3nE83pTq fMxcPRSmNXu63IWVPvh84U0W3MIg5M+cjRzTJliUjyTaTmFP1VEUz5zgG6cxOAvDmo7jpGvsSAvs BzbgyeI52N+toOudgwZi+ENLsaThBaxQnDekcRu1bxihn7rBNd5RnV+G1TkWrFGmQQvse3bicPF0 FGXyEtKNPuwrrqGxbgv0+fPxrvTtsJp1iuEYoRQmHWflGLt5HlZ4v60m5f0S5t1fg2lry5Dv6s6v 0Nz0Ln6+5iX/r+O3ncDBA74gWD18Z57XZQAACIFJREFUOp5Z0og1KyyK90AL7LW7YNTPkt8zwZYZ qB3SMboY5Z8Z8cKhi4ESKNY14gPLzv7fsRT8F16Bdqsw5JYLc/1xYV42RQAQwDihM/xR1Ld2Ksrq FK31ZrGsWONOU7xMbLN+IF7X5QqgXJgdXwiroVgAuUJnPi7qzStEsSsvCI1uvdhff9mXV+dJUTVt tjD8ziB0Gqm8KJTpK51LFIgjgVZhNeiEwdraS52k99Y0AWhEseGI6DFl6xFhcL0/pwmD9YsA+XV5 D0vvO41OGMxW4fC81R1moZPft+73pef9Kb3H2/3y7HQcEdu854wA73NX6suKc4FGFC/bLqzW19xl 6MzCIaUJ+hwkhOh0CKtZed6YIpZV1fifq6Q025Z5zz+uNu6vl90kb+k8JbVLOledFe1Wg8gFRK7B KtoDtl95fit22TrM5a48XPv4qaT6H1+J+qpHhEb3ojji+Do8GK31Yr9BJzTycdnteiIuiJpls4XB bBYG3Ti5b6VjrUrUKK87rtp8LRzWINL1Wma78PS/8jjyNLazvkpMcR1PNeID77HmeR8pX6Vjqcd3 sye7Xl9V0lZFmMXF/gpIg/PGvILRf5ZH2fc3P+5PAQpQIBQBnoNC0WJaCngFeL/TS8EFClCAAhSg AAVSVYB3iMLZ865PZoVY+g9PpuUwO3inyKPBVwpQIMICPAdFGJjZJ7MAA6Jk7l22jQIUoAAFKECB oAT4yCwoJiaiAAUoQAEKUCCZBRgQJXPvsm0UoAAFKEABCgQlwIAoKCYmogAFKEABClAgmQUYECVz 77JtFKAABShAAQoEJcCAKCimyCZSThjom5QwMmVGs6zItIC5UiC5BaL5Ho1mWcnda8naOuXkuIrJ cCPS3GiWFbgBDIgCu0R9bZbBinYh4J0gUPr6bJ5i1mXXjMsdaLTM9c7irVLlQW85J9fV/TP+eq28 j1YP44F9qNYvgqXRNx2IZ3LCdqsBWVFvJQukAAWCEeD5IBglpomOwO3yZMm+yXCVgbRKpYL7g/w5 WPR5iuuTYoJj1zxseu9M9lr9BhyofQV6vQWN3kZ4JuKVJmi+3bs2mgsMiKKpHUpZ0uzLfzZD55n9 1zXjsjSZ3cuuCVw766swbdlvsLlsBABpbqafYM25+7DFIc/E7HgVc0c04fAB5QR9oVSAaSlAgbgR 4PkgbrqCFQHSChbhz65JjM+6rkfuD/IjUGZqgBBfob6qHMtqnnFPcCzNCThjPc5N3wyHawJkAYdp DkZ88iEOxBkmA6I46xC/6kgTOR49DYd0g8c1gasW2spatEiTwX7agDM5QyDNNe20W/D0yRlY+6Nx SPdmoEb6GD1MjpdDmHXbuzMXKECBeBPg+SDeeiSF66PG4KybcPT0/8B1ebJXY6qqEJW10iSsbfi0 /hJyhgwCcBX23VtxsnwFfjQmU+GViTGzq+AwlUGjWBvrRQZEse6B3sq/aQhycAmXv3TC2fAXWIbe h5KPP0GT04krzV9iwuh/Rho68NlHR9E+8U5o2Ju9aXIbBRJbgOeDxO6/pKq9GjcNyQYuXMaXuIqG 997HUN1ofPzJRTjxFZqbtBitlQKiC/jocAcmjrsViXB5SoQ6JtVhFFJj0v4Zoyd8ieYrX6LhvcO4 ZcYCzPlmHd5raIbj9BcYP/JmObs0DMsanBAHXEjtZ2IKUMAnwPOBz4JLMRdI047GhKZmXHF+gvd2 3YgZK+bgm5a/oOHa/+D0x7dhZE6aXMebkZXhWY55tXutAAOiXnlivfFmjBz/BU6fO4H3dnVg0rhc 3HZHK3a99xEuXbgR2QEPsq4Dr1VQ+Q1ci3WbWD4FKNA3AZ4P+ubGvSIikDMS4z8+jXOn/oJdmIBx eSNxR3sN3vtbIy4My0ZGwOii68Br5ReDIlLLkDINWOWQcmDiCAqkISMbOH7sKOpvmIx78rKQd89k 3PDxh7B9/M8YNWwggDTcOu5f8PmRv6PFVRPfwGshzsKsWwjzcw/E1XPaCIIxawoksQDPB0ncuYnX NPVgZN/SgGMf1uOGR7+HvLRRuOfRDHz8pzp8/M1RGOaKLnIwbtJVHDnZLLfPM/BaQDikLw09j+dc XwyKj+YzIIqPfuihFgMxbNRInN25Cx+XfQ95akCd9z2UfbQJK05lYshN7u5T55dhdY4Fayyn0KbM yXkFzU2+r9wrN3GZAhRINAGeDxKtx5K6vuqhGPWtT7FzRxPK7hkFNQYh754ifLT0Vzglf+EHGIT8 mbORY9oEi939kd1j4mxtRpPnjzh5ZUAUJx0RuBrSwLVMnDsEFN91m3uMkPo23HXfHcDE0dB6H8tm oaBiLeZgO+5X+X67SPvk28hauwoPabwJAxfDtRSgQAII8HyQAJ2UQlUchCE5V3Do3HjcNVoaQA2o R9+F+3JzMdH1hR+ZIr0IFVseA6oeUfxG0Xg8+VYW1j43Pa6eXvBKGeeHr/uHFCsUtZR/vEqxxr2Y ifyytTgo1nbbwhUUoEByCPB8kBz9mBytkK9FysuT9HtZDQ3dm5c+BmXr9kGs674pntbwDlGc9Ebz 0kLc4P3Fz8hVyvMLozcULoXnqW7kSmPOFKBAXwR4PuiLGveJjMBZLC3MgEoVrak7MlC49GxkmnKd XFVCCHGdNNxMAQpQgAIUoAAFklqAd4iSunvZOApQgAIUoAAFghFgQBSMEtNQgAIUoAAFKJDUAgyI krp72TgKUIACFKAABYIRYEAUjBLTUIACFKAABSiQ1AIMiJK6e9k4ClCAAhSgAAWCEWBAFIwS01CA AhSgAAUokNQCDIiSunvZOApQgAIUoAAFghFgQBSMEtNQgAIUoAAFKJDUAgyIkrp72TgKUIACFKAA BYIRYEAUjBLTUIACFKAABSiQ1AIMiJK6e9k4ClCAAhSgAAWCEfj/AbvKtQCuJ3z2AAAAAElFTkSu QmCC --=_7036e5c6d63374b3b4229db8f2674fcc Content-Transfer-Encoding: base64 Content-ID: Content-Type: image/png; name=f5a62dc7.png Content-Disposition: inline; filename=f5a62dc7.png; size=14317 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEjCAYAAAArGeXSAAAgAElEQVR4Ae3dD3RU9Z338c+ExNqS UJqVlcRG+0g2pa6uT515gD5ut0xQeayydYOrPbZmFE4LeyiiPBNTtdbaFinNPCrQHKE9UINdd0vN 1C26LSIJ9mx3KSfjPjx2FbKpKyoJXa1LIbYqMPc5N5k7mZlMkplk/tx7551zcmbmzu/+/rx+v3vn O/f+5l6PYRiG+EMAAQQQQAABBBDISKAso1QkQgABBBBAAAEEEBgSIHhiICCAAAIIIIAAAlkIEDxl gUVSBBBAAAEEEECA4IkxgAACCCCAAAIIZCFA8JQFFkkRQAABBBBAAAGCJ8YAAggggAACCCCQhQDB UxZYJEUAAQQQQAABBAieGAMIIIAAAggggEAWAgRPWWCRtMQFTkcU8oUUOV3iDjTfFgKnIyH5QhEx HG3RHVSixAQInkqsw2kuAggggAACCExNgOBpan6sjQACCCCAAAIlJkDwVGIdTnMRQAABBBBAYGoC BE9T82NtlwuY80rqPR55zP8Kn1oiLfJVxF57/ApFBocEktJZ6WOP9fF5KYOKhPzDeaWk8STkJXNu Vb1VRspj/cicq1yWmcu8ilH/YpRZeLPk8VPha1GkxacKaywljA2Xb5Y0D4GiC3gMwzCKXgsqgIAT BMygZkG3/PuD8pY7ocLU0c0CZvC2oNuv/UGvGI5u7mnaZkcBjjzZsVeoEwIIIIAAAgjYVoDgybZd Q8UQQAABBBBAwI4CBE927BXqhAACCCCAAAK2FWDOk227hoohgAACCCCAgB0FOPJkx16hTggggAAC CCBgWwGCJ9t2DRVDAAEEEEAAATsKEDzZsVeoEwIIIIAAAgjYVoDgybZdQ8UQQAABBBBAwI4CBE92 7BXqhAACCCCAAAK2FSB4sm3XUDEEEEAAAQQQsKMAwZMde4U6IYAAAggggIBtBQiebNs1VMx2Aua9 7XwjN+a1Xf2oUEkJmPe288VvOl1STaexCBRdIIvgybyjdyB+F/mi15wKTE2AQGBqflNem+1pyoQ2 yoBAxkadQVUQKIBAFsFTAWpDEQgggAACCCCAgM0FCJ5s3kFUDwEEEEAAAQTsJUDwZK/+oDYIIIAA AgggYHOB8YMnc15MvUcej/lfJV/LDrX4qmKvPaq3JismpbPSxx7rRybYmvMC6ofySknjSchL5lwQ f7yM4bKt9P6ROVdFKNNV9a/wqSXSIl9FGlubD1rHVi9pzNpre3L62FaSrTWmY4952Qcl76cqfC2K tPhUYe3fEsp07Hil4gggMKaAxzAMY8x3k94wdxar1O1vV9BbmfQOLxwoYH7YLOiWf39Q3nIH1r8Y Vc6pGdtTMbowX2WaweeCbr/2B70q1OZUjDLz5Ue+CDhNYPwjT05rDfVFAAEEEEAAAQTyLEDwlGdg skcAAQQQQAABdwkQPLmrP2kNAggggAACCORZIIs5T3muCdkjYHeBnM55sntjqZ/dBZjzZPceon5u FuDIk5t7l7blXqCuWlVsNbl3JcdJCExTXfV0MRwnQccqCExRgCNPUwRkdQQQQAABBBAoLQG+tJRW f9NaBBBAAAEEEJiiAMHTFAFZHQEEEEAAAQRKS4DgqbT6m9YigAACCCCAwBQFCJ6mCMjqCCCAAAII IFBaAgRPpdXftBYBBBBAAAEEpiiQRfBk3osrMHJj3ikWzOpFFjCvWeQbuWlzkWvjjOJzasb25IxO z6yW5jWXfNaN0jNbZcqpilHmlCtNBgi4RCCL4MklLU7bjNMaCK+Ux7ojuqdW/tABDaZLO3hI4dbF sbS18rdu1/bWzxFUprNimYsEUreRegXC/5G83QTCGpBkfqjXx7clT2xbuUSB0G71DkaTTKIDEYVD AdUOpTe3p8cUiTyuQCyvpMS8QAABBGwiQPA01BHlqmnaIsN4V6933qkVP/qubtr3lA6cSN7RK3pE 4TVfVc/i7TpjGDKMQ9o6v0+PfbvfJt1JNRDIl0BsG+nvVHNzp/qNPnU0/TfVXPUlbWteqOZtL+hk R5NqJJV7g+qLpzO3E/P/oNr9L2r1mid11NqsBg9o48Mv6qKV31f/UJp+7b39Qv1803rtyFczyBcB BBDIgQDBUyJi9GXt3v4+3XBVoz7V9J/a3fNW4rtS9E29fHCelv7FebGr+s5QQ9Na3XvnrOR0vEKg BASiA3t099KH9LtVj+v7yy5W5bhtLlOl92+0+fJntGnfm5LeUe/O7Tq2+GrNrRzZDZXVXK4199yh q8bNizcRQACB4gqM7LWKWw9blB7t+2eF/3ShfDM+oIbrb9C0nT8f+ZZs1rDsHF146dPa9HDi6Ydz 1Lhhp4Le8T86bNFAKoFATgTeUf+Bdt3q3ajqB/6P7phXk+EtQs7WhZfWa+/zR3Rab+hXz52t+R+b OapGZQ3LtDt2FGvUmyxAAAEEbCBA8BTvhOP6158cVtPy/6kZ5rIZf6YrPviMdve9E0+hsgvUtHGr Ah95Qesapsljzo1q/Z7CXb3p50eNrMkzBNwjsONzWtL+By35zk3Spi/q7q6jss7EuaeRtAQBBBAY W4DgybI58bx2PvhtLf/o+2MTXGdp0bd/oh/+0yvJHwyVDWq8PqiOfnMex+vatfx8vdyxQmvCR5LT WfnyiIDbBBY+qF3ta3V9000KtgdVvaFNTx59bxKt/C8dP3l6EuuxCgIIIFBcAYKnIf+oTvTs0799 86XYRPDYJNczXbox/Lj2DU0cj+pE11d17fZDCUFSmSobFuv2267RwZffTFhe3E6ldATyKnD+Baq1 5ilV+vTF1hnavvvlDMb/O3r5YJ8WXXaBynWu5n/mQwqnfjnJa8XJHAEEEMiNAMGT6Rh9Tc/ufFfL Fl+YPHej7CP68/jE8ajePv6fevor6/XgnsTTdMd1sPuF2AdCbjqFXBBwjkCZZsy7Vgt/aH3JGKvm 72ngwDZtOHCVblt4jqSzdN51LVrb97DuCh8aOe092KuuJ0IKLH5IkZTLGoyVM8sRQACBQgsQPJkX Pmz4iJZu/baWfvh9qrcudGcur3+/Prp8q769aJbqQ8/rfTP/WNesXaJLDq5Tg3UdG/96HbzsHt3b aH4g8IeAWwVi13mqXaodO5aq1mNe5+m14cZW/pn+8sZDWvTBhqFlQ9d5iqezrvPk1Zd/Xq/W0HU6 z9rrlJ2nxm/epxv0lFbVxtJVrdbuE5fpns418lpHt9xKSrsQQMCxAuWOrXmuKl7uVbDPUDA1v7TL 5+mpRjPh9eoPdqSuwWsEXCxgXQttS5o2nq2GZTtlLLPeCqrPGLVFWW8mP5bVyNsUVIf5n/wOrxBA AAHbCljfATOs4IdUXUW8lSGW/ZPVVasqyxFg/0bluYY5NWN7ynNvFTD7aaqrnp582j/vpRejzLw3 igIQcISAxzAv/8sfAggggAACCCCAQEYCHHfIiIlECCCAAAIIIIDAsADBEyMBAQQQQAABBBDIQoDg KQsskiKAAAIIIIAAAgRPjAEEEEAAAQQQQCALAYKnLLBIigACCCCAAAIIZBE8DSoSCigUGUTNDQLm RUB9IUW4tViRepPtqUjweSnWvDCoz7rAbl5KGJ1pMcocXQuWIFCaAlkET6UJRKtzJ+Denf3w1bdr A+06MDCZG+TmzpicEEAAAQTyL0DwlH9jSnC9gHn17U2KrJLavUvU2nFAA1HXN5oGIoAAAiUrQPBU sl1Pw3MrcJZq5q1SR+9mXfFGu7yLWtURGRAxVG6VyQ0BBBCwgwDBkx16gTq4R6CyQVcGv6/erY16 Y9MSLWp9TBFO5bmnf2kJAgggIBX4VkyQl5iAOSnaL4/HM/Rf4WtRpMWnithrT701YT05nZV++NE/ 8iMFc5J7/XBeyWk8GslLMudW1VtlpDzWxyf15rbM5I4tU2XDYgU7fqzVx+6Xz7tW4aPMhUo24hUC CCDgXAHu8uvcvnNAzSvlDXbLCA5X1QxqFnT7tT/oVfLAS043ZsPKvQr2GYplN06yoPqsQsdMldsy k4uJarB3j7asu0dPz75PPZEb5a05KzkJrxBAAAEEHCuQ/Bnm2GZQcQRsIjDYqz1b1inw9GytD+3S Xm8Nh3dt0jVUAwEEEMiVAMFTriTJp8QF3tPAge/py9f9RLPXf0ORvfNUw4zCEh8TNB8BBNwqQPDk 1p6lXQUUeEe925u18LlP6cnILs3jFF0B7SkKAQQQKLwAwVPhzUu2xHJvUD1eNzb/bDUs26n+ZW5s G21CAAEEEEgVyPLEwodUXUW8lYro2Nd11arKcgQ4tq22rDjbky27ZVKVmqa66ukFnt9WjDInhcNK CLhOwGMYhuG6VtEgBBBAAAEEEEAgTwIcd8gTLNkigAACCCCAgDsFCJ7c2a+0CgEEEEAAAQTyJEDw lCdYskUAAQQQQAABdwoQPLmzX2kVAggggAACCORJgOApT7BkiwACCCCAAALuFCB4cme/0ioEEEAA AQQQyJMAwVOeYMl2tIB5Y2BfKKLTo99yxpLTEYV8IUUc2wBnMFPLzAQcvz1l1kxSIWBLgSyCp0FF QgGFIoO2bAiVylKAQCBLsFwnZ3vKtWgx8yOQKaY+ZSNQeIEsgqfCV44SEUAAAQQQQAABuwkQPNmt R6gPAggggAACCNhagODJ1t1D5RBAAAEEEEDAbgLjB0/mvJh6jzwe879KvpYdavFVxV57VG9N/k1K Z6WPPdaPTLA15wXUD+WVksaTkJfMuSD+eBnDZVvp/SNzropQpqvqX+FTS6RFvoo0tnYbpW6pT9KY tdf25PSxrSRba0zHHvOyD0reT1X4WhRp8anC2r8llOmW4Us7EEBgRCCLGwObO4tV6va3K+itHMmB Z84UMD9sFnTLvz8ob3lhmmB+QC/o9mt/0KsCFZnbhuXUjO0pt51T3NyKMbaLUWZxlSkdAfsIjH/k yT71pCYIIIAAAggggIAtBAiebNENVAIBBBBAAAEEnCJA8OSUnqKeCCCAAAIIIGALgSymnlTKG+yQ 1xbVphJTFij3KthDb07ZcdIZsD1Nms6GK5Z7g2JzsmHHUCUE8iTAkac8wZJtOoFpqqueLkcPurpq VTm6Aen6hWXOFHDB9uRMeGqNgLL4tR1aCCCAAAIIIIAAAnyHZgwggAACCCCAAAJZCBA8ZYFFUgQQ QAABBBBAgOCJMYAAAggggAACCGQhQPCUBRZJEUAAAQQQQAABgqdRYyCqwd6D6h2MjnqHBQgggAAC CCCAAMFTyhiIHn1SaxZerRVbejSY8h4vpyZg3ovLZ91MempZFWdt8952vpEbXRenEpSKwLCA47cn OhIBBwsQPCV2XvSInvzqZmnTD7TqpVatCR8Rx58SgXiOAAIIIIAAAllcYdztWMcVefB2bf7YBu26 fp4+cPkZPX/Lej160be1bO4Mtzee9iGAAAIIIIBAhgIceYpBRXvDuu+F6/TISp8qJZXVLNLdD3xU j615Qr0cfspwOJEMAQQQQAAB9wtw5CnWx2UNy/RUR2KHl6nSe4e6dycu4zkCCCCAAAIIlLoAR55K fQTQfgQQQAABBBDISoDgKSsuEiOAAAIIIIBAqQsQPJX6CKD9CCCAAAIIIJCVAMFTVlwkRgABBBBA AIFSFyB4KvURQPsRQAABBBBAICsBgqesuEiMAAIIIIAAAqUuQPBU6iOgoO2fprrq6XL0oKurVpWj G1DQDqewvAq4YHvKqw+ZI5A/AY9hGEb+sidnBBBAAAEEEEDAXQJ8h3ZXf9IaBBBAAAEEEMizAMFT noHJHgEEEEAAAQTcJUDw5K7+pDUIIIAAAgggkGcBgqc8A5M9AggggAACCLhLgODJXf1JaxBAAAEE EEAgzwIET6OABxUJBRSKDI56hwVTEzgdCckXiuj01LIp3tqnIwr5Qoo4tgHFo6Pk3As4fnvKPQk5 IlAwAYKnglFTEAKlIPCawoF6eTyelP/Fau04oIFoisHgIYVbF8fS1srful3bWz/Hl5cUJl4igIC9 BAie7NUf1AYBhwvUqanj/6qn7Ro1d74q8zJy5v+Z/m/oohe/rlsePaR4/BQ9ovCar6pn8XadGUp3 SFvn9+mxb/c73IDqI4CA2wUIntzew7QPARsIlNXM083Lm6TnXtRvrPpE39TLB+dp6V+cF7vq/Aw1 NK3VvXfOslLwiAACCNhSgODJlt1CpRBwk0BUg7279eC6n8kbmK9zraaVnaMLL31amx7erd5B63jU OWrcsFNBb6WVikcEEEDAdgIET7brEiqEgBsE3taOpefH5jJNU8O6F3ThbRv1zUbrKJOksgvUtHGr Ah95QesapsnjMec8fU/hrl7xcw03jAHagIB7BQie3Nu3tAyBIgpMH5nzdPIlfWf2Af3Dwd/q96k1 qmxQ4/VBdfSbc6Ne167l5+vljhVaEz4yMjcqdR1eI4AAAkUWIHgqcgdQPAKuF6icq6b1bfrML76u B7qOxoKiqE50fVXXbk+YQK4yVTYs1u23XaODL79J8OT6gUEDEXCuAMGTc/uOmiPgHIGyC3Td1z+r 33yxXftOmPObonr7+H/q6a+s14N7Ek/THdfB7he06LILVO6c1lFTBBAoMQGCpxLrcJqLQH4FzOs8 /Xf5Wp6OzXlaqfDA8FVFy877tFrv7tOiDy5SKPJ7TZ/5x7pm7RJdcnCdGqzrQvnX6+Bl9+jexnPy W01yRwABBKYgwJe7KeCxKgIIpAqY13nqk9GRutx8fbYalu2Uscx67+t6qtF8fr36g2lXsBLyiAAC CNhKgCNPabvjQ6quIq5MSzOlhdNUVz09dk2fKWVUvJXrqlXFVlM8f0pOEHDB9pTQGp4i4CQBj2Fe /pc/BBBAAAEEEEAAgYwE+A6dEROJEEAAAQQQQACBYQGCJ0YCAggggAACCCCQhQDBUxZYJEUAAQQQ QAABBAieGAMIIIAAAggggEAWAgRPWWCRFAEEEEAAAQQQIHhiDBRM4HQkJF8oouFLJhas2NwVdDqi kC+kiGMbkDsKciq+gOO3p+ITUgMEJi1A8DRpOlZEAAEEELCFAF9sbNENuaqEE74YEDzlqrfJBwEE EEAAAQRKQoDgSYOKhPzyWPfWqjdPy5zWQHjlyDKPX6HIYEkMCBqJAAIIIIAAAuMLcA8SVcob3KuT /o1auvNS/WhDo2aYZk1bdOb1q/SFFcfV+pNlaiDMHH8k8S4CCCCAAAIlIkBIMNTRZar8eJNWvPm3 eqL3nVjXv6O+3c/onLV/SeBUIhsDzUQAAecImPNi6q0zBhU+tURa5KvwxM4YjJwtSEpnpY891sd/ wJJyBiIp3UheMudW1VtlpDwOnbUY9nN6mYWvf7J/ha9FkRafKqx+SLC1ywjl3nbxnojqRNfX9NfP X6vO4DxVnuhS618f1A2da+StJMaMM03hiblBLuj2a3/QK0ce8jR3nAu65d8flNeRDZhC57Gq7QQc vz3lUpRtM5eaRc/LCWObqCA+TMo0Y+FNunHf43rm6An1PvG3enNFkz5O4BQX4gkCCCCAAAIIyJkH APLWcWUNun7tDN30d4/rz/ecp8/9qE5El3nTJmMEEEAAAQQcKUBskNRtZZox71otfDqk7htv0sIZ 8CTx8AIBBBBAAAEEOPI0agxUzlOwu0/BUW+wAAEEEEDAlgLlXgV7vLasGpXKXqDcG5Tdu5NDK9n3 K2tMWmCa6qqnO/tUaF21qthqJj0CWDGXAi7YnnLJQV4IFFCAX9sVEJuiEEAAAQQQQMD5AnyHdn4f 0gIEEEAAAQQQKKAAwVMBsSkKAQQQQAABBJwvQPDk/D6kBQgggAACCCBQQAGCpwJiUxQCCCCAAAII OF+A4Mn5fUgLEEAAAQQQQKCAAgRPBcQu9aLM+xX54jfidKCGef8sX0iR0w6sO1V2nYDjt6dc9gjb Zi41ySsDgSyCJ/OuxwGFIoMZZEsS2wuwsylyF7E9FbkDilA8fV4E9KQiCTiTOBz+orjbUxbBk8Od qT4CCCCAAAIIIJADAYKnHCCSBQIIIIAAAgiUjgDBU+n0NS1FAAEEEEAAgVwIGOP9neox2ubIkNL/ z2nrMU6Z64+Xbk6b0TOUyEzWZsyZKC/jpNHTtnCMMhcabT0nh2tchDLdXH8pwXa8MTGF90w/rzVm ppBP0VY1x5x3ZDxnXY/xxqxkFHN7cvrYLsY+KCOzTPs868E0vD919PY0iTaPucqY2+Z4nycyFP98 Gi9dwr5xvP6M58VnXdLnSS7NxssrcR865kDJ3RtZ3NvOnJy1St3+dgW9lbmI28ijmALmhPEF3fLv D8pbXpiKmJM1F3T7tT/oVYGKzG3DcmrG9pTbznFCbrntc8dvT7nssgy3TcxyiV7svHK7PWXbGk7b ZStGegQQQAABBBAoaQGCp5LufhqPAAIIIIAAAtkKEDxlK0Z6BBBAAAEEEChpgSymnlTKG+yQt6S5 XNT4cq+CPfRm8XqU7al49sUqmT4vlrxVbrk3KHZ7lobTH4u7PXHkyenjx1H1n6a66uly9KCrq1aV oxvgqAFDZccVcMH2NG77snyTbTNLMJJPRSCLX9tNpRjWRQABBBBAAAEE3CHAd2h39COtQAABBBBA AIECCRA8FQiaYhBAAAEEEEDAHQIET+7oR1qBAAIIIIAAAgUSIHgqEDTFIIAAAggggIA7BAieUvvR vMx/vV+hyGDqO7xGwNkCjG1n9x+1RwAB2whkETyZ95EJODCoMOvtl8fjGfqvD0V02jb8RayI+UHq CykCRuadkFMzp25PmXMVLqW1jdcrEH6tcMVmXVJu+9y8T5uP/dlwL2S4bWKW9aBlhTEEsgiexsih mIujA4qEQwrUDgdGHn+rOiL79UTgdoUHrKjAvJBWtwzD0KmeNs2cqL7mxSP7ugt08+Pc7kwnatrk 349qsHe3QgGfFm8/pOgkM2LHNUm4tKtZAUNs7Me+HHhqAwrt6VXa46YFHdtpKz16YYYfeqNXTFxi buN71N95beJCniMwSQGn7Jcn2bxSWy0n+5jRaA4Ono4rsvG7OnjRF9XRbwwFR8be2/Wxnz+i23a8 M7qlLJmcwGCv9oRuVcOKLs26bZd+umyusy9yOTkFG65lBQxr1Nz56vD4NwwZ/RvlP3i/1oSPTDrI tWFjqRICCCBgKwHHBk/R3rDuO/ZJXT93xghoWY3mrblL37wqi7vOWGub0Wm99S1+rDlP72ngQPvI kS5Prfyt29XVe8LKRRoIK2AeBQg8od5DHfG0tYF2HRh4L57OPApT76mSr2WHWnxV8dOKHs9YZcdX LdCT9zQQeUytS9bq2VmrFNm7QQFvDYFTgfQnX8xMedfeq8u3b9O+E7FjhBmNbSk6cEAdrYtjY9Ec 2+vU6v9S7CiudaSrXoEn9uvAQwHVxo521QZCCkcGEoI1c+w8pe1JeX1P/5CUJpZfhU8tkRb5Kqxt zyNPferpZOvI5yUJddui7a3LR08jOP6CwvFyF6u144AGkg6VZrAN67QGwitjZa1U+OhrinS0yj/U 3sW6u+toQlsn31OsiQACzhVwaPB0Wr/51f/TH83/EyWETsO9UDZXy3Z/R001WQZQQ6c0zCNYJ9XT dn6aHo1qMNKuW9qlVZF3Y9/0X9eu5efp+Q3rFD4aC4xqmtTR36nmvnatWPOKAkNpf6euTz2vmx7+ J1lhlnmPpb6hsprV1nNy5MiBUahThmmaGFs0/CG6RN5Nb+qKrY9rQ2Ceahw6UsZupYvfKfuwLl14 RM//+++HGznh2DaTval9D2/Ui/M36qR5BMswx/bHEpDMI1271NM2R33tj+jJ6lWKnBk+4tvffq20 c50ejByPpT9L59Z+RB+/fdfIdnLrWQrfuHkkoFPsdPqpHrV529RzKnb02Cy7LyhvwuYbPfqk1qx+ Thfe84tYfv3ae/sl+t2xtxLqZz59RzuWb9QvY2040/9Vze66Vw/vezOWLsNtWOWqadoiw3hVnc2H tfnzn1bwxYsV6n9XxsnNukJvKyabUj4vEUCgVAT4SMy4p9/SgZ2HdeM9yzWv5qzYWmWqbFista0X 6ZndLyd/G/2PP9Xq7XepcSjtDM29+hpdfuy43s64vOIkjPZu19W183XLsRWKdNyhKxtGhaexillH IhKOGFjzbuJHz5LTVPhaFGnxqcJKN+oIQ3HaTKmmwB90/FhiSGCO7SZt6B79RaTy5rv0zcSAunKu rlt+mfbtfD7+5aCs5mJ9PHE7mduoz1z+ex1/O+kwUAb0g/rXv/t7ndO6Vk0JY7Gs5nLd0fHjlLmJ 5bpq20atb5qrSkllNfP12c98TMeO/yFWTpbb8NBaM/WJe3+mvRtultdsT2WDGhsbhvLPoPIkcYpA 0tHZ0WcE4j80SkqXsu9L2J8Nn1lIeT+234vnpeT9o/WjpuHHhDMQRSjTVfUfdXQ7wXYK49PBwdNp HTv+dnLAMgWIiVc1P1ye1fKPvj/hFNvwxjHto7do63Mv6jeJmVzZqE+cZwVZiW/Y+3lZwzL9tP+X enT2VnkDD2lP4inJpKrHjhwMHaVIOGow9No6epacxpyw723r0SlrnZQjDEnZ86LAAufpqntuljY3 qsoKbv2t2t6VOvm8QrNnjr65c1nVTP1R/MuBedourFDAOs1mbifna+mk5iL+l468UKv5H5vwpx6S ytPWbQQyy214aMUL5PvYuZyuHkF057P40VlzX2aefUg+I9AX9GroYGhSupT9XsL+bPjMQsr7sf1e PC/r6Ku1P0x6tPah5rA2f8SUPq/Eo7S5LDOXeRW9/qOObifYTmE0OzR4Kte58xv14fA/qy/bL7KT xpqliz91k7Yd/kPCKbaEAd3RpJpJ522vFctq5imwYZcit52jZ1c0KvDQL1LmjdirvtQmRSD6ug7u u0CX/ckHUt4Y76V1pKk/Nr7fVX9ovt7qWK1vdFmnvcz1T6X90hI9eVy/nT1T0yVFe3+gL2w6okvj p9nM7cQ8BXb2eBUY4733a+bsPv3yJeuU4FFTx0UAABeoSURBVBjJMlpcOttwRhwkQgCBSQs4NHiS ys67Vt9cO6B1d4XVO2hFUCfU2/VDhQKfUyg+/2LSNikrnq36qz+pV7Y9kjI59oR6w3drcWtX/JRF yooTvDyhFw6+MvzT8vilF1YmXGphgtXz9vZZqvHerA27Htfnz3xX3kXmZSASJwXnrWAynopAdEAH Nn5HB5Yt18IZmW/e5unaxf67FY4faTTnLZ2raWnqMvjYen0lcSL24CE9+egrarrVNzQHMXryLR0p v0AX1cdO+Q72quuJH+of9ozxK9h3X9LBvuHZgNGBiMKhgGoDYQ0MlX2OFt62TG9ueDChbuYE8n16 IrRc12Z16Yx8bcNpkFiEAALuFjAy/jtp9LQ1G209JzNeI/8J3zX6ezqNtuaLDUmGVGMsvHObsffw 7+JFn+ppM+YMvWe+n/w/p63HODWU0mzbwlHvD6dfmNTmM/09Rmdbs1Fj5VXTbLR19hj9Z2JF9nca zdZ7c9qMnlOGkVSH2DKrgmf6/8l4cJz6W+ly/niqx2jzDtdv4rzPGCcP/8xoa77KuHPvGxMnHyOF 6eCNm4+RyM6LszKbqCFT3Z7GGLPmeHzmsDGylY6RbmiMjoztM4e3Gdc0txl/nzq2R+V1jdHc+YJx uPMuY2FsnNc0P2g8k7DNGWf6jV8+mLCNLLzT2Lb3Z8a25jmGNFLmsNC7Rv8vv2M011jb5lXGndv2 GodPWhuUmcoaf9Z2LqOmuc340V6rnYltnGM0d75qGEbiMhkj27phTLgNG68anUN1tepkPVp5T9S3 Y71v1il3+1DHb09jMU1meYbbZmZmue2nyTSHdXIokOHYyLZEj7lCZuGhObltlbr97SmTNDNbm1Q2 EzAnIS7oln9/8i+bbFZLe1Unp2ZO3J7MOn9Wmy58RB1NdfbqG0fUJrd9bk7qXdDt135rPo4jDPJU yQy3Tczy5F+C2WZ+XH8I50Oqrkr4DXEJgrmqyXXVqspyBLiq/ZNpTE7N2J4m0wXOXieXfT5NddWj J+8722cKtc9o28RsCsKsmiCQxZGnhLV4igACJSZgHjVZIl/Lvli756i5s5sjUCU2CmguAggMCxA8 MRIQQAABBBBAAIEsBDhpkwUWSRFAAAEEEEAAAYInxgACCCCAAAIIIJCFAMFTFlgkRQABBBBAAAEE CJ4YAwgggAACCCCAQBYCBE9ZYJEUAQQQQAABBBDIIngyf6ocUCgyiJobBMyLyvlCipx2Q2Oc2Aa2 Jyf22tTqTJ9PzW/qa5sXyfSFIhp/t0c/TV3aRjnk6bMui+DJRhhUpcAC5r3EdisU8GlxVvcSK3A1 i1bcaQ2EV6o20K4DA+8VrRYU7DaBE+rd85ACtTdoe+8Y9wV0W5Ozas9rCgcuL5Ebl1tjwSOPxyNP bUChPbu1PXC7De6DmlWnuSYxwZNrujJPDRns1Z7QrWpY0aVZt+3ST5fNFYMm1bpcNU2bFFkltXuX qDXxprmpSXmNwIQC1peVRq149hzdFvmBljWcPeFapZegTk3ff0Kr5PYblx9XJPQ3WvfalWrvN2Te Uc3o/75W1h3Tc2PdbLv0BkPBW8znYMHJnVLgexqIPKbWJWv17KxViuzdoIC3hsBpzO47SzXzVqmj d7OueKNd3kWt6ogMKDpmet5AII1AdECRjru0JPZlZe+Gm+WtOStNQhYNCZTVaN4d31fv1ka9sWmJ FrU+pojLjv5Ge8O676WleuCWi1UZ7/YyVc4NqKN/i5pqYrdMGwgrYB6V8tQrEP718P7bXyuPp1b+ u/doIL4ziu3bh94z01+iQGi3egdjCczTXPXm8pXxo1rm6c76obytZeapTf9wWU/s14GHAqodet+j 2kBI4RLY9xE8xQcjTyyB6MABdbQukXfTm7pi6+PaEJinGkaKxTP+Y2WDrgy6e2c+PgDvTk4g9oG2 aIk2vdGorbvW82UlY8gyVTYsVrCjS1uveFObXHX097R+86vnderyiybeB9c0qcM4pf7O/6W+zc3y Bn+li0IRnTEOaesVZ+vk783gKKrByBZ9uXO2bt/bP3wUy3hB3/9cmR5d9R1FzACq3Ktg36vqbB45 2lnuDarPSFxWKW9wl3ra5qiv/RE9Wb1KkTPDR8X626+Vdq7Tg5HjGfegExPykejEXstjnaO923V1 7XzdcmyFIh136MqGGWOUZn3ziJ2Dj33rGDof7/HHf1gw8o1ldLr6+MTNzPJS/BvR6Lw89SOT34tR ZjKStTP/sVYfu18+71qFjzIXKtmIVyMC76h3++dV67tfx1b/WB3BxWqoTL9rLsbYLnyZGe4PRgBj z2ao4co71BFZoWO3zJf3C2EdjR9tGZXYQQvKNXtmdjeAPusTX0s4WzBDDY2fHB5T0V7tvO9NBb68 KCkYK6vxa/Vnjmrngbeydqm8+S59M/ELduVcXbf8Mu3b+bxOZJ2bc1aIHe9zToWpaX4FyhqW6af9 F+uxh++VN3BEHfcsHyOAMr95dMsIjl+f4W8sEyRSZnkNfyMyNFFuxSgzWcGcs7JHW9bdo6dn36ee yI2cekkG4lWSwNlqWPYD9V/6Qz0c/CsFXl6ne1ZemTaAKsbYLnyZGe4PkgzNF+ak6m1aF/iZZj/6 S0VuduMRc/PHKV9S7dKtI61v7lR/R5Nq4kvKdb5vblJwFH8r+rbeOjZDl34gNTgv16wLZmlv9xGd bjxHmQcGFWkDu7KqmfqjY8f1tqSxvn7H6+TQJ6mCDm0G1c6lQFnNPAU27FLktnP07IrGEvk1S44E UybYM2clR66uz+Ys1Xhv1oa9u3TbrC6taLhVDx1gzlxm3Z46wX6Xi6YalOvci/9Mv/3lv8eO4pg/ TtkSO91mnkZbo85v/WVC4DSBWNl0Vc8+od8NncJLTPuOXj7Yp0WXXTB24BR9W8ePpV7k4ZSOHX97 1NzO6Mnj+u3smZqeWITLnhM8uaxDc9ec2M581+P6/Bm3/5olF2rvaeBAuwINq5lgnwvOUs2jrEbe wHrt2neTzrS7cwJ0Trs2OqADD438GtiNX1bKGpp0/6yw1oUPKekqi2mDmQl0yxp0w/3nqGPdkyMT xM15UL3/qG3PXaQb5lXHMni/Zs5+Qz0v/UbRofd3K3TrX2v5M6nBkzT42Hp9JfEXxoOH9OSjr6jp Vp9rjzqZSARPE4y1kn87aQL0Lbqr682SJxkNMDxnxdsurYq46Vvv6JaypBAC1py52AToT35NXSdc MXknt3jRQ9p+9RK164sJ83tyW4Q9cpspb/ABLdcOLUmYW1p761Oa+cA9um7o13bD15rzeCpUu3Sj diw9f/h6UGb6QFgD8YaUqdK7Ut+64W1tW/LhWJpLteon07W8/UvyxufaVWve8qU6843/oWmeaaoa +vXn9/Sj5me1tPZL8V/hSRWqX92iW6qe1E3Thuei1q76qapuCWrZXLeesBvGzPzUZhyfJ6UnYO3M F5de0zNqsTlnZaf6l2WUmEQIZCgQmwDdl2HyUktWNlfLdveoNDa7GWpoekDdxgNj9LJ1Om/LGO8n Lo6dVei+WRsSFyc9N/f5TdrQ3ZScpqNPRkdSQkkfnKBuqend8TrLI08fUnUV8ZY7ul5SXbWqshwB rmm7LRrC9mSLbihoJejzgnKPKmya6qoz+eUa/TSKzskL8vBZ5zHMy5XyhwACCCCAAAIIZCRgXk5i iXwt+2Kp56i5s1sdTXUZre2GRARPbuhF2oAAAggggAACBRPgpE3BqCkIAQQQQAABBNwgQPDkhl6k DQgggAACCCBQMAGCp4JRUxACCCCAAAIIuEGA4MkNvUgbEEAAAQQQQKBgAgRPBaOmIMcLmDcm9o3c gNjx7aEBjhYwb9jri99c29FNsVnlzV+SBeI3N7dZ5SZfnfiN1VcmXORy8tk5Zs087bezCJ5cOqAc MwJyXNE8Dagc19LF2bE9ubhzx2gafT4GTMEWl3TAWe5V8FCP2uYUjNvVBWURPLnagcYhgAACCCCA AAIZCRA8ZcREIgQQQAABBHIkYJ1Cqw3oW98KqNZziQLbI+rtul9+8350/vvVNfBevLDowC/0UOCS kfvV+Vu1vat3+EbBWeY1lOnJQwq3Lo7ld4kCod0JNwo2U8RudF47fL86j6dW/tbt6uo9Ea+TZN1P z0yzUuGjrynS0Tpcf89i3d11VPE7MkYHEt4z2/e/FWr9KwXCryXk56ynBE/O6i9qiwACCCDgdAHr FNoH9mj3ic8rcupH+tQPl2hhx0f0yMnfqueaf1PHv/xmuJWDB/TgLdulVc/ojGHIvCmIsWu56p7f pGD4iKLZ5DWUY482r/6Ojix9NJbfL3TPpS9q3dKNigya4U5Ug5F23TJ0o/N3h8szXteu5efp+Q3r FD5qBXXW/fReVWfzYW3+/KcVfPFihfrflXFys67Q2/r9UHlRndj3iO5+cb62njwTq/8XdKHT+9C8 PcuYf6d6jLY5Mm/fkvZ/TluPccpcebx0c9qMnqFEZrI2Y85EeRknjZ62hWnLkxYabT0nh6tbhDLd XP8k2zEHRIm/YY4578h4zlpjvDErGcXcnpw+touxD8rILNM+z3owDe9PvdY+eBLrl8Yq432eyFDC 59OIh7lO88hnzcgbuX2WtD9JLPOU0d+5xmjufNUwjDPG7/bea1yz7SXjTGrpZ14ytq141DhsvpFR XtZn9TVGW89/peT2B+PwthXGnXvfMAzjDWPvnSuMbYf/kJLGMM4cftRYMaourxqdzdcZd+19fXQd h3Iw27PKWHhnp3H45KhWjCoj5wuSbHKXuxkFZviX2LkZrkIy+wrkaUDZt8E5qFlOzdiectAjDssi t31uBm8ET9kNgczMcttPY9YwaX+SWGZi8GQ+XzHGwQTzoMYKo7P/VJbBU2ydpIollmkGQ3PGLrO5 0+hPWtdMv2a4HknLE16cfMnovPOqhDyvMu7ctrcwwVSSc0KdpviU03ZOP3RI/RFAAAEEXCpQrnMv /oRWbHtp5JSddepu6HGLmmrKs2z763q5fzBlndM6efwdzZ75fkmzdPGnbtK2w3+InbKLnSq0yu1o Uk3K2hO+rJyrpg274/md6X9A89/q0Ke/sU+Js6gmzMdGCQiebNQZVAUBBBBAAIFEgbL6K3TDKzv0 YDiigZEZ2BrsDat18VfVdSK+MHG1cZ4f09N3f1kPHRgYntA9NJn7Pq1+7hO6dV61pLNVf/Un9cq2 RxSOxNIM5XZCveG7tbi1K7uAJ3pI2xdfq9bwoeEJ7pLKzq3Vh6eNU0UHvEXw5IBOoooIIIAAAi4S MH8hN9enlkiLfBXWRStfVYtvSezinO9ox9LzVW9eBLXsPDV+bbX86taXP2z9+u1SrfqJdMOjX1Hj B/41s7zWhbTOLPPXPq3e/CVd0HmLppm/7Jt2lTa90ajN7TdrbuVwSFBWc6W+dvtfSN1f1ofNNOZ/ 7Wr9REv16PpGzRjqitcUDtTL4zlfS3ds1NLaitiv9+pH/4qu4lzNOvWUVlm/3pt2ldrP3KR/vHdh LC/n9a3HPO3nvGpTYwSKIGDu8BZ0y78/KG+2R8qLUF2KdLeAecHHBd1+7Q96xXDMZV+bFzNdpW5/ u4LeylxmTF7FEMjTfpsjT8XoTMp0rkBdtarYapzbf66q+TTVVU8XwzEfnfohVVcRkuZDtih55mG/ zZGnovQkhSKAAAIIIICAUwX40uLUnqPeCCCAAAIIIFAUAYKnorBTKAIIIIAAAgg4VYDgyak9R70R QAABBBBAoCgCBE9FYadQBBBAAAEEEHCqAMGTk3pu8NeKJN3V2kmVp64IIIAAAo4T4HMnbZcRPKVl seHC6BGF11wn34ptsTtf27CObq+Seb0QX0iR025vKO1zgoB5nSefeRFFJ1SWOjpTgM+dMfuN4GlM Gju98Z6OPtmmO3WX/mXVr3Xjmid1NNsr8tupOdQFAQQQsK2AeZHMQOxK37atZAEq5pLPnTx96SV4 KsAQnFoRUQ1G2vX5zXP0w42f1YKmu/Tdc/9edz/6q/h9gqaWP2sjgAACCCCQKMDnTqJGuucET+lU 7LQs2qud9x3WzY8sl9e875B5n6O7g7rksfXa2fuOnWpKXRBAAAEE3CDA586Evcj15yckKnKCsrla 9tSW5EpUzlOw+2+Tl/EKAQQQQACBXAjwuTOhIkeeJiQiAQIIIICAqwXMeTH1Hnk85n+VfC071OKr ir32qN6amJ+Uzkofe6wf+TGJOZm/fiivlDSehLxkzq3yx8sYLttK7x+Zc1WMMjPqbPvWP8m/wqeW SIt8FWlsM2pn+kTc2y69C0sRGC1g7sQWdMu/Pygvx2xH+7CkoALmB8SCbr/2B71iOOaS3gwKVqnb 366gtzKXGZNXMQTytN/myFMxOpMyEUAAAQQQQMCxAgRPju06Ko4AAggggAACxRAgeCqGOmUigAAC CCCAgGMFOFXu2K6j4ggggAACuReolDfYIW/uMybHYgiUexXsyX1vcuSpGJ1Jmc4VqKtWFVuNc/vP VTWfprrq6WI4uqpTaYxDBPi1nUM6imoigAACCCCAgD0E+NJij36gFggggAACCCDgEAGCJ4d0FNVE AAEEEEAAAXsIEDzZox+oBQIIIIAAAgg4RIDgySEdRTURQAABBBBAwB4CBE/26AdqgQACCCCAAAIO ESB4ckhHmdU072Xls25Q6aB6U1UEEEAAAWcK8LmTvt8IntK7sBSB0QLmDSZ9I3dOH52AJQgUToAP tcJZUxICqQIET6kivEYAAQQQQAABBMYRIHgaB4e3EEAAAQQQQACBVAGCp1QRXiOAAAIIIIAAAuMI EDyNg8NbCJjzSuo9HnnM/wqfWiIt8lXEXnv8CkUGh5CS0lnpY4/18Un+g4qE/MN5paTxJOQlc25V vVVGymP9yJyrXJaZy7yKUf9ilFl4s+TxU+FrUaTFpwprLCWMDbZcBBDIrwD3tsuvb05zN3fWC7r9 2h/0qjynOZNZRgJmULOgW/79QXnpgIzISJQ/AfYH+bMl5xEBxtmIReIzjjwlavAcAQQQQAABBBCY QIDgaQIg3kYAAQQQQAABBBIFCJ4SNXiOAAIIIIAAAghMIMDMjQmAeBuBuEC5V8Eeb/wlTxAopkC5 NyiGYzF7gLJLWYAjT47q/Wmqq54uOs1RnUZlEUAAAQcL8LmTrvP4tV06FZYhgAACCCCAAAJjCHAQ YwwYFiOAAAIIIIAAAukECJ7SqbAMAQQQQAABBBAYQ4DgaQwYFiOAAAIIIIAAAukECJ7SqbAMAQQQ QAABBBAYQ4DgaQwYFiOAAAIIIIAAAukECJ7SqbAMAQQQQAABBBAYQ4DgaQwYOy42b9DoC0V02o6V o04IIIAAAq4T4HMnfZcSPKV3YSkCCCCAAAIIIJBWgOApLQsLEUAAAQQQQACB9AIET+ldWIoAAggg gAACCKQXMPizscBJo6dtoSEp/f+cNqPnlFn98dItNNp6Tg638VSP0TZnorwM41RPmzFnjDLntPUY Q0VmWGYu8zKKUH/7lmnfPsdMRrbbiX3NMtwfsG0aiu+PnW423r5FSe208Ydn3qvGve3Sx5S2XGpO 3FvQ7df+oFfltqwhlUIAAQQQcJMAnzvpe5PTduldWIoAAggggAACCKQVIHhKy8JCBBBAAAEEEEAg vQDBU3oXliKAAAIIIIAAAmkFmPOUloWFCCCAAAIIIIBAegGOPKV3YSkCCCCAAAIIIJBWgOApLQsL EUAAAQQQQACB9AIET+ldWIoAAggggAACCKQVIHhKy8JCBBBAAAEEEEAgvQDBU3oXliKAAAIIIIAA AmkFCJ7SsrAQAQQQQAABBBBIL0DwlN6FpQgggAACCCCAQFoBgqe0LCxEAAEEEEAAAQTSCxA8pXdh KQIIIIAAAgggkFaA4CktCwsRQAABBBBAAIH0AgRP6V1YigACCCCAAAIIpBUgeErLwkIEEEAAAQQQ QCC9AMFTeheWIoAAAggggAACaQUIntKysBABBBBAAAEEEEgvQPCU3oWlCCCAAAIIIIBAWgGCp7Qs LEQAAQQQQAABBNILEDyld2EpAggggAACCCCQVoDgKS0LCxFAAAEEEEAAgfQC/x+tkJyrYkjHyAAA AABJRU5ErkJggg== --=_7036e5c6d63374b3b4229db8f2674fcc-- --=_f84ee3b034e6761fcf18e41dc87185bf-- From nobody Mon Jul 30 15:10:49 2018 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7D131147; Mon, 30 Jul 2018 15:10:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153298864768.8255.12499424928369646545@ietfa.amsl.com> Date: Mon, 30 Jul 2018 15:10:47 -0700 Archived-At: Subject: [core] Secdir last call review of draft-ietf-core-object-security-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 22:10:48 -0000 Reviewer: Daniel Migault Review result: Has Issues Hi, Reviewer: Daniel Migault Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has (small) Issues. I am not an expert in CoAP. The document is well written, and I believe securing objects is important. I had comments regarding the description of security contexts. I hesitated between Nits and Issues. I do not believe these are major design issues, and some clarifications may be sufficient. Other comments are mostly editorial nits. Please find above my comments. I am happy to follow up the updates. Object Security for Constrained RESTful Environments (OSCORE) draft-ietf-core-object-security-14 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252] is a web transfer protocol, designed for constrained nodes and networks [RFC7228], and may be mapped from HTTP [RFC8075]. CoAP specifies the use of proxies for scalability and efficiency and references DTLS [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP proxies require DTLS or TLS [RFC5246] to be terminated at the proxy. The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of, the message payload and metadata in transit between the endpoints. The proxy can also inject, delete, or reorder packets since they are no longer protected by (D)TLS. The proxy can almost do whatever it wants as mentioned in the second sentence. Accessing the data enables it to passively monitor the communication. I would thus propose some text around these lines: OLD: The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of, the message payload and metadata in transit between the endpoints. The proxy can also inject, delete, or reorder packets since they are no longer protected by (D)TLS. NEW: The proxy therefore has access to the data required for performing the intended proxy functionality, and so can passively monitor the communications. In addition, the proxy can also inject, delete, or reorder packets since they are no longer protected by (D)TLS. This document defines the Object Security for Constrained RESTful Environments (OSCORE) security protocol, protecting CoAP and CoAP- mappable HTTP requests and responses end-to-end across intermediary nodes such as CoAP forward proxies and cross-protocol translators including HTTP-to-CoAP proxies [RFC8075]. In addition to the core CoAP features defined in [RFC7252], OSCORE supports Observe [RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and FETCH [RFC8132]. Maybe too many "and". An analysis of end-to-end security for CoAP messages through some types of intermediary nodes is performed in [I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the RESTful interactions; the request method, the requested resource, the message payload, etc. (see Section 4). OSCORE protects neither the CoAP Messaging Layer nor the CoAP Token which may change between the endpoints, and those are therefore processed as defined in [RFC7252]. Additionally, since the message formats for CoAP over unreliable transport [RFC7252] and for CoAP over reliable transport [RFC8323] differ only in terms of CoAP Messaging Layer, OSCORE can be applied to both unreliable and reliable transports (see Figure 1). Selander, et al. Expires January 27, 2019 [Page 4] Internet-Draft OSCORE July 2018 +-----------------------------------+ | Application | +-----------------------------------+ +-----------------------------------+ \ | Requests / Responses / Signaling | | |-----------------------------------| | | OSCORE | | CoAP |-----------------------------------| | | Messaging Layer / Message Framing | | +-----------------------------------+ / +-----------------------------------+ | UDP / TCP / ... | +-----------------------------------+ Figure 1: Abstract Layering of CoAP with OSCORE OSCORE works in very constrained nodes and networks, thanks to its small message size and the restricted code and memory requirements in addition to what is required by CoAP. Examples of the use of OSCORE are given in Appendix A. OSCORE does not depend on underlying layers, and can be used with non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]). OSCORE may also be used in different ways with HTTP. OSCORE messages may be transported in HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP messages, as described below. I believe that "underlying layers" should be specified. My understanding is that OSCORE requires CoAP or HTTP. If that is correct, I believe that should be clarified in the paragraph above. OSCORE is designed to protect as much information as possible while still allowing CoAP proxy operations (Section 10). It works with existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and CoAP-to-HTTP proxies can also be used with OSCORE, as specified in Section 11. OSCORE may be used together with TLS or DTLS over one or more hops in the end-to-end path, e.g. transported with HTTPS in one hop and with plain CoAP in another hop. The use of OSCORE does not affect the URI scheme and OSCORE can therefore be used with any URI scheme defined for CoAP or HTTP. The application decides the conditions for which OSCORE is required. OSCORE uses pre-shared keys which may have been established out-of- band or with a key establishment protocol (see Section 3.2). The technical solution builds on CBOR Object Signing and Encryption (COSE) [RFC8152], providing end-to-end encryption, integrity, replay protection, and binding of response to request. A compressed version of COSE is used, as specified in Section 6. The use of OSCORE is signaled in CoAP with a new option (Section 2), and in HTTP with a new header field (Section 11.1) and content type (Section 13.5). The solution transforms a CoAP/HTTP message into an "OSCORE message" before sending, and vice versa after receiving. The OSCORE message Selander, et al. Expires January 27, 2019 [Page 5] Internet-Draft OSCORE July 2018 is a CoAP/HTTP message related to the original message in the following way: the original CoAP/HTTP message is translated to CoAP (if not already in CoAP) and protected in a COSE object. The encrypted message fields of this COSE object are transported in the CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/ header field is included in the message. A sketch of an exchange of OSCORE messages, in the case of the original message being CoAP, is provided in Figure 2. Client Server | OSCORE request - POST example.com: | | Header, Token, | | Options: {OSCORE, ...}, | | Payload: COSE ciphertext | +--------------------------------------------->| | | |<---------------------------------------------+ | OSCORE response - 2.04 (Changed): | | Header, Token, | | Options: {OSCORE, ...}, | | Payload: COSE ciphertext | | | Figure 2: Sketch of CoAP with OSCORE Options are mentioned in {}. How these "{}" should be interpreted may be specified in the figure. The paragraph above mentions that OSCORE can be used both with CoAP or HTTP. It might be helpful to split Figure 2 in to two sub figures Figure 2a) that illustrates the use of OCSORE with CoAP and figure 2b) that illustrates the use of OSCORE with HTTP. My understanding is that CoAP and HTTP can easily be translated. As such it might also be able to consider OSCORE only with CoAP and having a specific section that deals with HTTP. Such split may avoid to deal in parallel with HTTP and CoAP. An implementation supporting this specification MAY implement only the client part, MAY implement only the server part, or MAY implement only one of the proxy parts. 1.1. Terminology 2. The OSCORE Option The OSCORE option (see Figure 3, which extends Table 4 of [RFC7252]) indicates that the CoAP message is an OSCORE message and that it contains a compressed COSE object (see Sections 5 and 6). The OSCORE option is critical, safe to forward, part of the cache key, and not repeatable. I believe it would be clearer to specify that this section defines the OSCORE option which is a new CoAP option. Similarly Table 4 may also be designated by CoAP Options or something similar. +------+---+---+---+---+----------------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +------+---+---+---+---+----------------+--------+--------+---------+ | TBD1 | x | | | | OSCORE | (*) | 0-255 | (none) | +------+---+---+---+---+----------------+--------+--------+---------+ C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable (*) See below. Figure 3: The OSCORE Option The OSCORE option includes the OSCORE flag bits (Section 6), the Sender Sequence Number, the Sender ID, and the ID Context when these fields are present (Section 3). The detailed format and length is specified in Section 6. If the OSCORE flag bits are all zero (0x00) the Option value SHALL be empty (Option Length = 0). An endpoint receiving a CoAP message without payload, that also contains an OSCORE option SHALL treat it as malformed and reject it. I believe the logic for the OSCORE option is the other way around, that is: an CoAP message with an OSCORE option with an empty CoAP payload MUST be rejected as malformed and reject it. A successful response to a request with the OSCORE option SHALL contain the OSCORE option. Whether error responses contain the OSCORE option depends on the error type (see Section 8). For CoAP proxy operations, see Section 10. 3. The Security Context OSCORE requires that client and server establish a shared security context used to process the COSE objects. OSCORE uses COSE with an Authenticated Encryption with Additional Data (AEAD, [RFC5116]) algorithm for protecting message data between a client and a server. In this section, we define the security context and how it is derived Selander, et al. Expires January 27, 2019 [Page 7] Internet-Draft OSCORE July 2018 in client and server based on a shared secret and a key derivation function (KDF). 3.1. Security Context Definition The security context is the set of information elements necessary to carry out the cryptographic operations in OSCORE. For each endpoint, the security context is composed of a "Common Context", a "Sender Context", and a "Recipient Context". The endpoints protect messages to send using the Sender Context and verify messages received using the Recipient Context, both contexts being derived from the Common Context and other data. Clients and servers need to be able to retrieve the correct security context to use. I believe it might be clarifying to specify that CoAP endpoints have always bidirectional communications. If that is correct, then for each communication each end point is both a "Sender" and a "Recipient" for its respective outbound and inbound traffic. The 4 context are derived from a Common Context. As security context are established to secure unidirectional communications, maybe that would be easier to base the description on the unidirectional communications rather than the end points. An endpoint uses its Sender ID (SID) to derive its Sender Context, and the other endpoint uses the same ID, now called Recipient ID (RID), to derive its Recipient Context. In communication between two endpoints, the Sender Context of one endpoint matches the Recipient Context of the other endpoint, and vice versa. Thus, the two security contexts identified by the same IDs in the two endpoints are not the same, but they are partly mirrored. Retrieval and use of the security context are shown in Figure 4. "An endpoint uses its Sender ID (SID) to derive its Sender Context," I see the ID as mostly useful to the recipient in order to retrieve the appropriated security context and decrypt the message. In other words, the sender should know who it sends the message to and does not really need the SID to match the security context. I believe this should be clarified as the current text prevents Sender ID collision, while collision should only be avoided on the receiver's side. .-------------. .-------------. | Common, | | Common, | | Sender, | | Recipient, | | Recipient | | Sender | '-------------' '-------------' Client Server | | Retrieve context for | OSCORE request: | target resource | Token = Token1, | Protect request with | kid = SID, ... | Sender Context +---------------------->| Retrieve context with | | RID = kid | | Verify request with | | Recipient Context | OSCORE response: | Protect response with | Token = Token1, ... | Sender Context Retrieve context with |<----------------------+ Token = Token1 | | Verify request with | | Recipient Context | | Figure 4: Retrieval and Use of the Security Context I might be helpful to clarify that Sender Context on both sides are not the same context. Security Context seems to be missing in the box. It would also help to have in the figure, the relation between the Common Security Context, the Sender Context and Recipient Context on both sides. Selander, et al. Expires January 27, 2019 [Page 8] Internet-Draft OSCORE July 2018 The Common Context contains the following parameters: o AEAD Algorithm. The COSE AEAD algorithm to use for encryption. o Key Derivation Function. The HMAC based HKDF [RFC5869] used to derive Sender Key, Recipient Key, and Common IV. This is confusing to have a generic term such as KDF defined by a sup set of it (HKDF). I believe that either the KDF is defined generic enough and later the default value is set to HKDF with a specific hash function. Another alternative could be to limited the scope of this parameter to HKDF Hash Function. o Master Secret. Variable length, random byte string (see Section 12.3) used to derive traffic keys and IVs. I believe that IVs is the Common IV. o Master Salt. Optional variable length byte string containing the salt used to derive traffic keys and IVs. I believe that IVs is the Common IV. o ID Context. Optional variable length byte string providing additional information to identify the Common Context and to derive traffic keys and IVs. o Common IV. Byte string derived from Master Secret, Master Salt, and ID Context. Length is determined by the AEAD Algorithm. RFC8152 uses context IV. It is not clear to me how these two differ. I believe some text should be added to explain how Common IV differs from the context IV. It is unclear to me whether the Common Context is used for the two bidirectional communications. If that is the case, I am reading that Common IV and Sequence Number in the two directions will end up in IV collision. So Keys needs to be unidirectional and different. The Sender Context contains the following parameters: o Sender ID. Byte string used to identify the Sender Context, to derive traffic keys and IVs, and to assure unique nonces. Maximum length is determined by the AEAD Algorithm. o Sender Key. Byte string containing the symmetric key to protect messages to send. Derived from Common Context and Sender ID. Length is determined by the AEAD Algorithm. o Sender Sequence Number. Non-negative integer used by the sender to protect requests and certain responses, e.g. Observe notifications. Used as 'Partial IV' [RFC8152] to generate unique nonces for the AEAD. Maximum value is determined by the AEAD Algorithm. The Recipient Context contains the following parameters: o Recipient ID. Byte string used to identify the Recipient Context, to derive traffic keys and IVs, and to assure unique nonces. Maximum length is determined by the AEAD Algorithm. o Recipient Key. Byte string containing the symmetric key to verify messages received. Derived from Common Context and Recipient ID. Length is determined by the AEAD Algorithm. o Replay Window (Server only). The replay window to verify requests received. Looking at the different contexts, maybe some text should be added to specify that Sender ID and Recipient ID are equal for a given unidirectional communication. The same occurs for Sender Key and Recipient Key. I believe that Sender Sequence Number also needs to be present in the Recipient Context in order to implement anti replay mechanism. Sequence Number May be interpreted differently. I believe that interpretation should also be part of the Common Security Context. As mentioned above the contexts may probably be refactored with one Context per unidirectional communication. Selander, et al. Expires January 27, 2019 [Page 9] Internet-Draft OSCORE July 2018 All parameters except Sender Sequence Number and Replay Window are immutable once the security context is established. An endpoint may free up memory by not storing the Common IV, Sender Key, and Recipient Key, deriving them when needed. Alternatively, an endpoint may free up memory by not storing the Master Secret and Master Salt after the other parameters have been derived. Endpoints MAY operate as both client and server and use the same security context for those roles. Independent of being client or server, the endpoint protects messages to send using its Sender Context, and verifies messages received using its Recipient Context. The endpoints MUST NOT change the Sender/Recipient ID when changing roles. In other words, changing the roles does not change the set of keys to be used. 3.2. Establishment of Security Context Parameters The parameters in the security context are derived from a small set of input parameters. The following input parameters SHALL be pre- established: o Master Secret o Sender ID o Recipient ID I believe that Sender ID and Recipient ID could be the same value for a given unidirectional communication. I believe that what is required her is the two IDs used by the sessions. The following input parameters MAY be pre-established. In case any of these parameters is not pre-established, the default value indicated below is used: o AEAD Algorithm * Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10) o Master Salt * Default is the empty byte string I believe explicitly providing the string could help. There is always the confusion with "\0" versus "". o Key Derivation Function (KDF) * Default is HKDF SHA-256 o Replay Window Type and Size * Default is DTLS-type replay protection with a window size of 32 [RFC6347] This section specifies Type and windows for the anti replay mechanism. This was described as Replay Windows in the context description. Selander, et al. Expires January 27, 2019 [Page 10] Internet-Draft OSCORE July 2018 All input parameters need to be known to and agreed on by both endpoints, but the replay window may be different in the two endpoints. The way the input parameters are pre-established, is application specific. Considerations of security context establishment are given in Section 12.2 and examples of deploying OSCORE in Appendix B. 3.2.1. Derivation of Sender Key, Recipient Key, and Common IV The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms defined for COSE [RFC8152]. It might be better to consider HKDF instead of KDF and then just specify the Hash function HKDF SHA-256 is mandatory to implement. The security context parameters Sender Key, Recipient Key, and Common IV SHALL be derived from the input parameters using the HKDF, which consists of the composition of the HKDF-Extract and HKDF-Expand steps [RFC5869]: output parameter = HKDF(salt, IKM, info, L) where: o salt is the Master Salt as defined above o IKM is the Master Secret as defined above o info is the serialization of a CBOR array consisting of: info = [ id : bstr, id_context : bstr / nil, alg_aead : int / tstr, type : tstr, L : uint ] bstr, nil, tstr are used for the first time here. Maybe a reference to 8152 may be clarifying. where: o id is the Sender ID or Recipient ID when deriving keys and the empty byte string when deriving the Common IV. The encoding is described in Section 5. o id_context is the ID Context, or nil if ID Context is not provided. o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152]. o type is "Key" or "IV". The label is an ASCII string, and does not include a trailing NUL byte. Selander, et al. Expires January 27, 2019 [Page 11] Internet-Draft OSCORE July 2018 o L is the size of the key/IV for the AEAD algorithm used, in bytes. For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in [RFC8152]) is used, the integer value for alg_aead is 10, the value for L is 16 for keys and 13 for the Common IV. Note that [RFC5869] specifies that if the salt is not provided, it is set to a string of zeros. For implementation purposes, not providing the salt is the same as setting the salt to the empty byte string. OSCORE sets the salt default value to empty byte string, which in [RFC5869] is converted to a string of zeroes (see Section 2.2 of [RFC5869]). I believe that how Sender Key, Recipient Key, and Common IV are derived from the output_parameters should be described as well. Note that in this case I believe that Sender Key and Recipient Key are used for the two unidirectional communications. In other words, the same key should be used by the sender and the recipient of the same communication. The same Common IV is used in both communications. 3.2.2. Initial Sequence Numbers and Replay Window The Sender Sequence Number is initialized to 0. The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see Section 7.4. The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of [RFC6347]. This should be specified the same in the Context. 3.3. Requirements on the Security Context Parameters To ensure unique Sender Keys, the quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be unique, i.e. the pair (ID Context, Sender ID) SHALL be unique in the set of all security contexts using the same Master Secret and Master Salt. This means that Sender ID SHALL be unique in the set of all security contexts using the same Master Secret, Master Salt, and ID Context; such a requirement guarantees unique (key, nonce) pairs, which avoids nonce reuse. I understand the use of SHALL and MUST as similar. If that is correct, It may be better to use the same term throughout the document. I believe that we would like to avoid that the same IV is being reused with the same key. Any change in the inputs of the HMAC based KDF will result in a different output. As such any change in the output will result in that property. I suspect we would like to some parameters to remain wit the same value, while some could be changed, and for that reason, we chose the Sender ID. I believe the text could be clarified either on the reasoning behind or how this should be operated. Different methods can be used to assign Sender IDs: a protocol that allows the parties to negotiate locally unique identifiers, a trusted third party (e.g., [I-D.ietf-ace-oauth-authz]), or the identifiers can be assigned out-of-band. The Sender IDs can be very short (note that the empty string is a legitimate value). The maximum length of Sender ID in bytes equals the length of AEAD nonce minus 6. For AES- CCM-16-64-128 the maximum length of Sender ID is 7 bytes. I suspect those restriction coming from the COSE specification. If that is correct, I believe it would be helpful to have a reference to that document. To simplify retrieval of the right Recipient Context, the Recipient ID SHOULD be unique in the sets of all Recipient Contexts used by an endpoint. If an endpoint has the same Recipient ID with different Recipient Contexts, i.e. the Recipient Contexts are derived from different Common Contexts, then the endpoint may need to try multiple times before verifying the right security context associated to the Recipient ID. Such collision could represent an attack where the attacker could in case a collision is observed craft a packet that costs two time more computation than a regular packet. I might be wrong, but it seems that the ID is more important for the recipient. Typically the sender can easily address Sender ID collision. On the other hand the cryptographic properties are based on the uniqueness of the Sender ID. Maybe these could be considered with the Recipient ID in mind. Selander, et al. Expires January 27, 2019 [Page 12] Internet-Draft OSCORE July 2018 The ID Context is used to distinguish between security contexts. The methods used for assigning Sender ID can also be used for assigning the ID Context. Additionally, the ID Context can be generated by the client (see Appendix B.2). ID Context can be arbitrarily long. 4. Protected Message Fields 4.1. CoAP Options 4.1.1. Inner Options 4.1.2. Outer Options 4.1.3. Special Options 4.1.3.1. Max-Age 4.1.3.2. Uri-Host and Uri-Port 4.1.3.3. Proxy-Uri 4.1.3.4. The Block Options 4.1.3.4.1. Inner Block Options 4.1.3.4.2. Outer Block Options 4.1.3.5. Observe 4.1.3.5.1. Registrations and Cancellations 4.1.3.5.2. Notifications If the server accepts an Observe registration, a Partial IV MUST be included in all notifications (both successful and error), except for the first one where Partial IV MAY be omitted. To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers. The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in Section 7.4.1. For notifications, the Inner Observe value MUST be empty (see Section 3.2 of [RFC7252]). The Outer Observe in a notification is Selander, et al. Expires January 27, 2019 [Page 20] Internet-Draft OSCORE July 2018 needed for intermediary nodes to allow multiple responses to one request, and may be set to the value of Observe in the original CoAP message. The client performs ordering of notifications and replay protection by comparing their Partial IVs and SHALL ignore the outer Observe value. If the client receives a response to an Observe request without an Inner Observe option, then it verifies the response as a non-Observe response, as specified in Section 8.4. If the client receives a response to a non-Observe request with an Inner Observe option, then it stops processing the message, as specified in Section 8.4. A client MUST consider the notification with the highest Partial IV as the freshest, regardless of the order of arrival. In order to support existing Observe implementations the OSCORE client implementation MAY set the Observe value to the three least significant bytes of the Partial IV; such an implementation needs to make sure that the Observe value for an observe notification without Partial IV is smaller than a notification with Partial IV. This section discuss the behavior regarding the sequence number. While the sequence number and the partial IV have the same value, I am wondering if it would not be more appropriated to mention the sequence number value is provided by the partial IV, and then use the sequence number variable to describe anti replay. 4.1.3.6. No-Response 4.1.3.7. OSCORE 4.2. CoAP Header Fields and Payload 4.3. Signaling Messages 5. The COSE Object 5.1. Kid Context 5.2. Nonce 5.3. Plaintext 5.4. Additional Authenticated Data 6. OSCORE Header Compression 6.1. Encoding of the OSCORE Option Value 6.2. Encoding of the OSCORE Payload 6.3. Examples of Compressed COSE Objects 7.2. Sequence Numbers 7.2.1. Maximum Sequence Number 7.3. Freshness 7.4. Replay Protection In order to protect from replay of requests, the server's Recipient Context includes a Replay Window. A server SHALL verify that a Partial IV received in the COSE object has not been received before. If this verification fails the server SHALL stop processing the message, and MAY optionally respond with a 4.01 Unauthorized error message. Also, the server MAY set an Outer Max-Age option with value zero, to inform any intermediary that the response is not to be cached. The diagnostic payload MAY contain the "Replay detected" string. The size and type of the Replay Window depends on the use case and the protocol with which the OSCORE message is transported. In case of reliable and ordered transport from endpoint to endpoint, e.g. TCP, the server MAY just store the last received Partial IV and require that newly received Partial IVs equals the last received Partial IV + 1. However, in case of mixed reliable and unreliable transports and where messages may be lost, such a replay mechanism Selander, et al. Expires January 27, 2019 [Page 33] Internet-Draft OSCORE July 2018 may be too restrictive and the default replay window be more suitable (see Section 3.2.2). I am reading the anti replay mechanism used as very specific. Incrementing Partial IV is one way to perform anti-replay protection. It could be the way OSCORE performs anti replay protection but this is not the only way to do. In addition, incrementing the Partial IV result in the IV being predictible. This condition may not be sufficient as some algorithm may require the IV being unpredictable. I believe Anti-Replay Type shoudl be configurable, and some note shoudl be added to comply with the encryption being used. Responses (with or without Partial IV) are protected against replay as they are bound to the request and the fact that only a single response is accepted. Note that the Partial IV is not used for replay protection in this case. The operation of validating the Partial IV and updating the replay protection MUST be atomic. 7.4.1. Replay Protection of Notifications 7.5. Losing Part of the Context State To prevent reuse of an AEAD nonce with the same key, or from accepting replayed messages, an endpoint needs to handle the situation of losing rapidly changing parts of the context, such as the request Token, Sender Sequence Number, Replay Window, and Notification Numbers. These are typically stored in RAM and therefore lost in the case of an unplanned reboot. After boot, an endpoint can either use a persistently stored complete or partial security context, or establish a new security context with each endpoint it communicates with. However, establishing a fresh security context may have a non-negligible cost in terms of, e.g., power consumption. If the endpoint uses a persistently stored partial security context, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT Selander, et al. Expires January 27, 2019 [Page 34] Internet-Draft OSCORE July 2018 accept previously received messages. Some ways to achieve this are described in the following sections. 7.5.1. Sequence Number To prevent reuse of Sender Sequence Numbers, an endpoint may perform the following procedure during normal operations: o Before using a Sender Sequence Number that is evenly divisible by K, where K is a positive integer, store the Sender Sequence Number in persistent memory. After boot, the endpoint initiates the Sender Sequence Number to the value stored in persistent memory + K. Storing to persistent memory can be costly. The value K gives a trade-off between the number of storage operations and efficient use of Sender Sequence Numbers. I have hard time reading the section above. I guess K is a parameter known by OSCORE. My understanding is that SSN=0 ... K-1 are stored in persistent memory. After boot SSN = SSN + K. I might be wrong but as storage in persistent memory is costly. Given K a parameter defined by the implementation. I would rather store F = floor(SSN / K ). SSN = F.K + ssn with ssn = 0... K-1, so a storage operation happens every K. In case of reboot, SSN = (F + 1).K + ssn. This ends in a jump of maximum K and anti replay must be able to handle this. 7.5.2. Replay Window 7.5.3. Replay of Notifications 8. Processing This section describes the OSCORE message processing. Additional processing for Observe or Block-wise are described in subsections. Note that, analogously to [RFC7252] where the Token and source/ destination pair are used to match a response with a request, both endpoints MUST keep the association (Token, {Security Context, Selander, et al. Expires January 27, 2019 [Page 35] Internet-Draft OSCORE July 2018 Partial IV of the request}), in order to be able to find the Security Context and compute the AAD to protect or verify the response. The association MAY be forgotten after it has been used to successfully protect or verify the response, with the exception of Observe processing, where the association MUST be kept as long as the Observation is active. 8.1. Protecting the Request Given a CoAP request, the client SHALL perform the following steps to create an OSCORE request: 1. Retrieve the Sender Context associated with the target resource. 2. Compose the Additional Authenticated Data and the plaintext, as described in Sections 5.3 and 5.4. 3. Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. I believe this depends on the Anti-replay type. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV as described in Section 5.2. 4. Encrypt the COSE object using the Sender Key. Compress the COSE Object as specified in Section 6. 5. Format the OSCORE message according to Section 4. The OSCORE option is added (see Section 4.1.2). 8.2. Verifying the Request A server receiving a request containing the OSCORE option SHALL perform the following steps: 1. Discard Code and all class E options (marked in Figure 5 with 'x' in column E) present in the received message. For example, an If-Match Outer option is discarded, but an Uri-Host Outer option is not discarded. 2. Decompress the COSE Object (Section 6) and retrieve the Recipient Context associated with the Recipient ID in the 'kid' parameter, additionally using the 'kid context', if present. If either the decompression or the COSE message fails to decode, or the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, then the server SHALL stop processing the request. * If either the decompression or the COSE message fails to decode, the server MAY respond with a 4.02 Bad Option error Selander, et al. Expires January 27, 2019 [Page 36] Internet-Draft OSCORE July 2018 message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload SHOULD contain the string "Failed to decode COSE". * If the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, the server MAY respond with a 4.01 Unauthorized error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload SHOULD contain the string "Security context not found". 3. Verify the 'Partial IV' parameter using the Replay Window, as described in Section 7.4. My understanding is that the Partial IV value has not been authenticated. Thus I believe this step mostly consists in discarding packets with irrelevant Partial IV values. Here irrelevant are limited to repeated sequence numbers that is too say known replayed packets. 4. Compose the Additional Authenticated Data, as described in Section 5.4. 5. Compute the AEAD nonce from the Recipient ID, Common IV, and the 'Partial IV' parameter, received in the COSE Object. 6. Decrypt the COSE object using the Recipient Key, as per [RFC8152] Section 5.3. (The decrypt operation includes the verification of the integrity.) * If decryption fails, the server MUST stop processing the request and MAY respond with a 4.00 Bad Request error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the "Decryption failed" string. * If decryption succeeds, update the Replay Window, as described in Section 7. 7. Add decrypted Code, options, and payload to the decrypted request. The OSCORE option is removed. 8. The decrypted CoAP request is processed according to [RFC7252]. 8.2.1. Supporting Block-wise 8.3. Protecting the Response If a CoAP response is generated in response to an OSCORE request, the server SHALL perform the following steps to create an OSCORE response. Note that CoAP error responses derived from CoAP processing (step 8 in Section 8.2) are protected, as well as successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6 in Section 8.2) do not follow the processing below, but are sent as simple CoAP responses, without OSCORE processing. 1. Retrieve the Sender Context in the Security Context associated with the Token. 2. Compose the Additional Authenticated Data and the plaintext, as described in Sections 5.3 and 5.4. 3. Compute the AEAD nonce as described in Section 5.2: * Either use the nonce from the request, or * Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Again this is very specific. I am reading that SSN is incremented after the Partial IV is generated. It seems to me that the Partial IV should reflect the SSN, and as such being encoded after the incrementation of the SSN. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. 4. Encrypt the COSE object using the Sender Key. Compress the COSE Object as specified in Section 6. If the AEAD nonce was constructed from a new Partial IV, this Partial IV MUST be included in the message. If the AEAD nonce from the request was used, the Partial IV MUST NOT be included in the message. 5. Format the OSCORE message according to Section 4. The OSCORE option is added (see Section 4.1.2). 8.3.1. Supporting Observe 8.4. Verifying the Response 9. Web Linking 10. CoAP-to-CoAP Forwarding Proxy 11. HTTP Operations 11.2. CoAP-to-HTTP Mapping 11.3. HTTP-to-CoAP Mapping 11.4. HTTP Endpoints 11.5. Example: HTTP Client and CoAP Server 11.6. Example: CoAP Client and HTTP Server 12. Security Considerations An overview of the security properties is given in Appendix D. 12.1. End-to-end Protection In scenarios with intermediary nodes such as proxies or gateways, transport layer security such as (D)TLS only protects data hop-by- hop. As a consequence, the intermediary nodes can read and modify any information. The trust model where all intermediary nodes are considered trustworthy is problematic, not only from a privacy perspective, but also from a security perspective, as the intermediaries are free to delete resources on sensors and falsify commands to actuators (such as "unlock door", "start fire alarm", "raise bridge"). Even in the rare cases where all the owners of the intermediary nodes are fully trusted, attacks and data breaches make such an architecture brittle. (D)TLS protects hop-by-hop the entire message. OSCORE protects end- to-end all information that is not required for proxy operations (see Section 4). (D)TLS and OSCORE can be combined, thereby enabling end- to-end security of the message payload, in combination with hop-by- hop protection of the entire message, during transport between end- point and intermediary node. In particular when OSCORE is used with Selander, et al. Expires January 27, 2019 [Page 47] Internet-Draft OSCORE July 2018 HTTP, the additional TLS protection of HTTP hops is recommended, e.g. between an HTTP endpoint and a proxy translating between HTTP and CoAP. I see that (D)TLS provides privacy to OSCORE communication, while OSCORE protects the data. Applications need to consider that certain message fields and messages types are not protected end-to-end and may be spoofed or manipulated. The consequences of unprotected message fields are analyzed in Appendix D.4. 12.2. Security Context Establishment Wouldn't agreement preferred to established ? The use of COSE_Encrypt0 and AEAD to protect messages as specified in this document requires an established security context. The method to establish the security context described in Section 3.2 is based on a common Master Secret and unique Sender IDs. The necessary input parameters may be pre-established or obtained using a key establishment protocol augmented with establishment of Sender/ Recipient ID such as the OSCORE profile of the ACE framework [I-D.ietf-ace-oscore-profile]. Such a procedure must ensure that the requirements of the security context parameters for the intended use are complied with (see Section 3.3) and also in error situations. It is recommended to use a key establishment protocol which provides forward secrecy whenever possible. Considerations for deploying OSCORE with a fixed Master Secret are given in Appendix B. 12.3. Master Secret OSCORE uses HKDF [RFC5869] and the established input parameters to derive the security context. The required properties of the security context parameters are discussed in Section 3.3, in this section we focus on the Master Secret. HKDF denotes in this specification the composition of the expand and extract functions as defined in [RFC5869] and the Master Secret is used as Input Key Material (IKM). Informally, HKDF takes as source an IKM containing some good amount of randomness but not necessarily distributed uniformly (or for which an attacker has some partial knowledge) and derive from it one or more cryptographically strong secret keys [RFC5869]. rfc4086 may be a usefull reference. Therefore, the main requirement for the OSCORE Master Secret, in addition to being secret, is that it is has a good amount of randomness. The selected key establishment schemes must ensure that the necessary properties for the Master Secret are fulfilled. For pre-shared key deployments and key transport solutions such as [I-D.ietf-ace-oscore-profile], the Master Secret can be generated offline using a good random number generator. Selander, et al. Expires January 27, 2019 [Page 48] Internet-Draft OSCORE July 2018 12.4. Replay Protection Replay attacks need to be considered in different parts of the implementation. Most AEAD algorithms require a unique nonce for each message, for which the sender sequence numbers in the COSE message field 'Partial IV' is used. If the recipient accepts any sequence number larger than the one previously received, then the problem of sequence number synchronization is avoided. Do we have cases where the Partial IV represents the LSB of the SSN ? If that is the case, if more then len(Partial IV) packet have been dropped. The two peers may have hard time to resynchronize their SSN. This may happen in a communication with a lot of notifications. In a query-response paradigm, the sender may have some hints when the packet has been receieved or not. With reliable transport, it may be defined that only messages with sequence number which are equal to previous sequence number + 1 are accepted. An adversary may try to induce a device reboot for the purpose of replaying a message (see Section 7.5). Note that sharing a security context between servers may open up for replay attacks, for example if the replay windows are not synchronized. 12.5. Client Aliveness A verified OSCORE request enables the server to verify the identity of the entity who generated the message. However, it does not verify that the client is currently involved in the communication, since the message may be a delayed delivery of a previously generated request which now reaches the server. To verify the aliveness of the client the server may use the Echo option in the response to a request from the client (see [I-D.ietf-core-echo-request-tag]). 12.6. Cryptographic Considerations The maximum sender sequence number is dependent on the AEAD algorithm. The maximum sender sequence number is 2^40 - 1, or any algorithm specific lower limit, after which a new security context must be generated. The mechanism to build the nonce (Section 5.2) assumes that the nonce is at least 56 bits, and the Partial IV is at most 40 bits. The mandatory-to-implement AEAD algorithm AES-CCM- 16-64-128 is selected for compatibility with CCM*. In order to prevent cryptanalysis when the same plaintext is repeatedly encrypted by many different users with distinct keys, the nonce is formed by mixing the sequence number with a secret per- context initialization vector (Common IV) derived along with the keys (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key derivation (see [MF00] for an overview). The Master Secret, Sender Key, Recipient Key, and Common IV must be secret, the rest of the parameters may be public. The Master Secret must have a good amount of randomness (see Section 12.3). Selander, et al. Expires January 27, 2019 [Page 49] Internet-Draft OSCORE July 2018 12.7. Message Segmentation The Inner Block options enable the sender to split large messages into OSCORE-protected blocks such that the receiving endpoint can verify blocks before having received the complete message. The Outer Block options allow for arbitrary proxy fragmentation operations that cannot be verified by the endpoints, but can by policy be restricted in size since the Inner Block options allow for secure fragmentation of very large messages. A maximum message size (above which the sending endpoint fragments the message and the receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery. 12.8. Privacy Considerations Privacy threats executed through intermediary nodes are considerably reduced by means of OSCORE. End-to-end integrity protection and encryption of the message payload and all options that are not used for proxy operations, provide mitigation against attacks on sensor and actuator communication, which may have a direct impact on the personal sphere. The unprotected options (Figure 5) may reveal privacy sensitive information, see Appendix D.4. CoAP headers sent in plaintext allow, for example, matching of CON and ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. OSCORE does not provide protection for HTTP header fields which are not both CoAP-mappable and class E. The HTTP message fields which are visible to on-path entity are only used for the purpose of transporting the OSCORE message, whereas the application layer message is encoded in CoAP and encrypted. COSE message fields, i.e. the OSCORE option, may reveal information about the communicating endpoints. E.g. 'kid' and 'kid context', which are intended to help the server find the right context, may reveal information about the client. Tracking 'kid' and 'kid context' to one server may be used for correlating requests from one client. Unprotected error messages reveal information about the security state in the communication between the endpoints. Unprotected signaling messages reveal information about the reliable transport used on a leg of the path. Using the mechanisms described in Section 7.5 may reveal when a device goes through a reboot. This can be mitigated by the device storing the precise state of sender sequence number and replay window on a clean shutdown. Selander, et al. Expires January 27, 2019 [Page 50] Internet-Draft OSCORE July 2018 The length of message fields can reveal information about the message. Applications may use a padding scheme to protect against traffic analysis. 13. IANA Considerations 14. References Appendix A. Scenario Examples Appendix B. Deployment Examples B.1. Master Secret Used Once An application may derive a security context once and use it for the lifetime of a device. For many IoT deployments, a 128 bit uniformly random Master Key is sufficient for encrypting all data exchanged with the IoT device. This specification describes techniques for persistent storage of the security context and synchronization of sequence numbers (see Section 7.5) to ensure that security is maintained with the existing security context. B.2. Master Secret Used Multiple Times Section 12.2 recommends the use of a key establishment protocol providing forward secrecy of the Master Secret. I believe that forward secrecy is a property associated to the kex. I am reading it as associated to the Master Secret. That said, English is not my native language. An application which does not require forward secrecy may allow multiple security contexts to be derived from one Master Secret. The requirements on the security context parameters must be fulfilled (Section 3.3) even if the client or server is rebooted, recommissioned or in error cases. This section gives an example of an application allowing new security contexts to be derived from input parameters pre-established between client and server for this purpose: in particular Master Secret, Master Salt and Sender/Recipient ID (see Section 3.2): o The client generates an ID Context which has previously not been used with the pre-established input parameters and derives a new security context. ID context may be pseudo-random and large for Selander, et al. Expires January 27, 2019 [Page 62] Internet-Draft OSCORE July 2018 stochastic uniqueness, but care must be taken e.g. to avoid re-use of the same seed for random number generation. Using this new security context, the client generates an OSCORE request with (kid context, kid) = (ID Context, Sender ID) in the OSCORE option. o The server receiving such an OSCORE request with kid matching the Recipient ID of pre-established input parameters, but with a new kid context, derives the security context using ID Context = kid context. If the message verifies then a new security context with this ID Context is stored in the server, and used in the response. Further requests with the same (kid context, kid) are verified with this security context. As an alternative procedure to reduce the subsequent overhead in requests due to kid context, the verification of a message with a new ID Context may trigger the server to generate a new kid to replace the Client Sender ID in future requests. A client may e.g. indicate support for such a procedure by requesting a special well-known URI and receive the new kid in the response, which together with the input parameters and the ID context is used to derive the new security context which may be identified only by its kid. The details are out of scope for this specification. The procedures may be complemented with the use of the Echo option for verifying the aliveness of the client requesting a new security context. Appendix C. Test Vectors Appendix D. Overview of Security Properties D.1. Supporting Proxy Operations CoAP is designed to work with intermediaries reading and/or changing CoAP message fields to perform supporting operations in constrained environments, e.g. forwarding and cross-protocol translations. Securing CoAP on transport layer protects the entire message between the endpoints in which case CoAP proxy operations are not possible. In order to enable proxy operations, security on transport layer needs to be terminated at the proxy in which case the CoAP message in its entirety is unprotected in the proxy. Requirements for CoAP end-to-end security are specified in [I-D.hartke-core-e2e-security-reqs]. The client and server are assumed to be honest, but proxies and gateways are only trusted to perform their intended operations. I expected after 'but' something saying the proxies are not trusted, but t seems that everyone is honest here. maybe we should replace: OLD but proxies and gateways are only trusted to perform their intended operations. NEW: and proxies and gateways are trusted to perform their intended operations. That the server is honest does not means that the node terminating the session is the server.... Forwarding is specified in Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs]. HTTP-CoAP translation is specified in [RFC8075]. Intermediaries translating between different transport layers are intended to perform just that. By working at the CoAP layer, OSCORE enables different CoAP message fields to be protected differently, which allows message fields required for proxy operations to be available to the proxy while message fields intended for the other endpoint remain protected. In the remainder of this section we analyze how OSCORE protects the protected message fields and the consequences of message fields intended for proxy operation being unprotected. This text seems clear to me. Maybe the last paragraph could be sufficient. D.2. Protected Message Fields Protected message fields are included in the Plaintext (Section 5.3) and the Additional Authenticated Data (Section 5.4) of the COSE_Encrypt0 object and encrypted using an AEAD algorithm. OSCORE depends on a pre-established random Master Secret (Section 12.3) used to derive encryption keys, and a construction for making (key, nonce) pairs unique (Appendix D.3). Assuming this is true, and the keys are used for no more data than indicated in Section 7.2.1, OSCORE should provide the following guarantees: o Confidentiality: An attacker should not be able to determine the plaintext contents of a given OSCORE message or determine that different plaintexts are related (Section 5.3). Selander, et al. Expires January 27, 2019 [Page 74] Internet-Draft OSCORE July 2018 o Integrity: An attacker should not be able to craft a new OSCORE message with protected message fields different from an existing OSCORE message which will be accepted by the receiver. o Request-response binding: An attacker should not be able to make a client match a response to the wrong request. o Non-replayability: An attacker should not be able to cause the receiver to accept a message which it has previously received and accepted. In the above, the attacker is anyone except the endpoints, e.g. a compromised intermediary. Informally, OSCORE provides these properties by AEAD-protecting the plaintext with a strong key and uniqueness of (key, nonce) pairs. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Response-request binding is provided by including the kid and Partial IV of the request in the AAD of the response. Non-replayability of requests and notifications is provided by using unique (key, nonce) pairs and a replay protection mechanism (application dependent, see Section 7.4). OSCORE is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets. OSCORE does not provide any specific defenses against this form of attack but the application may use a padding mechanism to prevent an attacker from directly determine the length of the padding. However, information about padding may still be revealed by side-channel attacks observing differences in timing. D.3. Uniqueness of (key, nonce) In this section we show that (key, nonce) pairs are unique as long as the requirements in Sections 3.3 and 7.2.1 are followed. Fix a Common Context (Section 3.1) and an endpoint, called the encrypting endpoint. An endpoint may alternate between client and server roles, but each endpoint always encrypts with the Sender Key of its Sender Context. Sender Keys are (stochastically) unique since they are derived with HKDF using unique Sender IDs, so messages encrypted by different endpoints use different keys. It remains to prove that the nonces used by the fixed endpoint are unique. Since the Common IV is fixed, the nonces are determined by a Partial IV (PIV) and the Sender ID of the endpoint generating that Partial IV (ID_PIV). The nonce construction (Section 5.2) with the size of the ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs. There are two cases: Selander, et al. Expires January 27, 2019 [Page 75] Internet-Draft OSCORE July 2018 A. For requests, and responses with Partial IV (e.g. Observe notifications): o ID_PIV = Sender ID of the encrypting endpoint o PIV = current Partial IV of the encrypting endpoint Since the encrypting endpoint steps the Partial IV for each use, the nonces used in case A are all unique as long as the number of encrypted messages is kept within the required range (Section 7.2.1). B. For responses without Partial IV (e.g. single response to a request): o ID_PIV = Sender ID of the endpoint generating the request o PIV = Partial IV of the request Since the Sender IDs are unique, ID_PIV is different from the Sender ID of the encrypting endpoint. Therefore, the nonces in case B are different compared to nonces in case A, where the encrypting endpoint generated the Partial IV. Since the Partial IV of the request is verified for replay (Section 7.4) associated to this Recipient Context, PIV is unique for this ID_PIV, which makes all nonces in case B distinct. D.4. Unprotected Message Fields This section lists and discusses issues with unprotected message fields. D.4.1. CoAP Header Fields o Version. The CoAP version [RFC7252] is not expected to be sensitive to disclose. Currently there is only one CoAP version defined. A change of this parameter is potentially a denial-of- service attack. Future versions of CoAP need to analyze attacks to OSCORE protected messages due to an adversary changing the CoAP version. o Token/Token Length. The Token field is a client-local identifier for differentiating between concurrent requests [RFC7252]. An eavesdropper reading the token can match requests to responses which can be used in traffic analysis. In particular this is true for notifications, where multiple responses are matched with one request. CoAP proxies are allowed to change Token and Token Length between UDP hops. However, modifications of Token and Token Length during a UDP hop may become a denial-of-service Selander, et al. Expires January 27, 2019 [Page 76] Internet-Draft OSCORE July 2018 attack, since it may prevent the client to identify to which request the response belongs or to find the correct information to verify integrity of the response. I am reading the text as. When the attacker is on-path, a long Token does not prevents the attack based on a spoofed response. However, for an attacker that is not on path, the attacker needs to guess the Token, and this can be mitigated (partially) by increasing the Token size. Note that in the latest case, a long Token should not be seen as a replacement for cryptographic protection of the message. o Code. The Outer CoAP Code of an OSCORE message is POST or FETCH for requests with corresponding response codes. The use of FETCH reveals no more than what is revealed by the Outer Observe option. Changing the Outer Code may be a denial-of-service attack by causing errors in the proxy processing. o Type/Message ID. The Type/Message ID fields [RFC7252] reveal information about the UDP transport binding, e.g. an eavesdropper reading the Type or Message ID gain information about how UDP messages are related to each other. CoAP proxies are allowed to change Type and Message ID. These message fields are not present in CoAP over TCP [RFC8323], and does not impact the request/ response message. A change of these fields in a UDP hop is a denial-of-service attack. By sending an ACK, an attacker can make the endpoint believe that the other endpoint received the previous message. By sending a RST, an attacker may be able to cancel an observation, make one endpoint believe the other endpoint is alive, or make one endpoint endpoint believe that the other endpoint is missing some context. By changing a NON to a CON, the attacker can cause the receiving endpoint to respond to messages for which no response was requested. o Length. This field contain the length of the message [RFC8323] which may be used for traffic analysis. These message fields are not present in CoAP over UDP, and does not impact the request/ response message. A change of Length is a denial-of-service attack similar to changing TCP header fields. D.4.2. CoAP Options o Max-Age. The Outer Max-Age is set to zero to avoid unnecessary caching of OSCORE error responses. Changing this value thus may cause unnecessary caching. No additional information is carried with this option. o Proxy-Uri/Proxy-Scheme. These options are used in forward proxy deployments. With OSCORE, the Proxy-Uri option does not contain the Uri-Path/Uri-Query parts of the URI. The other parts of Proxy-Uri cannot be protected since they are allowed to be changed by a forward proxy. The server can verify what scheme is used in the last hop, but not what was requested by the client or what was used in previous hops. Selander, et al. Expires January 27, 2019 [Page 77] Internet-Draft OSCORE July 2018 o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/ Uri-Port may be changed by an adversary, and the application needs to handle the consequences of that (see Section 4.1.3.2). The Uri-Host may either be omitted, reveal information equivalent to that of the IP address or more privacy-sensitive information, which is discouraged. o Observe. The Outer Observe option is intended for a proxy to support forwarding of Observe messages, but is ignored by the endpoints since the Inner Observe determines the processing in the endpoints. Since the Partial IV provides absolute ordering of notifications it is not possible for an intermediary to spoof reordering (see Section 4.1.3.5). The absence of Partial IV, since only allowed for the first notification, does not prevent correct ordering of notifications. The size and distributions of notifications over time may reveal information about the content or nature of the notifications. Cancellations (Section 4.1.3.5.1) are not bound to the corresponding registrations in the same way responses are bound to requests in OSCORE (see Appendix D.2), but that does not open up for attacks based on mismatched cancellations, since [RFC7641] specifies that for cancellations to be accepted, all options except for ETags MUST be the same (see Section 3.6 of [RFC7641]). For different target resources, the OSCORE option is different, and even if the Token is modified to match a different observation, such a cancellation would not be accepted. o Block1/Block2/Size1/Size2. The Outer Block options enables fragmentation of OSCORE messages in addition to segmentation performed by the Inner Block options. The presence of these options indicates a large message being sent and the message size can be estimated and used for traffic analysis. Manipulating these options is a potential denial-of-service attack, e.g. injection of alleged Block fragments. The specification of a maximum size of message, MAX_UNFRAGMENTED_SIZE (Section 4.1.3.4.2), above which messages will be dropped, is intended as one measure to mitigate this kind of attack. o No-Response. The Outer No-Response option is used to support proxy functionality, specifically to avoid error transmissions from proxies to clients, and to avoid bandwidth reduction to servers by proxies applying congestion control when not receiving responses. Modifying or introducing this option is a potential denial-of-service attack against the proxy operations, but since the option has an Inner value its use can be securely agreed between the endpoints. The presence of this option is not expected to reveal any sensitive information about the message exchange. Selander, et al. Expires January 27, 2019 [Page 78] Internet-Draft OSCORE July 2018 o OSCORE. The OSCORE option contains information about the compressed COSE header. Changing this field may cause OSCORE verification to fail. D.4.3. Error and Signaling Messages Error messages occurring during CoAP processing are protected end-to- end. Error messages occurring during OSCORE processing are not always possible to protect, e.g. if the receiving endpoint cannot locate the right security context. For this setting, unprotected error messages are allowed as specified to prevent extensive retransmissions. Those error messages can be spoofed or manipulated, which is a potential denial-of-service attack. Signaling messages used in CoAP over TCP [RFC8323] are intended to be hop-by-hop; spoofing signaling messages can be used as a denial-of- service attack of a TCP connection. D.4.4. HTTP Message Fields In contrast to CoAP, where OSCORE does not protect header fields to enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is restricted to transporting a protected CoAP message over an HTTP hop. Any unprotected HTTP message fields may reveal information about the transport of the OSCORE message and enable various denial-of-service attacks. It is recommended to additionally use TLS [RFC5246] for HTTP hops, which enables encryption and integrity protection of headers, but still leaves some information for traffic analysis. Appendix E. CDDL Summary