From nobody Tue Mar 1 04:44:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E87C1B2B6D for ; Tue, 1 Mar 2016 04:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzxTOmYy4Cbz for ; Tue, 1 Mar 2016 04:44:06 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 AA13C1B2B6A for ; Tue, 1 Mar 2016 04:44:06 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id CC711B41BFDD; Tue, 1 Mar 2016 12:44:02 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u21Ci4WI020396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Mar 2016 12:44:04 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u21ChwcH029882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Mar 2016 13:44:04 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.130]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 1 Mar 2016 13:43:07 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] Introducing Server Name Identifiers in Certificates Thread-Index: AQHRctiKi5AEjQ3QRUeCHzf97fkrzp9EeU6A Date: Tue, 1 Mar 2016 12:43:06 +0000 Message-ID: References: <56D4178A.6040302@gmx.net> In-Reply-To: <56D4178A.6040302@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Introducing Server Name Identifiers in Certificates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 01 Mar 2016 12:44:08 -0000 On 29/02/2016 10:03, "core on behalf of Hannes Tschofenig" wrote: >Hi all, > >working on the DTLS/TLS profile document Thomas and I realized that >there are some challenges when certificates are used for IoT devices. >For this reason we published >already early 2015. > >When Thomas presented the draft at IETF #92 it triggered a fair amount >of discussion and we got lots of good feedback from several CORE working >group participants. > >Some time passed and the work on the DTLS/TLS profile draft finished but >we haven't forgotten the feedback and have now re-written the document. > >Here is the link to the new document: >https://tools.ietf.org/html/draft-fossati-core-server-name-id-00 > >The easiest way is to read Section 1 ("Introduction") and Section 8 >("Example") to see what we are trying to accomplish. In particular, we are trying to understand what kind of non-DNS environment we need to cater for. Resource Directory is an obvious candidate -- do we need more than that? Cheers, t From nobody Sat Mar 5 01:36:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A21B2B10; Sat, 5 Mar 2016 01:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL-xWZLn24oc; Sat, 5 Mar 2016 01:36:41 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C071B2B15; Sat, 5 Mar 2016 01:36:38 -0800 (PST) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 1B51AA80D2; Sat, 5 Mar 2016 10:36:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id St7K2TDTDe_m; Sat, 5 Mar 2016 10:36:35 +0100 (CET) X-Originating-IP: 93.204.214.47 Received: from nar.local (p5DCCD62F.dip0.t-ipconnect.de [93.204.214.47]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 54004A80D1; Sat, 5 Mar 2016 10:36:32 +0100 (CET) Message-ID: <56DAA5D7.5030806@tzi.org> Date: Sat, 05 Mar 2016 10:24:39 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "ace@ietf.org" , "core@ietf.org WG" , "cose@ietf.org" , "dtls-iot@ietf.org" , "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF95: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Mar 2016 09:36:42 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF95. Remember that there is still quite some potential for changes. All times are COT (UTC-0500), which is the same as US CDT (Chicago or Dallas time) during the meeting (the browser timezone function is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote). Grüße, Carsten MONDAY, April 4, 2016 1000-1230 Morning Session I Atlantico C SEC *** ace Authentication and Authorization for Constrained Environments WG Buen Ayre A SEC tokbind Token Binding WG 1400-1530 Afternoon Session I Atlantico C ART uta Using TLS in Applications WG Buen Ayre B INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Buen Ayre C OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Buen Ayre A INT dnssd Extensions for Scalable DNS Service Discovery WG Pacifico A IRTF maprg Proposed Measurement and Analysis for Protocols Research Group Buen Ayre C RTG babel Babel routing protocol BOF Buen Ayre B SEC *** cose CBOR Object Signing and Encryption WG 1740-1940 Afternoon Session III Quebracho B ART webpush Web-Based Push Notifications WG Buen Ayre C INT *** lpwan Low-Power Wide Area Networks BOF Buen Ayre B OPS anima Autonomic Networking Integrated Model and Approach WG Buen Ayre A SEC acme Automated Certificate Management Environment WG TUESDAY, April 5, 2016 1000-1230 Morning Session I Atlantico C INT arcing Alternative Resolution Contexts for Internet Naming BOF Buen Ayre C OPS v6ops IPv6 Operations WG Buen Ayre A RTG detnet Deterministic Networking WG Atlantico B SEC tls Transport Layer Security WG 1400-1600 Afternoon Session I Pacifico A INT homenet Home Networking WG Atlantico C SEC lurk Limited Use of Remote Keys BOF Buen Ayre B TSV tsvwg Transport Area Working Group WG 1620-1720 Afternoon Session II Buen Ayre C INT intarea Internet Area Working Group WG Quebracho B RTG *** roll Routing Over Low power and Lossy networks WG Buen Ayre B SEC curdle CURves, Deprecating and a Little more Encryption WG 1730-1900 Afternoon Session III Buen Ayre B ART *** core Constrained RESTful Environments WG Pacifico A TSV tsvarea Transport Area Open Meeting WEDNESDAY, April 6, 2016 1000-1230 Morning Session I Buen Ayre C INT 6man IPv6 Maintenance WG Buen Ayre B SEC oauth Web Authorization Protocol WG Atlantico C SEC openpgp Open Specification for Pretty Good Privacy WG - 11:00 - 12:30 Atlantico B TSV rmcat RTP Media Congestion Avoidance Techniques WG 1400-1600 Afternoon Session I Buen Ayre C INT its Intelligent Transportation Systems BOF Quebracho B RTG bier Bit Indexed Explicit Replication WG 1620-1720 Afternoon Session II Buen Ayre C RTG rtgarea Routing Area Open Meeting Buen Ayre B SEC httpauth Hypertext Transfer Protocol Authentication WG Buen Ayre A TSV tsvwg Transport Area Working Group WG THURSDAY, April 7, 2016 1000-1230 Morning Session I Atlantico C SEC tls Transport Layer Security WG Pacifico A TSV accord Alternatives to Content Classification for Operator Resource Deployment BOF 1400-1600 Afternoon Session I Buen Ayre A ART ice Interactive Connectivity Establishment WG Pacifico A SEC saag Security Area Open Meeting 1620-1820 Afternoon Session II Atlantico C ART httpbis Hypertext Transfer Protocol WG Pacifico A INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Buen Ayre C TSV tcpinc TCP Increased Security WG 1830-1930 Afternoon Session III Buen Ayre C IRTF*** t2trg Thing-to-Thing Atlantico B OPS anima Autonomic Networking Integrated Model and Approach WG FRIDAY, April 8, 2016 1000-1200 Morning Session I Quebracho B ART *** core Constrained RESTful Environments WG Buen Ayre B IRTF cfrg Crypto Forum Buen Ayre A TSV taps Transport Services WG From nobody Sat Mar 5 01:49:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0192E1B2BA7; Sat, 5 Mar 2016 01:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVckiMGbHFwZ; Sat, 5 Mar 2016 01:49:20 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01261B2BAF; Sat, 5 Mar 2016 01:49:16 -0800 (PST) Received: from mfilter49-d.gandi.net (mfilter49-d.gandi.net [217.70.178.180]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id F1AA141C08D; Sat, 5 Mar 2016 10:49:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id sHBKzp0rPSTR; Sat, 5 Mar 2016 10:49:13 +0100 (CET) X-Originating-IP: 93.204.214.47 Received: from nar.local (p5DCCD62F.dip0.t-ipconnect.de [93.204.214.47]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 3BAF641C08A; Sat, 5 Mar 2016 10:49:10 +0100 (CET) Message-ID: <56DAAB99.4030309@tzi.org> Date: Sat, 05 Mar 2016 10:49:13 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "ace@ietf.org" , "core@ietf.org WG" , "cose@ietf.org" , "dtls-iot@ietf.org" , "t2trg@irtf.org" References: <56DAA5D7.5030806@tzi.org> In-Reply-To: <56DAA5D7.5030806@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] [T2TRG] Constrained Node/Network Cluster @ IETF95: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Mar 2016 09:49:22 -0000 Amazing how you find the obvious error only after sending the mail to ten mailing lists... It is of course ART (UTC-0300), which is New Brunswick or Bermuda time. Sorry about that. Carsten Bormann wrote: > All times are COT (UTC-0500), which is the same as US CDT ( Grüße, Carsten From nobody Mon Mar 7 00:36:46 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADF71A8889 for ; Mon, 7 Mar 2016 00:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRs86oR2xErd for ; Mon, 7 Mar 2016 00:36:42 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD4A1A871A for ; Mon, 7 Mar 2016 00:36:42 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud6.xs4all.net with ESMTP id Swcf1s01J4QBLo201wcfd2; Mon, 07 Mar 2016 09:36:39 +0100 Received: from AMontpellier-654-1-113-50.w90-0.abo.wanadoo.fr ([90.0.128.50]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 07 Mar 2016 09:36:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 Mar 2016 09:36:39 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20160307083032.29319.78185.idtracker@ietfa.amsl.com> References: <20160307083032.29319.78185.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (5UDmXh2jijmJeNrIs8xRj3LGRoEueKVp) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 08:36:44 -0000 Dear all, a New version of the comi draft has been submitted. - All yang hash text has been removed and the draft refers to bierman-core-yang-hash draft. draft refers to managed numbering. - All YANG to CBOR mapping has been removed, the draft waits for the publication of the yang-cbor draft - the draft lists all differences with restconf - rpc has been added. - and several other editorials. Peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-core-comi-09.txt Datum: 2016-03-07 09:30 Afzender: internet-drafts@ietf.org Ontvanger: "Peter van der Stok" , "Peter Van der Stok" , "Andy Bierman" A new version of I-D, draft-vanderstok-core-comi-09.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-comi Revision: 09 Title: CoAP Management Interface Document date: 2016-03-07 Group: Individual Submission Pages: 48 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-comi-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-09 Abstract: This document describes a network management interface for constrained devices, called CoMI. CoMI is an adaptation of the RESTCONF protocol for use in constrained devices and networks. The Constrained Application Protocol (CoAP) is used to access management data resources specified in YANG, or SMIv2 converted to YANG. CoMI use the YANG to CBOR mapping and encodes YANG names to reduce payload size. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. 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 Mon Mar 7 06:42:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3DE1B41D8 for ; Mon, 7 Mar 2016 06:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl2x0POJmpIn for ; Mon, 7 Mar 2016 06:42:12 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D15D1B394E for ; Mon, 7 Mar 2016 06:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4GvYrwMRSFMnY9ltpy8uotVb0ElMUH9Kjp4oMG9stlw=; b=JbrpkQ0rdl72RQvtsMrGeMrg98o19OwEtbxbOtBHqObRP4s7srKPgwsBqIHkm+QB6K+uoz6OSOoH1XNF38VNibxfQBuh6p5oP+/XWowmLJC1tJf2Kft2AnmFogn+hpLlh3jmVyRkHFlMUlVsyawaypsbLRmn45j40/pFtCvTCck= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.427.16; Mon, 7 Mar 2016 14:42:08 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0427.019; Mon, 7 Mar 2016 14:42:08 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt Thread-Index: AdF4f34PcCdHLPqYQ0WUDYiqZ7ChJg== Date: Mon, 7 Mar 2016 14:42:08 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: d1e7e985-10f0-46eb-960b-08d34696a95d x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:LZrLzAWLdl/Gelwf6tjDqqzSdwWfjcmFmkGlNuT/a8DurUUc2dzE9orGR5+Ifdj4KQIvtNYYYDDVV4XUSUdo+cznvY+yCXucp2HibOrd4ddfzS0V4921ZV52XfejtQuDXPwcBcbQGJM89+l61qPEig==; 24:FJKDQ6wyVJa+zX889cNDceTgjIhHMO4YEv/XjgCXRywPZEA7cGV0KSiiFCvPyjTk/52Vumlm5i6Xv5WXh2T1N+DCA/BWG598l/sgflM5ujw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 087474FBFA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2473001)(52084003)(377424004)(377454003)(13464003)(99286002)(54356999)(15650500001)(189998001)(11100500001)(230783001)(40100003)(1220700001)(122556002)(2501003)(1096002)(5003600100002)(19580405001)(19580395003)(50986999)(92566002)(5002640100001)(5004730100002)(2900100001)(5001770100001)(5008740100001)(107886002)(15975445007)(3660700001)(87936001)(66066001)(33656002)(76576001)(2906002)(6116002)(102836003)(10400500002)(77096005)(586003)(3846002)(81166005)(3280700002)(74316001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2016 14:42:08.7862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Mar 2016 14:42:14 -0000 Hi Peter We are correctly in final review process of the mapping draft prior publish= ing. The current version is available at: https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-= latest.html If possible, send me your comments before Wednesday to give us some time to= apply them. About "draft-vanderstok-core-patch-02", in the examples: - should "Content-Type" be replaced by "Content-Format" since it's a CoAP r= equest? - should PATCH be replaced by "iPATCH" More globally, do we really need two methods "PATCH" and "iPATCH"? If both methods are supported, should the client select to proper method pe= r request or just on the potential for a method to sometime create non-idempotent requests? For example, should the client use iPATCH for a "replace" and PATCH for a "= insert-after"? iPATCH CoAP://www.example.com/object Content-Type: application/json-patch+json [ { "op":"replace","path":"/x-coord","value":45} ] PATCH CoAP://www.example.com/object Content-Type: application/json-patch+json [ { "op":"insert-after", "insertion-point" : "/y-coord", "path":"/z-coord= ","value":45} ] Regards, Michel Veillette -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: March-07-16 3:37 AM To: Core Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-com= i-09.txt Dear all, a New version of the comi draft has been submitted. - All yang hash text has been removed and the draft refers to bierman-core-= yang-hash draft. draft refers to managed numbering. - All YANG to CBOR mapping has been removed, the draft waits for the public= ation of the yang-cbor draft - the draft lists all differences with restconf - rpc has been added. - and several other editorials. Peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-core-comi-09.txt Datum: 2016-03-07 09:30 Afzender: internet-drafts@ietf.org Ontvanger: "Peter van der Stok" , "Peter Van de= r Stok" , "Andy Bierman"=20 A new version of I-D, draft-vanderstok-core-comi-09.txt has been successful= ly submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-comi Revision: 09 Title: CoAP Management Interface Document date: 2016-03-07 Group: Individual Submission Pages: 48 URL: =20 https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.txt Status: =20 https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: =20 https://tools.ietf.org/html/draft-vanderstok-core-comi-09 Diff: =20 https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-core-comi-09 Abstract: This document describes a network management interface for constrained devices, called CoMI. CoMI is an adaptation of the RESTCONF protocol for use in constrained devices and networks. The Constrained Application Protocol (CoAP) is used to access management data resources specified in YANG, or SMIv2 converted to YANG. CoMI use the YANG to CBOR mapping and encodes YANG names to reduce payload size. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 8 00:16:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2348C12D53F for ; Tue, 8 Mar 2016 00:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxgU22F2eNgJ for ; Tue, 8 Mar 2016 00:16:43 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7735912D53D for ; Tue, 8 Mar 2016 00:16:42 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud3.xs4all.net with ESMTP id TLGe1s00j4Hiz6i01LGeBM; Tue, 08 Mar 2016 09:16:40 +0100 Received: from AMontpellier-654-1-113-50.w90-0.abo.wanadoo.fr ([90.0.128.50]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 08 Mar 2016 09:16:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Mar 2016 09:16:38 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> X-Sender: stokcons@xs4all.nl (K/75OpYFvYkqEI3YcpEQvwW/Wd/hPyV4) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 08:16:46 -0000 Hi Michel see below. Michel Veillette schreef op 2016-03-07 15:42: > Hi Peter > > We are correctly in final review process of the mapping draft prior > publishing. > The current version is available at: > https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-latest.html > pvds> will try > > If possible, send me your comments before Wednesday to give us some > time to apply them. > > About "draft-vanderstok-core-patch-02", in the examples: > - should "Content-Type" be replaced by "Content-Format" since it's a > CoAP request? good remark, In the coap RFC content-Type is used a few times, and content-format mostly. I will change > - should PATCH be replaced by "iPATCH" don't think so, why? > > More globally, do we really need two methods "PATCH" and "iPATCH"? people like idem-potent as explained in earlier e_mail by Carsten other people prefer more freedom by removing idem-potency restriction. Both camps have valid arguments. > If both methods are supported, should the client select to proper > method per request or just > on the potential for a method to sometime create non-idempotent > requests? > For example, should the client use iPATCH for a "replace" and PATCH > for a "insert-after"? > > iPATCH CoAP://www.example.com/object > Content-Type: application/json-patch+json > [ > { "op":"replace","path":"/x-coord","value":45} > ] > > PATCH CoAP://www.example.com/object > Content-Type: application/json-patch+json > [ > { "op":"insert-after", "insertion-point" : "/y-coord", > "path":"/z-coord","value":45} > ] My opinion: Both iPATCH and Patch can be invoked. When the content suggests a non-idem-potent update (like add an item to an array) - the Patch should execute the update - and iPatch should return an error and do nothing (atomicity) > > Regards, > Michel Veillette > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: March-07-16 3:37 AM > To: Core > Subject: [core] Fwd: New Version Notification for > draft-vanderstok-core-comi-09.txt > > Dear all, > > a New version of the comi draft has been submitted. > > - All yang hash text has been removed and the draft refers to > bierman-core-yang-hash draft. draft refers to managed numbering. > - All YANG to CBOR mapping has been removed, the draft waits for the > publication of the yang-cbor draft > - the draft lists all differences with restconf > - rpc has been added. > - and several other editorials. > > Peter > > -------- Oorspronkelijke bericht -------- > Onderwerp: New Version Notification for > draft-vanderstok-core-comi-09.txt > Datum: 2016-03-07 09:30 > Afzender: internet-drafts@ietf.org > Ontvanger: "Peter van der Stok" , "Peter > Van der Stok" , "Andy Bierman" > > > A new version of I-D, draft-vanderstok-core-comi-09.txt has been > successfully submitted by Peter van der Stok and posted to the IETF > repository. > > Name: draft-vanderstok-core-comi > Revision: 09 > Title: CoAP Management Interface > Document date: 2016-03-07 > Group: Individual Submission > Pages: 48 > URL: > https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.txt > Status: > https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ > Htmlized: > https://tools.ietf.org/html/draft-vanderstok-core-comi-09 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-09 > > Abstract: > This document describes a network management interface for > constrained devices, called CoMI. CoMI is an adaptation of the > RESTCONF protocol for use in constrained devices and networks. The > Constrained Application Protocol (CoAP) is used to access > management > data resources specified in YANG, or SMIv2 converted to YANG. CoMI > use the YANG to CBOR mapping and encodes YANG names to reduce > payload > size. > > Note > > Discussion and suggestions for improvement are requested, and > should > be sent to core@ietf.org. > > > > > 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 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 8 11:38:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D9412DA28 for ; Tue, 8 Mar 2016 11:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-uK2R4xFj7M for ; Tue, 8 Mar 2016 11:38:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2607F12D9E5 for ; Tue, 8 Mar 2016 11:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EdDCGPSgRDClw8BoZZZ1bk4Il0MgX9sZ0b21AoPh1/I=; b=n1Q0bgPZYRol91LPr7bkUB7fzGy7qMTri+/OLHdbpay82uo2pXjvK6qzpBLefWG5gKRag6PtV44ZLGknNhrs+i2Y/ZvyDhWxxVaDwaYYgs3tJqJKuA7IOQQo0+sxTnvwp+cMWF2NkneBQ7KKOl1tYNmrVIv+Wy7D3QTuTsumhXE= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (TLS) id 15.1.427.16; Tue, 8 Mar 2016 19:38:06 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0427.019; Tue, 8 Mar 2016 19:38:06 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt Thread-Index: AdF4f34PcCdHLPqYQ0WUDYiqZ7ChJgAk1gcAABdsK9A= Date: Tue, 8 Mar 2016 19:38:06 +0000 Message-ID: References: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> In-Reply-To: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: 5d2c109b-3ac1-4aad-b3a4-08d347892c57 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:yo8Q8p5drpflBE58AToEO1q7pXWQwq0gKI1RN6nkT3rihy9ud2Xqpxf9SUQuizCHT/lzzwPRaZ3ZlI0EHXDFmscN+SRCUUXFghPNqEOSxXmMR+7NGzPVK/YmGMhtFNuvh8zbDkhDHelLpUAWdSvZsw==; 24:pExgtPze7QpIHGgFG6h4LT0FV3dq8FupjxF4RYt8g3wk6geCbwNFJSk2c3F5Gzz35AvaAz1PvdSmRg0MXZ5530nfcZ9NRqd8o1NjQaloxIs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(377454003)(2473001)(189998001)(1096002)(1220700001)(110136002)(102836003)(3846002)(77096005)(92566002)(6116002)(5003600100002)(87936001)(586003)(86362001)(99286002)(15975445007)(5002640100001)(50986999)(74316001)(1730700002)(66066001)(76576001)(230783001)(5004730100002)(15650500001)(122556002)(33656002)(19580405001)(19580395003)(54356999)(81166005)(4326007)(2501003)(10400500002)(2900100001)(5008740100001)(2950100001)(76176999)(3280700002)(3660700001)(2906002)(11100500001)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2016 19:38:06.7689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 08 Mar 2016 19:38:26 -0000 Hi Peter. About "don't think so, why?" An update operation is not always idempotent. For both examples, don't we have the following behaviour? f(f("x-coord": 256) =3D f("x-coord": 256) =3D "x-coord": 45 First example: PATCH CoAP://www.example.com/object Content-Type: application/json-patch+= json [ { "op":"replace","path":"x-coord","value":45} ] Second example: PATCH CoAP://www.example.com/object Content-Type: application/merge-patch= +json { "x-coord" : 45 } So, should we replace the PATCH by an iPATCH? I just trying to understand how this work. Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: March-08-16 3:17 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] Fwd: New Version Notification for draft-vanderstok-core= -comi-09.txt Hi Michel see below. Michel Veillette schreef op 2016-03-07 15:42: > Hi Peter >=20 > We are correctly in final review process of the mapping draft prior=20 > publishing. > The current version is available at: > https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-map > ping-latest.html > pvds> will try >=20 > If possible, send me your comments before Wednesday to give us some=20 > time to apply them. >=20 > About "draft-vanderstok-core-patch-02", in the examples: > - should "Content-Type" be replaced by "Content-Format" since it's a=20 > CoAP request? good remark, In the coap RFC content-Type is used a few times, and content-= format mostly. I will change > - should PATCH be replaced by "iPATCH" don't think so, why? >=20 > More globally, do we really need two methods "PATCH" and "iPATCH"? people like idem-potent as explained in earlier e_mail by Carsten other peo= ple prefer more freedom by removing idem-potency restriction. Both camps have valid arguments. > If both methods are supported, should the client select to proper=20 > method per request or just on the potential for a method to sometime=20 > create non-idempotent requests? > For example, should the client use iPATCH for a "replace" and PATCH=20 > for a "insert-after"? >=20 > iPATCH CoAP://www.example.com/object > Content-Type: application/json-patch+json > [ > { "op":"replace","path":"/x-coord","value":45} > ] >=20 > PATCH CoAP://www.example.com/object > Content-Type: application/json-patch+json > [ > { "op":"insert-after", "insertion-point" : "/y-coord",=20 > "path":"/z-coord","value":45} > ] My opinion: Both iPATCH and Patch can be invoked. When the content suggests a non-idem-potent update (like add an item to an = array) - the Patch should execute the update - and iPatch should return an error and do nothing (atomicity) >=20 > Regards, > Michel Veillette >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der=20 > Stok > Sent: March-07-16 3:37 AM > To: Core > Subject: [core] Fwd: New Version Notification for=20 > draft-vanderstok-core-comi-09.txt >=20 > Dear all, >=20 > a New version of the comi draft has been submitted. >=20 > - All yang hash text has been removed and the draft refers to=20 > bierman-core-yang-hash draft. draft refers to managed numbering. > - All YANG to CBOR mapping has been removed, the draft waits for the=20 > publication of the yang-cbor draft > - the draft lists all differences with restconf > - rpc has been added. > - and several other editorials. >=20 > Peter >=20 > -------- Oorspronkelijke bericht -------- > Onderwerp: New Version Notification for=20 > draft-vanderstok-core-comi-09.txt > Datum: 2016-03-07 09:30 > Afzender: internet-drafts@ietf.org > Ontvanger: "Peter van der Stok" , "Peter=20 > Van der Stok" , "Andy Bierman" > >=20 > A new version of I-D, draft-vanderstok-core-comi-09.txt has been=20 > successfully submitted by Peter van der Stok and posted to the IETF=20 > repository. >=20 > Name: draft-vanderstok-core-comi > Revision: 09 > Title: CoAP Management Interface > Document date: 2016-03-07 > Group: Individual Submission > Pages: 48 > URL: > https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.txt > Status: > https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ > Htmlized: > https://tools.ietf.org/html/draft-vanderstok-core-comi-09 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-core-comi-09 >=20 > Abstract: > This document describes a network management interface for > constrained devices, called CoMI. CoMI is an adaptation of the > RESTCONF protocol for use in constrained devices and networks. The > Constrained Application Protocol (CoAP) is used to access=20 > management > data resources specified in YANG, or SMIv2 converted to YANG. CoMI > use the YANG to CBOR mapping and encodes YANG names to reduce=20 > payload > size. >=20 > Note >=20 > Discussion and suggestions for improvement are requested, and=20 > should > be sent to core@ietf.org. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 8 20:53:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118B212DC75 for ; Tue, 8 Mar 2016 20:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW-2CwCEyDlP for ; Tue, 8 Mar 2016 20:53:04 -0800 (PST) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0257D12DB0C for ; Tue, 8 Mar 2016 20:53:03 -0800 (PST) X-ASG-Debug-ID: 1457499180-06daaa714d5c7410001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id kQgk4RVca5yCYji2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 08 Mar 2016 23:53:01 -0500 (EST) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0266.001; Tue, 8 Mar 2016 23:52:58 -0500 From: "Rahman, Akbar" To: Klaus Hartke Thread-Topic: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 X-ASG-Orig-Subj: RE: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 Thread-Index: AQHQ78omyjBftircP0+PSVXhf7jhrZ5SUdSAgP8zhAA= Date: Wed, 9 Mar 2016 04:52:57 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BA61E93@NABESITE.InterDigital.com> References: <55F83752.3090609@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.3] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1457499180 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.27689 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 04:53:06 -0000 Hi Klaus, Thank you for your thorough review and apologies for the long delay in answ= ering your comments. None of the authors were able to make it to last Nov= ember's IETF meeting where we had wanted to speak to you directly to resolv= e some of the issues. This resulted in an overall delay to the entire proc= ess. However, we were recently able to coordinate a point by point respons= e to comments. Please review and tell if us you agree with the responses. = Once we have closed all the comments with you we will do an update of the = draft before the IETF-95 cut-off date. Best Regards, Akbar (on behalf of all the authors) ----------------------------------------------------------------- KH Comment #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here's my review of draft-ietf-core-http-mapping-07: Overall -- the document is 'Informational', but it makes a lot of use of re= quirement keywords (SHOULD, MUST, etc.). Do these keywords indicate conform= ance requirements? What happens if a proxy implementation ignores any of th= e requirements? Where do interoperability problems occur in this case? Plea= se review all occurrences of a requirement keywords in the document and ver= ify that is really necessary for interoperability. Explain what happens whe= n a proxy implementation fails to implement a requirement keyword. IMHO the= only requirement is really that the proxy MUST keep up the illusion that i= t is an HTTP origin server; everything else seems to be OPTIONAL to me. Authors? Response #1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Okay. We will change any requirements language taken from other RFCs to = lower case (and this will remove quite a few requirements). - We will go through and see if remaining requirements language should be o= ptional or mandatory. - We propose to leave the document as Informational as there is good preced= ence for this. For example, a random search of Informational RFCs in the I= ETF stream shows that many Informational RFCs use RFC2119 language. ----------------------------------------------------------------- KH Comment #2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. "is to reduce variation between proxy implementations, thereby increasin= g interoperability" -- where do these interoperability problems occur? A HT= TP-CoAP cross-protocol reverse proxy appears as an origin server to the HTT= P client, so for the HTTP client any such proxy looks the same. Authors? Response #2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Not if proxy ?A? does something with a given HTTP request and proxy ?B? doe= s something else. What we are talking here is interoperability between a C= oAP endpoint and an HTTP endpoint independently of the HC proxy that implem= ents the protocol mappings. For example, the mapping of CoAP Response code= s to HTTP Status codes to be done by the HC proxy can be subject to differe= nt interpretations unless some guidelines are given as in Table 2. We will= clarify this in the draft. ----------------------------------------------------------------- KH Comment #3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. "base URI" -- the term "base URI" has a well-defined meaning in the cont= ext of URI reference resolution (RFC 3986, Section 5). You're using it here= for something else, which is confusing. Please use a different term. Authors? Response #3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The term ?base (or context) URI? for the subject of the ?hosts? link relati= onship of with resource type ?core.hc? is correct. However, we will review= all the uses of ?base URI? in the draft because there might be inconsisten= cies. We will clarify this in the draft. ----------------------------------------------------------------- KH Comment #4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.2 "The default URI mapping function is RECOMMENDED to be implemented" -- = why? What happens when this requirement is ignored? Authors? Response #4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay. This is a key point that requires clarification in the current draft= . We will clarify that the whole section 5 is only for the special (option= al) case where a CoAP URI is embedded within the HTTP URI by the HTTP clien= t. The other case is when only a ?pure? HTTP URI is sent by the HTTP clien= t to the HC proxy, and the HC proxy itself generates the CoAP URI. In this= second case the whole section 5 is not required. Specifically, the case where the HTTP client embeds the CoAP URI info into = the HTTP URI as we describe in Section 5 will map implicitly to our 1st use= case in section 4. On the other hand, our 2nd use case in section 4 impli= es that the legacy application probably does not embed the CoAP URI info in= to the HTTP URI as it is legacy and was written without CoAP support. So i= n this case, section 5 does not imply but sections 6 and 7 do apply. We de= finitely need to clarify these different possible scenarios of "pure revers= e proxy" vs the other case of embedded CoAP URI info in the HTTP request. Please remember that the request for this type of feature was brought up in= the WG a long time ago ... "Standardize a workaround for HTTP library limitations in talking to= forward HTTP-COAP cross-proxies?" http://trac.tools.ietf.org/wg/core/trac/ticket/259 ----------------------------------------------------------------- KH Comment #5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.3 -- I don't understand this section. What is this? Why do we need this? = How is this different from the default mapping in Section 5.2? Who uses these templates, the client or the proxy? Authors? Response #5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay, we will explicitly state in the section that it applies to the client= . Please see London f2f discussion for the background on this at http://tools= .ietf.org/wg/core/minutes?item=3Dminutes-89-core.html (?Zach: on 'hct' link= parameter - could be more widely usable concept. URI templates are more ge= neral, so perhaps not define just for this I-D context? Could be in a separ= ate draft, or in a separate section that can be easily referenced from othe= r docs.?) We did the latter, adding a separate section for it. ----------------------------------------------------------------- KH Comment #6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define three a= dditional mappings, 5.3.2 seems to define yet another mapping. Section 1 says that one goal of the spec "is to reduce variation between pr= oxy implementations, thereby increasing interoperability". How does this multitude of mappings reduce variability? Authors? Response #6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Same as Response #5 (and in particular please go back to Zach's comment fro= m the London f2f meeting). ----------------------------------------------------------------- KH Comment #7: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.4 -- "to discover the proxy function, the HC proxy SHOULD publish informa= tion related to the location and syntax of the HC proxy function" -- the pr= oxy is a reverse proxy. It appears as an origin server to any client. Why d= oes the proxy function need to be discovered? Who are the "third parties"? Authors? Response #7: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As per our Response #4, we will clarify that the whole section 5 is only fo= r the special (optional) case where the HTTP client wishes to embed CoAP UR= I information into the overall HTTP URI. If this is not the case, then no = discovery needs to happen and the whole section 5 is not necessary. ----------------------------------------------------------------- KH Comment #8: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is abou= t discovering resources, 5.4.2 is about discovering the proxy function agai= n. This is confusing. Authors? Response #8: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay, you are right. We put 5.4.2 in the document quite recently to hint t= hat a co-located RD could provide resource discovery. Probably, it doesn't= really add much value. If it also potentially generates confusion, so we = will remove section 5.4.2 ----------------------------------------------------------------- KH Comment #9: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.4.2 "The first example exercises the CoAP interface" -- why does a CoAP c= lient need to discover a HTTP-CoAP proxy? Authors? Response #9: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The idea here is to support use case 1, i.e. ?Smartphone and home sensor?: = the smartphone discovers the public HC proxy before leaving the homenet and= then uses it from outside to query the homenet-attached sensors. We will = clarify this in the draft. ----------------------------------------------------------------- KH Comment #10: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6.5.2. -- to keep the illusion up that the proxy is an origin server, the p= roxy MUST rewrite _all_ URIs in _all_ representation formats, not just Link= Formats. This includes _all_ URIs generated on-the-fly by JavaScript code!= Unless the proxy has a very deep understanding of the application, this is= generally not possible. But a reverse proxy with a very deep understanding= of the application is unlikely to use any of the URI mapping schemes defin= ed in the document. So basically the whole Section 5 is useless. Authors? Response #10: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The recommendation in this section is to not fiddle with the payloads which= is a very sensible thing to do unless this is an application specific HC p= roxy. Also the ?MUST rewrite? argument is not correct: reverse proxies typ= ically do nothing with the response bodies, it?s just not their territory. ----------------------------------------------------------------- KH Comment #11: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6.5.3. "the CoAP diagnostic payload must be used as the HTTP reason-phrase = of the HTTP status line" -- a diagnostic payload is similar to the HTTP rea= son phrase, but it can be much more verbose and, e.g., can include CR-LF li= ne breaks. It's probably best to stick the diagnostic payload into the payl= oad and use the default reason phrase for the status code. Authors? Response #11: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay. This is a good observation: reason-phrase?s must not include CR-LF. = If diagnostic payloads do, the 1:1 mapping is not possible. We will clarif= y this in the draft. ----------------------------------------------------------------- KH Comment #12: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a change= to its request so that the proxy does not include the bad option in its Co= AP request? If not, the bad option is the proxy's fault (5xx status code) a= nd not the HTTP client's fault (4xx status code). Authors? Response #12: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay. This is a good observation as well. If the proxy has a way to deter= mine that the bad option is due to the straightforward mapping of a client = request header into a CoAP option, then the 400 is appropriate. Otherwise = we should probably return a 500, because the error is proxy?s ?fault? not b= eing able to translate the request appropriately. We will clarify this in = the draft. ----------------------------------------------------------------- KH Comment #13: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7. "The proxy receiving 2.03 updates the freshness of its cached representa= tion and returns the entire representation to the HTTP client." -- If the p= roxy receives a response indicating that the etag supplied by the HTTP clie= nt is valid, why does the proxy need to send the representation to the clie= nt? Authors? Response #13: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To clarify, the situation we are describing here is: - HTTP client makes an unconditional request for resource R; - HC proxy finds R in its cache but R is out of its ?freshness lifet= ime? as dictated by its max-age; - HC proxy thus makes a conditional request to check the validity of= the stored R; - CoAP server replies 2.03 confirming it?s still OK; - HC proxy sends the cached R to HTTP client. It?d be completely different (and similar to what you say) if the HTTP clie= nt had made a conditional request. We will clarify this in the draft. ----------------------------------------------------------------- KH Comment #14: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7. "If the HC proxy does not implement a proper authentication method that = can be used to gain access to the target CoAP resource, it can include a 'd= ummy' challenge for example "WWW-Authenticate: None"." -- if the proxy cann= ot gain access to the CoAP resource, it should probably return a 403 (Forbi= dden) status code to the HTTP client. Authors? Response #14: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ok. Good point. We will clarify this in the draft. ----------------------------------------------------------------- KH Comment #15: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase in th= e HTTP status line that starts with the string "405" in order to facilitate= troubleshooting." -- this leads to a status line like "HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may confuse imp= lementers. Authors? Response #15: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ok. Good point. There is a typo in Note 7 of Section 7: ?HTTP 400 (Method= Not Allowed)? should be ?HTTP 400 (Bad Request)?. You are right, the stat= us line is quite confusing. We will change it to something like ?CoAP serv= er returned 4.05? instead. We will clarify this in the draft. ----------------------------------------------------------------- KH Comment #16: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7. "The value of the HTTP "Retry-After" response-header field is taken from= the value of the CoAP Max-Age Option, if present." -- if the Max-Age Optio= n is not present, it means that the Max-Age is 60 seconds, not that the rep= resentation doesn't have a Max-Age. Authors? Response #16: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is just a straightforward mapping of Section 5.9.3.4. of RFC7252, whic= h decided to overload Max-Age to convey Retry-After semantics. Can you rew= ord what you are concerned about? ----------------------------------------------------------------- KH Comment #17: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers by res= ponding, where applicable, with a cached representation of the resource." -= - The proxy actually MUST perform congestion control as specified in RFC 72= 52. Caching is not about congestion control, it is about efficiency. So, as= a matter of quality of implementation, it is a good idea for a proxy to im= plement caching. But responding with a cached representation of the resourc= e is not a tool to enforce congestion control. Authors? Response #17: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay. Good point. We will clarify this in the draft. ----------------------------------------------------------------- KH Comment #18: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 8.1 "Duplicate idempotent pending requests by an HC proxy to the same CoAP = resource SHOULD in general be avoided, by using the same response for multi= ple requesting HTTP clients without duplicating the CoAP request." -- this = is not how caching in CoAP works. Please read RFC 7252. Authors? Response #18: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC 7252, Section 5.6. says ?endpoints MAY cache responses?. Here we are t= ightening up the requirement to a SHOULD for a specific class of CoAP endpo= ints (HC proxies). ----------------------------------------------------------------- KH Comment #19: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 8.1 "According to [RFC7252], a proxy MUST limit the number of outstanding i= nteractions to a given CoAP server to NSTART." -- this has already been spe= cified in RFC 7252. There is no need to repeat that here. Authors? Response #19: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Okay. We will change the ?MUST? to ?must? as per our Response #1. We will= clarify this in the draft. ----------------------------------------------------------------- KH Comment #20: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 9.2 -- have you submitted the registration to the media-types@ietf.org mail= ing list for review? It's probably a good idea to do this before sending th= e document to the IESG. Authors? Response #20: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Good point. We will do so shortly. ----------------------------------------------------------------- KH Comment #21: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Are there any implementations of this document? Authors? Response #21: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Yes, there are various open source implementations that we are aware of (to= various versions of this draft). ****************************************** That's all. Thanks again for all your good comments. /Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Klaus Hartke Sent: Monday, September 28, 2015 10:09 AM To: core@ietf.org WG Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 Here's my review of draft-ietf-core-http-mapping-07: Overall -- the document is 'Informational', but it makes a lot of use of re= quirement keywords (SHOULD, MUST, etc.). Do these keywords indicate conform= ance requirements? What happens if a proxy implementation ignores any of th= e requirements? Where do interoperability problems occur in this case? Plea= se review all occurrences of a requirement keywords in the document and ver= ify that is really necessary for interoperability. Explain what happens whe= n a proxy implementation fails to implement a requirement keyword. IMHO the= only requirement is really that the proxy MUST keep up the illusion that i= t is an HTTP origin server; everything else seems to be OPTIONAL to me. 1. "is to reduce variation between proxy implementations, thereby increasin= g interoperability" -- where do these interoperability problems occur? A HT= TP-CoAP cross-protocol reverse proxy appears as an origin server to the HTT= P client, so for the HTTP client any such proxy looks the same. 5. "base URI" -- the term "base URI" has a well-defined meaning in the cont= ext of URI reference resolution (RFC 3986, Section 5). You're using it here= for something else, which is confusing. Please use a different term. 5.2 "The default URI mapping function is RECOMMENDED to be implemented" -- = why? What happens when this requirement is ignored? 5.3 -- I don't understand this section. What is this? Why do we need this? = How is this different from the default mapping in Section 5.2? Who uses these templates, the client or the proxy? 5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define three a= dditional mappings, 5.3.2 seems to define yet another mapping. Section 1 says that one goal of the spec "is to reduce variation between pr= oxy implementations, thereby increasing interoperability". How does this multitude of mappings reduce variability? 5.4 -- "to discover the proxy function, the HC proxy SHOULD publish informa= tion related to the location and syntax of the HC proxy function" -- the pr= oxy is a reverse proxy. It appears as an origin server to any client. Why d= oes the proxy function need to be discovered? Who are the "third parties"? 5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is abou= t discovering resources, 5.4.2 is about discovering the proxy function agai= n. This is confusing. 5.4.2 "The first example exercises the CoAP interface" -- why does a CoAP c= lient need to discover a HTTP-CoAP proxy? 6.5.2. -- to keep the illusion up that the proxy is an origin server, the p= roxy MUST rewrite _all_ URIs in _all_ representation formats, not just Link= Formats. This includes _all_ URIs generated on-the-fly by JavaScript code!= Unless the proxy has a very deep understanding of the application, this is= generally not possible. But a reverse proxy with a very deep understanding= of the application is unlikely to use any of the URI mapping schemes defin= ed in the document. So basically the whole Section 5 is useless. 6.5.3. "the CoAP diagnostic payload must be used as the HTTP reason-phrase = of the HTTP status line" -- a diagnostic payload is similar to the HTTP rea= son phrase, but it can be much more verbose and, e.g., can include CR-LF li= ne breaks. It's probably best to stick the diagnostic payload into the payl= oad and use the default reason phrase for the status code. 7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a change= to its request so that the proxy does not include the bad option in its Co= AP request? If not, the bad option is the proxy's fault (5xx status code) a= nd not the HTTP client's fault (4xx status code). 7. "The proxy receiving 2.03 updates the freshness of its cached representa= tion and returns the entire representation to the HTTP client." -- If the p= roxy receives a response indicating that the etag supplied by the HTTP clie= nt is valid, why does the proxy need to send the representation to the clie= nt? 7. "If the HC proxy does not implement a proper authentication method that = can be used to gain access to the target CoAP resource, it can include a 'd= ummy' challenge for example "WWW-Authenticate: None"." -- if the proxy cann= ot gain access to the CoAP resource, it should probably return a 403 (Forbi= dden) status code to the HTTP client. 7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase in th= e HTTP status line that starts with the string "405" in order to facilitate= troubleshooting." -- this leads to a status line like "HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may confuse imp= lementers. 7. "The value of the HTTP "Retry-After" response-header field is taken from= the value of the CoAP Max-Age Option, if present." -- if the Max-Age Optio= n is not present, it means that the Max-Age is 60 seconds, not that the rep= resentation doesn't have a Max-Age. 8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers by res= ponding, where applicable, with a cached representation of the resource." -= - The proxy actually MUST perform congestion control as specified in RFC 72= 52. Caching is not about congestion control, it is about efficiency. So, as= a matter of quality of implementation, it is a good idea for a proxy to im= plement caching. But responding with a cached representation of the resourc= e is not a tool to enforce congestion control. 8.1 "Duplicate idempotent pending requests by an HC proxy to the same CoAP = resource SHOULD in general be avoided, by using the same response for multi= ple requesting HTTP clients without duplicating the CoAP request." -- this = is not how caching in CoAP works. Please read RFC 7252. 8.1 "According to [RFC7252], a proxy MUST limit the number of outstanding i= nteractions to a given CoAP server to NSTART." -- this has already been spe= cified in RFC 7252. There is no need to repeat that here. 9.2 -- have you submitted the registration to themedia-types@ietf.org maili= ng list for review? It's probably a good idea to do this before sending the= document to the IESG. Are there any implementations of this document? Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 8 23:56:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C0412DF3B; Tue, 8 Mar 2016 23:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m9qQCoL5IwL; Tue, 8 Mar 2016 23:56:31 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCA512DF49; Tue, 8 Mar 2016 23:56:30 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud2.xs4all.net with ESMTP id TjwV1s00m4QBLo201jwVUL; Wed, 09 Mar 2016 08:56:29 +0100 Received: from AMontpellier-654-1-113-50.w90-0.abo.wanadoo.fr ([90.0.128.50]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 09 Mar 2016 08:56:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Mar 2016 08:56:29 +0100 From: peter van der Stok To: Roll , Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20160309075354.6559.7145.idtracker@ietfa.amsl.com> References: <20160309075354.6559.7145.idtracker@ietfa.amsl.com> Message-ID: <0d9c836d62b57adf1f682dae57ef0f78@xs4all.nl> X-Sender: stokcons@xs4all.nl (5M9zp0EKI9UzOLpf79bbBlQAk8n1Sjb3) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-roll-mpl-yang-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 07:56:33 -0000 Dear all, A first version of the mpl yang model has been submitted to to roll. Please, ignore the version that I submitted by accident to core. Looking forward to your comments, peter A new version of I-D, draft-vanderstok-roll-mpl-yang-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-roll-mpl-yang Revision: 00 Title: A YANG model for Multicast Protocol for Low power and lossy Networks (MPL) Document date: 2016-03-08 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-roll-mpl-yang-00.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-roll-mpl-yang/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-roll-mpl-yang-00 Abstract: This document defines a YANG data model for management of Multicast Protocol for Low power and lossy Networks (MPL) implementations. The data model includes configuration data and state data. Note Discussion and suggestions for improvement are requested, and should be sent to roll@ietf.org. 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 Wed Mar 9 00:03:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9C612DE83 for ; Wed, 9 Mar 2016 00:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCwOjAW5lLMI for ; Wed, 9 Mar 2016 00:03:06 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7BE12DEDC for ; Wed, 9 Mar 2016 00:03:04 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud2.xs4all.net with ESMTP id Tk311s00t4QBLo201k31Ax; Wed, 09 Mar 2016 09:03:02 +0100 Received: from AMontpellier-654-1-113-50.w90-0.abo.wanadoo.fr ([90.0.128.50]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 09 Mar 2016 09:03:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Mar 2016 09:03:01 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> Message-ID: <61453504599048979219019bea41f248@xs4all.nl> X-Sender: stokcons@xs4all.nl (jXOzUPO7Y8DKiVSyy9A0HP1FUXQPPTsS) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 08:03:08 -0000 Hi Michel, see below Michel Veillette schreef op 2016-03-08 20:38: > Hi Peter. > > About "don't think so, why?" > > An update operation is not always idempotent. > For both examples, don't we have the following behaviour? > f(f("x-coord": 256) = f("x-coord": 256) = "x-coord": 45 and if I understand your notation: f(f("x-coord": 45) = f("x-coord": 45) = "x-coord": 45 showing that the replace op is idem-potent. Independent of the number of times that you execute it, the results is the same. > > First example: > PATCH CoAP://www.example.com/object Content-Type: > application/json-patch+json > [ { "op":"replace","path":"x-coord","value":45} ] > > Second example: > PATCH CoAP://www.example.com/object Content-Type: > application/merge-patch+json > { "x-coord" : 45 } > > So, should we replace the PATCH by an iPATCH? > I just trying to understand how this work. PATCH invocation do not need to be idem-potent but are allowed to be idem-potent. So both iPATCH and PATCH would be correct here. Do you have suggestions for clarifications? Do you think a non-idempotent example would help? > > Michel > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: March-08-16 3:17 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] Fwd: New Version Notification for > draft-vanderstok-core-comi-09.txt > > Hi Michel > > see below. > > Michel Veillette schreef op 2016-03-07 15:42: >> Hi Peter >> >> We are correctly in final review process of the mapping draft prior >> publishing. >> The current version is available at: >> https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-map >> ping-latest.html > >> pvds> will try >> >> If possible, send me your comments before Wednesday to give us some >> time to apply them. >> >> About "draft-vanderstok-core-patch-02", in the examples: >> - should "Content-Type" be replaced by "Content-Format" since it's a >> CoAP request? > > > good remark, In the coap RFC content-Type is used a few times, and > content-format mostly. > I will change > >> - should PATCH be replaced by "iPATCH" > > don't think so, why? > >> >> More globally, do we really need two methods "PATCH" and "iPATCH"? > > people like idem-potent as explained in earlier e_mail by Carsten > other people prefer more freedom by removing idem-potency restriction. > Both camps have valid arguments. > > >> If both methods are supported, should the client select to proper >> method per request or just on the potential for a method to sometime >> create non-idempotent requests? >> For example, should the client use iPATCH for a "replace" and PATCH >> for a "insert-after"? >> >> iPATCH CoAP://www.example.com/object >> Content-Type: application/json-patch+json >> [ >> { "op":"replace","path":"/x-coord","value":45} >> ] >> >> PATCH CoAP://www.example.com/object >> Content-Type: application/json-patch+json >> [ >> { "op":"insert-after", "insertion-point" : "/y-coord", >> "path":"/z-coord","value":45} >> ] > > My opinion: > Both iPATCH and Patch can be invoked. > When the content suggests a non-idem-potent update (like add an item > to an array) > - the Patch should execute the update > - and iPatch should return an error and do nothing (atomicity) >> >> Regards, >> Michel Veillette >> >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der >> Stok >> Sent: March-07-16 3:37 AM >> To: Core >> Subject: [core] Fwd: New Version Notification for >> draft-vanderstok-core-comi-09.txt >> >> Dear all, >> >> a New version of the comi draft has been submitted. >> >> - All yang hash text has been removed and the draft refers to >> bierman-core-yang-hash draft. draft refers to managed numbering. >> - All YANG to CBOR mapping has been removed, the draft waits for the >> publication of the yang-cbor draft >> - the draft lists all differences with restconf >> - rpc has been added. >> - and several other editorials. >> >> Peter >> >> -------- Oorspronkelijke bericht -------- >> Onderwerp: New Version Notification for >> draft-vanderstok-core-comi-09.txt >> Datum: 2016-03-07 09:30 >> Afzender: internet-drafts@ietf.org >> Ontvanger: "Peter van der Stok" , "Peter >> Van der Stok" , "Andy Bierman" >> >> >> A new version of I-D, draft-vanderstok-core-comi-09.txt has been >> successfully submitted by Peter van der Stok and posted to the IETF >> repository. >> >> Name: draft-vanderstok-core-comi >> Revision: 09 >> Title: CoAP Management Interface >> Document date: 2016-03-07 >> Group: Individual Submission >> Pages: 48 >> URL: >> https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.txt >> Status: >> https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >> Htmlized: >> https://tools.ietf.org/html/draft-vanderstok-core-comi-09 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-09 >> >> Abstract: >> This document describes a network management interface for >> constrained devices, called CoMI. CoMI is an adaptation of the >> RESTCONF protocol for use in constrained devices and networks. >> The >> Constrained Application Protocol (CoAP) is used to access >> management >> data resources specified in YANG, or SMIv2 converted to YANG. >> CoMI >> use the YANG to CBOR mapping and encodes YANG names to reduce >> payload >> size. >> >> Note >> >> Discussion and suggestions for improvement are requested, and >> should >> be sent to core@ietf.org. >> >> >> >> >> 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 >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 9 07:13:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEAA12D6EF for ; Wed, 9 Mar 2016 06:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47cdYgUYWydD for ; Wed, 9 Mar 2016 06:50:30 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868ED12DFEA for ; Wed, 9 Mar 2016 06:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bssyxLKfKKT09DNmYHmPDfGxRfTqnhTCNSOOL42hwP4=; b=KX8q5RkJmlI9YtxpPHegExeGYScHHoVlnrY3atetTBeZeoUUW0AqldPuwtW80Ic1OXmIfLf+rVbHz8seU1d+LgS4o1Ha3k614XXc2DJnLoIEOTS4C2KaW9/RoaTImYCE27G/3LXsZo2Da3fZ6sxZkJc6e8quQq9Po6XuRZSYogU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 14:43:58 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 14:43:58 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt Thread-Index: AdF4f34PcCdHLPqYQ0WUDYiqZ7ChJgAk1gcAABdsK9AAGmSxgAAN2HaQ Date: Wed, 9 Mar 2016 14:43:58 +0000 Message-ID: References: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> <61453504599048979219019bea41f248@xs4all.nl> In-Reply-To: <61453504599048979219019bea41f248@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 5eb8f5ba-cbb2-41fd-8a8d-08d348293f78 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:QRmCkHWEsq+iZSI3GJWH/lIAxwpQB42RgqAEx3WZkSXHUKYE1i+vntx7s3xumOpO31uaXsekjTD4xwIOmpxsIKEYYkhWQTJhoXKvoYJSNlbSXSoTbDUY2327raBg7eBuaDY4b9MAj9lyJ5YvLnHelg==; 24:5qn4W73iOKFjXCHbHes9aGpeKvRWCoWxCwsYt2HzR1f+USGDqvp8df5L0phtK667saAUHbIhdd/piOvrSX3k6txqEkKQuxWJJWw/Nz4ayV4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(2473001)(377454003)(76576001)(92566002)(3846002)(102836003)(6116002)(5002640100001)(1730700002)(586003)(11100500001)(5640700001)(110136002)(5008740100001)(74316001)(2501003)(3660700001)(15650500001)(5003600100002)(81166005)(86362001)(10400500002)(2351001)(33656002)(2950100001)(50986999)(77096005)(2900100001)(230783001)(19580405001)(93886004)(76176999)(189998001)(15975445007)(54356999)(19580395003)(87936001)(122556002)(1096002)(3280700002)(66066001)(5004730100002)(4326007)(2906002)(99286002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 14:43:58.2126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 14:50:33 -0000 Hi Peter You seem to agree that the replace operation uses in the two examples is id= empotent. "showing that the replace op is idem-potent" " Do you think a non-idempotent example would help?" In this case, why these examples use PATCH instead of iPATCH? I'm still confuse about this notion of PATCH vs. iPATCH. Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: March-09-16 3:03 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] Fwd: New Version Notification for draft-vanderstok-core= -comi-09.txt Hi Michel, see below Michel Veillette schreef op 2016-03-08 20:38: > Hi Peter. >=20 > About "don't think so, why?" >=20 > An update operation is not always idempotent. > For both examples, don't we have the following behaviour? > f(f("x-coord": 256) =3D f("x-coord": 256) =3D "x-coord": 45 and if I understand your notation: f(f("x-coord": 45) =3D f("x-coord": 45) =3D "x-coord": 45 showing that the replace op is idem-potent. Independent of the number of ti= mes that you execute it, the results is the same. >=20 > First example: > PATCH CoAP://www.example.com/object Content-Type:=20 > application/json-patch+json > [ { "op":"replace","path":"x-coord","value":45} ] >=20 > Second example: > PATCH CoAP://www.example.com/object Content-Type:=20 > application/merge-patch+json > { "x-coord" : 45 } >=20 > So, should we replace the PATCH by an iPATCH? > I just trying to understand how this work. PATCH invocation do not need to be idem-potent but are allowed to be idem-p= otent. So both iPATCH and PATCH would be correct here. Do you have suggestions for clarifications? Do you think a non-idempotent example would help? >=20 > Michel >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: March-08-16 3:17 AM > To: Michel Veillette > Cc: consultancy@vanderstok.org; Core > Subject: RE: [core] Fwd: New Version Notification for=20 > draft-vanderstok-core-comi-09.txt >=20 > Hi Michel >=20 > see below. >=20 > Michel Veillette schreef op 2016-03-07 15:42: >> Hi Peter >>=20 >> We are correctly in final review process of the mapping draft prior=20 >> publishing. >> The current version is available at: >> https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-ma >> p >> ping-latest.html >=20 >> pvds> will try >>=20 >> If possible, send me your comments before Wednesday to give us some=20 >> time to apply them. >>=20 >> About "draft-vanderstok-core-patch-02", in the examples: >> - should "Content-Type" be replaced by "Content-Format" since it's a=20 >> CoAP request? >=20 > > good remark, In the coap RFC content-Type is used a few times, and=20 > content-format mostly. > I will change > >> - should PATCH be replaced by "iPATCH" > > don't think so, why? > >>=20 >> More globally, do we really need two methods "PATCH" and "iPATCH"? > > people like idem-potent as explained in earlier e_mail by Carsten=20 > other people prefer more freedom by removing idem-potency restriction. > Both camps have valid arguments. > >=20 >> If both methods are supported, should the client select to proper=20 >> method per request or just on the potential for a method to sometime=20 >> create non-idempotent requests? >> For example, should the client use iPATCH for a "replace" and PATCH=20 >> for a "insert-after"? >>=20 >> iPATCH CoAP://www.example.com/object >> Content-Type: application/json-patch+json >> [ >> { "op":"replace","path":"/x-coord","value":45} >> ] >>=20 >> PATCH CoAP://www.example.com/object >> Content-Type: application/json-patch+json >> [ >> { "op":"insert-after", "insertion-point" : "/y-coord",=20 >> "path":"/z-coord","value":45} >> ] > > My opinion: > Both iPATCH and Patch can be invoked. > When the content suggests a non-idem-potent update (like add an item=20 > to an array) > - the Patch should execute the update > - and iPatch should return an error and do nothing (atomicity) >>=20 >> Regards, >> Michel Veillette >>=20 >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der=20 >> Stok >> Sent: March-07-16 3:37 AM >> To: Core >> Subject: [core] Fwd: New Version Notification for=20 >> draft-vanderstok-core-comi-09.txt >>=20 >> Dear all, >>=20 >> a New version of the comi draft has been submitted. >>=20 >> - All yang hash text has been removed and the draft refers to=20 >> bierman-core-yang-hash draft. draft refers to managed numbering. >> - All YANG to CBOR mapping has been removed, the draft waits for the=20 >> publication of the yang-cbor draft >> - the draft lists all differences with restconf >> - rpc has been added. >> - and several other editorials. >>=20 >> Peter >>=20 >> -------- Oorspronkelijke bericht -------- >> Onderwerp: New Version Notification for=20 >> draft-vanderstok-core-comi-09.txt >> Datum: 2016-03-07 09:30 >> Afzender: internet-drafts@ietf.org >> Ontvanger: "Peter van der Stok" , "Peter=20 >> Van der Stok" , "Andy Bierman" >> >>=20 >> A new version of I-D, draft-vanderstok-core-comi-09.txt has been=20 >> successfully submitted by Peter van der Stok and posted to the IETF=20 >> repository. >>=20 >> Name: draft-vanderstok-core-comi >> Revision: 09 >> Title: CoAP Management Interface >> Document date: 2016-03-07 >> Group: Individual Submission >> Pages: 48 >> URL: >> https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-09.tx >> t >> Status: >> https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >> Htmlized: >> https://tools.ietf.org/html/draft-vanderstok-core-comi-09 >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-vanderstok-core-comi-09 >>=20 >> Abstract: >> This document describes a network management interface for >> constrained devices, called CoMI. CoMI is an adaptation of the >> RESTCONF protocol for use in constrained devices and networks. =20 >> The >> Constrained Application Protocol (CoAP) is used to access=20 >> management >> data resources specified in YANG, or SMIv2 converted to YANG. =20 >> CoMI >> use the YANG to CBOR mapping and encodes YANG names to reduce=20 >> payload >> size. >>=20 >> Note >>=20 >> Discussion and suggestions for improvement are requested, and=20 >> should >> be sent to core@ietf.org. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 9 07:44:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D612E2AE for ; Wed, 9 Mar 2016 07:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCfBiDwCXy4z for ; Wed, 9 Mar 2016 07:43:28 -0800 (PST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2013112E10C for ; Wed, 9 Mar 2016 07:27:03 -0800 (PST) Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id AABFCFB8DB; Wed, 9 Mar 2016 16:27:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fbfWfdtJ99f6; Wed, 9 Mar 2016 16:26:59 +0100 (CET) X-Originating-IP: 134.102.91.57 Received: from eduroam-pool10-314.wlan.uni-bremen.de (eduroam-pool10-314.wlan.uni-bremen.de [134.102.91.57]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 54D55FB8FD; Wed, 9 Mar 2016 16:26:58 +0100 (CET) Message-ID: <56E040C0.9030203@tzi.org> Date: Wed, 09 Mar 2016 16:26:56 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michel Veillette References: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> <61453504599048979219019bea41f248@xs4all.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 15:43:33 -0000 I think the point is you can always use PATCH. Using iPATCH is a courtesy to the server, *if* the request is indeed idempotent. The "i" is just a bit that you can set, everything else stays the same. Grüße, Carsten Michel Veillette wrote: > I'm still confuse about this notion of PATCH vs. iPATCH. From nobody Wed Mar 9 08:01:11 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394C612DFDE for ; Wed, 9 Mar 2016 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-vxXks_WkVM for ; Wed, 9 Mar 2016 07:59:59 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D96712E1B6 for ; Wed, 9 Mar 2016 07:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aBYlrrPBtbiMPJnCIK7mpXF6eHnp/s8o055/Zwo2W8Y=; b=eOLVgdrmAjZwn8Jnc7fZMMKFNa8MrmGZvjFJcKIMj1p+uq6dn4tE55/mADxZ4Sq6k1dBH8J/s9c3mwEjoF6COGNw8ETK44MXUEUuYp4xqXO8e2bhTKVe6sjorF6UE0ZBXnLnopAmreeQtUwYK5mKB21Ml92zDNP4bXd36EzlZXU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 15:49:31 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 15:49:31 +0000 From: Michel Veillette To: Carsten Bormann Thread-Topic: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt Thread-Index: AdF4f34PcCdHLPqYQ0WUDYiqZ7ChJgAk1gcAABdsK9AAGmSxgAAN2HaQAAGodwAAAH2aIA== Date: Wed, 9 Mar 2016 15:49:31 +0000 Message-ID: References: <6b64abc32bfd7ca521a8ee3eb6377c43@xs4all.nl> <61453504599048979219019bea41f248@xs4all.nl> <56E040C0.9030203@tzi.org> In-Reply-To: <56E040C0.9030203@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: abee9e85-5f7f-4261-0da6-08d3483267fc x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:f3pNwgS/y51X0uruVZfoS43KqgHhWy4dzaOsMFtGqNdf116p/yg6xlPnM0uV0Kins91IyNc6Qnv66mFn8xsrrbWCn7/elqyOLJLvYqssc0Y9fkFxKugVGY6OBo/WxMR5ko1Ld51mfxgIththjdZFng==; 24:mwn/hnxYg26/4q9LX+dJtsitrMeBFWYug+CfzgZ/fqUoQugfMCBnEApUBHBptdkah4QOH8cFhSgGtoTyu3U4JiVHDVupOH35OpkklTYQMEg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(2473001)(51914003)(24454002)(13464003)(377454003)(99286002)(189998001)(54356999)(15650500001)(11100500001)(5003600100002)(110136002)(230783001)(1220700001)(1096002)(19580395003)(50986999)(19580405001)(92566002)(2900100001)(5004730100002)(2950100001)(5002640100001)(76176999)(93886004)(122556002)(5008740100001)(66066001)(3660700001)(87936001)(76576001)(2906002)(4326007)(102836003)(10400500002)(77096005)(6116002)(586003)(3846002)(33656002)(3280700002)(74316001)(86362001)(81166005)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 15:49:31.6226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Mar 2016 16:00:05 -0000 VGhhbmtzIGZvciB0aGUgYW5zd2VyIENhcnN0ZW4uDQoNCklkZW1wb3RlbnQgaXMgYW4gaW1wb3J0 YW50IGNvbmNlcHQgdG8gY29uc2lkZXIgd2hlbiBkZXNpZ25pbmcgYSBwcm90b2NvbC4NCkhvd2V2 ZXIsIEkgZG9uJ3QgdGhpbmdzIHRoaXMgc2VtYW50aWMgYXR0cmlidXRlIGp1c3RpZnkgYSBkaWZm ZXJlbnQgQ29BUCBtZXRob2QuDQpTdXBwb3J0aW5nIGJvdGggUEFUQ0ggYW5kIGlQQVRDSCBjYW4g YWxzbyBsZWFkIHRvIHNvbWUgY29uZnVzaW9uLg0KDQpKdXN0IHNoYXJpbmcgbXkgb3Bpbmlvbiwg SSdtIG5vdCB0cnlpbmcgdG8gaW1wb3NlIGEgc29sdXRpb24uDQoNClJlZ2FyZHMNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9A dHppLm9yZ10gDQpTZW50OiBNYXJjaC0wOS0xNiAxMDoyNyBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0 dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5jLmNvbT4NCkNjOiBjb25zdWx0YW5jeUB2 YW5kZXJzdG9rLm9yZzsgQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZhbmRlcnN0b2stY29yZS1j b21pLTA5LnR4dA0KDQpJIHRoaW5rIHRoZSBwb2ludCBpcyB5b3UgY2FuIGFsd2F5cyB1c2UgUEFU Q0guDQpVc2luZyBpUEFUQ0ggaXMgYSBjb3VydGVzeSB0byB0aGUgc2VydmVyLCAqaWYqIHRoZSBy ZXF1ZXN0IGlzIGluZGVlZCBpZGVtcG90ZW50LiAgVGhlICJpIiBpcyBqdXN0IGEgYml0IHRoYXQg eW91IGNhbiBzZXQsIGV2ZXJ5dGhpbmcgZWxzZSBzdGF5cyB0aGUgc2FtZS4NCg0KR3LDvMOfZSwg Q2Fyc3Rlbg0KDQoNCg0KTWljaGVsIFZlaWxsZXR0ZSB3cm90ZToNCj4gSSdtIHN0aWxsIGNvbmZ1 c2UgYWJvdXQgdGhpcyBub3Rpb24gb2YgUEFUQ0ggdnMuIGlQQVRDSC4NCg== From nobody Thu Mar 10 01:06:40 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E50C12D5CD for ; Thu, 10 Mar 2016 01:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aKYpxLh4gehe for ; Thu, 10 Mar 2016 01:06:37 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9C612D5CB for ; Thu, 10 Mar 2016 01:06:36 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud6.xs4all.net with ESMTP id U96Y1s0124d84Ai0196Yea; Thu, 10 Mar 2016 10:06:34 +0100 Received: from AMontpellier-654-1-113-50.w90-0.abo.wanadoo.fr ([90.0.128.50]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 10 Mar 2016 10:06:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 Mar 2016 10:06:32 +0100 From: peter van der Stok To: Core , Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> X-Sender: stokcons@xs4all.nl (npYuPsZ9G4pUFnWCs3IJtWYYSH9TvZGq) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 09:06:39 -0000 Hi Michel, I read through the provisional draft; and have a few high level remarks It is nice to see that you follow the same structure as in netmod-yang-json. The mapping from YANG name to string, I understand. The mappings of the SID and the hash pose me problems. The SID and and hash are both numbers, why not map them both to unsigned integer (major type 0)? The server does not care how these numbers are produced, it only needs to map the number to the memory locations in the server. I would also suggest that you add a section about mapping instances of lists. When you want memory reduction, the sending of a single instance of a list instead of a whole list may result in the saving of tens of bytes if not much more. Greetings, peter From nobody Thu Mar 10 01:32:56 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950F112D5D9 for ; Thu, 10 Mar 2016 01:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 GjWB5CnJ_z5j for ; Thu, 10 Mar 2016 01:32:53 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1FE12D617 for ; Thu, 10 Mar 2016 01:32:52 -0800 (PST) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E43B4A80DF; Thu, 10 Mar 2016 10:32:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lZzt36SE_206; Thu, 10 Mar 2016 10:32:49 +0100 (CET) X-Originating-IP: 93.204.214.47 Received: from nar.local (p5DCCD62F.dip0.t-ipconnect.de [93.204.214.47]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BAF8AA80E4; Thu, 10 Mar 2016 10:31:58 +0100 (CET) Message-ID: <56E13F0C.7020504@tzi.org> Date: Thu, 10 Mar 2016 10:31:56 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: consultancy@vanderstok.org References: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> In-Reply-To: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Mar 2016 09:32:55 -0000 Hi Peter, > The SID and and hash are both numbers, why not map them both to unsigned > integer (major type 0)? SIDs benefit from compression by delta encoding (turning them into signed integers in the actual delta). Delta encoding does not make sense for hashes (just spreads the numbers further out). So it is useful to be able to *distinguish* the two, specifically before the delta encoding kicks in. One way that came up for this in discussions about how to best use CBOR for YANG data representation is to represent the hashes as binary strings. E.g., if the hash value is 1234567890, what might have been 1a 499602d2 # unsigned(1234567890) becomes h'499602d2' or 44 # bytes(4) 499602d2 # "I\x96\x02\xD2" Since hashes are evenly distributed in the 30-bit space, there is no change in the number of bytes needed (except maybe for the p = 1/16384 case that the hash happens to be < 65536). With this way of distinguishing identifiers, in the end, we can have a mapping of CBOR data types to identifiers: CBOR type meaning integer delta encoded SID byte string hash text string native YANG identifier (It is then a matter of design and/or deployment which of these kinds of identifiers are actually used in a specific instance.) > The server does not care how these numbers are produced, it only needs > to map the number to the memory locations in the server. Exactly. Grüße, Carsten From nobody Thu Mar 10 01:52:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483D512D63C for ; Thu, 10 Mar 2016 01:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CdOp4mF0710K for ; Thu, 10 Mar 2016 01:52:45 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A912712D643 for ; Thu, 10 Mar 2016 01:52:42 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud6.xs4all.net with ESMTP id U9sg1s0164d84Ai019sgwW; Thu, 10 Mar 2016 10:52:40 +0100 Received: from AMontpellier-654-1-113-50.w90-0.abo.wanadoo.fr ([90.0.128.50]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 10 Mar 2016 10:52:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 10 Mar 2016 10:52:40 +0100 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <56E13F0C.7020504@tzi.org> References: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> <56E13F0C.7020504@tzi.org> Message-ID: <595bb409b727e8fb26bdc5d0bae86d47@xs4all.nl> X-Sender: stokcons@xs4all.nl (9hlKXRAfPXdINAbY/lkJJCbE0hLIMHNf) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 09:52:47 -0000 Hi Carsten, thanks, see below. Carsten Bormann schreef op 2016-03-10 10:31: > Hi Peter, > >> The SID and and hash are both numbers, why not map them both to >> unsigned >> integer (major type 0)? > > SIDs benefit from compression by delta encoding (turning them into > signed integers in the actual delta). > Delta encoding does not make sense for hashes (just spreads the numbers > further out). > So it is useful to be able to *distinguish* the two, specifically > before > the delta encoding kicks in. > > One way that came up for this in discussions about how to best use CBOR > for YANG data representation is to represent the hashes as binary > strings. E.g., if the hash value is 1234567890, what might have been > > 1a 499602d2 # unsigned(1234567890) > > becomes h'499602d2' or > > 44 # bytes(4) > 499602d2 # "I\x96\x02\xD2" Is misinterpreted this in the draft as a rather long "character" string thanks for the explanation > > Since hashes are evenly distributed in the 30-bit space, there is no > change in the number of bytes needed (except maybe for the p = 1/16384 > case that the hash happens to be < 65536). > > With this way of distinguishing identifiers, in the end, we can have a > mapping of CBOR data types to identifiers: > > CBOR type meaning > integer delta encoded SID > byte string hash > text string native YANG identifier like the table > > (It is then a matter of design and/or deployment which of these kinds > of > identifiers are actually used in a specific instance.) > >> The server does not care how these numbers are produced, it only needs >> to map the number to the memory locations in the server. > > Exactly. > > Grüße, Carsten From nobody Thu Mar 10 07:15:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C112D8D1 for ; Thu, 10 Mar 2016 07:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8U9gYtcE82Zu for ; Thu, 10 Mar 2016 07:15:22 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7567E12D99A for ; Thu, 10 Mar 2016 07:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BgZYul51MMRAWvaxvIL+Ke33TXX06Tb64AfB5BKLC9U=; b=RPom0l9lyR2ttvkucbs5P67lIO668aqmeWafblAr05LVmMEKu1zUiQCSatTMyuJyb8l7BWxT5+8Zq3ZQa/+YoWpYkkOq9b/urtpBRVjKui5YmFbonwgwBLw1jEJrfYZJG413XPC5nCqiifAy3ThZF3xqP1ea631OE0B/xWv2hYo= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (TLS) id 15.1.427.16; Thu, 10 Mar 2016 15:07:46 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0427.020; Thu, 10 Mar 2016 15:07:47 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: YANG to CBOR mapping Thread-Index: AQHReqwpv4GV3DdT0UCv7zUIvxJWyp9SwChA Date: Thu, 10 Mar 2016 15:07:46 +0000 Message-ID: References: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> In-Reply-To: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: 2d74bc76-b1e7-4cf4-bc56-08d348f5bd5b x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:Qou92OMDxxMsM1Un+51ImreOjF7AyIVVnkDcJg6ft1QJCRuVbkzdUW0piJxn36S69G4EzMxrsV2uVp58cmxMVtydsFhQKaAvAdpgs7WkAaqQIvVY5ay1EYusQcjphqOVtAVPv7DykjSD8vJP8oa28w==; 24:EEL/ISUz3C2OPfMthKL4YwIT9o2PTe+xWDqxhdMxjAalpohccnCD5Hfead7cfL7ek8vYSjAlppuPJvh1VqAXN3wa8mx2U3UATkpWltvS5Z0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 08770259B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(3480700003)(3660700001)(3280700002)(81166005)(66066001)(10400500002)(2950100001)(15395725005)(2900100001)(102836003)(3846002)(6116002)(106116001)(1096002)(99286002)(1220700001)(586003)(33656002)(5640700001)(87936001)(1730700002)(5004730100002)(74316001)(2501003)(76576001)(4326007)(5008740100001)(2906002)(2351001)(86362001)(92566002)(19580395003)(19580405001)(54356999)(122556002)(15975445007)(5002640100001)(76176999)(77096005)(110136002)(189998001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2016 15:07:46.7183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Mar 2016 15:15:24 -0000 Hi Peter =3D=3D=3D About the octet string I agree that the use of byte string for the hash is slightly disturbing sin= ce all the previous works have been done with integers. The rational is to use a different CBOR type for the three type of naming (= string, octet string, integer). A collateral advantage of using the octet string is that you can now uses t= he diagnostic notation with hexadecimal digits (e.g h'334c67d9') which is s= upported by [RFC7049] and tools like http://cbor.me/ . =3D=3D=3D About list instance On the identification side of list instance, I thinks this is fully documen= ted in section (https://core-wg.github.io/yang-cbor/draft-veillette-core-ya= ng-cbor-mapping-latest.html#rfc.section.5.13) and the third example in this= section address specifically this topic. On the encoding side, we mention list instances in section (https://core-wg= .github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-latest.html#rfc= .section.4.2)=20 "Collections such as containers, list instances, notifications, RPC inputs,= RPC outputs, action inputs and action outputs MUST be encoded using a CBOR= map data item (major type 5)." However, we don't have a specific example. This is the case also for notifications, RPC inputs, RPC outputs, action in= puts and action outputs. However, we have these examples in CoOL and in CoMI. Is it sufficient? Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: March-10-16 4:07 AM To: Core ; Michel Veillette Subject: YANG to CBOR mapping Hi Michel, I read through the provisional draft; and have a few high level remarks It is nice to see that you follow the same structure as in netmod-yang-json= . The mapping from YANG name to string, I understand. The mappings of the SID and the hash pose me problems. The SID and and hash are both numbers, why not map them both to unsigned in= teger (major type 0)? The server does not care how these numbers are produced, it only needs to m= ap the number to the memory locations in the server. I would also suggest that you add a section about mapping instances of list= s. When you want memory reduction, the sending of a single instance of a list = instead of a whole list may result in the saving of tens of bytes if not mu= ch more. Greetings, peter From nobody Fri Mar 11 22:55:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E60712DAF2; Fri, 11 Mar 2016 22:55:07 -0800 (PST) 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_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 jZALcRwo5nZg; Fri, 11 Mar 2016 22:55:04 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD72E12D511; Fri, 11 Mar 2016 22:55:04 -0800 (PST) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 7EFF4C5A4E; Sat, 12 Mar 2016 07:55:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id hMe2WwyJbewK; Sat, 12 Mar 2016 07:55:01 +0100 (CET) X-Originating-IP: 93.204.214.47 Received: from nar.local (p5DCCD62F.dip0.t-ipconnect.de [93.204.214.47]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 61C27C5A4F; Sat, 12 Mar 2016 07:54:50 +0100 (CET) Message-ID: <56E3BD3B.7050606@tzi.org> Date: Sat, 12 Mar 2016 07:54:51 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "ace@ietf.org" , "core@ietf.org WG" , "cose@ietf.org" , "dtls-iot@ietf.org" , "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF95: Final agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Mar 2016 06:55:07 -0000 Here is my usual eclectic condensed agenda based on the "final" agenda for IETF95. Compared to the draft agenda, this mostly has room changes and small adjustments to the session timings. (Also, taps is now on top of ace and httpbis is on top of cose.) Wednesday is still constrained-free, as are Tuesday and Thursday morning; time to go to, say, tls, homenet, oauth, saag. Remember that late changes still can happen. All times are ART (UTC-0300), which is the same as New Brunswick or Bermuda daylight savings time (ADT) (the browser timezone function is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote). Grüße, Carsten MONDAY, April 4, 2016 1000-1230 Morning Session I Atlantico C SEC *** ace Authentication and Authorization for Constrained Environments WG Buen Ayre B SEC tokbind Token Binding WG Buen Ayre A TSV taps Transport Services WG 1400-1530 Afternoon Session I Atlantico C ART uta Using TLS in Applications WG Buen Ayre B INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Buen Ayre C OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Atlantico B ART httpbis Hypertext Transfer Protocol WG Buen Ayre B INT dnssd Extensions for Scalable DNS Service Discovery WG Pacifico A IRTF maprg Proposed Measurement and Analysis for Protocols Research Group Buen Ayre C RTG babel Babel routing protocol BOF Quebracho B SEC *** cose CBOR Object Signing and Encryption WG 1740-1940 Afternoon Session III Quebracho B ART webpush Web-Based Push Notifications WG Buen Ayre C INT *** lpwan Low-Power Wide Area Networks BOF Buen Ayre B OPS anima Autonomic Networking Integrated Model and Approach WG Buen Ayre A SEC acme Automated Certificate Management Environment WG TUESDAY, April 5, 2016 1000-1230 Morning Session I Atlantico C INT arcing Alternative Resolution Contexts for Internet Naming BOF Buen Ayre C OPS v6ops IPv6 Operations WG Buen Ayre A RTG detnet Deterministic Networking WG Atlantico B SEC tls Transport Layer Security WG 1400-1600 Afternoon Session I Pacifico A INT homenet Home Networking WG Atlantico C SEC lurk Limited Use of Remote Keys BOF Buen Ayre B TSV tsvwg Transport Area Working Group WG 1620-1720 Afternoon Session II Buen Ayre C INT intarea Internet Area Working Group WG Quebracho B RTG *** roll Routing Over Low power and Lossy networks WG Buen Ayre B SEC curdle CURves, Deprecating and a Little more Encryption WG 1740-1910 Afternoon Session III Buen Ayre B ART *** core Constrained RESTful Environments WG Pacifico A TSV tsvarea Transport Area Open Meeting WEDNESDAY, April 6, 2016 1000-1230 Morning Session I Buen Ayre C INT 6man IPv6 Maintenance WG Buen Ayre B SEC oauth Web Authorization Protocol WG Atlantico C SEC openpgp Open Specification for Pretty Good Privacy WG - 11:00 - 12:30 Atlantico B TSV rmcat RTP Media Congestion Avoidance Techniques WG 1400-1600 Afternoon Session I Buen Ayre C INT its Intelligent Transportation Systems BOF Quebracho B RTG bier Bit Indexed Explicit Replication WG 1620-1720 Afternoon Session II Atlantico C RTG rtgarea Routing Area Open Meeting Buen Ayre B SEC httpauth Hypertext Transfer Protocol Authentication WG Buen Ayre A TSV tsvwg Transport Area Working Group WG THURSDAY, April 7, 2016 1000-1230 Morning Session I Atlantico C SEC tls Transport Layer Security WG Pacifico A TSV accord Alternatives to Content Classification for Operator Resource Deployment BOF 1400-1600 Afternoon Session I Buen Ayre A ART ice Interactive Connectivity Establishment WG Pacifico A SEC saag Security Area Open Meeting 1620-1720 Afternoon Session II Buen Ayre C IRTF*** t2trg Thing-to-Thing Atlantico C OPS anima Autonomic Networking Integrated Model and Approach WG 1730-1930 Afternoon Session III Atlantico C ART httpbis Hypertext Transfer Protocol WG Pacifico A INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Buen Ayre C TSV tcpinc TCP Increased Security WG FRIDAY, April 8, 2016 1000-1200 Morning Session I Buen Ayre B ART *** core Constrained RESTful Environments WG Buen Ayre A IRTF cfrg Crypto Forum From nobody Sat Mar 12 08:21:10 2016 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 ED09512DDD7; Fri, 11 Mar 2016 15:05:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230529.15028.87529.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:29 -0800 Archived-At: X-Mailman-Approved-At: Sat, 12 Mar 2016 08:21:08 -0800 Cc: barryleiba@computer.org, core@ietf.org Subject: [core] core - Requested sessions have been scheduled for IETF 95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:30 -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:00) Tuesday, Afternoon Session III 1740-1910 Room Name: Buen Ayre B size: 125 --------------------------------------------- core Session 2 (2:00:00) Friday, Morning Session I 1000-1200 Room Name: Buen Ayre B size: 125 --------------------------------------------- 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, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6lo roll lwig appsawg tsvwg tcpm aqm ace jose cose t2trg Second Priority: 6man saag 6tisch dnssd netconf Third Priority: v6ops opsarea cfrg Special Requests: Prfrbly (pri 2), ≥ 1 of the 2 mtgs wth no cnflct in: "tls oauth jose uta" Pls avd othr IoT rltd BOFs tht mght cm up, sch as lpwan or its. *Prfrrd* pairing: Tue/Thu spce btwn Fri psbl. --------------------------------------------------------- From nobody Mon Mar 14 01:41:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DA612D510 for ; Mon, 14 Mar 2016 01:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LMC7LP0iyTDs for ; Mon, 14 Mar 2016 01:41:34 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E45212D568 for ; Mon, 14 Mar 2016 01:41:33 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.207]) by smtp-cloud6.xs4all.net with ESMTP id VkhW1s00k4U4Moq01khWSJ; Mon, 14 Mar 2016 09:41:31 +0100 Received: from 2001:983:a264:1:fda7:a70a:f49:c4e3 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 14 Mar 2016 09:41:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 Mar 2016 09:41:30 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (ITflUy2ZrLHhQHrvKDpSXckKtLHJDnfY) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 08:41:37 -0000 Hi Michel I'm confused about the answers below. > === About list instance > > On the identification side of list instance, I thinks this is fully > documented in section > (https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-latest.html#rfc.section.5.13) > and the third example in this section address specifically this topic. This section is about the "instance-identifier" not about the instance. > > On the encoding side, we mention list instances in section > (https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-latest.html#rfc.section.4.2) > "Collections such as containers, list instances, notifications, RPC > inputs, RPC outputs, action inputs and action outputs MUST be encoded > using a CBOR map data item (major type 5)." This section is about lists without keys. My suggestion is to create a section that describes the encoding of list instances (multiple instances) identified with key values. I prefer to have that subject handled here, so it is not exclusively comi speak, but for example can be used also for restconf. Greetings, Peter From nobody Mon Mar 14 07:54:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91E312DB87 for ; Mon, 14 Mar 2016 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 FGQIyHpyoroP for ; Mon, 14 Mar 2016 07:53:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::757]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942FE12DBA6 for ; Mon, 14 Mar 2016 07:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+zPfc5d+zGvqJR02CweT02tsB9mIaofCcubhXnwRtwk=; b=AeP1uS/ajUwszysS25iuaRsFsH2ps7i1oAVCkx51gAqgpTtmA6o0deSae/pm2k+J+C7VTrRQOHik/35xfIuMM+g+i5oNC351mCbVJTzh8oYjeUEq6pTKWW6G8rAHLeFCiq8OH1Ccgoznrtb+pAqaJXBz5yRtdGb/mNtcRaA4gzw= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 14 Mar 2016 14:48:11 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0434.016; Mon, 14 Mar 2016 14:48:11 +0000 From: Michel Veillette To: Core Thread-Topic: New CoOL drafts available Thread-Index: AdF+AEtW1C8D4FStShK6mATouApnmg== Date: Mon, 14 Mar 2016 14:48:11 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 270dff6e-2f08-4095-357e-08d34c17aa65 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:tXmP2ph2BMB1Z62gUS4Y0BGzL89Mz2qkm7eZ1xyg0ZttekaZTckJYTI7MIWnjZmXFqubDOf4z71HpawXmzykcA4QYZuIQ91cKhtGImToZ2SnpesdnoiPAGSu+RxIlkVLxdLpWhd54Hkx6jsxPZDA9g==; 24:/4Zywe/icS9PfPAABeBPngIPXT3OQtwFyibl4QHcsHG4gHVAOgBtyolmvpbQNJCacrGqysHDLebBMZ4Vb3r+0wJJodIPwHYUsoa+Z9QRxRM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0881A7A935 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(99286002)(2900100001)(110136002)(107886002)(81166005)(74316001)(229853001)(77096005)(5008740100001)(3480700003)(189998001)(2906002)(19580395003)(5003600100002)(15975445007)(5002640100001)(10400500002)(3280700002)(92566002)(66066001)(3660700001)(6116002)(102836003)(3846002)(1220700001)(1096002)(86362001)(87936001)(586003)(76576001)(54356999)(450100001)(50986999)(5004730100002)(11100500001)(33656002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2016 14:48:11.4739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Subject: [core] New CoOL drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Mar 2016 14:53:54 -0000 The following drafts related to the CoOL protocol have been released last w= eek. https://datatracker.ietf.org/doc/draft-turner-core-cool-problem-statement/ https://datatracker.ietf.org/doc/draft-somaraju-core-sid/=20 https://datatracker.ietf.org/doc/draft-veillette-core-yang-cbor-mapping/=20 https://datatracker.ietf.org/doc/draft-veillette-core-cool/ A pyang plugin is also available to generate or update the identifiers used= to CoOL (SID). https://github.com/lemikev/pyang/blob/master/pyang/plugins/sid.py Comments on these drafts are welcome. Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109 From nobody Mon Mar 14 08:48:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF912DB2C for ; Mon, 14 Mar 2016 08:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Y26jlBRJqJfA for ; Mon, 14 Mar 2016 08:48:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B11E12DCE1 for ; Mon, 14 Mar 2016 08:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y6vQCrBtfFN1YCgTq42pLUfZhyhfXnuimbJupNojRII=; b=xBJMvo0dypAHeEW2n+Y0S4V3kQB6pb8OQPMw1CqPdZjYritAHIn5z7Dy4QZZ9uHy0KjNe3XFcTKz7uCGepaGlAYSiGh9kQDIfIuanquCi9BwUBZe0xfnDi6gva3cIhO1E6fVmUjyFXOuO9tDWZB+k/gcYDNkJ8vAgsLltQXksS4= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 14 Mar 2016 15:42:51 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0434.016; Mon, 14 Mar 2016 15:42:51 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: YANG to CBOR mapping Thread-Index: AQHReqwpv4GV3DdT0UCv7zUIvxJWyp9SwChAgAXlGwCAAGiLsA== Date: Mon, 14 Mar 2016 15:42:51 +0000 Message-ID: References: <125ea14670116bd8cbc275a2b1b011f9@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 571b7d23-926d-4032-3186-08d34c1f4d6e x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:3JXICsfasispYmWu42DIkWsc1pdst+656EDpF1GiJZU5X0+j3nKUoohcLsUNtgwjTAUW0tMAhKK733eJKT6WqMnqXwAHbog1ly0HX9TNuWnLjbqSDYuAyhWVhXEz3hw1dCVP2zpUrfWftw5iZ4lEDA==; 24:vvJMHKkkgPNJKHOJThJYuYRqGByWgeZEBOy/gUE9Hswc3ZJ35tUYal7yMzyVsWJeYkaHH4lNI0EpjmIWozOVuYJiLpmOUzh3Q+32LubNxe0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0881A7A935 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(2501003)(81166005)(586003)(5003600100002)(76576001)(6116002)(3846002)(102836003)(74316001)(5002640100001)(86362001)(15975445007)(2950100001)(2900100001)(77096005)(110136002)(5640700001)(10400500002)(54356999)(50986999)(76176999)(99286002)(2351001)(2906002)(3480700003)(3280700002)(106116001)(3660700001)(5004730100002)(87936001)(1730700002)(1096002)(1220700001)(33656002)(4326007)(66066001)(189998001)(19580395003)(19580405001)(122556002)(5008740100001)(92566002)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2016 15:42:51.3948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Mar 2016 15:48:28 -0000 Hi Peter List instances are defined in section 7.8 of RFC 6020, I-D.ietf-netmod-rfc6= 020bis-09. (https://tools.ietf.org/html/rfc6020#section-7.8.3.1)=20 For example, the following definition: list server { key "name"; unique "ip port"; leaf name { type string; } leaf ip { type inet:ip-address; } leaf port { type inet:port-number; } } Is encoded in xml as: smtp 192.0.2.1 25 In draft-ietf-netmod-yang-json, the encoding of a list instance in JSON is = defined in section 5.4. (https://tools.ietf.org/html/draft-ietf-netmod-yang-json-09#section-5.4)=20 "A list instance is encoded as a name/array pair, and the array elements ar= e JSON objects." For the above example, the JSON encoding is: { "name" : "smtp", "ip" : "192.0.2.1", "port" : 25 } I-D.veillette-core-yang-cbor-mapping use the same approach in section 4.4 a= nd propose a CBOR map. (https://tools.ietf.org/html/draft-veillette-core-yang-cbor-mapping-00#sect= ion-4.4) For the above example, the CBOR encoding is: * For name* Diagnostic notation: { "name" : "smtp", "ip" : "192.0.2.1", "port" : 25 } CBOR encoding (31 bytes): a3 64 6e616d65 64 =20 736d7470 62 6970=20 69 3139322e302e322e31 64 706f7274 18 19 * For YANG hashes* Assuming: - YANG hash of "/unknown-module:server/name" =3D h'0e99676c' - YANG hash of "/unknown-module:server/ip" =3D h'2aa29479' - YANG hash of "/unknown-module:server/port" =3D h'30f67b93' Diagnostic notation: { h'0e99676c' : "smtp", h'2aa29479' : "192.0.2.1", h'30f67b93' : 25 } CBOR encoding (33 byte): a3 44=20 0e99676c 64 736d7470 44 2aa29479 69 3139322e302e322e31 44 30f67b93 18 19 * For SID * Assuming: - SID of "/unknown-module:server/name" =3D 1576 - SID of "/unknown-module:server/ip" =3D 1577 - SID of "/unknown-module:server/port" =3D 1578 Diagnostic notation: { 1576 : "smtp", 1577 : "192.0.2.1", 1578 : 25 } CBOR encoding (27 byte): a3 19 0628 64 736d7470 19 0629 69 3139322e302e322e31 19 062a 18 19 * For SID delta * Diagnostic notation: { 1 : "smtp", 2 : "192.0.2.1", 3 : 25 } CBOR encoding (21 byte): a3 01 64 736d7470 02 69 3139322e302e322e31 03 18 19 I understand that CoMI introduces a new approach to encode List instances which add metadata to identify which data nodes are keys and which ones are associated data. For the XML and JSON encoding, it seems too late to change the way list instances are encoded. For the CBOR encoding, adding metadata will be in contradiction with the "Properties of the CBOR Encoding" as defi= ned in section 3 (https://tools.ietf.org/html/draft-veillette-core-yang-cbor-mapping-00#sect= ion-3). "In order to minimize the size of the encoded data, the proposed mapping does not make use of any meta-information beyond those natively supported by CBOR." If this assumption in not what you had in mind, please clarify. Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: March-14-16 4:42 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: YANG to CBOR mapping Hi Michel I'm confused about the answers below. > =3D=3D=3D About list instance >=20 > On the identification side of list instance, I thinks this is fully=20 > documented in section > (https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-ma > pping-latest.html#rfc.section.5.13) > and the third example in this section address specifically this topic. This section is about the "instance-identifier" not about the instance. >=20 > On the encoding side, we mention list instances in section > (https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-ma > pping-latest.html#rfc.section.4.2) > "Collections such as containers, list instances, notifications, RPC=20 > inputs, RPC outputs, action inputs and action outputs MUST be encoded=20 > using a CBOR map data item (major type 5)." This section is about lists without keys. My suggestion is to create a section that describes the encoding of list in= stances (multiple instances) identified with key values. I prefer to have that subject handled here, so it is not exclusively comi s= peak, but for example can be used also for restconf. Greetings, Peter From nobody Tue Mar 15 01:17:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5095A12D95D for ; Tue, 15 Mar 2016 01:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 6QHpES6aZ4Nd for ; Tue, 15 Mar 2016 01:17:17 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA5012D95F for ; Tue, 15 Mar 2016 01:17:13 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.215]) by smtp-cloud6.xs4all.net with ESMTP id W8HA1s00k4eRkWy018HA0z; Tue, 15 Mar 2016 09:17:10 +0100 Received: from 2001:983:a264:1:f81e:2ed9:20e0:e47e by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 15 Mar 2016 09:17:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 15 Mar 2016 09:17:10 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20160315081458.30604.29046.idtracker@ietfa.amsl.com> References: <20160315081458.30604.29046.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (owkDV1Wagfjr7N85Y4AAC7Z0RkxFtSYU) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-patch-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 08:17:20 -0000 Hi all, a new draft of patch has been submitted. The modifications are minor: - added line about default values - content-Type to content_Format - extended Patch example with non-idempotent request Greetings, Peter A new version of I-D, draft-vanderstok-core-patch-03.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-patch Revision: 03 Title: Patch Method for Constrained Application Protocol (CoAP) Document date: 2016-03-15 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-core-patch-03.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-patch/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-patch-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-patch-03 Abstract: The existing Constrained Application Protocol (CoAP) PUT method only allows a complete replacement of a resource. This does not permit applications to perform partial resource modifications. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing a resource is not an option. Several applications using CoAP will need to perform partial resource modifications. This proposal adds new CoAP methods, PATCH and iPATCH, to modify an existing CoAP resource partially. 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 Mar 15 11:54:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D692012D67E; Tue, 15 Mar 2016 11:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 I1c6Qfs8anzz; Tue, 15 Mar 2016 11:54:38 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA1412D67C; Tue, 15 Mar 2016 11:54:38 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m184so35704772iof.1; Tue, 15 Mar 2016 11:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=zebQzLIJsIU3qQFkyUbFAJ8ouP1/Wks67KnFYUAMok4=; b=D8f6dIsRf8dmtjJ4LfyFoc5PmJZQ8G/ARfbS/m8Drl3HVF29tW0g4KY2nHxQKRPvVW wsAGOK8GfXkF0ho0bgb/sV/uE7JCHu5psHhjmtQ+aq2V66fqUR9wHq1YE0B2YpbGUWfV KiIKzaDFeH2IVbBSHQABd4mOW78D/gZQBipDY9cyi3aa4EzFUIRp2zfgIUjNFFWFq0nk /PRCOM1mDl9O5eCjimNZ2jt23NhjTJYdUv/YIkBn1cBIppYiEHG3tTNr+/RjQR763wvX iZTmjhLLr4/TaslYllxxGijCcM6m+EG7y0oq1g+T9OuJcvK5qVU78L530Y5h7KkAL/x4 OHrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=zebQzLIJsIU3qQFkyUbFAJ8ouP1/Wks67KnFYUAMok4=; b=ej52iOHPX+JA54S+H2dAX1O1aF0fiuylMah27FWCejKtmN3SXn0noiwybakzoH8LNa efHOpDTWucPvhV467WuKpW8QyLOEp1H2VX98kHNLezHTtyGl6hpT9WvTTbMdhnKW9zFJ PHmy0LnpHKwlrjWfVw68K7p2kRnIK9mIpt31iNgyDKRd1jwIE+j9gK8OrqwqOk1KJcBX RBjOwnS5cedLNEeRD0VukvSNXr3uuvhrT4YfGC3l6cQce8G8K8jgRcdRDpx5dVwkx+sS ZrGF30nzvXpTwdQ4ajYnrx/8poi+EPQ57gm12gN6piVU8kcIqzvPh1aUOYRDDk8dzYPn gGfw== X-Gm-Message-State: AD7BkJIxCKBUkDpb+2FFpPXM3P56X4dKcv6anqGDDP9UPhqVOMIIAOoPrg+Rs8XAQga0F3FrxCWwCLqTrKDsXQ== MIME-Version: 1.0 X-Received: by 10.107.134.165 with SMTP id q37mr256708ioi.41.1458068077658; Tue, 15 Mar 2016 11:54:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.15.139 with HTTP; Tue, 15 Mar 2016 11:54:37 -0700 (PDT) In-Reply-To: References: <20151020210304.27062.87223.idtracker@ietfa.amsl.com> <5626AE89.70305@tzi.org> <56289F96.1090608@cisco.com> <56AE324E.2010403@tzi.org> <56B35790.2090406@cisco.com> Date: Tue, 15 Mar 2016 18:54:37 +0000 X-Google-Sender-Auth: eeRAiYBkat9C-S1tcBRnlGv_2EE Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" Subject: Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Mar 2016 18:54:42 -0000 Beno=C3=AEt, this is still on your queue. Can you check this right away, please? Thanks. Barry On Thu, Feb 4, 2016 at 1:59 PM, Barry Leiba wrote= : >> Can we please use the tool >> (https://datatracker.ietf.org/doc/charter-ietf-core/history/) so that I = can >> do a quick diff. > > Sorry; done -- please check it. > > b > >>> Beno=C3=AEt, can you have a look at this version?: >>>> >>>> An edited version charter-ietf-core-01-01 with detailed history is now= at >>>> https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt >>> >>> Barry >>> >>> >>> On Sun, Jan 31, 2016 at 11:11 AM, Carsten Bormann wrote: >>>> >>>> Hi Barry, >>>> >>>> I'm back in Germany. >>>> >>>> I have expunged DICE (which has now closed) by replacing it with a >>>> reference to the security area in general (for DTLS over SMS), with a >>>> reference to the TLS WG (on DTLS specific efficiency work), and simply >>>> striking DICE from the list of WGs to coordinate with. That should >>>> cover Stephen's comments. >>>> >>>> Re Benoit's input (key: >>>>>>>> >>>>>>>> and >> are Beno=C3=AEt; >>> are Carsten) >>>>>>>> - "CoRE will also develop a way to make RESTCONF-style management >>>>>>>> functions >>>>>>>> available via CoAP that is appropriate for constrained node networ= ks. >>>>>>>> This >>>>>>>> will require very close coordination with NETCONF and other >>>>>>>> operations >>>>>>>> and >>>>>>>> management working groups." >>>>>>>> >>>>>>>> What is the goal of this coordination with NETCONF? >>>>>>>> Could RESTCONF be reused? If not, why not? >>>>>>>> If yes, will RESTCONF need to be modified? >>>>>>> >>>>>>> We want to coordinate with the NETCONF WG to ensure that the result= of >>>>>>> our work makes sense as a part of the overall NETCONF family. >>>>>> >>>>>> Thanks. The coordination objectives should be mentioned in the chart= er. >>>>>>> >>>>>>> The basis for COMI is RESTCONF, but there will be a need for some >>>>>>> streamlining. >>>>>> >>>>>> Can you expand on this, or point to a draft section/email thread. >>>> >>>> The main draft is draft-vanderstok-core-comi, and there are some >>>> additional considerations in draft-veillette-core-cool. >>>> >>>> (Or did you ask for text/pointers to be in the charter?) >>>> >>>>>>> It is not clear whether this will lead to modifications >>>>>>> of RESTCONF itself; more likely COMI will just be a dialect that is >>>>>>> applicable to very constrained devices. There are different >>>>>>> approaches >>>>>>> on the question whether the YANG models have to take some specific >>>>>>> care >>>>>>> about being used in COMI, >>>> >>>> (I was alluding to the COOL work here.) >>>> >>>>>> (I've not been following the core mailing list and I don't know whic= h >>>>>> specifics you speak about) >>>>>> I hope you will not go that path. >>>>>> This would be a failure from an OPS point of view: we need a single >>>>>> YANG >>>>>> data model language, and not another data model language. >>>> >>>> One objective that has been repeatedly stated in the COMI work is that >>>> any random YANG module should be usable with COMI, but there are still >>>> discussions whether this will be a less efficient mode and/or we shoul= d >>>> be leaving out some parts (RPC has been stated as an example). I thin= k >>>> we have been progressing towards enabling full coverage. There may, >>>> however, be some considerable efficiency gains that can be reaped by >>>> evolving YANG modules in a specific way. >>>> >>>>>> In the end, if >>>>>> there are YANG specifics for constrained node networks, then it's a >>>>>> different data model language. >>>> >>>> I think this statement reflects the current direction well, however, >>>> there may be some willingness to do additional work (such as COOL's SI= D >>>> files) in exchange for significant reductions in the message size. >>>> >>>>>> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model = for >>>>>> Interface Management for constrained networks? >>>> >>>> We already have RFC 7388, and we'd rather get more integration with th= e >>>> YANG world than less. >>>> >>>>>> Unless I miss something on the above, this should even mentioned in = the >>>>>> core >>>>>> charter. >>>>>> >>>>>> CoRE will also develop a way to make RESTCONF-style management >>>>>> functions available, based on YANG, via CoAP that is appropriat= e >>>>>> for >>>>>> constrained >>>>>> node networks. >>>>>> >>>>>> + >>>>>> >>>>>> No YANG specifics for constrained nodes network ... >>>> >>>> I somewhat nebulously phrased that as: >>>> >>>> Besides continuing to examine operational and manageability aspects= of >>>> the CoAP protocol itself, CoRE will also develop a way to make >>>> RESTCONF-style management functions available via CoAP that is >>>> appropriate for constrained node networks. This will require very >>>> close >>>> coordination with NETCONF and other operations and management worki= ng >>>> groups. The YANG modeling language is not a target for change in >>>> this process, however additional supporting mechanisms may be >>>> employed in specific cases where significant performance gains are >>>> both attainable and required. >>>> >>>> (Maybe this can still be improved.) >>>> >>>>>> And LWM2M? >>>>>> >>>>>> Do we need to expand a bit on those in the charter? I guess so >>>> >>>> I have added to the above: >>>> >>>> The working >>>> group will continue to consider the OMA LWM2M management functions >>>> as a well-accepted alternative form of management and provide >>>> support at the CoAP protocol level where required. >>>> >>>> That wording is obviously even more up for discussion: WG, please chim= e >>>> in (potentially after limiting the CC list to core@ietf.org). >>>> >>>> An edited version charter-ietf-core-01-01 with detailed history is now= at >>>> https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt >>>> >>>> Gr=C3=BC=C3=9Fe, Carsten >>>> >>>> _______________________________________________ >>>> 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 From nobody Tue Mar 15 14:07:00 2016 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 5420F12D7F0; Tue, 15 Mar 2016 14:06:49 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315210649.5419.18584.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 14:06:49 -0700 Archived-At: Cc: core@ietf.org Subject: [core] WG Review: Constrained RESTful Environments (core) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:06:49 -0000 The Constrained RESTful Environments (core) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-03-25. Constrained RESTful Environments (core) ----------------------------------------------------------------------- Current status: Active WG Chairs: Carsten Bormann Andrew McGregor Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: core@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Charter: https://datatracker.ietf.org/doc/charter-ietf-core/ CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Milestones: TDB From nobody Thu Mar 17 09:08:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6BC12D652 for ; Thu, 17 Mar 2016 09:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UzMa9FFatYF for ; Thu, 17 Mar 2016 09:08:35 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id D994C12D692 for ; Thu, 17 Mar 2016 09:08:34 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA28663; Thu, 17 Mar 2016 12:08:30 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id u2HG8TIu069320; Thu, 17 Mar 2016 12:08:30 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201603171608.u2HG8TIu069320@mainfs.snmp.com> To: Michel Veillette From: David Reid In-reply-to: Your message of Mon, 14 Mar 2016 14:48:11 -0000. Date: Thu, 17 Mar 2016 12:08:29 -0400 Archived-At: Cc: Core Subject: Re: [core] New CoOL drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Reid List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:08:38 -0000 I read draft-somaraju-core-sid and I have a few questions. How are yang revisions handled? I see a mention of adding new SIDs for revisions, but I don't know how the new SIDs are assigned. The process for assigning SIDs is "recommended". Does this mean I can assigned the SIDs any way I want and not follow the recommended approach? And does that mean that my SID assignments and someone elses will be different? In the .sid file, what is the value of the assigned date field and the type field. Is there a way that the .sid file could be a yang module so that standard yang tools could read it. For example, could deviations be used to add sid assignments with the deviate add statement. That way I would not have to have special tools to read the .sid file, any yang compiler would work. When assigning sids, "the list of items is ordered by type and label". What is the purpose of this ordering? -David Reid From nobody Thu Mar 17 10:14:11 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E537212D9D9 for ; Thu, 17 Mar 2016 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2PoseIfXtYhf for ; Thu, 17 Mar 2016 10:14:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C48912DCAE for ; Thu, 17 Mar 2016 10:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VXS8+ptugK9L0vWYEhfqQ5Kwm1D7IYmV6i1i69ETtcU=; b=HO+aYfnaKVTGQy+P2wU10+5tnp8vJc8EQo2jzVKfY1idC8pXGcARK0MlJ1HX4Mb5UImNlY5ehEFxV8Pb4DWvEskB4gqKXkaYs/t6V1YWk/wYuq4vtEt3c/y7Zdp+HK2opPGjkEhdvAdhAkbBxOq5Yh1bkRLtDHl6GKfYEZF+ayI= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 17 Mar 2016 17:11:27 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0434.020; Thu, 17 Mar 2016 17:11:27 +0000 From: Michel Veillette To: David Reid Thread-Topic: [core] New CoOL drafts available Thread-Index: AQHRgGdEIv4eM2OGgkusVgRN80vY6Z9d1A5Q Date: Thu, 17 Mar 2016 17:11:27 +0000 Message-ID: References: Your message of Mon, 14 Mar 2016 14:48:11 -0000. <201603171608.u2HG8TIu069320@mainfs.snmp.com> In-Reply-To: <201603171608.u2HG8TIu069320@mainfs.snmp.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: snmp.com; dkim=none (message not signed) header.d=none;snmp.com; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 04b88b84-e8cd-4123-ebcb-08d34e872d5c x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:8hJAEdosQtRql0RBw/8sA9nYtWQeqKbRCSRccxaZ1URNMSqHOvAhqt2v8PbXvQ45vyGdEOkfUnBIX9x0QeLxW/ik4N1yE44k91Q+yj3a9c6TOsuhYHPb1NyyPOjmx4RQdhOGzU/03K0Psg4L8DVi7w==; 24:OO/39FeFi7oXVFD5P5FN3qzXcE8PTPaqGGGjKXCkg8HcSPfVaCDrPpRl7n+L88jKIrqb1eg6anxYLBgD3qNa8u5aLsyn39zWGaYcoxISjEQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(2906002)(5003600100002)(99286002)(1096002)(4326007)(1220700001)(2950100001)(2900100001)(66066001)(19580395003)(19580405001)(110136002)(81166005)(189998001)(5002640100001)(92566002)(33656002)(106116001)(11100500001)(5004730100002)(19273905006)(76576001)(5008740100001)(3660700001)(3280700002)(122556002)(1720100001)(50986999)(76176999)(74316001)(3846002)(6116002)(102836003)(586003)(77096005)(86362001)(87936001)(54356999)(15975445007)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 17:11:27.3925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 Archived-At: Cc: Core Subject: Re: [core] New CoOL drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Mar 2016 17:14:10 -0000 Hi David. See [MV] bellow. Regards, Michel Veillette -----Original Message----- From: David Reid [mailto:reid@snmp.com]=20 Sent: March-17-16 12:08 PM To: Michel Veillette Cc: Core Subject: Re: [core] New CoOL drafts available I read draft-somaraju-core-sid and I have a few questions. How are yang revisions handled? I see a mention of adding new SIDs for revi= sions, but I don't know how the new SIDs are assigned. [MV] For revision, the algorithm defined at the bottom of section 3 can be = also be used assuming that the process=20 [MV] is resumed using the highest SID already allocated and YANG items alre= ady assigned are not modified. [MV] I agree that the draft should add this clarification. [MV] [MV] The following example is based on http://www.netconfcentral.org/module= report/toaster : [MV] [MV] python pyang --list-sid --generate-sid-file 2000 0:100 toaster@2009-1= 1-20.yang [MV] [MV] SID Assigned to [MV] --------- -------------------------------------------------- [MV] 20000 identity toaster:frozen-bagel [MV] 20001 identity toaster:frozen-waffle [MV] 20002 identity toaster:hash-brown [MV] 20003 identity toaster:toast-type [MV] 20004 identity toaster:wheat-bread [MV] 20005 identity toaster:white-bread [MV] 20006 identity toaster:wonder-bread [MV] 20007 node /toaster-info [MV] 20008 node /toaster-info/toaster-manufacturer [MV] 20009 node /toaster-info/toaster-model-number [MV] 20010 node /toaster-info/toaster-status [MV] 20011 notification /toast-done [MV] 20012 notification /toast-done/toast-status [MV] 20013 rpc /cancel-toast [MV] 20014 rpc /make-toast [MV] 20015 rpc /make-toast/input/toaster-doneness [MV] 20016 rpc /make-toast/input/toaster-toast-type [MV] [MV] [MV] File toaster@2009-11-20.sid created [MV] Number of SIDs available : 100 [MV] Number of SIDs assigned : 17 [MV] [MV] python pyang --list-sid --update-sid-file toaster@2009-11-20.sid toas= ter@2009-12-28.yang [MV] [MV] SID Assigned to [MV] --------- -------------------------------------------------- [MV] 20000 identity toaster:frozen-bagel [MV] 20001 identity toaster:frozen-waffle [MV] 20002 identity toaster:hash-brown [MV] 20003 identity toaster:toast-type [MV] 20004 identity toaster:wheat-bread [MV] 20005 identity toaster:white-bread [MV] 20006 identity toaster:wonder-bread [MV] 20017 identity toaster:croisant (New) [MV] 20007 node /toaster-info [MV] 20008 node /toaster-info/toaster-manufacturer (Remove) [MV] 20009 node /toaster-info/toaster-model-number [MV] 20010 node /toaster-info/toaster-status [MV] 20018 node /toaster-info/power-source/electric/voltage (New) [MV] 20011 notification /toast-done [MV] 20012 notification /toast-done/toast-status [MV] 20013 rpc /cancel-toast [MV] 20014 rpc /make-toast [MV] 20015 rpc /make-toast/input/toaster-doneness [MV] 20016 rpc /make-toast/input/toaster-toast-type [MV] [MV] WARNING, obsolete definitions should be defined as 'deprecated' or 'ob= solete'. [MV] [MV] File toaster@2009-12-28.sid updated [MV] Number of SIDs available : 100 [MV] Number of SIDs assigned : 19 The process for assigning SIDs is "recommended". Does this mean I can assig= ned the SIDs any way I want and not follow the recommended approach? [MV] The only requirement for a SID is to be globally unique. [MV] Any process which comply with this requirement should be fine. And does that mean that my SID assignments and someone elses will be differ= ent? [MV] Yes, this is why .sid files should be registered. [MV] Even if the same algorithm is used, the result can be different depend= ing when in the development cycle SIDs have been assigned. [MV] The only way to produce the same list of SIDs is to use the same algor= ithm, on the same revisions, in the same order. In the .sid file, what is the value of the assigned date field and the type= field. [MV] I agree that the assigned date don't add much value and should be opti= onal (mandatory false). [MV] For the type, this allows to group data nodes, RPCs and notifications = together which make the .sid file more readable and optimise the delta enco= ding. Is there a way that the .sid file could be a yang module so that standard y= ang tools could read it. For example, could deviations be used to add sid a= ssignments with the deviate add statement. That way I would not have to hav= e special tools to read the .sid file, any yang compiler would work. [MV] .yang files are the input of the SID assignment process, the .sid are= the output. [MV] Since the inputs are not modified, this process can be repeated as nee= ded. [MV] This is useful during the initial development when .yang files are cha= nging and a completely new SID assignment is preferred. [MV] Re-writing the .yang file will also add lot of complexities to the too= l. [MV] Finally, adding this information to the yang files won't change the fa= ct that the actual YANG tools don't understand SIDs and don't do anything u= seful with them. When assigning sids, "the list of items is ordered by type and label". What is the purpose of this ordering?=20 [MV] This ordering is important to minimise the size of the delta encoding. -David Reid From nobody Thu Mar 17 14:36:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A0612D7D0 for ; Thu, 17 Mar 2016 14:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgwNVysHfHWA for ; Thu, 17 Mar 2016 14:36:09 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1E67412D692 for ; Thu, 17 Mar 2016 14:36:02 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA18775; Thu, 17 Mar 2016 17:35:57 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id u2HLZsud011404; Thu, 17 Mar 2016 17:35:56 -0400 (EDT) (envelope-from reid@snmp.com) Message-Id: <201603172135.u2HLZsud011404@mainfs.snmp.com> To: Michel Veillette From: David Reid In-reply-to: Your message of Thu, 17 Mar 2016 17:11:27 -0000. Date: Thu, 17 Mar 2016 17:35:54 -0400 Archived-At: Cc: Core Subject: Re: [core] New CoOL drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Reid List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:36:10 -0000 Thanks Michel. One more question: > When assigning sids, "the list of items is ordered by type and label". > What is the purpose of this ordering? > > [MV] This ordering is important to minimise the size of the delta encoding. I'm not familar with CBOR encoding. Perhaps the answer is obvious to those who are. How does sorting alphabetically before assigning the SID minimize the encoding? -David Reid From nobody Thu Mar 17 15:43:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED70012DD60 for ; Thu, 17 Mar 2016 15:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8WbGnM8hG09F for ; Thu, 17 Mar 2016 15:43:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF4512DD63 for ; Thu, 17 Mar 2016 15:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vOeF3vfJ/xJj+n/MTToNlGOBfvQgsQ67vI1zjqPaLI0=; b=Mc+4Kdgk/CB7MtKTJhrmvcotm7oFvuoTafEKRyH+GcSiRFdM9aThu7nnsLdd2P6TQ8/m0vXMaZC1GggNWBEAJOK72Tw/IyOnmTCgdmIF6k6xp/nS+L2mcHLhH2j1bj2Ug4T+CqG8i74U+ZmSphh0uaZOwpLURxDe1dc4HHvMCSA= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 17 Mar 2016 22:43:40 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0434.020; Thu, 17 Mar 2016 22:43:40 +0000 From: Michel Veillette To: David Reid Thread-Topic: [core] New CoOL drafts available Thread-Index: AQHRgJT7Iv4eM2OGgkusVgRN80vY6Z9eOA5A Date: Thu, 17 Mar 2016 22:43:39 +0000 Message-ID: References: Your message of Thu, 17 Mar 2016 17:11:27 -0000. <201603172135.u2HLZsud011404@mainfs.snmp.com> In-Reply-To: <201603172135.u2HLZsud011404@mainfs.snmp.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: snmp.com; dkim=none (message not signed) header.d=none;snmp.com; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: a901957f-9729-41a9-c46d-08d34eb59615 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:NCZ/et29Bqo78AehLzDaYkphkdNDTWFi7X2PrhheeET7avoeBoNgASUYMRaN5eZYPNaU/RLtHX3rjcxCSLuxRJzQyRY7Rur1eQGer3G7ZDZsxrp4FQe7WTX+wRxLPzzZh0xhyQS0ybO42ikdAxGPiQ==; 24:h93oJufFnZbz0M9hO/s1HCcPuUEUiyN9QzqO8MhtJBNYxbiq/hW3PQK7Fy3guurVcftUL6qLS37ZjDjQ+AR+nbEXiK6t2GKI7/7ezMr+jw0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(5008740100001)(4326007)(106116001)(11100500001)(66066001)(81166005)(74316001)(54356999)(2906002)(76576001)(76176999)(5002640100001)(2900100001)(2950100001)(5003600100002)(50986999)(3280700002)(122556002)(10400500002)(86362001)(15975445007)(77096005)(87936001)(1096002)(1220700001)(189998001)(92566002)(5004730100002)(19580395003)(33656002)(586003)(3846002)(6116002)(102836003)(19580405001)(99286002)(3660700001)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 22:43:39.9834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: Core Subject: Re: [core] New CoOL drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Mar 2016 22:43:45 -0000 Hi David The optimization I'm referring is not associated to the CBOR encoding but w= ith delta as defined by https://tools.ietf.org/html/draft-veillette-core-yang-cbor-mapping-00#secti= on-4.2. In the following example, SID 1709 and 1710 are encoded as 1 and 2 respecti= vely. CBOR diagnostic notation: { 1708 : { # clock 2 : "2015-10-02T14:47:24Z-05:00", # current-datetime, SID 1710 1 : "2015-09-15T09:12:58Z-05:00" # boot-datetime, SID 1709 } } To keep these delta small, all children of a container or list need to be a= ssigned to consecutive SIDs. With the use of grouping in yang files, children can be defined far apart. By sorting the final schema tree, these children are group together. /system-state/clock /system-state/clock/boot-datetime /system-state/clock/current-datetime For more .sid files example, see: https://github.com/core-wg/yang-cbor/tree/master/registry Regards, Michel Veillette -----Original Message----- From: David Reid [mailto:reid@snmp.com]=20 Sent: March-17-16 5:36 PM To: Michel Veillette Cc: Core Subject: Re: [core] New CoOL drafts available Thanks Michel. One more question: > When assigning sids, "the list of items is ordered by type and label". > What is the purpose of this ordering?=20 >=20 > [MV] This ordering is important to minimise the size of the delta encodin= g. I'm not familar with CBOR encoding. Perhaps the answer is obvious to those = who are. How does sorting alphabetically before assigning the SID minimize = the encoding? -David Reid=20 From nobody Fri Mar 18 01:44:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8594512D7CC for ; Fri, 18 Mar 2016 01:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=1.899, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 DajWMecissxZ for ; Fri, 18 Mar 2016 01:44:43 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 64B0D12D806 for ; Fri, 18 Mar 2016 01:44:41 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 725F519F683 for ; Fri, 18 Mar 2016 16:44:40 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id F1A5219F675 for ; Fri, 18 Mar 2016 16:44:39 +0800 (HKT) Message-ID: <08A2EC6A426D4A62A57B6C79A6967397@WeiGengyuPC> From: "weigengyu" To: References: <20160315210649.5419.18584.idtracker@ietfa.amsl.com> In-Reply-To: <20160315210649.5419.18584.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 16:44:42 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] WG Review: Constrained RESTful Environments (core) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Mar 2016 08:44:45 -0000 Hi, One suggestion for the following paragraph. > There also may be proxies that interconnect between other Internet > protocols and the Devices using the CoAP protocol. It is worth noting > that proxy does not have to occur at the boundary between the > constrained network and the more general network, but can be deployed at > various locations in the less-constrained network. From: > There also may be proxies that interconnect between other Internet > protocols and the Devices using the CoAP protocol. Changed to: There also may be proxies that interconnect between CoAP or other Internet protocols and the Device using the CoAP protocol. Explanations: A CoAP to CoAP proxy may be needed for CoAP over TCP and CoAP over UDP. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: The IESG Sent: Wednesday, March 16, 2016 5:06 AM To: IETF-Announce Cc: core@ietf.org Subject: [core] WG Review: Constrained RESTful Environments (core) The Constrained RESTful Environments (core) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-03-25. Constrained RESTful Environments (core) ----------------------------------------------------------------------- Current status: Active WG Chairs: Carsten Bormann Andrew McGregor Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: core@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Charter: https://datatracker.ietf.org/doc/charter-ietf-core/ CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Milestones: TDB _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Mar 18 20:07:07 2016 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 9C2C712D53A; Fri, 18 Mar 2016 20:07:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160319030704.18438.51787.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 20:07:04 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 03:07:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Guidelines for HTTP-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-08.txt Pages : 38 Date : 2016-03-18 Abstract: This document provides reference information for implementing a proxy that performs translation between the HTTP protocol and the CoAP protocol, focusing on the reverse proxy case. It describes how a HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to a HTTP response. Furthermore, it defines a template for URI mapping and provides a set of guidelines for HTTP to CoAP protocol translation and related proxy implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-08 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 Mar 21 10:37:15 2016 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 5ECE912D9B8; Mon, 21 Mar 2016 10:37:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321173710.31940.69180.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 10:37:10 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-19.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:37:10 -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 of the IETF. Title : Block-wise transfers in CoAP Authors : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-19.txt Pages : 33 Date : 2016-03-21 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-block-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-19 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 Mar 21 10:41:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B85B12D9A1 for ; Mon, 21 Mar 2016 10:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 4GM4XfhshCpP for ; Mon, 21 Mar 2016 10:41:16 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D2C12D99F for ; Mon, 21 Mar 2016 10:40:43 -0700 (PDT) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5CDBD1726D8; Mon, 21 Mar 2016 18:40:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id oQBAcwB923bn; Mon, 21 Mar 2016 18:40:39 +0100 (CET) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 08F23172758; Mon, 21 Mar 2016 18:40:38 +0100 (CET) Message-ID: <56F03213.5070807@tzi.org> Date: Mon, 21 Mar 2016 18:40:35 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" References: <20160321173710.31940.44149.idtracker@ietfa.amsl.com> In-Reply-To: <20160321173710.31940.44149.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Fwd: New Version Notification for draft-ietf-core-block-19.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Mar 2016 17:41:24 -0000 This update has editorial changes covering the ops-dir comments (thank you, Qin!) as well as the late discussion about security considerations in e2e security mechanisms that may want to protect block-wise transfers (thank you, Göran!). Grüße, Carsten -------- Original Message -------- Subject: New Version Notification for draft-ietf-core-block-19.txt Date: Mon, 21 Mar 2016 10:37:10 -0700 From: internet-drafts@ietf.org To: Carsten Bormann , Zach Shelby , Dr. Carsten Bormann A new version of I-D, draft-ietf-core-block-19.txt has been successfully submitted by Carsten Bormann and posted to the IETF repository. Name: draft-ietf-core-block Revision: 19 Title: Block-wise transfers in CoAP Document date: 2016-03-21 Group: core Pages: 33 URL: https://www.ietf.org/internet-drafts/draft-ietf-core-block-19.txt Status: https://datatracker.ietf.org/doc/draft-ietf-core-block/ Htmlized: https://tools.ietf.org/html/draft-ietf-core-block-19 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-19 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. 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 Mon Mar 21 11:27:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2881612D9ED for ; Mon, 21 Mar 2016 11:27:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CF3T6sIAZ0rA for ; Mon, 21 Mar 2016 11:26:59 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 546B012D927 for ; Mon, 21 Mar 2016 11:26:59 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id u190so275233686pfb.3 for ; Mon, 21 Mar 2016 11:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9a5P/AWdHY+BrBjIRWOrO2mthEDYTrFM8jSxTDUwqrE=; b=SqehjMsej+K3CWTo/8qsZLXNfm5ncS38wyU230OSv1Sg4qCh0vO7Ycr0sJIO3jcNt5 7SE04mTbejjAvTGyzS+PhPISQrGOp54v5lvAQpge8Nx+AMqP5y5dcNGFHmOWPseo+6gk /3XPEfCUsNZ38QmYCHQyJkzFTEgx6EsgW0TRXia8DILEjmniOG6bHuRD4PC78olVe6o9 EFcK9HulpbO45w1mmDC8xff6n4PGS/JRG1583szhR7cfmWZKb8zxuknCKQA52YLvprhs o3xFFfVPDpr2VqZ+d7zIrJdHqboCPWffwkaem8utjFAmflLV4UEGnP/RlOspGaj3IcnQ OT/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9a5P/AWdHY+BrBjIRWOrO2mthEDYTrFM8jSxTDUwqrE=; b=EWKX/Z19cIX+c3Pm9uM7yF8aYqqCRSiLPNaIqZWvij1pYWk+E8KLH7lzgwR3DIPXgf tbV8yPr/YGRdxbe/5dF08subL/2B9vxrCkTLQ6yYtbO20QE+ZT0wL1zlh9UvNcQEQLDE RaUlwgQ61bocx6nceWqfEm5aJoCJ2hriUBIuQuoWnjmWcl0rjz1/w1Q/u69V3hR46G7D gj228KI3kXYx5XcQwo7iiQo77OTza7LmeuCVzIH/xZIhhWq/TP11gVMzMTEZcUZ96O6P VY+x05qiVphPkMzlTaf4X4LerqsTTkZoiEbPx+FLe6XoPU1X1TsTJrUIOs6EYFnl09cN DxfQ== X-Gm-Message-State: AD7BkJID+aSSZZ/7iILLkqLp01lnq1jqcy9QDXcA/Yi1FrUBfvEqsCQ3F5V3MCeU7eNFAA== X-Received: by 10.66.176.139 with SMTP id ci11mr27822434pac.68.1458584818914; Mon, 21 Mar 2016 11:26:58 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id g28sm42374892pfd.25.2016.03.21.11.26.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 11:26:57 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56C150AA.50304@nteczone.com> Date: Mon, 21 Mar 2016 11:26:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> <56B4043C.5020502@nteczone.com> <513D642A-0D83-48CD-B26C-4F9829A08811@gmail.com> <6C921742-9C21-4100-8548-7CB45845CF65@gmail.com> <56C150AA.50304@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Mar 2016 18:27:01 -0000 Hi, I propose adding three new optional notification attributes, two of = which which define a notification band, and adding the following = clarifying notes: nbll - the lower limit value of the notification band.=20 nbul - the upper limit value of the notification band init - the value to initialize the reporting state machine, i.e. the = initial value of the filter before the first sample is evaluated A sample is considered to be within the notification band if it is = greater than or equal to nbll and less than or equal to nbul, and less = than or equal to the maximum range value, and greater than or equal to = the minimum range value. In other words, the notification band may wrap = around the range of the value and thus be used as a high/low alarm band = when nbll > nbul. In this case, the band nbul > sample value > nbll is = considered the non-reporting band. In the reporting band, Pmin and Pmax are respected, as are reporting = state changes into and out of the reporting band. Step (st) is respected within the reporting band and must center it's = reporting values around the last reported sample. i.e. we can't just = quantize the band. To further clarify, the existing lt, gt, and step can be used together, = and the evaluation is using a sample driven FSM. Therefore a sample = transition across a limit (lt, gt) and also exceeding step, would create = a single report. Likewise, nbul, nbul, and step may also be used together, and the same = FSM rule applies. I will diagram the FSM for the draft when I have time = (can't commit to today...) NB The new notification band behavior is different from the existing = lt/gt band behavior and is an alternate notification filter for some = different use cases. It isn't expected to have lt, gt used along with = nbll, nbul in the same binding, but there may be multiple bindings on a = resource with diferent behaviors as the implementation allows. For example, assuming a 0-100 scale: nbll=3D80; nbul=3D20; pmax=3D10 This would generate a report every 10 seconds when the sample value is = >=3D 80 or <=3D 20, and no report when the sample value is between 20 = and 80.=20 nbll=3D1; st=3D1; pmin=3D10; pmax=3D600 This will cause, when the sample value is between 1 and 100, reporting = of every change of 1 unit or more, no more frequently than once every 10 = seconds and at least once every 600 seconds as long as the sample is = between 1 and 100 inclusive. Reporting is disabled when the sample value = is less than 1. Best regards, Michael > On Feb 14, 2016, at 8:14 PM, Christian Groves = wrote: >=20 > Hello Michael, >=20 > As part of a use case I've proposed an updates to the binding = attributes which I think will handle both simple and complex cases with = the same synyax. >=20 > Regards, Christian >=20 > On 14/02/2016 2:19 PM, Michael Koster wrote: >> The intention is to produce one notification when a limit value, gt = or lt, is crossed, not to continuously send notifications (at the sample = rate? at pmin? ) when a value is in a particular state. > [CNG] OK this wasn't clear. I was taking crossed to to mean = notifications occurred once the value was crossed. So cs leads to = multiple notifications but gt and lt only result in one notification? >> Pmax is intended to send repeat notifications for eventual = consistency. Maybe there should also be a cmax to set a notification = repeat intereval when the state is in a "critical" band. > [CNG] This could be useful. >>=20 >> Also your text below is "all value changes" ; what do you mean by all = changes? do you mean all samples, or do you mean an additional change in = value after a limit has been crossed? > [CNG] I meant all samples that met the attribute/s criteria. > e.g. pmin=3Dx, pmax=3Dy, gt=3D26 I would get a notification when 26 is = crossed. Then if the sample was 26 at pmax the next notification would = be 26. If the sample changed to 27 at the expiry of pmin the = notification would include 27 and so on. > The addition of cs=3D5 would modify the behaviour. >=20 >>=20 >> Perhaps it would be good if you would explain your use case in more = detail with some concrete examples of when values change and when you do = and do not expect notifications. If we want to add special alarm = functionality, I think we may want to define some special attributes for = that case, like amin, amax, agt, alt. > [CNG] I don't think special "alarm" functionality is needed. I think = it just needs to be possible for a user to set the bindings and know = what notifications will be expected. >=20 > Probably the simplest approach is to have a single attribute that = indicates when a value is met or crossed (in either direction). This = would allow the user to be explicit when it wants a notification. The = downside is that multiple bindings would be needed, leading possibly to = a large table. >=20 > An alternate approach could be to separate the value range = specification from the notification rate specification. A strawman: >=20 > A binding would consist of a band, notification and timing attributes: >=20 > Band - Sets a value region that triggers a notification. When a sample = is equal to or within this region notification is governed by the = NotificationRate parameter. Band consists of two parameters: start and = end (which are included in the notification range). Either start or end = could be omitted essentially meaning through to the end or start of the = number range, e.g. (,20) would mean 0 through to 20. (20,) would mean 20 = and over. If both start and end are omitted then the notifications are = unbounded and the initial sample value is taken as the start value. >=20 > NotificationRate - Would consist of one of the following: > once - This would indicate that a notification is set only once on = entering the band. > cs:value - This would indicate that a notification is set on entering = the band and then when the sample changes value according to band:start = + (N * cs:value). If value is omitted then the samples are notified = whenever sampling indicates a change (subject to pmin timing). >=20 > Timing - Two parameters: > Pmin: Minimum time between notifications. A notification is generated = only if the sample value has changed and meets a particular binding = criteria (band/notificationRate). >=20 > Pmax: Maximum time between notifications. A notification is generated = irrespective whether the sample value has changed or not. >=20 > If multiple bindings relate to the same value band then the pmin and = pmax values used for notifications related to those values should be the = smallest values. >=20 > Band, NotificationRate, Pmin and Pmax are at most once per binding. >=20 > Use case > -------- > Monitoring temperature in some plant process. Temp degC. >=20 > The following 3 bindings are made between two resources: > a) Notify once when process reaches 20c: > band(20,),notificationRate(once), pmin=3D60, pmax=3D300 > b) Notify every 1c change in the range 40c to 49c: > band(40,49),notificationRate(cs:1), pmin=3D60, pmax=3D240 > c) Notify immediately when meeting or exceeding 50c according to = sample rate: > band (50,),notificationRate(cs),pmin=3D1, pmax=3D180. >=20 > A notification is received once the process meets/exceeds 20c. Whilst = the temperature exceeds 20c notifications are sent according to pmin=3D60 = and pmax=3Dx. > The temperature stays between 20 and 39 for some time with = notifications being generated by pmax=3Dx. > The temperature then jumps to 41 and a notification is generated. The = notification is delayed for 30s because of the pmin=3D60 threshold. The = temperature continues to rise and after another pmin its 45c so a = notification is generated. The temperature then stablises at 45. A = notification of 45c is then generated at pmax=3D240. 10 seconds later = the temperature jumps to 60. A notification is immediately generated as = pmin for that band is pmin=3D1. Then temperature again jumps to 70 and a = notification is immediately generated subject to pmin=3D1. >=20 > The simplest use case would be: > band(,),notificationRate(once), pmin=3Dx, pmax=3Dy > Which indicates a notification with the current sample ise generated = on setting the binding and then a notification will be generated = according to pmax. >=20 > Thoughts? >=20 >=20 >=20 >=20 >>=20 >> Best regards, >>=20 >> Michael >>=20 >>> On Feb 13, 2016, at 6:57 PM, Michael Koster = > = wrote: >>>=20 >>>>>> The next sample is 26, which generates a notification due to the = gt=3D26 attribute, The new most recent value is now 26. >>>>>>=20 >>>>>> The next sample is 30, which does not generate a notification = since the last reported value was 26 and no new reporting condition is = met. >>>> [CNG] Wouldn't 30 be notified because it meets the gt=3D26 = attribute criteria? >>>>=20 >>>> I assumed that gt didn't result in a single notification but = notification of all value changes over 26. I think it has to be clear = whether the attributes are ORed or ANDed together to produce a = notification. >>>>=20 >>>=20 >>=20 >=20 From nobody Mon Mar 21 11:46:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4146A12D9F0 for ; Mon, 21 Mar 2016 11:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ijgFQ4PP6Vpw for ; Mon, 21 Mar 2016 11:46:41 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C67112D9DA for ; Mon, 21 Mar 2016 11:46:41 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 124so67822777iov.3 for ; Mon, 21 Mar 2016 11:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=ecSdCpTWm9rouHsHZFs5lSBD+U8ViGPS/WJRVWWHLBc=; b=IjzsX/OXvcru+t/M/po3rWD1IozHBoXU1tIeZIqF+O/ofDcUC8fuUWnX5LH8TtdPrr XSzYAO1bZY6IR62QCkRhYCSbxDUihiMoGLm64ig6ZsT7ao9pjBAEHaTSgsYKeW/JvH1E h+YC7m1NOf55jSrLToP43qSByFMWyGJjml0PMhhMcwKtupP1NMhZkodpMrNqMN3mzNfT yyGmOsModXW68hXbD5OlHpYJ0/WLgTksER25x0dmTLBlqjm0ezT3edReuTaKq/AvY7qg htX7/E4pm/j9ylhD4K7s0LlqCqP+zl1Jcna7Dvv0c5es6Av6gjr5l3HhHkLWl72AyMJU VGaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=ecSdCpTWm9rouHsHZFs5lSBD+U8ViGPS/WJRVWWHLBc=; b=RJoVq4BXMBngAN1u5hzYOQCvqOuaRz0ICO9paHDQFbfXCKScmT9dvv+t2oggU4ojU4 tVqsdW/gi844LXlAaOcI85znlA+TN0yHk7/fql3zG2IjJ8IH2MOIG5yOuG5UCfHMOT7y FDPOG1vV3Fqehm9GD7MOwnvJRD6cRUFTg4Az3VmjYZs9Kx63KdcZM4I6m3a6gE4D6c6A eJ0pJJmm3Te/ywb5v1FiAEFN4n6GSneewuJX/lTqyifZTJVPSvACE669OjQ9roAj7vjh WKqBre6cMC6l/1HwfQ6d+yR1dVFWfPGoIshqEbH9RXThDVeX8vbIsPuKIKgQ9EW/xDno rJrg== X-Gm-Message-State: AD7BkJIVxemb6EXauiU2oRaYbkwoZfpNdHxbaBlyYJxcUGKLYybfmKN3D0fOMYxGMJq1BAHX6g5jsvZ7jmpK6w== MIME-Version: 1.0 X-Received: by 10.107.12.207 with SMTP id 76mr31487611iom.70.1458586000446; Mon, 21 Mar 2016 11:46:40 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.15.139 with HTTP; Mon, 21 Mar 2016 11:46:40 -0700 (PDT) In-Reply-To: <56F03213.5070807@tzi.org> References: <20160321173710.31940.44149.idtracker@ietfa.amsl.com> <56F03213.5070807@tzi.org> Date: Mon, 21 Mar 2016 11:46:40 -0700 X-Google-Sender-Auth: twzZlz7qGy6zwb6ApIj6vDhozmo Message-ID: From: Barry Leiba To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-block-19.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Mar 2016 18:46:42 -0000 > This update has editorial changes covering the ops-dir comments (thank > you, Qin!) as well as the late discussion about security considerations > in e2e security mechanisms that may want to protect block-wise transfers > (thank you, G=C3=B6ran!). Thanks for getting that out. I've put the document into IESG Evaluation and put it on the first telechat after IETF 95 (currently planned for 21 April). Alexey will put the last coat of varnish on it then. Barry From nobody Mon Mar 21 15:09:30 2016 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 AE4A612D0F4; Mon, 21 Mar 2016 15:09:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321220928.12186.13209.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:09:28 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:09:28 -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 of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-06.txt Pages : 54 Date : 2016-03-21 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 resources 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-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 Mar 21 16:34:59 2016 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 C812F12D161; Mon, 21 Mar 2016 16:34:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321233447.10883.57937.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:34:47 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:34:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-07.txt Pages : 55 Date : 2016-03-21 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 resources 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-07 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 Mar 21 20:36:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD6012D66A for ; Mon, 21 Mar 2016 20:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 CW4XXW9ueu3n for ; Mon, 21 Mar 2016 20:36:18 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 0A04512D646 for ; Mon, 21 Mar 2016 20:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=wj6pj6pih6MnQkclyrnU42pGXLDO1Uc90RAJPEa32I4=; b=KYUOxYUAZDlvkUuMkvTH1CbhXn H6GA2BqVnXhTtf5+ZtDqSu2RSvW8LDkkjIV/xdAb61a62G2cU4d5PXLY3D4SAT/YaedW62xUl1EnJ vgW8YwR8yk+nvRvRIYy8DAj7gG06Jzr6zrQ/wO0q8a40DmeAZoBUyqQbKWhKN71p11iEmYDy52VzG FTMqn6btP5jYfGmG9oH28L34zpDZkrDah7mrHtFN3ZmyFffHJW6X7JJFNsnO/h9WKoIjEkeXe2xiE 4DPNsOFj6aSGvaViFpuOTeObdVVl05Ad+bk1Glz5AS+JHXi8X2ho5y9tD6Fif+eFOzU6hrIAtcsNu rHPrC2qw==; Received: from ppp118-209-30-74.lns20.mel4.internode.on.net ([118.209.30.74]:50300 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aiD79-003uGL-H0; Tue, 22 Mar 2016 14:36:15 +1100 To: Michael Koster References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> <56B4043C.5020502@nteczone.com> <513D642A-0D83-48CD-B26C-4F9829A08811@gmail.com> <6C921742-9C21-4100-8548-7CB45845CF65@gmail.com> <56C150AA.50304@nteczone.com> From: Christian Groves Message-ID: <56F0BDAC.4060608@nteczone.com> Date: Tue, 22 Mar 2016 14:36:12 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Mar 2016 03:36:19 -0000 Hello Michael, Please see my responses below. Regards, Christian On 22/03/2016 5:26 AM, Michael Koster wrote: > Hi, > > I propose adding three new optional notification attributes, two of which which define a notification band, and adding the following clarifying notes: > > nbll - the lower limit value of the notification band. > nbul - the upper limit value of the notification band [CNG] I guess these are equivalent to the band parameter I proposed below? > init - the value to initialize the reporting state machine, i.e. the initial value of the filter before the first sample is evaluated [CNG] I didn't see init mentioned below. Can it be used with gt, lt, st also? > > A sample is considered to be within the notification band if it is greater than or equal to nbll and less than or equal to nbul, and less than or equal to the maximum range value, and greater than or equal to the minimum range value. In other words, the notification band may wrap around the range of the value and thus be used as a high/low alarm band when nbll > nbul. In this case, the band nbul > sample value > nbll is considered the non-reporting band. [CNG] From the examples below I take it that nbll and nbul may appear by themselves basically meaning that the band is open ended toward the relevant end of the supported values? > In the reporting band, Pmin and Pmax are respected, as are reporting state changes into and out of the reporting band. [CNG] Is the reporting of state changes out of the band due to the Pmax only or a property of the nbll, nbul notification? e.g. does the notification occur before Pmax or at Pmax? > > Step (st) is respected within the reporting band and must center it's reporting values around the last reported sample. i.e. we can't just quantize the band. [CNG] Do you mean that to be reported the next value must exceed "previous value +/- step"? How would this relate to the set init value? > > To further clarify, the existing lt, gt, and step can be used together, and the evaluation is using a sample driven FSM. Therefore a sample transition across a limit (lt, gt) and also exceeding step, would create a single report. > > Likewise, nbul, nbul, and step may also be used together, and the same FSM rule applies. I will diagram the FSM for the draft when I have time (can't commit to today...) [CNG] Hopefully the FSM can shed some light. > > NB The new notification band behavior is different from the existing lt/gt band behavior and is an alternate notification filter for some different use cases. It isn't expected to have lt, gt used along with nbll, nbul in the same binding, but there may be multiple bindings on a resource with diferent behaviors as the implementation allows. [CNG] "Isn't expected" should we make that a "shall not" in the draft? > > For example, assuming a 0-100 scale: > > nbll=80; nbul=20; pmax=10 > > This would generate a report every 10 seconds when the sample value is >= 80 or <= 20, and no report when the sample value is between 20 and 80. > > nbll=1; st=1; pmin=10; pmax=600 > > This will cause, when the sample value is between 1 and 100, reporting of every change of 1 unit or more, no more frequently than once every 10 seconds and at least once every 600 seconds as long as the sample is between 1 and 100 inclusive. Reporting is disabled when the sample value is less than 1. [CNG] Is that the case? In the above description you indicated that there would be notification into and out of the band. You would get a report when the value is 0. > > Best regards, > > Michael > > >> On Feb 14, 2016, at 8:14 PM, Christian Groves wrote: >> >> Hello Michael, >> >> As part of a use case I've proposed an updates to the binding attributes which I think will handle both simple and complex cases with the same synyax. >> >> Regards, Christian >> >> On 14/02/2016 2:19 PM, Michael Koster wrote: >>> The intention is to produce one notification when a limit value, gt or lt, is crossed, not to continuously send notifications (at the sample rate? at pmin? ) when a value is in a particular state. >> [CNG] OK this wasn't clear. I was taking crossed to to mean notifications occurred once the value was crossed. So cs leads to multiple notifications but gt and lt only result in one notification? >>> Pmax is intended to send repeat notifications for eventual consistency. Maybe there should also be a cmax to set a notification repeat intereval when the state is in a "critical" band. >> [CNG] This could be useful. >>> Also your text below is "all value changes" ; what do you mean by all changes? do you mean all samples, or do you mean an additional change in value after a limit has been crossed? >> [CNG] I meant all samples that met the attribute/s criteria. >> e.g. pmin=x, pmax=y, gt=26 I would get a notification when 26 is crossed. Then if the sample was 26 at pmax the next notification would be 26. If the sample changed to 27 at the expiry of pmin the notification would include 27 and so on. >> The addition of cs=5 would modify the behaviour. >> >>> Perhaps it would be good if you would explain your use case in more detail with some concrete examples of when values change and when you do and do not expect notifications. If we want to add special alarm functionality, I think we may want to define some special attributes for that case, like amin, amax, agt, alt. >> [CNG] I don't think special "alarm" functionality is needed. I think it just needs to be possible for a user to set the bindings and know what notifications will be expected. >> >> Probably the simplest approach is to have a single attribute that indicates when a value is met or crossed (in either direction). This would allow the user to be explicit when it wants a notification. The downside is that multiple bindings would be needed, leading possibly to a large table. >> >> An alternate approach could be to separate the value range specification from the notification rate specification. A strawman: >> >> A binding would consist of a band, notification and timing attributes: >> >> Band - Sets a value region that triggers a notification. When a sample is equal to or within this region notification is governed by the NotificationRate parameter. Band consists of two parameters: start and end (which are included in the notification range). Either start or end could be omitted essentially meaning through to the end or start of the number range, e.g. (,20) would mean 0 through to 20. (20,) would mean 20 and over. If both start and end are omitted then the notifications are unbounded and the initial sample value is taken as the start value. >> >> NotificationRate - Would consist of one of the following: >> once - This would indicate that a notification is set only once on entering the band. >> cs:value - This would indicate that a notification is set on entering the band and then when the sample changes value according to band:start + (N * cs:value). If value is omitted then the samples are notified whenever sampling indicates a change (subject to pmin timing). >> >> Timing - Two parameters: >> Pmin: Minimum time between notifications. A notification is generated only if the sample value has changed and meets a particular binding criteria (band/notificationRate). >> >> Pmax: Maximum time between notifications. A notification is generated irrespective whether the sample value has changed or not. >> >> If multiple bindings relate to the same value band then the pmin and pmax values used for notifications related to those values should be the smallest values. >> >> Band, NotificationRate, Pmin and Pmax are at most once per binding. >> >> Use case >> -------- >> Monitoring temperature in some plant process. Temp degC. >> >> The following 3 bindings are made between two resources: >> a) Notify once when process reaches 20c: >> band(20,),notificationRate(once), pmin=60, pmax=300 >> b) Notify every 1c change in the range 40c to 49c: >> band(40,49),notificationRate(cs:1), pmin=60, pmax=240 >> c) Notify immediately when meeting or exceeding 50c according to sample rate: >> band (50,),notificationRate(cs),pmin=1, pmax=180. >> >> A notification is received once the process meets/exceeds 20c. Whilst the temperature exceeds 20c notifications are sent according to pmin=60 and pmax=x. >> The temperature stays between 20 and 39 for some time with notifications being generated by pmax=x. >> The temperature then jumps to 41 and a notification is generated. The notification is delayed for 30s because of the pmin=60 threshold. The temperature continues to rise and after another pmin its 45c so a notification is generated. The temperature then stablises at 45. A notification of 45c is then generated at pmax=240. 10 seconds later the temperature jumps to 60. A notification is immediately generated as pmin for that band is pmin=1. Then temperature again jumps to 70 and a notification is immediately generated subject to pmin=1. >> >> The simplest use case would be: >> band(,),notificationRate(once), pmin=x, pmax=y >> Which indicates a notification with the current sample ise generated on setting the binding and then a notification will be generated according to pmax. >> >> Thoughts? >> >> >> >> >>> Best regards, >>> >>> Michael >>> >>>> On Feb 13, 2016, at 6:57 PM, Michael Koster > wrote: >>>> >>>>>>> The next sample is 26, which generates a notification due to the gt=26 attribute, The new most recent value is now 26. >>>>>>> >>>>>>> The next sample is 30, which does not generate a notification since the last reported value was 26 and no new reporting condition is met. >>>>> [CNG] Wouldn't 30 be notified because it meets the gt=26 attribute criteria? >>>>> >>>>> I assumed that gt didn't result in a single notification but notification of all value changes over 26. I think it has to be clear whether the attributes are ORed or ANDed together to produce a notification. >>>>> > From nobody Mon Mar 21 23:55:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA6B12D71C for ; Mon, 21 Mar 2016 23:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=1.899, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 ZQMf7FZzgQ_T for ; Mon, 21 Mar 2016 23:55:51 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB5F12D715 for ; Mon, 21 Mar 2016 23:55:51 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 2811A19F4B4 for ; Tue, 22 Mar 2016 14:55:50 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0011A19F4A4 for ; Tue, 22 Mar 2016 14:55:49 +0800 (HKT) Message-ID: <1BC08AE5A1EF444185F720D49EA67670@WeiGengyuPC> From: "weigengyu" To: References: <20160321233447.10883.57937.idtracker@ietfa.amsl.com> In-Reply-To: <20160321233447.10883.57937.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 14:55:53 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Mar 2016 06:55:52 -0000 Hi, I have a question. Only 5.1 Discory is with " HTTP support : NO" and all from 5.2 to 5.6 are with "HTTP support : YES" in 5. Resource Directory Function Set, Why? " 5.1. Discovery Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt := Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : NO " Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: internet-drafts@ietf.org Sent: Tuesday, March 22, 2016 7:34 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-07.txt Pages : 55 Date : 2016-03-21 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 resources 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 22 00:02:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAA312D68D for ; Tue, 22 Mar 2016 00:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 fYL8wNUOys_y for ; Tue, 22 Mar 2016 00:02:51 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id CE44F12D1AD for ; Tue, 22 Mar 2016 00:02:50 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id E04014961F6; Tue, 22 Mar 2016 08:02:49 +0100 (CET) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id D0C05A80CE; Tue, 22 Mar 2016 08:02:48 +0100 (CET) Message-ID: <56F0EE16.90403@tzi.org> Date: Tue, 22 Mar 2016 08:02:46 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: weigengyu References: <20160321233447.10883.57937.idtracker@ietfa.amsl.com> <1BC08AE5A1EF444185F720D49EA67670@WeiGengyuPC> In-Reply-To: <1BC08AE5A1EF444185F720D49EA67670@WeiGengyuPC> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Mar 2016 07:02:52 -0000 weigengyu wrote: > Only 5.1 Discory is with " HTTP support : NO" and all from 5.2 to 5.6 > are with "HTTP support : YES" in 5. Resource Directory Function Set, > Why? Section 5.1 says: " HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. " Does that answer your question? Grüße, Carsten From nobody Tue Mar 22 00:28:48 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FDE12D77E for ; Tue, 22 Mar 2016 00:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=1.899, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 TlZErJTp_5RX for ; Tue, 22 Mar 2016 00:28:44 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id B7A6A12D77C for ; Tue, 22 Mar 2016 00:28:44 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 78A8C19F4EA for ; Tue, 22 Mar 2016 15:28:43 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id EFBEA19F404; Tue, 22 Mar 2016 15:28:42 +0800 (HKT) Message-ID: <384BBB4BA50849E79DEFE2CD6B8A3730@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" References: <20160321233447.10883.57937.idtracker@ietfa.amsl.com> <1BC08AE5A1EF444185F720D49EA67670@WeiGengyuPC> <56F0EE16.90403@tzi.org> In-Reply-To: <56F0EE16.90403@tzi.org> Date: Tue, 22 Mar 2016 15:28:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Mar 2016 07:28:45 -0000 Hi Carsten, Thank you for your reply. The following decriptions in Section 5.1 are clear, " Discovery is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter [RFC6690] with the value "core.rd" in the query string. HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. As HTTP unicast discovery is not fobidden, the descriptions of discovery request interface seems inconsistent to above statements. " The discovery request interface is specified as follows: Interaction: EP -> RD Method: GET URI Template: /.well-known/core{?rt} URI Template Variables: rt := Resource Type (optional). MAY contain one or more of the values "core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" Content-Format: application/link-format (if any) Content-Format: application/link-format+json (if any) Content-Format: application/link-format+cbor (if any) The following response codes are defined for this interface: Success: 2.05 "Content" with an application/link-format, application/link-format+json, or application/link-format+cbor payload containing one or more matching entries for the RD resource. Failure: 4.04 "Not Found" is returned in case no matching entry is found for a unicast request. Failure: 4.00 "Bad Request" is returned in case of a malformed request for a unicast request. Failure: No error response to a multicast request. HTTP support : NO regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Tuesday, March 22, 2016 3:02 PM To: weigengyu Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-resource-directory-07.txt weigengyu wrote: > Only 5.1 Discory is with " HTTP support : NO" and all from 5.2 to 5.6 > are with "HTTP support : YES" in 5. Resource Directory Function Set, > Why? Section 5.1 says: " HTTP does not support multicast and consequently only unicast discovery can be supported using HTTP. Links to Resource Directories MAY be registered in other Resource Directories, and well-known entry points SHOULD be provided to enable the bootstrapping of unicast discovery. " Does that answer your question? Grüße, Carsten From nobody Wed Mar 23 00:22:09 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243E812DA49 for ; Wed, 23 Mar 2016 00:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJnx_JnPRrNp for ; Wed, 23 Mar 2016 00:22:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BF312DA45 for ; Wed, 23 Mar 2016 00:22:05 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-d0-56f2441b9cfe Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.A0.16394.B1442F65; Wed, 23 Mar 2016 08:22:03 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 08:22:03 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: New Version Notification for draft-hartke-core-e2e-security-reqs-00.txt Thread-Index: AQHRgixyvDRG2d5Qc0Sc5mvjRW12h59mpQmA Date: Wed, 23 Mar 2016 07:22:02 +0000 Message-ID: References: <20160319221235.15087.23340.idtracker@ietfa.amsl.com> In-Reply-To: <20160319221235.15087.23340.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7sa60y6cwgw079S32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHWbPjAXXOCvOPFmEnsD4xz+LkZODgkBE4nZ73eyQdhiEhfu rQeyuTiEBA4zSvRM2cAE4SxhlJjfMJEZpIpNwEXiQcMjJhBbREBZYvOZ14wgtrBAmMSVn8+g 4uESJ99PZ4ewjSTOrOkDs1kEVCX+ztzLCmLzClhI/G5vApspJOAosfrSKxYQm1PASWL1n/dg FzECXfT91BqwmcwC4hK3nsxngrhUQGLJnvPMELaoxMvH/8BmigroSdzuWAu0iwMoriixvF8O xGQW0JRYv0sfYoq1xJ313xkhbEWJKd0P2SGuEZQ4OfMJywRG8VlIls1C6J6FpHsWku5ZSLoX MLKuYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMq4NbfqvuYLz8xvEQowAHoxIPb8G5j2FC rIllxZW5hxglOJiVRHijVD+FCfGmJFZWpRblxxeV5qQWH2KU5mBREudl/XQ5TEggPbEkNTs1 tSC1CCbLxMEp1cAot6byZ3PLd0eFfftDdR6fUVI68bIx98YE+RdSchyZz9+dvXIjT/d+vlnw xixv69eXpS01Uvdp+9o6d/xYtqdb5Jr6jw/Xdq39a8H8JiW/v0OxQmS131wmccnmNa/7Q0Kk Q3bNuGeuKtndqWLFL2ignvtNofyq7717zhONVnz6G1VutUdlt5YSS3FGoqEWc1FxIgDu/jwo pwIAAA== Archived-At: Subject: [core] FW: New Version Notification for draft-hartke-core-e2e-security-reqs-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 23 Mar 2016 07:22:07 -0000 DQpEZWFyIENvUkUgV0csDQoNCkFzIHByb21pc2VkIGR1cmluZyB0aGUgbGFzdCBDb1JFIFdHIGYy ZiBtZWV0aW5nIHdlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQNCm9uIGVuZC10by1lbmQgc2VjdXJp dHkgcmVxdWlyZW1lbnRzIGZvciBDb0FQIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgb2YNCnNlbnNv ciBhbmQgYWN0dWF0b3IgZGVwbG95bWVudHMgaW52b2x2aW5nIHByb3hpZXMgYW5kIG90aGVyIHNp bWlsYXINCmludGVybWVkaWFyaWVzLiANCg0KV2Ugd291bGQgbGlrZSB0byBwcmVzZW50IHRoZSBk cmFmdCBhdCB0aGUgQ29SRSBXRyBmMmYgbWVldGluZy4NCg0KDQpSZWdhcmRzLA0KR8O2cmFuDQoN Cg0KT24gMjAxNi0wMy0xOSAyMzoxMiwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3RlOg0KDQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWhhcnRrZS1jb3JlLWUyZS1zZWN1cml0eS1yZXFzLTAwLnR4dA0KPmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2xhdXMgSGFydGtlIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1oYXJ0a2UtY29yZS1lMmUtc2VjdXJp dHktcmVxcw0KPlJldmlzaW9uOgkwMA0KPlRpdGxlOgkJUmVxdWlyZW1lbnRzIGZvciBDb0FQIEVu ZC1Uby1FbmQgU2VjdXJpdHkNCj5Eb2N1bWVudCBkYXRlOgkyMDE2LTAzLTE5DQo+R3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTM3DQo+VVJMOiAgICAgICAgICAgIA0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJ0a2UtY29yZS1lMmUt c2VjdXJpdHktcmVxcy0wDQo+MC50eHQNCj5TdGF0dXM6ICAgICAgICAgDQo+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJlcXMv DQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o YXJ0a2UtY29yZS1lMmUtc2VjdXJpdHktcmVxcy0wMA0KPg0KPg0KPkFic3RyYWN0Og0KPiAgIFRo aXMgZG9jdW1lbnQgYW5hbHlzZXMgdGhyZWF0cyB0byBDb0FQIG1lc3NhZ2UgZXhjaGFuZ2VzIHRy YXZlcnNpbmcNCj4gICBwcm94aWVzIGFuZCBkZXJpdmVzIHRoZSBzZWN1cml0eSByZXF1aXJlbWVu dHMgZm9yIG1pdGlnYXRpbmcgdGhvc2UNCj4gICB0aHJlYXRzLg0KPg0KPiAgICAgICAgICAgICAg ICAgIA0KPiAgICAgICAgDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Wed Mar 23 00:25:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5512D695; Wed, 23 Mar 2016 00:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZLlZoYjKdhV; Wed, 23 Mar 2016 00:25:42 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BEE12D691; Wed, 23 Mar 2016 00:25:41 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-a8-56f244f3d44d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.61.16394.3F442F65; Wed, 23 Mar 2016 08:25:39 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 08:25:39 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "cose@ietf.org" , "Ace@ietf.org" Thread-Topic: New Version Notification for draft-selander-ace-object-security-04.txt Thread-Index: AQHRg6KwEZzPkdXlwU+r10cfDXqI5p9moxoA Date: Wed, 23 Mar 2016 07:25:38 +0000 Message-ID: References: <20160321185131.12223.78205.idtracker@ietfa.amsl.com> In-Reply-To: <20160321185131.12223.78205.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7ru5nl09hBh/v6Fp8/9bDbLHv7Xpm i2lbp7I6MHssWfKTKYAxissmJTUnsyy1SN8ugStjwvEfjAVrJCqW7jjL3sB4R7yLkZNDQsBE ovHLASYIW0ziwr31bF2MXBxCAocZJdbP/8cOkhASWMIo0XNMBMRmE3CReNDwCKxBRCBV4sWF zYwgtrBAqMTf39fZIeJhEn8O7YaqMZJo3HgcrIZFQFXiyK7lrCA2r4CFxI8F3WwQ8x0lLt7e wwJicwo4SVx6dxeshhHooO+n1oDNYRYQl7j1ZD7UoQISS/acZ4awRSVePv4HVi8qoCdxu2Mt 0A0cQHEliWlb00BMZgFNifW79CGmWEvsf76JGcJWlJjS/ZAd4hpBiZMzn7BMYBSfhWTZLITu WUi6ZyHpnoWkewEj6ypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwEg7uOW36g7Gy28cDzEK cDAq8fAWnPsYJsSaWFZcmXuIUYKDWUmEN0r1U5gQb0piZVVqUX58UWlOavEhRmkOFiVxXtZP l8OEBNITS1KzU1MLUotgskwcnFINjHaX1S5fXrm8+ZLhyuznPleXdMqU3RR96WZeN9/DrMVT Rcc2SO+lh0XtRnNOo2WXtr2MFAl97fK9ZZPvRjbG+E0/8lg+nvRNdqjUeff21ILnd4WW/FT4 4Xp3RYbrDZXFLWHXGL2PJ1XyGwtec5RheFeZJ+03g1ng9upLtecZdaYa/0018eZcpMRSnJFo qMVcVJwIAPWRihOwAgAA Archived-At: Subject: [core] FW: New Version Notification for draft-selander-ace-object-security-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 23 Mar 2016 07:25:43 -0000 RGVhciBDb1JFLCBDT1NFIGFuZCBBQ0UgV0dzLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRh dGVkIHZlcnNpb24gb2YgT1NDT0FQLg0KDQpGb3IgdGhvc2Ugd2hvIGRvbuKAmXQga25vdywgT1ND T0FQIGlzIGFuIGFwcGxpY2F0aW9uIGxheWVyIHNlY3VyaXR5IHByb3RvY29sDQpmb3IgQ29BUCwg YmFzZWQgb24gd3JhcHBpbmcgcmVxdWVzdCBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgaW4gQ09TRSBv YmplY3RzDQp3aGljaCBhcmUgc2VudCBpbiBhIENvQVAgbWVzc2FnZSBleGNoYW5nZS4NCg0KVGhl IGRyYWZ0IGlzIGVzc2VudGlhbGx5IHJld3JpdHRlbiBidXQgbWFueSBjb21wb25lbnRzIGFyZSB1 bmNoYW5nZWQgc2luY2UNCi0wMy4gVGhlIHJlcXVpcmVtZW50cyBmb3IgZW5kLXRvLWVuZCBzZWN1 cml0eSBhcmUgcmVwbGFjZWQgYnkgdGhlIHJlY2VudGx5DQphbm5vdW5jZWQgZHJhZnQgb24gdGhl IENvUkUgbGlzdCBbMV0uIFRoZSBhZG9wdGlvbiBvZiBDT1NFIGlzIG5vdw0KY29tcGxldGVkLg0K DQpXZSB3b3VsZCBsaWtlIHByZXNlbnQgdGhpcyBhdCB0aGUgQ29SRSBXRyBtZWV0aW5nLCBhbmQg YWxzbyBhIHNob3J0IHNsb3QNCmF0IHRoZSBDT1NFIFdHIG1lZXRpbmcuDQoNClJlZ2FyZHMsDQpH w7ZyYW4NCg0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcnRrZS1j b3JlLWUyZS1zZWN1cml0eS1yZXFzDQoNCg0KDQpPbiAyMDE2LTAzLTIxIDE5OjUxLCAiaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0Kd3JvdGU6DQoN Cj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1 cml0eS0wNC50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdvZXJhbiBT ZWxhbmRlciBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJ ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eQ0KPlJldmlzaW9uOgkwNA0KPlRpdGxl OgkJT2JqZWN0IFNlY3VyaXR5IG9mIENvQVAgKE9TQ09BUCkNCj5Eb2N1bWVudCBkYXRlOgkyMDE2 LTAzLTIxDQo+R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTM0DQo+VVJM OiAgICAgICAgICAgIA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTA0DQo+LnR4dA0KPlN0YXR1czogICAgICAg ICANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zZWxhbmRlci1hY2Ut b2JqZWN0LXNlY3VyaXR5Lw0KPkh0bWxpemVkOiAgICAgICANCj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNA0KPkRpZmY6ICAg ICAgICAgICANCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc2VsYW5k ZXItYWNlLW9iamVjdC1zZWN1cml0eS0wNA0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgbWVtbyBk ZWZpbmVzIE9iamVjdCBTZWN1cml0eSBvZiBDb0FQIChPU0NPQVApLCBhIG1ldGhvZCBmb3INCj4g ICBhcHBsaWNhdGlvbiBsYXllciBwcm90ZWN0aW9uIG9mIG1lc3NhZ2UgZXhjaGFuZ2VzIHdpdGgg dGhlDQo+ICAgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLCB1c2luZyB0 aGUgQ0JPUiBFbmNvZGVkDQo+ICAgTWVzc2FnZSBTeW50YXguICBPU0NPQVAgcHJvdmlkZXMgZW5k LXRvLWVuZCBlbmNyeXB0aW9uLCBpbnRlZ3JpdHkgYW5kDQo+ICAgcmVwbGF5IHByb3RlY3Rpb24g dG8gQ29BUCBwYXlsb2FkLCBvcHRpb25zLCBhbmQgaGVhZGVyIGZpZWxkcywgYXMNCj4gICB3ZWxs IGFzIGEgc2VjdXJlIGJpbmRpbmcgYmV0d2VlbiBDb0FQIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1l c3NhZ2VzLg0KPiAgIFRoZSB1c2Ugb2YgT1NDT0FQIGlzIHNpZ25hbGVkIHdpdGggdGhlIENvQVAg b3B0aW9uIE9iamVjdC1TZWN1cml0eSwNCj4gICBhbHNvIGRlZmluZWQgaW4gdGhpcyBtZW1vLg0K Pg0KPiAgICAgICAgICAgICAgICAgIA0KPiAgICAgICAgDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJt aXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Wed Mar 23 07:51:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A8C12D0B9 for ; Wed, 23 Mar 2016 07:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwDsDx5n6Cqc for ; Wed, 23 Mar 2016 07:51:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D8C12D50B for ; Wed, 23 Mar 2016 07:49:38 -0700 (PDT) Received: from [192.168.10.140] ([47.73.229.30]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LpKrt-1a6Oba3oaj-00f6rt for ; Wed, 23 Mar 2016 15:49:36 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F2AD00.7010407@gmx.net> Date: Wed, 23 Mar 2016 15:49:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HUEINbusDtL77dxKmhGXSWRa9vnroHwL5" X-Provags-ID: V03:K0:waP7GQJMYP+MCGKtomCfN/xGuuriKPZkyHIVuisggfnqhgeDJ72 RRQIWyvBgdykJWodFhYL/B9cllMwPPOeW+V9nBTn29E2SuNZt8rtZzzkKLXiuls4N/YlU4l hOLbJUoqp47iO5eEc4zGyZJXl/gOKG752dWxxBXEjA4+v7T6T+YhaMRfEg7IchzDFuT49dU My0+aLmAgbAwKjLkibqOA== X-UI-Out-Filterresults: notjunk:1;V01:K0:XQMD/4ZeOlY=:egcSMoaiB8MwbNOWb49wWE lXVAwBHgPYWhjvVYobDHTegJ8QuG3FJFxL2aTog/WmsTpAEMtUsjfmcIKkZXiKNO0aS8HJyG9 g9m4WoLmDs1TVLTilfhVUlw6DZy5TD8sZFXAkCVpn9NX/JFX/LMc52CfPCeyIVzUN2zhhJsZb gg5UDaF9mGktXEyXAub+Fr6As46NbbrT9ZPDi+hhmOgFKIhTPOy4D+MNpl2UnLGjcXnFApA8+ IJkIfsp20X5942kBfNHcyH+YOOOSQYPlZ4xcoR5tgPIAWVqzPsZaVwcFpzm/bfYSirN5jc/eC U84STnx5/UfAksWUHba7+E4+tR2UpOZoi4rgKxRXYccAvghUCU/uvZHyHgWVM+mlRx68DNR3B WNMNOAMkaCVoSY+5eGuj+bEuFEdUkZCYwXYhilLWS/4PU7BjmI45eayJrDMdpE51NWX0i8vMR pdE/8ZwpAyvnAJSeGMzY1kf6dSQqxbCIP7kk3ypD/1gJEb/rKQ8ArL+ciK5lRVuMfWaYaCKAr FwzUbl8Sf4trOmnFc8MtgIi8Ev8yvaUI3fCjzH9LsfeKpv+iJRw4ofMWAdHjpRAXwDgacvGhz lEK1YTtzkeE+s+Mb0TvtrbU93QsmOgxMIiMaM+WLmKZDamMYZHrJkjQV72ToUOHAx8vFFzCW2 6Gh3vX1Y4vwCtWOB4CsWK7y7W+4QG4EpV9+CSp6r4hmPjuC6uFwTVymBujZa+3XiljNu64sLz XSb3uEETlVPluuYtCKc5m6Q/J8WmxB3X+X/Kyeh3IdrtowuL4f7mDQ3RpZQ= Archived-At: Subject: [core] draft-koster-core-coap-pubsub-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 23 Mar 2016 14:51:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HUEINbusDtL77dxKmhGXSWRa9vnroHwL5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi authors, Hi all, I was wondering about the status of , which describe functionality to allow "sleeping nodes" to outsource state storage to some other node. Currently draft-koster-core-coap-pubsub-04 is not a working group draft, there is no milestone on the charter, and there has been no update of the document for this IETF meeting. Nevertheless, the CORE charter talks about this item: " CoAP will support various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to a proxy that has subscribed, when the proxy receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. " So, what is the roadmap for this item? The milestones of the CORE WG are, btw, terrible out of date! Ciao Hannes PS: What is the relationship to the draft-zotti-core-sleepy-nodes-04? --HUEINbusDtL77dxKmhGXSWRa9vnroHwL5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW8q0BAAoJEGhJURNOOiAtRJsH/3ZtwDBFhlZzlqCfr8xLJX4p 1c/QkpfotvLxTZh7FYgHIigxHQuCr2qqd2pBYf/IVWk53/UlR2TFN5z28nYbnQA4 IFbpAeltvjUBFwUHHs4//oGqon/2rseyYqrQ6ewG+oG0s+ZyexStr1YU3GO49pJe z1afIplmLLvgduNJuvKzIJT8NMwfVoFjfEnq7aIFbrEE/3iTiaIqZSnb/IP/cfhK B2yhXg2YCzfq1pBC6UeHnPeSBpL1Q0izIHpXnE4Th/cLZ3zHPAO8BThVygD+L+Va t/vE2AqKPi+RlL0988+BS42TtLMHUT6mA51O1Kk8l7U6lhyHvlRT2rc0n9NML4c= =4Y69 -----END PGP SIGNATURE----- --HUEINbusDtL77dxKmhGXSWRa9vnroHwL5-- From nobody Wed Mar 23 08:48:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3500F12D67C for ; Wed, 23 Mar 2016 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 79YxUBV1iuXg for ; Wed, 23 Mar 2016 08:48:32 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB1D12D671 for ; Wed, 23 Mar 2016 08:48:31 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud6.xs4all.net with ESMTP id ZToT1s00u4SmhUa01ToT2Q; Wed, 23 Mar 2016 16:48:28 +0100 Received: from AMontsouris-555-1-25-107.w90-24.abo.wanadoo.fr ([90.24.152.107]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 23 Mar 2016 16:48:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Mar 2016 16:48:27 +0100 From: peter van der Stok To: Hannes Tschofenig Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <56F2AD00.7010407@gmx.net> References: <56F2AD00.7010407@gmx.net> Message-ID: X-Sender: stokcons@xs4all.nl (NRHQtmpRuif+PPnohTfsetQSVEdX7Ks0) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-koster-core-coap-pubsub-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:48:34 -0000 > > PS: What is the relationship to the draft-zotti-core-sleepy-nodes-04? > We wrote sleepy node draft to show that pubsub does not cover all sleepy node aspects. Secondly, I think that pubsub should be developed independent of sleepy node requirements Peter From nobody Fri Mar 25 09:45:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1A12DBA8 for ; Fri, 25 Mar 2016 09:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEggxHSyeaXD for ; Fri, 25 Mar 2016 09:45:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAEE712DB96 for ; Fri, 25 Mar 2016 09:45:05 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M54fe-1Zq1xI2d5S-00zGCt for ; Fri, 25 Mar 2016 17:45:02 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F56B0F.9070508@gmx.net> Date: Fri, 25 Mar 2016 17:45:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r5QxeIoHpCvH19whunNRpRCReMLG1N2iC" X-Provags-ID: V03:K0:FqroAOxntOcRu3dEzsHw8FBPhk/zAUmUx430hXtl8gEycWzpmW+ U1hn8f5glQZ6j5z2lvS1c+GnB0P+LR/CMcDuufm6Q9yTw0Ev9uJQDE/gKnN2Yw/Stz2Ju3G uax3P78Oy0LR64ddqKCTWU6MWZbW5U8yVrhNb1fAP6942aTdiS2ZfdHx5KXOssC++K8Rg+m c2Bl45Vov8NxP4oXnQKnA== X-UI-Out-Filterresults: notjunk:1;V01:K0:7ariPgHuvuQ=:+Dxx4prhO8tu1kuqsOFhv8 KHUfyByrteTlvoGhE1DADaXxScYCioBjAMoPoMvDfPOZQLdn5AUTIlZGrLuB4MrwHoVOaJhot FEwFCTgarmfLTaX3mxXm/+RfiG8SqiJzAZ9Tb61CWioGHtJPBwyzcE1DGzwvyB0f0C2Cr3ERf S9O6afd1tE+6Fo7B6wROLWln4Nid2ZoJ5lNaZmRGbIgg3TE9E1rTfB3HiUOXlBQgTokNd+3Ot mqQkdSb6dEQ/fJYy/ZXIFZTAkYEvYG+7ezQsKNN5+eLv8SAFIsXVYygY6LGVONcJy8s6pCGfO Q4z+kLKvYjPGUOnOD4Co8vZA71Q1qVL0M6FYIaT2kITCwAEgsrwYLHjhiyBpsnQPByU8Q6MN/ /IEg4FvfC9LwFh6ifbg5XaWiOWDifkkdznqvT0knmnh2c23bwR3xG6ZcMCRrNLL3/AmN1TCRX CUC7FvQihyTbI68hq/FN/MoJQxGm2/tW6V81HEu5a8zjKFsjZluN4OfMUhAJ6livxWPf3W31N vFeeSNASFjTyPTKtcj28wI1UaOxHADgHbQ2Zus86lmUJiQADxPKxIn+2WUL+aui1aEXxc2M9p TthYPp6LPmqYLhUCs1mwLbhdm0zJSl3yBYdhj6RmixSsUpVdX1cY6Qir3jkoQRcWF97pEp69J MP3UVAXwRi7AHpttnthtIdHlAepA+BuJN3/9bUNjvIQYIz8UGoTbcxguErnIsXmoDemzCKjM2 vS77LPu7AL7SHXCG9CzR2KYvl5t88nhLuWZJdujGICUFtE2Y1iCz54myJsY= Archived-At: Subject: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 25 Mar 2016 16:45:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r5QxeIoHpCvH19whunNRpRCReMLG1N2iC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I thought I should kick of a discussion about the agenda items for the upcoming IETF meeting. Too early to have that discussion? I don't think so given that the meeting is roughly in a week. I would like to see the following items discussed: 1) Resource Directory 2) CORE Interfaces 3) Block Transfer 4) CoAP over TCP 5) CoAP/HTTP Mapping 6) Representing CoRE Formats in JSON and CBOR Let us try to finish some stuff. For that reason I don't want to see anything else on that agenda. Ciao Hannes --r5QxeIoHpCvH19whunNRpRCReMLG1N2iC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9WsQAAoJEGhJURNOOiAtq8sH/AjmXlGDdQQjt8/4zLoPjJCX YXG2xd+pe/odPFXdv4wwb9JBJc6oZdcLstOVL6Ke6O6+XJVsP2a3j6M+o/gS1/D6 8vRGt1uRa5vLMS4gay9R3jLBp9lVvtIIlMrpzgBQ/vj6vL3KABj7u9j5VMuczNqt l3v3aNs8SwYp4KG4NUsKAPzy4nPeuJkCBpSMNYyf2MSq2s/3l71FJMB5/luYK4+c JgaNOgf3Ga+uZOnjy63aEUh0htFGQhtwd1E8zE4n7d9spxB7cI7XHihPauV/JWcH NVQBYz+ieRB9jQO0Z3asmvfygHPQ7quf2+qNZLjOezbiSuG7zQcx3tQzYD759W4= =BkNU -----END PGP SIGNATURE----- --r5QxeIoHpCvH19whunNRpRCReMLG1N2iC-- From nobody Fri Mar 25 09:59:23 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22C012D118 for ; Fri, 25 Mar 2016 09:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E1lDLWBSeSb for ; Fri, 25 Mar 2016 09:59:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E28F12D0C2 for ; Fri, 25 Mar 2016 09:59:19 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MD9uq-1aXN3o3bJc-00GXMv; Fri, 25 Mar 2016 17:59:09 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "core@ietf.org WG" Message-ID: <56F56E5D.8010202@gmx.net> Date: Fri, 25 Mar 2016 17:59:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IeVmGLtuQlBGiKeTxoRnBJHUBg1Did9de" X-Provags-ID: V03:K0:/GAKB0kRNYILB2swvtdnNck4SqYRsppZcmLjAl7WiaBHKqRTW8e KHUtA+tcL/zCJQdymKl9XFRJ4CUEgkqeuq7zRD7rVRAf6ax/ZGHaFwbgk9DTRcr/ZFvHpkd WS7oSV64fHSKjxA8g2jmukw7XSUkOEDC6G8nrwMfFSKGD/GUkMMZxqyujiySf1Ujus9//Bw 8Ceg5+pCLEYjzfa1Dog8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:nK9rITAkS7I=:P1cEHM4uOJL3l/nZWsCdrk BRm+hZPYSmmbvU/BANTOZRiJUWFaz/pKwOoHOT8NbcRZjRkN3qv0kbYfLc4PC9h14EX1O2ZrL jyO4xN42kr7FFDuMgSYXZiiQ+gvqGOUsF1Z/Y3MtHGFsMh/1MDn+wm2XhAOA0F6TkKP2+PlNF eW+mcNRtQHrq0NT/SLzgVWWtIRh+KN3iW25aZPG1yM/4TaWxpefhyHed8VSuBUtTZVBwnb4PE VtRnItvj4VPYcSuX2jX9P8Pe+SZsgt9SHWzDSWIqng5K7TQMSZ6yD0FrdXFHpkbb3czJsZS4u G0dxUMt5zfEMVZVWYDpMDMHEPPDcp0WyjFOQm1IUX3/ukDEjBcfx+Fwc+eCug1ADvS7AS8HFx vA6nFsuoZJ4VIVD9RKFRnN8DO+zE/PNbOXMvDnvrrD5CHNvoA0N90x1A1aaBRRJMSYJEcSM9a 4bs7Bcv/TKmZqKMJ+jRUUb4QrFEzhtwbBo6Oib2wmPeA9EZOeVhvsrgtEFtDBu6lWR8SUjxmZ grywcKvgF/w64hRpnjkd8P39pmdmQ5WqIB3Z10ZvrMBRh9aMt/WvZy5ENB9HRt2qbLrY6kWAn HCWCKKudJwH55gB5nwpEMWB+JHWmAGx/mvQ2y7ICk3zz549Od786gEPhjrDkTrYr70IK3+k6O D+KjYSG8vTFN2vBa3W5f6TjT9d+2Gwkg3IvXwTVAautVBWTqflS59Ihd6Vs87em265YvURHL2 t5POD1Fs+UMajBA1p9p6HjYfWSHBa7eoK3Qb24tC74dbFbwLpZapCFJGXh4= Archived-At: Subject: [core] CoAP over TCP Status Update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 25 Mar 2016 16:59:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IeVmGLtuQlBGiKeTxoRnBJHUBg1Did9de Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, at the T2TRG meeting, which took place the two days before the IAB IOTSI workshop in Santa Clara, we met with various OIC/OCF guys and talked about ongoing IoT standardization work in the IETF/IRTF as well as in the OIC/OCF. We learned that they have selected a different solution approach for CoAP over TCP: we have selected option L1 from Section 4 of https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 and they have selected option L3. In an off-list mail exchange we also received information about the performance investigations they have done. Here is what we got: > For 4MB data, the transmission time is > > 1. CoAP over TCP L1 + BWT : 70 s > > 2. CoAP over TCP L3 : 1.7 s (BWT =3D Block-Wise Transfer) We have not taken the performance aspect of larger file transfers (e.g., transfer of a 4MB firmware update) into account when we made the solution decision in Yokohama. The reason why the OIC/OCF take such large file transfers into account is because of their desire to use CoAP also for non-constrained devices. I believe it would be good to verify / analyse the performance analysis of the OIC/OCF guys. In particular, it would be reasonable to compare the performance of option L1 and option L3 from Section 4 of https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 with a CoAP protocol stack, such as Californium and the mbed CoAP library. Carsten pointed out that L1 is limited to 64 KiB (which is further reduced by Block's current largest block size of 1 KiB in the analysis above), while L3 allows for larger payloads. Of course, we may not need to use Block Transfer in CoAP when we already use CoAP over TCP. We are trying to find some folks who have time to play around with code during the next week to have a more informed discussion at the upcoming IETF meeting. If you are interested to help please get in touch with us (Carsten, Simon, and myself). Besides this issue there are also some open issues in the tracker: https://tools.ietf.org/wg/core/trac/query?component=3Dcoap-tcp-tls We will drop some mails about these open issues to the list in the hope to get some feedback from you before the IETF meeting. Ciao Hannes --IeVmGLtuQlBGiKeTxoRnBJHUBg1Did9de Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9W5dAAoJEGhJURNOOiAtD0MH/1LpkzPDu/YsOtaBBn0TW22h a2ur69zRRbj9EbvrO+vhGRWBqmpojiFIACQAUgmXtgNtkvwgmmS+HfRUuV+o5pv7 2LgZx3PHT5vTxK+bGkPgkGhXgfGLbqVvD0UlRBKjOUT6xujpHaAxMLC9qzGlkcns UEIKdWraK/jGY2MGbrdRt71j0FNnHTUysu1jwWou9+uQyui/RZX0sL1G+tGyBzoL 0YQ0a2+Nho49x+O+RSSy1/PCUbKvrWFwUvf2D/4gwvrmqtUYuFvuP0NPvW6p0mbL 6GvR8wmqqljnNrT/mXLeVrhd3v7ysj2qZKJp1rgK22CSiP3IppddAY4jO5EGcMY= =/u2Y -----END PGP SIGNATURE----- --IeVmGLtuQlBGiKeTxoRnBJHUBg1Did9de-- From nobody Fri Mar 25 10:33:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6512D11E for ; Fri, 25 Mar 2016 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 UrVAu_3PBZn3 for ; Fri, 25 Mar 2016 10:33:32 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C2F12D0DC for ; Fri, 25 Mar 2016 10:33:32 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:79ee:2fc8:6532:b29a] (unknown [IPv6:2001:660:7301:3728:79ee:2fc8:6532:b29a]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 2043017209B; Fri, 25 Mar 2016 18:33:29 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_79C9977E-55CD-4366-8EA7-951AE32FF528" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alexander Pelov In-Reply-To: <56F56B0F.9070508@gmx.net> Date: Fri, 25 Mar 2016 18:33:29 +0100 Message-Id: <319625C5-110D-49F5-8348-6B9B1F0C9CE2@ackl.io> References: <56F56B0F.9070508@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 25 Mar 2016 17:33:34 -0000 --Apple-Mail=_79C9977E-55CD-4366-8EA7-951AE32FF528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Hannes, Thanks for starting the discussion on the ML. To your list of items I would add the following topic: *) CoOL protocol for constrained device management In view of the 4 drafts and the management tool that have been released = two weeks ago.=20 = https://datatracker.ietf.org/doc/draft-turner-core-cool-problem-statement/= = https://datatracker.ietf.org/doc/draft-somaraju-core-sid/ = =20 https://datatracker.ietf.org/doc/draft-veillette-core-yang-cbor-mapping/ = = =20 https://datatracker.ietf.org/doc/draft-veillette-core-cool/ = https://github.com/lemikev/pyang/blob/master/pyang/plugins/sid.py = I share without reserves your will to get the work done and I am very = happy to be on the same page with you on this. Let=E2=80=99s keep it = lean and get to the running code. Best, Alexander > Le 25 mars 2016 =C3=A0 17:45, Hannes Tschofenig = a =C3=A9crit : >=20 > Hi all, >=20 > I thought I should kick of a discussion about the agenda items for the > upcoming IETF meeting. Too early to have that discussion? I don't = think > so given that the meeting is roughly in a week. >=20 > I would like to see the following items discussed: >=20 > 1) Resource Directory > 2) CORE Interfaces > 3) Block Transfer > 4) CoAP over TCP > 5) CoAP/HTTP Mapping > 6) Representing CoRE Formats in JSON and CBOR >=20 > Let us try to finish some stuff. >=20 > For that reason I don't want to see anything else on that agenda. >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_79C9977E-55CD-4366-8EA7-951AE32FF528 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Hannes,

Thanks for starting the discussion on the ML.

To your list of items I = would add the following topic:
*) CoOL protocol for = constrained device management

In view of the 4 drafts and the = management tool that have been released two weeks ago. 
https://datatracker.ietf.org/doc/draft-turner-core-cool-problem= -statement/
https://datatracker.ietf.org/doc/draft-somaraju-core-sid/&n= bsp;
https://datatracker.ietf.org/doc/draft-veillette-core-yang-cbor= -mapping/ 
https://datatracker.ietf.org/doc/draft-veillette-core-cool/=
https://github.com/lemikev/pyang/blob/master/pyang/plugins/sid.= py

I share = without reserves your will to get the work done and I am very happy to = be on the same page with you on this. Let=E2=80=99s keep it lean and get = to the running code.

Best,
Alexander



Le = 25 mars 2016 =C3=A0 17:45, Hannes Tschofenig <hannes.tschofenig@gmx.net> a =C3=A9crit :

Hi = all,

I thought I should kick of a = discussion about the agenda items for the
upcoming IETF = meeting. Too early to have that discussion? I don't think
so= given that the meeting is roughly in a week.

I would like to see the following items discussed:

1) Resource Directory
2) CORE = Interfaces
3) Block Transfer
4) CoAP over = TCP
5) CoAP/HTTP Mapping
6) Representing = CoRE Formats in JSON and CBOR

Let us try to = finish some stuff.

For that reason I don't = want to see anything else on that agenda.

Ciao
Hannes

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

= --Apple-Mail=_79C9977E-55CD-4366-8EA7-951AE32FF528-- From nobody Fri Mar 25 12:05:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8DE12D676 for ; Fri, 25 Mar 2016 12:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRxLVCA69YW0 for ; Fri, 25 Mar 2016 12:05:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA1112D18B for ; Fri, 25 Mar 2016 12:05:11 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LlESk-1a9eGB12ZC-00b0T8 for ; Fri, 25 Mar 2016 20:05:09 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F58BE5.7050400@gmx.net> Date: Fri, 25 Mar 2016 20:05:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JeSbW7mmeIqgPNeVv7JJp4gwDOwgufhfe" X-Provags-ID: V03:K0:mOIzlDML3M5iRXM0TRR7xpb5roG4kJxaqZhsd/euJF1CAO9VScx QTF80xZQEQJ6uzeir29fW9rtujgYWOcZ86I8HkshaMtHN1H6lhdxqzCqMU7xNKvER91qnjV F7ziKlJU0cDaFHe6FjIN5GeQObSn/LehpBhR0EyX9ZHuNmtU8XWgkYl5k/IEoP6ktM6nEwH z0fh6dh5JCi5KiMPY++lw== X-UI-Out-Filterresults: notjunk:1;V01:K0:51+5CBnFEIc=:hA5eRrA3qwigi+Lh4RVU77 3frWTe59z4FaUqoJRjeAs7CcjvtFxzniLRUCsuMiGOy3iAdcE7+mexQgk7O8SkYqQEBO/ecqi uYQBRee1++q1NQ0RayP+xxrzKNjNQOMfqxl0qAH45klttdYxE28qdfQn927oBchmGIgIe0iX7 lwwXnV/M24e3Fgo+sHXoQO3P+Zig/3dK6b0bEJFJ6bUtUii65SMRhQvOXYQrszT7TbPvUkoBv YKq9Zxk9hkDi8bX50Co9lnoFsPFKJPRq1dWJH8FHu/ts9tdnuHAGMfzQoR/uNZIPGe2p6RRV3 K7MJioUFZVDFYy5gbwSgbtsbbnf4VssBVPmwKTQDm7L6VpCzs6m8VTPLtkq6gyNhLcOotgNOT aVRMSBEUbBtHptI6SW97FxvLiQN+sLkiO6f6S2DSJNSSgQi/N+GCayV1hfeV1qatsplHoo7Al GsPLPbtBaZJIQ2rBZREj2ti3EBrDrOMyKwJsYs10w+Rpxt4F5jkURmI7/jyz6+l24p0oEahio uuIbuSD+Rv6Xnd3j3FdQYYG2VWqd5/wZW3tcECoANLwQ9sjxLstH8Z+rELx1hT5RColz3EVpV ObD9J0/F4ecro7BCLCkYP+Z4W0751lIFdQVb74jCRaqjkn6WXBpbbPiYBYvG+zZ78ST71HBEm QRHKzNCqYZkH8yEdOgJtbZcQwtda9X+ug+Qxs+oimdKZR0Frcz6EwS8ixntCidDMUuNEbpjLU BDs7sO57tnrSvd/30IePSH8eqh2juE8a6Y+mqqnPv/MuJlCeM1froXW4b+4= Archived-At: Subject: [core] Ticket #394 - CoAP over TCP: Server name indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 25 Mar 2016 19:05:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JeSbW7mmeIqgPNeVv7JJp4gwDOwgufhfe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In https://trac.tools.ietf.org/wg/core/trac/ticket/391 Klaus provided feedback for the CoAP over TCP draft and wrote: " Should the FQDN of the server be set during connection setup (e.g., using the TLS Server Name Indication (SNI) extension), or should the FQDN of the server be specified in each request? " The FQDN for the SNI is set during the TLS/DTLS handshake (in the ClientHello). The client cannot convey the SNI later in the exchange. The SNI is most often used in hosting deployments where multiple virtual servers are run on single IP address. Ciao Hannes --JeSbW7mmeIqgPNeVv7JJp4gwDOwgufhfe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9YvmAAoJEGhJURNOOiAtqc8H/AhDGQgH9Qv8ZLB44cDDLt2y p0WBMHPXGXwN8rC82wsbvrX+l/No+asj4FiS6DXWyM9vk/XgCWyP9ZnPSGpC4eMD UAqaDAAkQOnrOJXpYrENGCfvfqmIn6UN+wO2z/HsM6mxf1KiGtfwlbJm/EFk+kmc MntZptg1uYCzwMNpVdls48/2Z6uDJ7r+/RIYg8W0a5ixt7iymaztx95S6YQc2S4o 3KRzNq9ocoKqNPM0cK+U9JSwgXunVpC0iTxgwxrmTsF6qeolA+xEj0sBMopMGQb8 r+e0vkJr9FrtHFm7cQ09KuSArK+l9mlq88EfjKCNr4/wktwcDYbOwTJxRzlwcH0= =5zsC -----END PGP SIGNATURE----- --JeSbW7mmeIqgPNeVv7JJp4gwDOwgufhfe-- From nobody Fri Mar 25 12:05:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8D12D18B for ; Fri, 25 Mar 2016 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzVsT7-BjAcg for ; Fri, 25 Mar 2016 12:05:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A0212D66B for ; Fri, 25 Mar 2016 12:05:17 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MKIEQ-1aiz523ZR8-001fdQ for ; Fri, 25 Mar 2016 20:05:15 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F58BEC.60502@gmx.net> Date: Fri, 25 Mar 2016 20:05:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lIkLx8eWq0w0LnIbhraLMIX0uP1NqSEUm" X-Provags-ID: V03:K0:keP8A0YKLFOGvtxgIw8vw1Mpf9l5s/8MtowCjtiP+qJXz+s8/DS BvtLpwyoZUcQF+A3JrS06J2FML9vRhela72wsqkJtIfm8sAhMda3Bx0fnalTuk6X0fD+Al+ tEhoso/8KTY91PHWDhUmWFPwj9jLKAye1E+8Snz9vteIEXu4/XLX8V1fxRDI8v3fvbmZiza NDBCbnZIesPNbYvIHnj1g== X-UI-Out-Filterresults: notjunk:1;V01:K0:WQi+IRbHHnk=:Z6ekC+oroCz8xPV7YP2Gv3 gc2XKjAd09NG8rlhgrO2z5Suz108jtfGrHp44tllodaqnEwrmnhWyFqnEvKKOp54ykva2bkgq CXua/Enjgl1K2kL7cSF1p+G7PKslPk+4HYuMZEPMkneYlzG86yyFJXVjQ+JWEGEA1nq6X2yt3 Bz4Vidt/fsjpHFplCZTNWXaehY7VCXJ7/u86mENzQoKdVNLXaQyPSOeaM6twMa4Ck+rY1JJIa ILKDv8GJGBGuKn6u1lgSwJfR7VNDeWoEZhW4ULvrO/qmiYYolwUxr1gVy0j2kVcYwPGJ9s1VU 2v+ew3D6InIW5PiEnLGOpUapupHYq46SgZH3vP574z9ckM62zuJr2AMtVHQlyzx5Z5AGdej+w OKmRQlo94gxfiniiJKLakbCEpi5OQNVNQhvLf8HmbEkbIRLgZBiFZZKPtE+EuA7ZRdoweY3Lo 1q+vz8pnurfLMls5G6aHuH+AzXkDQ3CkQi0l1iF6pYy9rUKfuZf3POQmR8dxF+a/tUiVKlC+h I4jVNp3s5VPNd5JrISX1uCjSPnQ+j+hl662XTfI3N9hj6QwF6ByiYMfWVuMd9CNOwNZoLw9W5 a+XQvQnKjqyakEbwADW99cq+yR8Rfj9bmgXKmM+pgLjR1vIca5hKbh98zpGEjiNNSFDRJifMh +Y5hyMS1BmNG11udnKZST1olYZKS1Lob2LCHF47TQpmiD4S2jRfPtPjNG9ZRkOBS+K9xQS7Me fxMQZVWDdlZZlc17nenz1upCE7uY8WGmRFzEtV9NTE6pI5XTBsu0h+riZxU= Archived-At: Subject: [core] Ticket #394 - CoAP over TCP: Ping/pong X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 25 Mar 2016 19:05:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lIkLx8eWq0w0LnIbhraLMIX0uP1NqSEUm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In https://trac.tools.ietf.org/wg/core/trac/ticket/394 Klaus provided feedback for the CoAP over TCP draft and wrote: " Do we need ping/pong messages to keep an idle connection alive through NA= Ts? " There are various options for doing keeping state at NATs (and stateful packet filtering firewalls) alive: - Normally, an application performs retransmissions to keep state information alive (at the server side and also at intermediate devices). - TCP also offers a keep-alive message. - There is functionality in TLS (the heartbeat messages) that allow a state to be kept alive but those are obviously only available when you use TLS/DTLS. The DTLS/TLS profile document talks about those. It would be interesting to hear what the experience with these mechanisms is. I will check with our guys. Does anyone have feedback? Ciao Hannes --lIkLx8eWq0w0LnIbhraLMIX0uP1NqSEUm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9YvsAAoJEGhJURNOOiAtdB0H/034OfRnbmrTifwT5/z3GXi5 C9+NqovP1Aogceq+tMz53GCXS4F619Xm943Xc10Gq45SL3mv48zq8MRasmgdywTc 24YuPPBFm4z/j6OogqFAGo6kh6PX47PhL8mNB9uf4BNLoFDvVeyPUtfYOum2RSos lURJq9ISQWRG3eOjyFM/j9uQdbP2p/M6CoEZbPjjB1OX14zF7fR1Sah9SUbQzTa3 tP6KefjYl5azoxioj52n6/WWNYMK/piDYgcLd6TG5qFqtfLuoCz9PTgPtom585P6 TADTewgh3fNdiwYc4QT8vuky9YhZQ363xufg7XX6c6RzzhsJqB9pFIDlkN6VV+4= =QSKx -----END PGP SIGNATURE----- --lIkLx8eWq0w0LnIbhraLMIX0uP1NqSEUm-- From nobody Fri Mar 25 12:05:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C0912D668 for ; Fri, 25 Mar 2016 12:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dvg6HtlfeEcj for ; Fri, 25 Mar 2016 12:05:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF19112D68B for ; Fri, 25 Mar 2016 12:05:31 -0700 (PDT) Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MBWo2-1aaDdn3pIM-00AVEq; Fri, 25 Mar 2016 20:05:22 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F58BF2.2070203@gmx.net> Date: Fri, 25 Mar 2016 20:05:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rm8u7bd0nkxKgoLTS3vP2qMqeb1OAuX3Q" X-Provags-ID: V03:K0:XAnWnPhN1ehxkS6OyJ1Q2dxIpLb4yl+JD2eeZcAIaYSjn4Au3sJ erQVb1hNQn99oZE1j0EiX3cc3vH9BfIwtF6OcPkt5s1oKDoy6CMkw5/eCzRmRxhbCCiU/uN +1xlPt6kG6Wa59RNBzNU1iGIe2SgTaClIetXt5PKTBD6vVghTMoy6t9CQ2zcVUBiBEk2f1g efxJXqyuQdzhkSS7x+ECA== X-UI-Out-Filterresults: notjunk:1;V01:K0:q7mmxPlHbJI=:PExOL8taS1fXQjW6Rx15AW m2A+irmReCJyZon4fWQXiM6niMC849j0GSGGBe5BjhO8XjgmP4DUnhUHHz+v4zyJBmAywvRpE scT/pE6b3YSLt9YxLykwE0fFZ/0dGcMvt8NCLiGv3bG4rV97AO/KNZCiwNIrQ+ySrIHXw9Qzb jlZlYD2ZUbVaQNrQy1Hnum792gVmmpzhTzoIsJsqHegO6yOPc0HRZynnx22VrpsGnL0pZAz1T UsaeKuzAnfNvTlZMIrQ3qI/Il2DtXxHhTFSk5CtxqjuACrtW3KDEcj/FC7B7X9JeEXkIFn2HD VdJUhEsna/u939iC2iq0kQBhZWR5vRIv3IQLWNC+EfURU5ngv8ZThlT8w4ZQNUsl3+ciYEYou CvhCI8H+gBBTtwPExGjh2mG8LW11j6Vth6xXMsWJYgAwMgkK+j/DG8AieMy6Mv6wLVcu/9eci wVeMXUHdpgw14cd7DQ+XM4vVjj0keeKidrQv7AdX9qXYACMURgRi7RSWv2mrOwNP1UbTyn/wE 8Sb5CSKjsfDa8qoeEfpVVR3C0KRXKFKereN2HRe+pAAHY6tihO4eEHp5pfnqDBeR8wyanqE+w FZKavdX+xIqp8aTFlasCgVyVK1BZi5ZGqLmuoyPVojtnakf1M/RpuTZPOOx5Ux/4UAb1Xbs5r KNWUDftx0lg65FjZR8nUJXv++ubqJNz+eNBPIdKOiEpy9//4RTD8c0Az8dvJDwAKWgzroCkC6 CGqhd9+aA1bRDAbLFZ2k27irzeG0X2H5M0PzS5bGMCGAVdKUfR1lCTZM28Q= Archived-At: Cc: Klaus Hartke Subject: [core] Ticket #395 - CoAP over TCP: Session Resumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 25 Mar 2016 19:05:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rm8u7bd0nkxKgoLTS3vP2qMqeb1OAuX3Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In https://trac.tools.ietf.org/wg/core/trac/ticket/395 Klaus provided feedback for the CoAP over TCP draft and wrote: " Should each connection be independent from all other connections, or should it be possible to set up a connection (e.g., registering to observe multiple resources), disconnect and resume the connection at a later time? (I'm leaning towards independent connections.) " When DTLS / TLS client communicates with a server then it typically establishes a session cache to allow session resumption. This is a feature that is recommended to be used in the DTLS profile document. There is also an additional version of the session resumption that does not require the server to maintain any session state but the state is stored in a ticket, cached at the client and later presented. This feature is called 'session resumption without server-side state' and defined in RFC 5077. In any case, if there is already cached information established from a prior exchange then the client should try to re-use that information to accelerate the TLS handshake. The performance benefit are large when a ciphersuite with public key cryptography is used during the full handshak= e. My recommendation is to follow the guidance given in the DTLS profile. I do, however, believe it would be useful to reference the DTLS profile draft and to reference the appropriate section. Did I correctly address your feedback? Ciao Hannes --rm8u7bd0nkxKgoLTS3vP2qMqeb1OAuX3Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9YvzAAoJEGhJURNOOiAt6lQH/32XPokd9N4F5SXu2PrQHY7l FSXZMSdo4vRtyU0Qubh9SC/cFVlYOQTsyxsZdDG0nMUdRluXZCfFvfDfnlpNg5al /rLMCxEw6bzMjrCDmv51Asvct/u00cySeO1yyq/Vk5YGQOrn4aCC/7gW2IX1yzKS /3np7zO9ujhRnTskg2SMPBoM7W5tJWZyfl0j6Gtpv2QQZOMGd+yqNOVCxkB3JCGz g2Fyp+wkfOBEB5iRWKiOFIjkRckuc0F5o7EPAd971YPiwesNrxI3CXgH3ny8fB0S UbrPqIYtYBwniCxDfpwT4oxVsdar648417Av/elASPEXL8i2iiPHa2yduVkCDeo= =tE+5 -----END PGP SIGNATURE----- --rm8u7bd0nkxKgoLTS3vP2qMqeb1OAuX3Q-- From nobody Sat Mar 26 04:02:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3C812D107 for ; Sat, 26 Mar 2016 04:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jBUM0tkofytx for ; Sat, 26 Mar 2016 04:02:35 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 B406912D0BA for ; Sat, 26 Mar 2016 04:02:34 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so38522073wml.0 for ; Sat, 26 Mar 2016 04:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gUelyxZsBxcNjj7ExMH0jOFMozFCmyJtJZiMkBYWl74=; b=kPTaaZfv8Kfbu8h6vb8LSgB5v1derVoapWx9jxR/yt0xC9MSw0uRVkz+45Bt7jT3VO YzKW6K1CqWTHqy4DwIiEqPJTWg2+rR+jbIqQ0F3NZZjrml1GVzI1dSSoUNF+u9NZXaDZ Sw6lT+fyIadnxf5Xm67fdPEo77TonLGRDuCbj6QO0dSpKxA3QBLZOZV6z9NcJfZ3hXPY 2MLz7aKCNBGp0EAqWhyFmTvOky8sHhsAm0Zt3H1jb5gn4vXgHhpqUX+t52gq74v/0lx3 4Wt/vNByb2Rheu7TgZwPOkTUjaidkwiJbGNWHPHP7+6X9CsNsMaau2qnN30jdXj8GD5r N/Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gUelyxZsBxcNjj7ExMH0jOFMozFCmyJtJZiMkBYWl74=; b=mXjS6bfH7gKXqGTkzbS+SH1OU5c2YIx8sFLf59SGXknk2Kf3HedfampXVvIYan2v59 372BOBUqw46/nFx15H16ly5+hBhheWQHzKQ1r7ikMrgYSIm/1KTSlraNAbU5KEPfnCQ8 pUTMWdUSCtC4cKDfSGDg4rjUO7/nk7GEesSIqB3hHU3PM1upSjONIrM0dboeUrLs7exv Y2uJCKk/TX51vi8J+2XNmUBkPXndMnTitluNk8xEumqrLpxb5RqQSyZ0oEeMT5jUaARH tjKZNPhDSv42X/wJVmmLPudtbKED+8qzGvkDoD1ZWVClV/dpGEv3SHtgoTLz5uzYgZxr EVAw== X-Gm-Message-State: AD7BkJKKbnD+q1Wh/b/+ebJdxRYY5m/IBCV4PdLm37x1/zBCJnGXXu/Fq1EcNQHVsqUptxI5RujBylqYA/I0+Q== X-Received: by 10.28.225.198 with SMTP id y189mr1404906wmg.94.1458990153264; Sat, 26 Mar 2016 04:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.84 with HTTP; Sat, 26 Mar 2016 04:02:13 -0700 (PDT) In-Reply-To: <56F58BEC.60502@gmx.net> References: <56F58BEC.60502@gmx.net> From: Julien Vermillard Date: Sat, 26 Mar 2016 12:02:13 +0100 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a114b0c88d0f4e5052ef19d4b Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #394 - CoAP over TCP: Ping/pong X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 11:02:36 -0000 --001a114b0c88d0f4e5052ef19d4b Content-Type: text/plain; charset=UTF-8 Hi, > TCP also offers a keep-alive message. This a "optional" feature and it's filtered on cellular network, so I never use it outside of local networks. HTH -- Julien Vermillard On Fri, Mar 25, 2016 at 8:05 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > In https://trac.tools.ietf.org/wg/core/trac/ticket/394 Klaus provided > feedback for the CoAP over TCP draft and wrote: > > " > Do we need ping/pong messages to keep an idle connection alive through > NATs? > " > > There are various options for doing keeping state at NATs (and stateful > packet filtering firewalls) alive: > > - Normally, an application performs retransmissions to keep state > information alive (at the server side and also at intermediate devices). > > - TCP also offers a keep-alive message. > > - There is functionality in TLS (the heartbeat messages) that allow a > state to be kept alive but those are obviously only available when you > use TLS/DTLS. The DTLS/TLS profile document talks about those. > > It would be interesting to hear what the experience with these > mechanisms is. I will check with our guys. Does anyone have feedback? > > Ciao > Hannes > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a114b0c88d0f4e5052ef19d4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


=C2=A0 > TCP also offers a keep-alive message.

This a "option= al" feature and it's filtered on cellular network, so I never use = it outside of local networks.

HTH

--
Julien Vermillard

On Fri, Mar 25, 2016 at 8:05 PM, Hannes Tsch= ofenig <hannes.tschofenig@gmx.net> wrote:
In https://trac.tools.iet= f.org/wg/core/trac/ticket/394 Klaus provided
feedback for the CoAP over TCP draft and wrote:

"
Do we need ping/pong messages to keep an idle connection alive through NATs= ?
"

There are various options for doing keeping state at NATs (and stateful
packet filtering firewalls) alive:

- Normally, an application performs retransmissions to keep state
information alive (at the server side and also at intermediate devices).
- TCP also offers a keep-alive message.

- There is functionality in TLS (the heartbeat messages) that allow a
state to be kept alive but those are obviously only available when you
use TLS/DTLS. The DTLS/TLS profile document talks about those.

It would be interesting to hear what the experience with these
mechanisms is. I will check with our guys. Does anyone have feedback?

Ciao
Hannes



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


--001a114b0c88d0f4e5052ef19d4b-- From nobody Sat Mar 26 04:46:23 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A352D12D107 for ; Sat, 26 Mar 2016 04:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 QDZcw72jP9C3 for ; Sat, 26 Mar 2016 04:46:21 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2616712D0F7 for ; Sat, 26 Mar 2016 04:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1458992780; d=isode.com; s=selector; i=@isode.com; bh=ZhWI/6F+0tKtk7xQS1SXUQ1mh2KHaRY7VePXV42/Eew=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=P3JQqFV/7qQuQSi01WLdnyUU+9UUYxNViWLxGS4YUEX5UEMkG4+bh4dUH+iEqFawrkHkoS zQEjjmfmPQ5mnnRHAki/uzJ6wr3OVZDsQ/LjagNnD63CA6pjweIxx94xli9+nKFQQgbdca 6Fk+2uhIH0FIOmX5GTl1CHqr6ND/MHY=; Received: from [10.11.157.131] ((unknown) [85.255.235.68]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 26 Mar 2016 11:46:19 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13D15) In-Reply-To: <56F56B0F.9070508@gmx.net> Date: Sat, 26 Mar 2016 11:45:58 +0000 Message-Id: References: <56F56B0F.9070508@gmx.net> To: "core@ietf.org WG" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 11:46:22 -0000 Hi, > On 25 Mar 2016, at 16:45, Hannes Tschofenig wr= ote: >=20 > I would like to see the following items discussed: >=20 > 1) Resource Directory > 2) CORE Interfaces > 3) Block Transfer > 4) CoAP over TCP > 5) CoAP/HTTP Mapping > 6) Representing CoRE Formats in JSON and CBOR >=20 > Let us try to finish some stuff. As your WG future responsible Area Director: +100. From nobody Sat Mar 26 04:48:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D693612D107 for ; Sat, 26 Mar 2016 04:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pP98oYBN6maw for ; Sat, 26 Mar 2016 04:48:25 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE30512D0F7 for ; Sat, 26 Mar 2016 04:48:24 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.211]) by smtp-cloud6.xs4all.net with ESMTP id aboN1s00C4ZF39u01boNbB; Sat, 26 Mar 2016 12:48:22 +0100 Received: from 2001:983:a264:1:249b:5a2:ff84:f6bf by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 26 Mar 2016 12:48:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 26 Mar 2016 12:48:22 +0100 From: peter van der Stok To: Hannes Tschofenig , Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <56F56B0F.9070508@gmx.net> References: <56F56B0F.9070508@gmx.net> Message-ID: <39451530450b303e51a473da4f9ab20d@xs4all.nl> X-Sender: stokcons@xs4all.nl (jesjU++r4G8QqW2or0CBpxTG9JqeesZ8) User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 11:48:28 -0000 Hi Hannes, I do sympathize with your wish to get stuff finished. I also understand your choice. However, it is more than getting things on the agenda and nothing but that. What are the goals: Do you want all development on the drafts stopped, WGLC called and only big mistakes removed and phrases improved? Or just consensus on the end goals of the documents, and authors decide what comments are in scope? Or just a time of 1 month after which the drafts are finished, full stop? Or ..... Can you elaborate a bit? Peter Hannes Tschofenig schreef op 2016-03-25 17:45: > Hi all, > > I thought I should kick of a discussion about the agenda items for the > upcoming IETF meeting. Too early to have that discussion? I don't think > so given that the meeting is roughly in a week. > > I would like to see the following items discussed: > > 1) Resource Directory > 2) CORE Interfaces > 3) Block Transfer > 4) CoAP over TCP > 5) CoAP/HTTP Mapping > 6) Representing CoRE Formats in JSON and CBOR > > Let us try to finish some stuff. > > For that reason I don't want to see anything else on that agenda. > > Ciao > Hannes > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Mar 26 06:24:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900F112D5E2 for ; Sat, 26 Mar 2016 06:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 SL4oLU-mXD3b for ; Sat, 26 Mar 2016 06:23:52 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6812D5B8 for ; Sat, 26 Mar 2016 06:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1458998631; d=isode.com; s=selector; i=@isode.com; bh=C8pEcEs+x3ORawEr7+tU9yWXND0fMdRYfPwfp509y8E=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=v3xM3rwFOwSono4BKPGDPfVYbkTjyGtdfinG8YdTdOY79yGVjGrtl9/xYTaL0Vd6efsVPh l3F55iUC02F2nDu0W1hGpcAmfeRtRGSukxWkVoq9+pVnNZZv9IM/nmTbQ5iZzma5cE8+08 6SU1WRGWcODQIMMrQd+vqyoahatGvDI=; Received: from [10.11.157.131] ((unknown) [85.255.235.68]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 26 Mar 2016 13:23:50 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13D15) In-Reply-To: <39451530450b303e51a473da4f9ab20d@xs4all.nl> Date: Sat, 26 Mar 2016 13:26:41 +0000 Message-Id: References: <56F56B0F.9070508@gmx.net> <39451530450b303e51a473da4f9ab20d@xs4all.nl> To: consultancy@vanderstok.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 13:23:53 -0000 Peter, Just to comment about what is on the agenda versa what is being worked on: n= ot having a document on agenda of s face-to-face meeting doesn't mean that a= ll work need to stop on such document. Chairs should reply to the rest of your questions. > On 26 Mar 2016, at 11:48, peter van der Stok wrote: >=20 > Hi Hannes, >=20 > I do sympathize with your wish to get stuff finished. > I also understand your choice. > However, it is more than getting things on the agenda and nothing but that= . >=20 > What are the goals: > Do you want all development on the drafts stopped, WGLC called and only bi= g mistakes removed and phrases improved? > Or just consensus on the end goals of the documents, and authors decide wh= at comments are in scope? > Or just a time of 1 month after which the drafts are finished, full stop? > Or ..... >=20 > Can you elaborate a bit? >=20 > Peter >=20 > Hannes Tschofenig schreef op 2016-03-25 17:45: >> Hi all, >> I thought I should kick of a discussion about the agenda items for the >> upcoming IETF meeting. Too early to have that discussion? I don't think >> so given that the meeting is roughly in a week. >> I would like to see the following items discussed: >> 1) Resource Directory >> 2) CORE Interfaces >> 3) Block Transfer >> 4) CoAP over TCP >> 5) CoAP/HTTP Mapping >> 6) Representing CoRE Formats in JSON and CBOR >> Let us try to finish some stuff. >> For that reason I don't want to see anything else on that agenda. >> Ciao >> Hannes >> _______________________________________________ >> 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 Sat Mar 26 06:40:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884E212D5E4 for ; Sat, 26 Mar 2016 06:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YPq3Op5m8Yav for ; Sat, 26 Mar 2016 06:39:59 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA6312D14A for ; Sat, 26 Mar 2016 06:39:59 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.211]) by smtp-cloud6.xs4all.net with ESMTP id adfw1s00c4ZF39u01dfwgT; Sat, 26 Mar 2016 14:39:56 +0100 Received: from 2001:983:a264:1:249b:5a2:ff84:f6bf by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 26 Mar 2016 14:39:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 26 Mar 2016 14:39:56 +0100 From: peter van der Stok To: Alexey Melnikov Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <56F56B0F.9070508@gmx.net> <39451530450b303e51a473da4f9ab20d@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (S0WP6mrPzcUyK7YPJEjW9+wGGdY3FG/M) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 13:40:02 -0000 Hi Alexey, few words inline Alexey Melnikov schreef op 2016-03-26 14:26: > Peter, > > Just to comment about what is on the agenda versa what is being worked > on: not having a document on agenda of s face-to-face meeting doesn't > mean that all work need to stop on such document. We fully agree. no discussion. > > Chairs should reply to the rest of your questions. My question was to Hannes how he thinks we should try to get movement in the proposed drafts. According to me each draft has a different history with changes. My suggestions are meant to start the discussion. May be we can come to a set of topics to be filled in by each author to define a horizon (content-wise or time-wise) for each draft. Peter > >> On 26 Mar 2016, at 11:48, peter van der Stok >> wrote: >> >> Hi Hannes, >> >> I do sympathize with your wish to get stuff finished. >> I also understand your choice. >> However, it is more than getting things on the agenda and nothing but >> that. >> >> What are the goals: >> Do you want all development on the drafts stopped, WGLC called and >> only big mistakes removed and phrases improved? >> Or just consensus on the end goals of the documents, and authors >> decide what comments are in scope? >> Or just a time of 1 month after which the drafts are finished, full >> stop? >> Or ..... >> >> Can you elaborate a bit? >> >> Peter >> >> Hannes Tschofenig schreef op 2016-03-25 17:45: >>> Hi all, >>> I thought I should kick of a discussion about the agenda items for >>> the >>> upcoming IETF meeting. Too early to have that discussion? I don't >>> think >>> so given that the meeting is roughly in a week. >>> I would like to see the following items discussed: >>> 1) Resource Directory >>> 2) CORE Interfaces >>> 3) Block Transfer >>> 4) CoAP over TCP >>> 5) CoAP/HTTP Mapping >>> 6) Representing CoRE Formats in JSON and CBOR >>> Let us try to finish some stuff. >>> For that reason I don't want to see anything else on that agenda. >>> Ciao >>> Hannes >>> _______________________________________________ >>> 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 From nobody Sat Mar 26 06:51:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E032912D601 for ; Sat, 26 Mar 2016 06:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWe_83PgLW4u for ; Sat, 26 Mar 2016 06:51:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6F312D5FE for ; Sat, 26 Mar 2016 06:51:35 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MOx4J-1ae1bS3L7f-006KUz; Sat, 26 Mar 2016 14:51:30 +0100 To: consultancy@vanderstok.org, Core References: <56F56B0F.9070508@gmx.net> <39451530450b303e51a473da4f9ab20d@xs4all.nl> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F693E3.2050306@gmx.net> Date: Sat, 26 Mar 2016 14:51:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <39451530450b303e51a473da4f9ab20d@xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MgXEO9jblWs62nNNgL8onxMu5ruJc3MK7" X-Provags-ID: V03:K0:+sUDVZ5r3/kGGKAZGv7MTlXWZKph/k3gs+HKUTBUZv+QtUMh2nP j69S4ZSFoDj5TEoJQuXuBfyN0Wq4QO5FqgxaGRnQr0q/a2ZtcP28SMNHG7CNJ1yCjJRvl7U EeQTkH+ec/Pz7iRdcQtGWAfTaFtO3y41qubUim1njEOxLqRJ61oFBkK7WHN8NK2jCY0qSsv /51DfD8ICwTvQC+juUY4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:QMf9Rvrxv3Y=:jhdKUET+St7jaVLNOFR5Nq zVP0cjYpmCsjNQf8jKbv08Ww2wImN3IaOiiy75HxIPcArEYrBs+k/naQmi6VcDPr/+q6tr8hu /MpkJtPsKInhmHmxlJO+N/6nvN/G7LfGSG7fADv15QL2PMY2vUL+r/FhpBJJyIHKFByTEz0xl RuZ0rOgp1DYlKhXBMcnky+nHn8KDcTVYF2oGVZCfnb/3Gg27nIfl/FkNCjRazAewQd7+Nhmfq YpzX6aIAkltLLhsYTWAq1gewSEhsAvnPW3PJ+HZtaTUDhclVwy8A+PJdpkYEmOOZjPM31WHIv 34HOaIcq3i8wnEDVMWoqWJAgbhF2pFq2hb7idYMfIpQwEivLj9MuFkeSGPvW4U26Xf0m1KcDC ZYYpKdXPZzkjXzJ8hEiHTy2aXx5pjkWYX3YTHicNr/8G8thMTD9YlIB7XzhDegv9CmI3n2qpx YL+TGfFhCP5vO7H6A+5HasuJmJP3OgMS4YxyffE9Vfu2lQl8fS2epFgzIo7wj5+UV4hPSlYk9 3rVv3DUviMiDswGIsekET70hD2fprzuqMCFZoL+g0RH5PiJ9+zjwsHYJnubyNNyPyJjfImW2f ihW0simNpLR9gzojnqONBuD0z9eKL2yKlwfwcGwiKWGWrhKugSCIiJkZi5Gl/Ad7mc3wN/jxX Ct2e/gMtWQ6Fc9+KHcUTHldMf1oz6lWVjK9NpEbZYitOwc4wL0clAirDWmbwHR9PT/VGI0P4r pW5kSIFXiXk5LEXBYbtB9s4DOkDOp2R85O4vc3epFxrmkgN5Xc0NvsnKihY= Archived-At: Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 13:51:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MgXEO9jblWs62nNNgL8onxMu5ruJc3MK7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter, I am happy to share my thoughts with you and the group. There is this unfortunate 80:20 rule and we are suffering badly from it in the working group. Whenever a new topic is presented in the group everyone raises their hands and wants to work on it. Unfortunately, the energy vanishes after 80% of the work is done and then there is no progress anymore. Most (if not all) of those who were previously interested moved on to other topics and rather want to discuss their latest document. This is, however, not the way to get things done. As with all working groups new work gets added only when old work gets finished (or killed). Many of the currently chartered items have been there for a very, very long time. They need more attention! Note that I am by no way saying that new work has to be stopped or delayed. As Alexey mentioned everyone should feel free to work on their favorite items as much as they like. Using the official face-to-face WG meeting for discussing non-WG items is IMHO the wrong approach to make progress. You are also co-author of one of the WG items, namely the Resource Directory. This work has (according to the tracker) been started early 2011 and is still in the status of a WG draft. People are implementing it and shipping products based on the draft. Other organizations use it in their architecture and have been asking for a long time already when it gets finished. What should I tell them?* Why has it taken so long? It is not even clear to me what has to be done to finish it. I have seen a minor draft update prior to the submission deadline but I have seen no mail explaining why changes have been made nor any discussions leading to those changes. From a transparency and accountability point of view document authors & editors should tell the group what the open issues are, what needs to be done to close them. Ciao Hannes *: In a recent mail I made the observation that the milestones are completely out of date and do not help anyone to guess the targeted completion date. On 03/26/2016 12:48 PM, peter van der Stok wrote: > Hi Hannes, >=20 > I do sympathize with your wish to get stuff finished. > I also understand your choice. > However, it is more than getting things on the agenda and nothing but t= hat. >=20 > What are the goals: > Do you want all development on the drafts stopped, WGLC called and only= > big mistakes removed and phrases improved? > Or just consensus on the end goals of the documents, and authors decide= > what comments are in scope? > Or just a time of 1 month after which the drafts are finished, full sto= p? > Or ..... >=20 > Can you elaborate a bit? >=20 > Peter >=20 > Hannes Tschofenig schreef op 2016-03-25 17:45: >> Hi all, >> >> I thought I should kick of a discussion about the agenda items for the= >> upcoming IETF meeting. Too early to have that discussion? I don't thin= k >> so given that the meeting is roughly in a week. >> >> I would like to see the following items discussed: >> >> 1) Resource Directory >> 2) CORE Interfaces >> 3) Block Transfer >> 4) CoAP over TCP >> 5) CoAP/HTTP Mapping >> 6) Representing CoRE Formats in JSON and CBOR >> >> Let us try to finish some stuff. >> >> For that reason I don't want to see anything else on that agenda. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core --MgXEO9jblWs62nNNgL8onxMu5ruJc3MK7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9pPjAAoJEGhJURNOOiAt4kIH/2WKrKinEZqIGFP4IPc6BB9b 7mRgo9D4CaSXyHY8sktR98beAtT8gufSBLSZcXAL8X1qJBjFSM1/PJYJ7Sme6UWR V9kdU9C53Nq6w2rPNSJLJu0qlqO7vSuIoLRX3BoVEjWvhybMBhOnblgFIo25ufni txvxJusRHy0wA25Ds4iKaiRVMiZBu7qwaKGjrxAok6+SEfBN9yRNlNGBD6Q+tFDm KGPAixMiK5SMIpr65jnXXH5dW21fwJ4WbONBLZOFn0WvPaiL3U5G9YJ8/OC3b4pr A0gp/uEbJE/QKs3AbSeZyLDz4mrRMSMCh79DTW4Tyahxlzf2DGMmlWEzPDaVmek= =sCUD -----END PGP SIGNATURE----- --MgXEO9jblWs62nNNgL8onxMu5ruJc3MK7-- From nobody Sat Mar 26 06:53:17 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D9712D601 for ; Sat, 26 Mar 2016 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXJBOivekZSr for ; Sat, 26 Mar 2016 06:53:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995DF12D5FE for ; Sat, 26 Mar 2016 06:53:13 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTSrf-1aI91k1vtv-00SST4; Sat, 26 Mar 2016 14:53:11 +0100 To: Julien Vermillard References: <56F58BEC.60502@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F69449.2090703@gmx.net> Date: Sat, 26 Mar 2016 14:53:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h8WQ2oXjhBWUAhI1XngOxtlVpbvCoIE15" X-Provags-ID: V03:K0:g/UukvgCz6OMtf6CO+cTpy+ZvmhFkxwyKJtoVNw3F3Qc+rLe4lc j4lCgN2Y0/gcyxhNlE4WUazSfFciAjHxszlWsEiBTihAiukXNHZfRlSBsPuuGIGdJHZ/lJO Q24S7ehk01e7WgIbL62xWCpZtAJgtsjzVBvwQ3FAqrfCKzlGX1uHthvAi6ojtFJjP4bLHG7 Zq2ejgqTTqfuuqVcpXXUg== X-UI-Out-Filterresults: notjunk:1;V01:K0:KLpnOUL0MBQ=:siFawNWfgjtvnILWyYlDo+ xXM2XTMgNAklT4SymH5KNMkNcmKMXBilwAubuDuwABcaeBUkBp0hug+gkP/oEorDlWma8Ade/ YaBu1rAHDzULp6ieTxd5eCgba7/msEKUvn7ncGuCgsDw4XamQImPq5pDZUl1uAaK09BNXOGyg /5FgeTW+7UxBQj2pzyvnd3+auoP81keTjQT/QBpOLzwN7OW3ZWW8shHyR2o8r2FLh8+PmKsu4 yk9OEG11Bd8bKdzpv4fsHHS+NvnPGDactinzz9dkUwJuJXhDq1e9FAfv3Vv3noeLUcgrP0fLD qRfAEdFHst+g8JL1eIf0pF8w/8iOpiKQPpshnKzub9BEsAd3SP1OXGJkGMlks11W+a3B8w063 wsOZ4yR+Siz2krLnHJkbToiSGuZ5DY6w2z0BKUr87uli7Yhj7h2JoykOUULQZXXhbiLIORA65 N1GAJjHdK/ptNMtFiKkMjsGR+g78JP4ktJ6j3L4eqjlFk3ywrcuBmCczcw5ZdjIkbjhUSDEAE km6CwU10fgXbtD3mWlAB89CkhiVaOWD9W183cxbqQbW8yE+SHOkA6KcOhUH34a38S5pjPa8GJ Yt+Grb2CZptWvn+IZ0iDwM4uXkXMLVBgVEXjqb5/GuX3yoB9zJ2hxNlhyvMBArDDbCFbQtmtz zwXul+YTmLJOjecfMHCz/O2st1mzAQp1E0SBYrl3XjmEKNTAdfK6FFPRa/h4/yeIVEbMI0NxK NsSfOMbcTiVFnQrRBzP1fdIIquTn7M7VnFVki+uWwChCwDTq/ep64o+c9Aw= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #394 - CoAP over TCP: Ping/pong X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 13:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h8WQ2oXjhBWUAhI1XngOxtlVpbvCoIE15 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julien, thanks for your remark. You are right that this is an optional feature, which we could (theoretically) turn into a mandatory feature if people in this group think it is useful. Regarding the filtering do you have a reference that we could cite or is this rather anecdotal evidence? Ciao Hannes On 03/26/2016 12:02 PM, Julien Vermillard wrote: > Hi, >=20 >=20 > > TCP also offers a keep-alive message. >=20 > This a "optional" feature and it's filtered on cellular network, so I > never use it outside of local networks. >=20 > HTH >=20 > -- > Julien Vermillard >=20 > On Fri, Mar 25, 2016 at 8:05 PM, Hannes Tschofenig > > wrote: >=20 > In https://trac.tools.ietf.org/wg/core/trac/ticket/394 Klaus provid= ed > feedback for the CoAP over TCP draft and wrote: >=20 > " > Do we need ping/pong messages to keep an idle connection alive > through NATs? > " >=20 > There are various options for doing keeping state at NATs (and stat= eful > packet filtering firewalls) alive: >=20 > - Normally, an application performs retransmissions to keep state > information alive (at the server side and also at intermediate devi= ces). >=20 > - TCP also offers a keep-alive message. >=20 > - There is functionality in TLS (the heartbeat messages) that allow= a > state to be kept alive but those are obviously only available when = you > use TLS/DTLS. The DTLS/TLS profile document talks about those. >=20 > It would be interesting to hear what the experience with these > mechanisms is. I will check with our guys. Does anyone have feedbac= k? >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 --h8WQ2oXjhBWUAhI1XngOxtlVpbvCoIE15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9pRJAAoJEGhJURNOOiAt2KoH/RKutk8KTlanjJBzqMrB2ghd U+aT+dxDT2u/4hWjU3H0uFrSADTwdNbdHm3JHN4RgAr6l9j2z1IGY7zm3H0Wppke D+hDPhtYJ2yWYE67yRkNs0RrMjIbOn14g8lb5R2PGnrp/T6Fl6m+yAgcdHnkNVAH BXjKVkMN5RQ0LnrCTVv3hbHnVxZC/BW1fuqRHnZeUa8vYLWbh7JJ+DNrxeaAp5Q+ EuQ4pDfzVS2M8mqveoEDGZ3cSKzLeImIWC4OVlDvsh2a6F63LeYft5MA96BiWVNN ENF0CV8OGtPpWwAB9tU0g2BAFNSxQNomtAXCqhkwC7ybW+n69PM1XkhGS/KaXcw= =StlQ -----END PGP SIGNATURE----- --h8WQ2oXjhBWUAhI1XngOxtlVpbvCoIE15-- From nobody Sat Mar 26 07:21:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7412D54A for ; Sat, 26 Mar 2016 07:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 oue72HIvDUhu for ; Sat, 26 Mar 2016 07:21:27 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 818AB12D60E for ; Sat, 26 Mar 2016 07:21:27 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id l68so50386020wml.1 for ; Sat, 26 Mar 2016 07:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xhkjEsHE6TRStoOchHCUQkkDg6jxJtAjlxwtimPQsSU=; b=NgB4OcLjYow621YfKqQcYZyty1JWgEZXM3V9rSWOFa2x/LQie2ARkQw6Vc0WMd6bIC B0pxSZgskmgFpchpoITmwPF7tXe5cyrtderk94aZaXUTHlx46OE5Su6LFCUtcsJsWb3U K4qzhPeUg1QBcJpQVpwLtKjwm4itk/klCoDk+ODEoq/EJMXVDiF1m5kyEpcEijJk8jVl I56oRhNp4eWximbltMMFYGnQRK3EqPjWUju3sZwZs36xl+NnIyxKX0ipTR3JDIHsFOlY 0C67BQ2Be5RMlKHrfGVPvbHEpN71WCxbiPj7hcXFuiuyCtu94K1cZbXcQjzVPmAizXUj DK8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xhkjEsHE6TRStoOchHCUQkkDg6jxJtAjlxwtimPQsSU=; b=gLvam57F+95RKoy7F5QW4M/qtKtG2rDE8NdCj1gfb/pwDlfOWU3x/KVXN60BleAuGi 4Hp4dnIOjP+dJaqupip855FoEU9aW1FBBdalTaHPQjdo3PIDXlEK6N5yeyAlSNA6AUTz nfykk9MLb5CtpDJTr38tQtgeelrbN9hj2GhHAaMjc9La1c41Mh/nhetR/kyg8xEF3coQ 7jk+dyEcVsD9iiRUmHt6uJg6p2eqzsDE4xwoy26J7yCazQ0nl44hAQyeHtAeknh+Phfb cYEt4MOoas4h9ITmspCWFtA04j1sgbNUY1lCXhY94/uWWeVsNLOgjMbHeO/I+sTFiUoI 79+w== X-Gm-Message-State: AD7BkJJQwiEVT8CtksnvKZSZWU6HOHgLVqKP2mjkn+ZywHyN9YT+3zgyU/AX9l5CX7evdY0dDEKLk7zoT7k1Ig== X-Received: by 10.194.202.133 with SMTP id ki5mr20138903wjc.27.1459002085763; Sat, 26 Mar 2016 07:21:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.84 with HTTP; Sat, 26 Mar 2016 07:21:06 -0700 (PDT) In-Reply-To: <56F69449.2090703@gmx.net> References: <56F58BEC.60502@gmx.net> <56F69449.2090703@gmx.net> From: Julien Vermillard Date: Sat, 26 Mar 2016 15:21:06 +0100 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b873c860c732e052ef4654a Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #394 - CoAP over TCP: Ping/pong X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 14:21:30 -0000 --047d7b873c860c732e052ef4654a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm talking about the TCP keepalive feature. In fact it's an optional feature of the TCP stack: https://tools.ietf.org/html/rfc1122#page-101 Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. >From my personal experience some router/proxy may not retransmit TCP keep-alive. Le sam. 26 mars 2016 14:53, Hannes Tschofenig a =C3=A9crit : > Hi Julien, > > thanks for your remark. > > You are right that this is an optional feature, which we could > (theoretically) turn into a mandatory feature if people in this group > think it is useful. > > Regarding the filtering do you have a reference that we could cite or is > this rather anecdotal evidence? > > Ciao > Hannes > > > On 03/26/2016 12:02 PM, Julien Vermillard wrote: > > Hi, > > > > > > > TCP also offers a keep-alive message. > > > > This a "optional" feature and it's filtered on cellular network, so I > > never use it outside of local networks. > > > > HTH > > > > -- > > Julien Vermillard > > > > On Fri, Mar 25, 2016 at 8:05 PM, Hannes Tschofenig > > > wrote: > > > > In https://trac.tools.ietf.org/wg/core/trac/ticket/394 Klaus > provided > > feedback for the CoAP over TCP draft and wrote: > > > > " > > Do we need ping/pong messages to keep an idle connection alive > > through NATs? > > " > > > > There are various options for doing keeping state at NATs (and > stateful > > packet filtering firewalls) alive: > > > > - Normally, an application performs retransmissions to keep state > > information alive (at the server side and also at intermediate > devices). > > > > - TCP also offers a keep-alive message. > > > > - There is functionality in TLS (the heartbeat messages) that allow= a > > state to be kept alive but those are obviously only available when > you > > use TLS/DTLS. The DTLS/TLS profile document talks about those. > > > > It would be interesting to hear what the experience with these > > mechanisms is. I will check with our guys. Does anyone have feedbac= k? > > > > Ciao > > Hannes > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > > > --047d7b873c860c732e052ef4654a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm talking about the TCP keepalive fea= ture.

In fact it's an optional feature of the TCP sta= ck:

https://tools.ietf.org/html/rfc1122#page-101

Imp=
lementors MAY include "keep-alives" in their TCP
            implementations, although this practice is not universally
            accepted.

From my personal experience some router/prox= y may not retransmit TCP keep-alive.

Le sam. 26 mars 2016 14:53, Hannes Tschofenig <hannes.tschofenig@gmx.ne= t> a =C3=A9crit=C2=A0:
Hi Julien,

thanks for your remark.

You are right that this is an optional feature, which we could
(theoretically) turn into a mandatory feature if people in this group
think it is useful.

Regarding the filtering do you have a reference that we could cite or is this rather anecdotal evidence?

Ciao
Hannes


On 03/26/2016 12:02 PM, Julien Vermillard wrote:
> Hi,
>
>
>=C2=A0 =C2=A0> TCP also offers a keep-alive message.
>
> This a "optional" feature and it's filtered on cellular = network, so I
> never use it outside of local networks.
>
> HTH
>
> --
> Julien Vermillard
>
> On Fri, Mar 25, 2016 at 8:05 PM, Hannes Tschofenig
> <han= nes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0In https://trac.tools.iet= f.org/wg/core/trac/ticket/394 Klaus provided
>=C2=A0 =C2=A0 =C2=A0feedback for the CoAP over TCP draft and wrote:
>
>=C2=A0 =C2=A0 =C2=A0"
>=C2=A0 =C2=A0 =C2=A0Do we need ping/pong messages to keep an idle conne= ction alive
>=C2=A0 =C2=A0 =C2=A0through NATs?
>=C2=A0 =C2=A0 =C2=A0"
>
>=C2=A0 =C2=A0 =C2=A0There are various options for doing keeping state a= t NATs (and stateful
>=C2=A0 =C2=A0 =C2=A0packet filtering firewalls) alive:
>
>=C2=A0 =C2=A0 =C2=A0- Normally, an application performs retransmissions= to keep state
>=C2=A0 =C2=A0 =C2=A0information alive (at the server side and also at i= ntermediate devices).
>
>=C2=A0 =C2=A0 =C2=A0- TCP also offers a keep-alive message.
>
>=C2=A0 =C2=A0 =C2=A0- There is functionality in TLS (the heartbeat mess= ages) that allow a
>=C2=A0 =C2=A0 =C2=A0state to be kept alive but those are obviously only= available when you
>=C2=A0 =C2=A0 =C2=A0use TLS/DTLS. The DTLS/TLS profile document talks a= bout those.
>
>=C2=A0 =C2=A0 =C2=A0It would be interesting to hear what the experience= with these
>=C2=A0 =C2=A0 =C2=A0mechanisms is. I will check with our guys. Does any= one have feedback?
>
>=C2=A0 =C2=A0 =C2=A0Ciao
>=C2=A0 =C2=A0 =C2=A0Hannes
>
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0core mailing list
>=C2=A0 =C2=A0 =C2=A0= core@ietf.org <mailto:core@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/core
>
>

--047d7b873c860c732e052ef4654a-- From nobody Sat Mar 26 07:50:33 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D7012D621 for ; Sat, 26 Mar 2016 07:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfjGWe-KKO0s for ; Sat, 26 Mar 2016 07:50:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7487612D1C9 for ; Sat, 26 Mar 2016 07:50:29 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mg42v-1aN61c14YH-00NRTs; Sat, 26 Mar 2016 15:50:25 +0100 To: Julien Vermillard References: <56F58BEC.60502@gmx.net> <56F69449.2090703@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F6A1AF.7070105@gmx.net> Date: Sat, 26 Mar 2016 15:50:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ewU31Ep6EoalbB2j7R0JLv414Ue3uBWFW" X-Provags-ID: V03:K0:8ws1bSCL7vkODoGqH2Q1VBTLEsh8WaOAXAhdnO3I7jLmW+jf8/k FnNvnCM41pRJguzOd+a6Jvw0ThmSlVqyiW0jcPwi/fM/LxWWCvaFzPfTOkU5P3Js2nM2MGc qJ809qEGQ0IQE9PZ/5pA+uZtjhxwm28QnF4afhybl56smcHnD6MPudIYADtp6V/LCf3ExWl iONNuxcbXwfWdwquDn9iQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Rvs+yG4RYKw=:KHr3/f5g77TMlqSSGtlP+n jYGsiAwyDt/lUVxFDyhUZ7dvTWgzQTdc77j9EfxeILdp8IyVXEGnLMCL1o6rU1pLB0Ig+VtXU P9sLTsWHqRzjJ5ogYkLu2wm3oE3kqnXBt7z23BfKuNxIjTUGYIqT1mlKtjIIPNuYIYA+Rv4F/ ZlJF+aJQUUCTfhpTyvCgNVf5I+OLNZqHJDI1XFuTFcJzwxrUEEhqUq16pQVoiQ2PtFZKgkKYE NR3m5J+MTfhT46zthDueA57EPOu3iW7VbGTbezviR1+RCrkVpaQkwLznbUO6wYalqsRgKg99F oXJeJ9e+tna3bxUq9Kv7pQxbKDpXovijipZ81A6nBhhQHGIOTuthCGuDVa6UgrL3w5dAc5CvY Rqld+wfqRCBBO2KTekIDAMvVw9XuI3/jELxCj4+7hwMh2MwdVTlzwDf1L1dSdHyF6zeI0Q+j3 Rudzh7l6LdVPbQHNTsSXZS/LoB1NIPGW7Qdzpo9Kgd+NXn1DhtBiH3dTsWNgDd5FVMBzrL8y0 S+dX5buksLyPtZ42Qmo/98WT4huJCZejVloy02JYJHFD0Qivi+Gc1vziMz2KPNaDEQpEAi3Dh sBVwQKufJ0afVsgBTl+IwPZ1bhvUcpa2HHMiYPnpTJpOIkbtvmO4Z8gnYrQvhmIysCVoNQz9d d8uGyK3pKytxlYib6/e3EJq63Rk/2r28FlFWEVrZstKTmbxQWfABTaaI9OAUxjy+kILs1riAh XfWu3EJZMRkMnMkTfk7dbfia7ybs5jH5781vOX/NZzwPSR3Z9Rzfns1pHsE= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #394 - CoAP over TCP: Ping/pong X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 14:50:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ewU31Ep6EoalbB2j7R0JLv414Ue3uBWFW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julien, but the DTLS/TLS heartbeat functionality is also an optional feature and hence there is not much difference. However, routers dropping the TCP keep-alive would indeed be a problem. I will ask the Transport Area Directorate for feedback on this issue. Ciao Hannes On 03/26/2016 03:21 PM, Julien Vermillard wrote: > I'm talking about the TCP keepalive feature. >=20 > In fact it's an optional feature of the TCP stack: >=20 > https://tools.ietf.org/html/rfc1122#page-101 >=20 > Implementors MAY include "keep-alives" in their TCP > implementations, although this practice is not universally > accepted.=20 >=20 > From my personal experience some router/proxy may not retransmit TCP > keep-alive. >=20 > Le sam. 26 mars 2016 14:53, Hannes Tschofenig > a =C3=A9crit : >=20 > Hi Julien, >=20 > thanks for your remark. >=20 > You are right that this is an optional feature, which we could > (theoretically) turn into a mandatory feature if people in this gro= up > think it is useful. >=20 > Regarding the filtering do you have a reference that we could cite = or is > this rather anecdotal evidence? >=20 > Ciao > Hannes >=20 >=20 > On 03/26/2016 12:02 PM, Julien Vermillard wrote: > > Hi, > > > > > > > TCP also offers a keep-alive message. > > > > This a "optional" feature and it's filtered on cellular network, = so I > > never use it outside of local networks. > > > > HTH > > > > -- > > Julien Vermillard > > > > On Fri, Mar 25, 2016 at 8:05 PM, Hannes Tschofenig > > > >> wrote: > > > > In https://trac.tools.ietf.org/wg/core/trac/ticket/394 Klaus > provided > > feedback for the CoAP over TCP draft and wrote: > > > > " > > Do we need ping/pong messages to keep an idle connection aliv= e > > through NATs? > > " > > > > There are various options for doing keeping state at NATs (an= d > stateful > > packet filtering firewalls) alive: > > > > - Normally, an application performs retransmissions to keep s= tate > > information alive (at the server side and also at intermediat= e > devices). > > > > - TCP also offers a keep-alive message. > > > > - There is functionality in TLS (the heartbeat messages) that= > allow a > > state to be kept alive but those are obviously only available= > when you > > use TLS/DTLS. The DTLS/TLS profile document talks about those= =2E > > > > It would be interesting to hear what the experience with thes= e > > mechanisms is. I will check with our guys. Does anyone have > feedback? > > > > Ciao > > Hannes > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > >=20 --ewU31Ep6EoalbB2j7R0JLv414Ue3uBWFW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9qGvAAoJEGhJURNOOiAt8lcH/RabWt8Upv+pDXtGLly+dGRp F7z80+tOcpuvIDw8sjJCtB9dvijKaPfFJsvv+guZtm9aCQfE5uTVC1QXnkzG5us+ 2qcUPF7vIYP2Xrm7tBxLvjZexAflgoNWuPuQq+UsYGARJ1oGzKilCmiZ208/Gp0G EN+JDOQHoRpVovWmGpEP0alS4TNQ0D1mAStLHuH1u2HmYCYJj/oaSVdkLP/OT1HF b7UEUUQicrzBLy0e3tPjPbuqZvKiYye9bYOmU6WxQt9xCzjLCHj24T8u2ZBe2S19 R7W6mYgOVvGjmUOYLBdMz4uDOapiCh8A5WT3VznI58Rl0+0yndr59/L9zoQoJrk= =2G/c -----END PGP SIGNATURE----- --ewU31Ep6EoalbB2j7R0JLv414Ue3uBWFW-- From nobody Sat Mar 26 08:22:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4A12D63B for ; Sat, 26 Mar 2016 08:22:50 -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 QmlrEOC75cHc for ; Sat, 26 Mar 2016 08:22:47 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDBB12D63D for ; Sat, 26 Mar 2016 08:22:47 -0700 (PDT) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 80A78FB882; Sat, 26 Mar 2016 16:22:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Lb3EJW_q9wTy; Sat, 26 Mar 2016 16:22:44 +0100 (CET) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id E2591FB886; Sat, 26 Mar 2016 16:22:43 +0100 (CET) Message-ID: <56F6A942.4010405@tzi.org> Date: Sat, 26 Mar 2016 16:22:42 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56F56B0F.9070508@gmx.net> In-Reply-To: <56F56B0F.9070508@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 15:22:50 -0000 Hi Hannes, thanks for volunteering as the new WG secretary. I have put up the current status with respect to slot requests at https://github.com/core-wg/ietf95/wiki This is a wiki, so I'm asking the discussion leaders for the slots to update the information right there. We need to get more detailed objectives for the items; it is not sufficient to have an item on the agenda, we also need to know what needs to be decided. Any slot request that is missing? Any other input on time needed, priorities? Andrew and I have to put in a revised agenda by Monday, so items where do don't have a discussion leader and detailed objectives are a bit endangered. Grüße, Carsten Hannes Tschofenig wrote: > Hi all, > > I thought I should kick of a discussion about the agenda items for the > upcoming IETF meeting. Too early to have that discussion? I don't think > so given that the meeting is roughly in a week. > > I would like to see the following items discussed: > > 1) Resource Directory > 2) CORE Interfaces > 3) Block Transfer > 4) CoAP over TCP > 5) CoAP/HTTP Mapping > 6) Representing CoRE Formats in JSON and CBOR > > Let us try to finish some stuff. > > For that reason I don't want to see anything else on that agenda. > > Ciao > Hannes > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Mar 26 08:33:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF612D658 for ; Sat, 26 Mar 2016 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5LrAtmyIVwI for ; Sat, 26 Mar 2016 08:33:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5099812D650 for ; Sat, 26 Mar 2016 08:33:49 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M1nbu-1Zuc8u2jD0-00tmda for ; Sat, 26 Mar 2016 16:33:47 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F6ABDC.7070201@gmx.net> Date: Sat, 26 Mar 2016 16:33:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="B4kPRlhcATN7xslpE94wcVfI4cjfxQwaW" X-Provags-ID: V03:K0:LXtcFqW9fslXc1YYUJsD2bT9WyryzpJxAm0Q6O2rlWulWO4D4tz 7r4dSnbaIvXnFxQnK8m/lFIecQ2N2nXVdGTn7XQbaVeUmXegZ68srRl09lI+eUbXtyy+Rrm SoavJwJfEx5m8jfiDFEWjDR7gfbSnpBo23AJ7gaYpQJEzK/CH0FPe68hl2Cqyww3GtHcBCG qJdg/a4sbLL8Y6yG9ghxQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:420kK0f076c=:Gv7sOMC5bmLRF+3go6m3lH ifEa4G4i0UDJTO4PpdJcfwjexkvLmst5GT5REEM93+iStmDcBAsdgyj6t88hUVFeCPHDa9Nzw kLoCqva7U2jxK6wDosVgtxjgrM7ChPm0JtKWtIxQIQJR0cX//nKEx3CbfeC4A9nOYtY58kSuk huh9auplfW7W+M18VZzPNGAG7zEoy9LLAgOdJBKWTdqstTbFMLKZBYCaXECku3VN0GKaKKfLq S5QupEck9J3rxTO/FXQmli5cLWzG3VEd7Nu+ooPRuuwhLxylX/2TvpAOywYDr+fUhadbw/M4d eKAwCQC0E0deIDqmnec7MrAreT2KiWVkOH+f5/gWNl/Wo1w9yjilPsP+j3ign4UHNQdLmaCAl rfZFo6iTsiL4tazcBbSnsi0Y5bBKp+yXTDh3v+KzRCsR2MQNfzIIbmerdnRdqOL7rnGaiTyqx MsYQ8u0/NwQOKNvOzg+8wEMqaUkGuNeSrwRhR9r5OreGfTiV1PRzxIz2jWeb75mZwgivw7m6e 79GpZypRzx/b+v8lacl376NHKLz9siX7EujWRI2scWSf4UvJHLbXSNrMV6qwnglHv8Rt1GUfy 05i5WdjuPbQSd45ZmptOy5AkfFKx+M3mgB99N8gKCPYF3hyjqCJweKog1nG7+b5/PxYAVvoQr +sm1rCRAr3LVv8KvJs5fohBeYVCNIhSHahFsP3HWLbUurl2F13E/ZL7bZFUazRObtrw0flUwG s9OJ57HCJWh4zKB1MVMk7hNj2fp/I6n5/pb8MW+1LAITZyJWjX+HFxj61fw= Archived-At: Subject: [core] Ticket #390 - CoAP over TCP: Connection close reason X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 15:33:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B4kPRlhcATN7xslpE94wcVfI4cjfxQwaW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In https://trac.tools.ietf.org/wg/core/trac/ticket/390 Klaus provided feedback for the CoAP over TCP draft and wrote: " When a client or a server has to close a connection (for example, due to an unrecoverable error), there should be a message with the reason. Reasons might include: A client or server sends a bad message. - The Length is less than 2. - TKL is greater than 8. - The message is shorter than TKL. - The message is Empty. The connection timed out. The server lacks the system resources to service a new connection. The server does not service the connection itself but redirects traffic to another host. The server is being shut down and all connections are closed. The client or server sends a message in an unsupported version. " Currently, the CoAP over TCP draft only adds a shim header to convey length information. As Klaus pointed out it is possible that errors may occur during processing of that shim header. The failure to process the shim header will prevent any CoAP message header parsing but the plain TCP handling will be fine. It may be reasonable to define an error response message in case something is wrong with the shim header processing. However, I don't think anything else (such as TCP-related errors, such as timeouts or lack of resources) should be conveyed. The challenge is, however, that we would have to define an additional field -- a command type -- to distinguish a regular message from an error response. If we do that we could (referring to ticket #394) also define a keep-alive message at that layer as well or even a version negotiation (referring to ticket #389). I think you raised an interesting point and I wonder what others in the group think about it. Ciao Hannes --B4kPRlhcATN7xslpE94wcVfI4cjfxQwaW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9qvcAAoJEGhJURNOOiAtDo8H/Al2JzATgSDXXazsWsAv1uDG 0gmzAsknBVp95LrYQ4rTtwBUCDtOxfkqhYE/Z1bt/fByqlcEa6fndHn4HJnQHSOD QGLvtAqYVSPC28IlFxkkLSoCkCv8AsUKbrJUspPDUgnXzz4xs2J+Hpx8+Wp2LCze H055vKvoZVh4xPbl7he6Z2cMjXN9Wuio8UkZxqhGt5/E4e2ZcSvhnpTOmoJtUXIY FXWqAJMK/0xX0dHuZMKpHYvTn6hJ1yZeebF8LMIDg2bC+rX0mJZG7yeg/wL0fY8Y XK+v1iEXhNmXJjeTjnp58YJ8wGKan5bXh+28gQOaHm7oN7MGX7IICYbosXk6o3I= =LNnm -----END PGP SIGNATURE----- --B4kPRlhcATN7xslpE94wcVfI4cjfxQwaW-- From nobody Sat Mar 26 08:55:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9309712D55A for ; Sat, 26 Mar 2016 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNGA8w3lMiJJ for ; Sat, 26 Mar 2016 08:55:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B190E12D1E4 for ; Sat, 26 Mar 2016 08:55:51 -0700 (PDT) Received: from localhost ([::1]:52011 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ajqZ5-0007Rm-8R; Sat, 26 Mar 2016 08:55:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Sat, 26 Mar 2016 15:55:51 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/396 Message-ID: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org> X-Trac-Ticket-ID: 396 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 15:55:53 -0000 #396: L1 vs. L3 Encoding Approach Copy-and-paste from the mailing list: http://www.ietf.org/mail-archive/web/core/current/msg06905.html At the T2TRG meeting, which took place the two days before the IAB IOTSI workshop in Santa Clara, we met with various OIC/OCF guys and talked about ongoing IoT standardization work in the IETF/IRTF as well as in the OIC/OCF. We learned that they have selected a different solution approach for CoAP over TCP: we have selected option L1 from Section 4 of https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 and they have selected option L3. In an off-list mail exchange we also received information about the performance investigations they have done. Here is what we got: > For 4MB data, the transmission time is > > 1. CoAP over TCP L1 + BWT : 70 s > > 2. CoAP over TCP L3 : 1.7 s (BWT = Block-Wise Transfer) We have not taken the performance aspect of larger file transfers (e.g., transfer of a 4MB firmware update) into account when we made the solution decision in Yokohama. The reason why the OIC/OCF take such large file transfers into account is because of their desire to use CoAP also for non-constrained devices. I believe it would be good to verify / analyse the performance analysis of the OIC/OCF guys. In particular, it would be reasonable to compare the performance of option L1 and option L3 from Section 4 of https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 with a CoAP protocol stack, such as Californium and the mbed CoAP library. Carsten pointed out that L1 is limited to 64 KiB (which is further reduced by Block's current largest block size of 1 KiB in the analysis above), while L3 allows for larger payloads. Of course, we may not need to use Block Transfer in CoAP when we already use CoAP over TCP. -- -------------------------------------+------------------------------------- Reporter: | Owner: Hannes.Tschofenig@gmx.net | hannes.tschofenig@gmx.net Type: other technical | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: core From nobody Sat Mar 26 09:05:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B19E12D67C for ; Sat, 26 Mar 2016 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9Jy_ZSy9NXB for ; Sat, 26 Mar 2016 09:05:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE98812D665 for ; Sat, 26 Mar 2016 09:05:16 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M9Jss-1abZls2OBq-00Ci7t; Sat, 26 Mar 2016 17:05:06 +0100 To: Carsten Bormann References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F6B333.2060105@gmx.net> Date: Sat, 26 Mar 2016 17:05:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F6A942.4010405@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d1CLhDUI7lAgnbojm3Gp40b1twmpaOVWR" X-Provags-ID: V03:K0:94fqq5VTFAdQy7UTToAo+y4JwBnSa6rZPzqkH+wlh+udt4iHiAL y5QPcvk8nYNlL8AZja0Xf0O9OPw3MpstdK+LKd+iWZ3xjg5344gPTUk9z4/35PdTfXxxbx+ kpvfnd1sOGwuNcAM6d8LQahVAkNH/fgaMTCVJBuZGutuA1lDmMZtH9c4o/qA3pJJ8PNQiSy +ACHy6xx30Rjd7aePMcRg== X-UI-Out-Filterresults: notjunk:1;V01:K0:gT1GzitMiIA=:AnefDWZ5Pmo+FMZI/ZURHr wdPXnbBH2VQpLAqianDj0omS+iq6Ll8yIpQiJUYqgGVWV0ERau3Tu6XZKO5FV1fOgKhCYDf81 SYYXw1FyEbh4T03QVZ+3IgTBXqOMkiFsy9GW+QVX8clcv5VchCLqnBUb+hQe+MQBwEPehh6RI re9Qe0kUmU9NpXk3oAboIIR7uV5dZdeUy+EisRuSbQjC7qHeUB5K7UjoFltdktdCiQPPB5Ca+ lk/GPSNYzu1ix4VLnIkA1T39tVtYztSLYBjcakk7Ky//kHdT48u4gYSSBUOXtfcMwsOhQch1B Y3rMUPdPX3vJV8uBcSsgO2IC6lBbotWCyWxRXIIpDK/IIC2TPwrKBeLedfejU8rvLp+pSaP8O aX5KGtqKFJ64PTafEHzght4AG3PWpMXYw9nPiLZVZs9qySbXIjc5VyHOgCXrMX1QYSSuxRBcl EdvsRfFdKiwNamaGgW7o4sbBoxXZscBGtum0wHbaxPkOPXWGoplE5cLXlgYoSFS3gi8k1b+za ZB2MHnFVw8tU9MvzJ2EhQFDCNtZQzSZKhySmNFrn++T7VYpdLz6nwCokbXRrSpoC4l8lHx1mb QKJzbpwbO8FSW5l+lhYjr3Is/2+zS1QLMRZmMwh9V/GSDMdl537GIYT7Gws2JZIJqrxGd375O FiNG8WZEtiAbak/6MCXou1NN04rThD6B7nmuQPw658kjPl1jcJM7f27/4IbjP0f4HOPyTVPxv LLIJV3IPXMJMhSjx4ndkvbwvR8S7TypfqZfflW43Gn/kMrimaCGIkUVA2Tc= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 16:05:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d1CLhDUI7lAgnbojm3Gp40b1twmpaOVWR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, thanks for putting up a Wiki. For the Block Transfer draft it is obviously difficult to predict what the IESG comments will be; hence a short slot is appropriate. For many of the other WG items (e.g., CoRE Resource Directory, draft-ietf-core-interfaces, draft-ietf-core-http-mapping, draft-ietf-core-links-json-04) it is not clear what the open issues are since the document authors do not seem to either use the WG issue tracker or haven't touched it for a while. Could this be done before the meeting starts? This would allow folks to prepare for the discussion. I would like to avoid being in a meeting where nobody knows what is being decided. draft-ietf-core-links-json-04 does not seem to be listed as a separate item on the agenda? Do we know who is going to attend the meeting to assign presenters to the individual items? Ciao Hannes PS: Btw, I am not volunteering to be the WG secretary. The group has two chairs and you guys should be able to handle this task easily. PPS: I still believe that SENML, COOL/COMI, and the security discussion requires too much preparation for the group upfront so that it will actually distract everyone. On 03/26/2016 04:22 PM, Carsten Bormann wrote: > Hi Hannes, >=20 > thanks for volunteering as the new WG secretary. >=20 > I have put up the current status with respect to slot requests at >=20 > https://github.com/core-wg/ietf95/wiki >=20 > This is a wiki, so I'm asking the discussion leaders for the slots to > update the information right there. >=20 > We need to get more detailed objectives for the items; it is not > sufficient to have an item on the agenda, we also need to know what > needs to be decided. >=20 > Any slot request that is missing? >=20 > Any other input on time needed, priorities? >=20 > Andrew and I have to put in a revised agenda by Monday, so items where > do don't have a discussion leader and detailed objectives are a bit > endangered. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >=20 > Hannes Tschofenig wrote: >> Hi all, >> >> I thought I should kick of a discussion about the agenda items for the= >> upcoming IETF meeting. Too early to have that discussion? I don't thin= k >> so given that the meeting is roughly in a week. >> >> I would like to see the following items discussed: >> >> 1) Resource Directory >> 2) CORE Interfaces >> 3) Block Transfer >> 4) CoAP over TCP >> 5) CoAP/HTTP Mapping >> 6) Representing CoRE Formats in JSON and CBOR >> >> Let us try to finish some stuff. >> >> For that reason I don't want to see anything else on that agenda. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core --d1CLhDUI7lAgnbojm3Gp40b1twmpaOVWR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9rM0AAoJEGhJURNOOiAtzJgIAJbfV+fwvyNxzDmT4yMFC8yv 3J5l3Xhz/ldOhPHBQawvi6/dCiZhtnF0SXdV7TyFQqbIgAPOaLKAqRZOq+2CAxyW r32xL455CrOfGtXoIOU17FcZISjpy2O8oqv+RgbOx4BmyfJw90qOwjz0/l8G/4SL ZiPJha9ylPI0qifGMm9d15WXhPfqTWbf0gse5HsgZ7qNi3OIjszV9VwSFmiXJW+W EvZHZ0vQXayf7B0pTBR79ky2IuqjgtPSpyJ0sfD8KSB1mcDEuHaBz+9I7qQOOn7C qXl6PPqnCTNxr14AYm0Ech5HBzX/woZKNDIdhnNDwXo0hpoLe2bXwS8BhRp4za0= =GRo3 -----END PGP SIGNATURE----- --d1CLhDUI7lAgnbojm3Gp40b1twmpaOVWR-- From nobody Sat Mar 26 09:21:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA412D666 for ; Sat, 26 Mar 2016 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 lj0T3guY4M7U for ; Sat, 26 Mar 2016 09:21:35 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96EDB12D110 for ; Sat, 26 Mar 2016 09:21:35 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E1E8CA80CB; Sat, 26 Mar 2016 17:21:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id AlO4C6YO6RdC; Sat, 26 Mar 2016 17:21:32 +0100 (CET) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id F0506A80C0; Sat, 26 Mar 2016 17:21:28 +0100 (CET) Message-ID: <56F6B708.4080805@tzi.org> Date: Sat, 26 Mar 2016 17:21:28 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> In-Reply-To: <56F6B333.2060105@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 16:21:37 -0000 > For the Block Transfer draft it is obviously difficult to predict what > the IESG comments will be; hence a short slot is appropriate. Exactly. The one issue that has taken a while to resolve at the end was the interaction with Object Security, we can discuss that part there, and Göran has volunteered to lead that discussion. > For many of the other WG items (e.g., CoRE Resource Directory, > draft-ietf-core-interfaces, draft-ietf-core-http-mapping, > draft-ietf-core-links-json-04) it is not clear what the open issues are > since the document authors do not seem to either use the WG issue > tracker or haven't touched it for a while. > > Could this be done before the meeting starts? This would allow folks to > prepare for the discussion. I would like to avoid being in a meeting > where nobody knows what is being decided. Yes, that would indeed be useful. > draft-ietf-core-links-json-04 does not seem to be listed as a separate > item on the agenda? I have lumped it under resource-directory because I am not aware of anything to decide on this document per se, but the interaction with RD is the interesting one. Same with fetch/patch. > Do we know who is going to attend the meeting to assign presenters to > the individual items? While there seems to be some subsetting here, we probably will have a quorum. Discussion leaders: Please note down yourself on the Wiki... > PPS: I still believe that SENML, COOL/COMI, and the security discussion > requires too much preparation for the group upfront so that it will > actually distract everyone. Those are areas where a lot of preparation has already happened. (The agenda has 60 minutes more of material right now than we have time; we might indeed want to minimize the discussion on SenML, and the Friday items are the compressible ones if we need more time for the Tuesday ones.) Grüße, Carsten From nobody Sat Mar 26 09:38:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDB512D6B7 for ; Sat, 26 Mar 2016 09:38:47 -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 ddv4UDr95cCz for ; Sat, 26 Mar 2016 09:38:46 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6C212D6BE for ; Sat, 26 Mar 2016 09:38:45 -0700 (PDT) Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 4CC4CFB8A9; Sat, 26 Mar 2016 17:38:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3NdyUbx35clQ; Sat, 26 Mar 2016 17:38:42 +0100 (CET) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 0BFDAFB886; Sat, 26 Mar 2016 17:38:41 +0100 (CET) Message-ID: <56F6BB11.5050808@tzi.org> Date: Sat, 26 Mar 2016 17:38:41 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: trac+core@zinfandel.tools.ietf.org References: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org> In-Reply-To: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 16:38:47 -0000 > We have not taken the performance aspect of larger file transfers (e.g., > transfer of a 4MB firmware update) into account when we made the > solution decision in Yokohama. The reason why the OIC/OCF take such > large file transfers into account is because of their desire to use CoAP > also for non-constrained devices. Actually, we did discuss larger transfers in Yokohama (although the word "performant" only occurs once in the minutes, specifically where Matthias reported on the IoTivity work). The understanding was that an extension to -block like draft-bormann-core-block-bert would reduce the performance gap between a 16-bit (L1) and a 32-bit length (L3), if needed. The sentiment in the room was a bit against creating a dialect of CoAP with much larger payload sizes than the ones recommended in section 4.6 of RFC 7252, but we didn't really have much input on this to work from. So this particular question really reduces to: Should CoAP be extended to provide payload sizes well over 64 KiB over TCP, TLS? (The Websockets framing already provides the capability, up to 16 EiB.) Grüße, Carsten From nobody Sat Mar 26 14:24:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C3912D1BA for ; Sat, 26 Mar 2016 14:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 W-K4kM19GOJW for ; Sat, 26 Mar 2016 14:24:28 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28B112D18C for ; Sat, 26 Mar 2016 14:24:28 -0700 (PDT) X-ASG-Debug-ID: 1459027466-06daaa35b792b580001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id ciFOaOaDcVqxITAE (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2016 17:24:26 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0266.001; Sat, 26 Mar 2016 17:24:25 -0400 From: "Rahman, Akbar" To: Hannes Tschofenig Thread-Topic: [core] Agenda X-ASG-Orig-Subj: RE: [core] Agenda Thread-Index: AQHRhrW2zt+iXgwlSE+anWbkGv875Z9sHFAAgAAL2oCAABFFQA== Date: Sat, 26 Mar 2016 21:24:26 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BA6E252@NABESITE.InterDigital.com> References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> In-Reply-To: <56F6B333.2060105@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.131] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1459027466 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28194 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 21:24:30 -0000 Hi Hannes, >For many of the other WG items (e.g., CoRE Resource Directory, draft-ietf-= core-interfaces, draft-ietf-core-http-mapping, >draft-ietf-core-links-json-04) it is not clear what the open issues are si= nce the document authors do not seem to either use the WG issue tracker or = haven't touched it for a while. Here is a summary of the status for draft-ietf-core-http-mapping: 1) From IETF-94 (Yokohama) minutes https://www.ietf.org/proceedings/94/minutes/minutes-94-core "A post WGLC check on draft-ietf-core-http-mapping-07 revealed remaining ou= tstanding comments." 2) Here is our recent Email to the list to close these remaining outstandin= g comments (from Klaus) https://www.ietf.org/mail-archive/web/core/current/msg06866.html 3) Here is our update of the draft (to -08) that incorporates nearly all th= e comments: https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#appendix-A "Changes from ietf-07 to ietf-08: o Addressed WGLC review comments from Klaus Hartke as per the correspondence of March 9, 2016 on the CORE WG mailing list." >Do we know who is going to attend the meeting to assign presenters to the = individual items? >From the Wiki that Carsten just made https://github.com/core-wg/ietf95/wiki "=95HTTP Mapping (15) Thomas Fossati (Akbar is the backup) draft-ietf-core-http-mapping-08 2016-03-19 Objective: Review updates to address the WGLC comments from Klaus Hartke" > I would like to avoid being in a meeting where nobody knows what is being= decided. Yes, I agree. Do the above clarify the points for draft-ietf-core-http-map= ping? Please tell us if you need any more information from the authors. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, March 26, 2016 12:05 PM To: Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] Agenda Hi Carsten, thanks for putting up a Wiki. For the Block Transfer draft it is obviously difficult to predict what the = IESG comments will be; hence a short slot is appropriate. For many of the other WG items (e.g., CoRE Resource Directory, draft-ietf-c= ore-interfaces, draft-ietf-core-http-mapping, draft-ietf-core-links-json-04) it is not clear what the open issues are sin= ce the document authors do not seem to either use the WG issue tracker or h= aven't touched it for a while. Could this be done before the meeting starts? This would allow folks to pre= pare for the discussion. I would like to avoid being in a meeting where nob= ody knows what is being decided. draft-ietf-core-links-json-04 does not seem to be listed as a separate item= on the agenda? Do we know who is going to attend the meeting to assign presenters to the i= ndividual items? Ciao Hannes PS: Btw, I am not volunteering to be the WG secretary. The group has two ch= airs and you guys should be able to handle this task easily. PPS: I still believe that SENML, COOL/COMI, and the security discussion req= uires too much preparation for the group upfront so that it will actually d= istract everyone. On 03/26/2016 04:22 PM, Carsten Bormann wrote: > Hi Hannes, > > thanks for volunteering as the new WG secretary. > > I have put up the current status with respect to slot requests at > > https://github.com/core-wg/ietf95/wiki > > This is a wiki, so I'm asking the discussion leaders for the slots to > update the information right there. > > We need to get more detailed objectives for the items; it is not > sufficient to have an item on the agenda, we also need to know what > needs to be decided. > > Any slot request that is missing? > > Any other input on time needed, priorities? > > Andrew and I have to put in a revised agenda by Monday, so items where > do don't have a discussion leader and detailed objectives are a bit > endangered. > > Gr=FC=DFe, Carsten > > > > > Hannes Tschofenig wrote: >> Hi all, >> >> I thought I should kick of a discussion about the agenda items for >> the upcoming IETF meeting. Too early to have that discussion? I don't >> think so given that the meeting is roughly in a week. >> >> I would like to see the following items discussed: >> >> 1) Resource Directory >> 2) CORE Interfaces >> 3) Block Transfer >> 4) CoAP over TCP >> 5) CoAP/HTTP Mapping >> 6) Representing CoRE Formats in JSON and CBOR >> >> Let us try to finish some stuff. >> >> For that reason I don't want to see anything else on that agenda. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Sat Mar 26 14:59:17 2016 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 D71D712D0CC; Sat, 26 Mar 2016 14:59:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160326215915.19472.51650.idtracker@ietfa.amsl.com> Date: Sat, 26 Mar 2016 14:59:15 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' Yes on charter-ietf-core-01-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 21:59:16 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-core-01-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-core/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm fine with rechartering CORE with roughly this charter (I'm a Yes), but just to make sure I understand, is it correct that the completed portfolio would include CoAP over HTTP (I didn't check the mapping RFC, but I'm guessing this includes HTTPS), and CoAP over TLS, and CoAP over TCP ? From nobody Sat Mar 26 15:07:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3560C12D176; Sat, 26 Mar 2016 15:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 PWKyUkGNTInY; Sat, 26 Mar 2016 15:07:43 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C16712D103; Sat, 26 Mar 2016 15:07:43 -0700 (PDT) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5179B17209A; Sat, 26 Mar 2016 23:07:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4LRR0X8dkt0r; Sat, 26 Mar 2016 23:07:39 +0100 (CET) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B677D172098; Sat, 26 Mar 2016 23:07:38 +0100 (CET) Message-ID: <56F70829.5080008@tzi.org> Date: Sat, 26 Mar 2016 23:07:37 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Spencer Dawkins References: <20160326215915.19472.51650.idtracker@ietfa.amsl.com> In-Reply-To: <20160326215915.19472.51650.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Spencer Dawkins' Yes on charter-ietf-core-01-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 22:07:45 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm fine with rechartering CORE with roughly this charter (I'm a Yes), > but just to make sure I understand, is it correct that the completed > portfolio would include > > CoAP over HTTP (I didn't check the mapping RFC, but I'm guessing this > includes HTTPS), and The mapping draft (which has completed WGLC, with an update now available) discusses mapping *between* CoAP and HTTP, which both are REST protocols that embrace proxies (i.e., that mapping is fundamentally already there, but there are some details to look at, which the document is about). There is no need for CoAP over HTTP. > CoAP over TLS, and > CoAP over TCP Indeed, completion of this is a hot work item now, with OCF already using a version of the document in their spec, and OMA very interested. Reasons include easier NAT traversal, as well as usage within backend server farms. Grüße, Carsten From nobody Sat Mar 26 15:11:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A4912D195; Sat, 26 Mar 2016 15:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8UuYfOjBieMy; Sat, 26 Mar 2016 15:11:45 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 532A912D103; Sat, 26 Mar 2016 15:11:45 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id s5so67355582qkd.0; Sat, 26 Mar 2016 15:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=e/uibwD+axXGPsPe37IdLjudJZ28Jnh98+280LZX7Ck=; b=z5ylKSlko1vtSFxd1GZ9vYmi2qItdBbWUhiEC88rAQ+oaN4pMO7dn3rtTbozkpcOn0 BRYp7m6ILGYUaXtipFsd8Zt81fiZmOi51AzH8GfZpmlhTpule05EouiQC8tQTvpBRqc1 Th0GimVw7AOog9NSvxuYeiYsxjI0Dbz50+rHFfhO7N8RvsU+pPBO7HIXc5epUnGRFc0A DrhUQIQAH79FnDankvbblrW1zT8T0GZXTOfOfjMjTKr1ByK/RzRN6o2alwV4/o8fXT+j sJgG9Kgo20GNjt5V3vrBnwk3mRNhn9rxmX67d9L6Q6mI4aRobStbg1YpPhEV3xJbwk9J OjpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=e/uibwD+axXGPsPe37IdLjudJZ28Jnh98+280LZX7Ck=; b=QEuTsPh6stJQvfl/GZs6Hj63ZGNQI3NMbSBTwCh5/iTTmmE9/g68Tjs4GIPpfneg6n oqoS6bYrITYOGVxVanTp0zrRvj0Ng81HftCsvrZnUpEWqIGT0SdvBiMa4gJjS/pwmmXJ E4tS2EYAKm9Uiv8Ex14blapZeBGPpfNkmNm3+WZpe8u9MRgJM8mP+F9kw+5RUlk2lme0 d4edQAvcg5cjTXvgU2Y6Bf8+Sl2jtM7fXWM44iiRvVjB8qC4qEJyJvPaGI8SJEb++RNm /s0cnIOWSgUz727IbVbC7baO4NotckZWyCrLxzCSBJFufYrrHFeEzZaF7RZjf89iFOFX ca6A== X-Gm-Message-State: AD7BkJJzMN8l6NFj8ZzvdC08q0wQOccaKv0tVNNxo/TV+sAvDDe13dnhW3+PqZysH5SJTVeXkq6v2zzU5Cl/AA== MIME-Version: 1.0 X-Received: by 10.37.231.9 with SMTP id e9mr2509109ybh.148.1459030304417; Sat, 26 Mar 2016 15:11:44 -0700 (PDT) Received: by 10.37.214.13 with HTTP; Sat, 26 Mar 2016 15:11:44 -0700 (PDT) In-Reply-To: <56F70829.5080008@tzi.org> References: <20160326215915.19472.51650.idtracker@ietfa.amsl.com> <56F70829.5080008@tzi.org> Date: Sat, 26 Mar 2016 17:11:44 -0500 Message-ID: From: Spencer Dawkins at IETF To: Carsten Bormann Content-Type: multipart/alternative; boundary=94eb2c0b14bc02f0d1052efaf769 Archived-At: Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" Subject: Re: [core] Spencer Dawkins' Yes on charter-ietf-core-01-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 22:11:47 -0000 --94eb2c0b14bc02f0d1052efaf769 Content-Type: text/plain; charset=UTF-8 Hi, Carsten, On Saturday, March 26, 2016, Carsten Bormann wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I'm fine with rechartering CORE with roughly this charter (I'm a Yes), > > but just to make sure I understand, is it correct that the completed > > portfolio would include > > > > CoAP over HTTP (I didn't check the mapping RFC, but I'm guessing this > > includes HTTPS), and > > The mapping draft (which has completed WGLC, with an update now > available) discusses mapping *between* CoAP and HTTP, which both are > REST protocols that embrace proxies (i.e., that mapping is fundamentally > already there, but there are some details to look at, which the document > is about). There is no need for CoAP over HTTP. > > > CoAP over TLS, and > > CoAP over TCP > > Indeed, completion of this is a hot work item now, with OCF already > using a version of the document in their spec, and OMA very interested. > Reasons include easier NAT traversal, as well as usage within backend > server farms. Thank you for catching me up, of course! Spencer --94eb2c0b14bc02f0d1052efaf769 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Carsten,

On Saturday, March 26, 2016, Carsten Bormann <cabo@tzi.org> wrote:
> --------------------------------------------------------= --------------
> COMMENT:
> ----------------------------------------------------------------------=
>
> I'm fine with rechartering CORE with roughly this charter (I'm= a Yes),
> but just to make sure I understand, is it correct that the completed > portfolio would include
>
> CoAP over HTTP (I didn't check the mapping RFC, but I'm guessi= ng this
> includes HTTPS), and

The mapping draft (which has completed WGLC, with an update now
available) discusses mapping *between* CoAP and HTTP, which both are
REST protocols that embrace proxies (i.e., that mapping is fundamentally already there, but there are some details to look at, which the document is about).=C2=A0 There is no need for CoAP over HTTP.

> CoAP over TLS, and
> CoAP over TCP

Indeed, completion of this is a hot work item now, with OCF already
using a version of the document in their spec, and OMA very interested.
Reasons include easier NAT traversal, as well as usage within backend
server farms.
=
Thank you for catching me up, of course!

Spencer
--94eb2c0b14bc02f0d1052efaf769-- From nobody Sat Mar 26 16:08:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6E812D612 for ; Sat, 26 Mar 2016 16:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaX-BhAaISr9 for ; Sat, 26 Mar 2016 16:08:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5C512D593 for ; Sat, 26 Mar 2016 16:08:45 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LeMWL-1ZyXnx24iL-00q9fY; Sun, 27 Mar 2016 00:08:32 +0100 To: "Rahman, Akbar" References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <36F5869FE31AB24485E5E3222C288E1F5BA6E252@NABESITE.InterDigital.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F71670.5010403@gmx.net> Date: Sun, 27 Mar 2016 00:08:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BA6E252@NABESITE.InterDigital.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pUD0mHcrKSWoAPRTL0L4l2eTlCath5icq" X-Provags-ID: V03:K0:qCWoa1IVcgRMkHVSkAnQXwRCAbK1QJpM73LEzDh6V4zWkVOm1dG E8qKrDTLyJTpsilVdYlWNYT6OnwsKHqb37EsM6zifi/2ZU38Nd4npdJ++BBdJIlHYi25G+I QJRuaAyT5fTPgVBK7t9X9VJJiC9v5DnktHee/RiAdosBPlqY8Pv2QfdGa7idBHJAK3pvTiZ qI1fdyXlaJhUkjRjCIg2A== X-UI-Out-Filterresults: notjunk:1;V01:K0:edxpmWg0MOQ=:bficH0DgPiyMUp1L27xmTO rDnvZWMEMwJb+5Az6aVoEh9liaUqhcfZj/IOqiIx970egxsCgdCVLuG+bktBxwtavfXa6R23w oVhZzf7iWnuST2VPUjvBZCUHMG1j8VNYxVmrDGX28NBirTf291L9P+2hvFNZXVWVEvES0Fyfx ODFNsI4AddQezzG2jKbRAOaip61H22o/nA4GZcIv+crQoDH+1DZNaCvNwmYB2sG0xux+NM9vr HYaavaeqX7/E0CgYWdX4cqvJmHFUb0UFbLULuLsWRkz+cFY06TMwf8w2HHa808mIg2DhhSyJl TvgiAN9iU/ljNoJQgC2rXwg8cCy+1uR95vhLfTKvIuTk2pRynXLUrd4gUFKjbIbkZ9WIIux6x AIuVIW+tqrQ4GRIeOBB6LGGarsIcheg451pAOb8dyVyoQFVntiC4e9enpXMJUqdcFumkFrZbi jmuqkBMEXHqcmuSp2m8z97FhEQUH4QUBZ7Aw1KwYOJTtUJhJ2vTJXfhwnHCzPz6c8OTICqiWU 8L2N5HJ4UAiDHqSPEfzg+3PBVEA44Lb8/0RHmPdxXNZ+32iUGNdPmRdZHvv9J2UfyQN1EoKpd GzBk332HyNy4JV6DQgvvV9TUgA0i80FC+R4v8dFlglgU+t/Ddv4/cyM65gntlAhOkataaZ3Ox 0byKHsLTGe4cSvO/rMvFr6VasYnhZKM+6xpoz/Q3BPnkOmDfSwLM1vljWrDSFZEZc+Ju8sEl/ RxrI0GBKqOvKdVwtDraPSZW2m9rlXSZU9DRDiv8BjwI0sC9MNJivjI3Teu4= Archived-At: Cc: "core@ietf.org WG" Subject: [core] draft-ietf-core-http-mapping-07 -- was Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 26 Mar 2016 23:08:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pUD0mHcrKSWoAPRTL0L4l2eTlCath5icq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Akbar, thanks for the quick feedback and for the details. I took a look at the mailing list and noticed that the draft has gotten very little feedback during the WGLC. Given the number of people who had provided reviews earlier during the process (as captured in the acknowledgement section) one would hope that those folks could also briefly look at the document and say something (even if it is only a 'I have read it and it looks good.' comment.) Klaus provided an extensive review for which received a detailed answer (around 6 months later). What I haven't seen is a confirmation from Klaus saying that he is happy with the way how the authors/editors handled his review. Basically, there was no discussion about the issues raised on the list. His review lead to a number of changes throughout the document, as it can easily be seen from the diff. Kepeng provided feedback saying that the document should be experimental but I didn't see a response (and the document is still informational). I asked a question about the mapping of HTTP parameters to CoAP options is. The conclusion was that there is no one-to-one mapping since there is no feature parity. As such, there is probably some text in the document that describes the limitations. (I haven't checked it yet.) I believe the HTTP-CoAP mapping document shows that any type of gateway is somewhat complex even for something as simple as a mapping from CoAP to HTTP (and vice versa). I suspect you guys have worked on an implementation to get all the details into the document. =46rom your judgement do you believe there are no further open issues wit= h the document or do you see any concerns with the small number of WGLC reviews? Did you reach out to some other implementers to get their input?= Ciao Hannes On 03/26/2016 10:24 PM, Rahman, Akbar wrote: > Hi Hannes, >=20 >=20 >> For many of the other WG items (e.g., CoRE Resource Directory, draft-i= etf-core-interfaces, draft-ietf-core-http-mapping, >> draft-ietf-core-links-json-04) it is not clear what the open issues ar= e since the document authors do not seem to either use the WG issue track= er or haven't touched it for a while. >=20 >=20 > Here is a summary of the status for draft-ietf-core-http-mapping: >=20 > 1) From IETF-94 (Yokohama) minutes >=20 > https://www.ietf.org/proceedings/94/minutes/minutes-94-core >=20 > "A post WGLC check on draft-ietf-core-http-mapping-07 revealed remainin= g outstanding comments." >=20 >=20 > 2) Here is our recent Email to the list to close these remaining outsta= nding comments (from Klaus) >=20 > https://www.ietf.org/mail-archive/web/core/current/msg06866.html >=20 >=20 > 3) Here is our update of the draft (to -08) that incorporates nearly al= l the comments: >=20 > https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#appendix-A >=20 >=20 > "Changes from ietf-07 to ietf-08: >=20 > o Addressed WGLC review comments from Klaus Hartke as per the > correspondence of March 9, 2016 on the CORE WG mailing list." >=20 >=20 >=20 >=20 >> Do we know who is going to attend the meeting to assign presenters to = the individual items? >=20 > From the Wiki that Carsten just made >=20 > https://github.com/core-wg/ietf95/wiki >=20 >=20 > "=95HTTP Mapping (15) Thomas Fossati (Akbar is the backup) >=20 > draft-ietf-core-http-mapping-08 2016-03-19 >=20 > Objective: Review updates to address the WGLC comments from Klaus Hartk= e" >=20 >=20 >=20 >=20 >> I would like to avoid being in a meeting where nobody knows what is be= ing decided. >=20 > Yes, I agree. Do the above clarify the points for draft-ietf-core-http= -mapping? Please tell us if you need any more information from the autho= rs. >=20 >=20 >=20 > Best Regards, >=20 >=20 > Akbar >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Saturday, March 26, 2016 12:05 PM > To: Carsten Bormann > Cc: core@ietf.org WG > Subject: Re: [core] Agenda >=20 > Hi Carsten, >=20 > thanks for putting up a Wiki. >=20 > For the Block Transfer draft it is obviously difficult to predict what = the IESG comments will be; hence a short slot is appropriate. >=20 > For many of the other WG items (e.g., CoRE Resource Directory, draft-ie= tf-core-interfaces, draft-ietf-core-http-mapping, > draft-ietf-core-links-json-04) it is not clear what the open issues are= since the document authors do not seem to either use the WG issue tracke= r or haven't touched it for a while. >=20 > Could this be done before the meeting starts? This would allow folks to= prepare for the discussion. I would like to avoid being in a meeting whe= re nobody knows what is being decided. >=20 > draft-ietf-core-links-json-04 does not seem to be listed as a separate = item on the agenda? >=20 > Do we know who is going to attend the meeting to assign presenters to t= he individual items? >=20 > Ciao > Hannes >=20 > PS: Btw, I am not volunteering to be the WG secretary. The group has tw= o chairs and you guys should be able to handle this task easily. >=20 > PPS: I still believe that SENML, COOL/COMI, and the security discussion= requires too much preparation for the group upfront so that it will actu= ally distract everyone. >=20 > On 03/26/2016 04:22 PM, Carsten Bormann wrote: >> Hi Hannes, >> >> thanks for volunteering as the new WG secretary. >> >> I have put up the current status with respect to slot requests at >> >> https://github.com/core-wg/ietf95/wiki >> >> This is a wiki, so I'm asking the discussion leaders for the slots to >> update the information right there. >> >> We need to get more detailed objectives for the items; it is not >> sufficient to have an item on the agenda, we also need to know what >> needs to be decided. >> >> Any slot request that is missing? >> >> Any other input on time needed, priorities? >> >> Andrew and I have to put in a revised agenda by Monday, so items where= >> do don't have a discussion leader and detailed objectives are a bit >> endangered. >> >> Gr=FC=DFe, Carsten >> >> >> >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> I thought I should kick of a discussion about the agenda items for >>> the upcoming IETF meeting. Too early to have that discussion? I don't= >>> think so given that the meeting is roughly in a week. >>> >>> I would like to see the following items discussed: >>> >>> 1) Resource Directory >>> 2) CORE Interfaces >>> 3) Block Transfer >>> 4) CoAP over TCP >>> 5) CoAP/HTTP Mapping >>> 6) Representing CoRE Formats in JSON and CBOR >>> >>> Let us try to finish some stuff. >>> >>> For that reason I don't want to see anything else on that agenda. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >=20 --pUD0mHcrKSWoAPRTL0L4l2eTlCath5icq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9xZxAAoJEGhJURNOOiAtbl4H/3YVno2fnpoQgFjYZ20VgWij gW78FkSykjtBEbdL2Zj7whW5Rr4Gna9y1RBq9059eiN/BfHRvqOrSzlFb8lvRxrY rTs0aPVwOYFtsSDpXksJEwM1AAOjZ8if9v7uEVQY+1GVZfGBGDQbw2zD+kj03Gg8 77gXUcs/w9g2XXLzsZFuG9Sp/DKm7ONERvFonRi6fVYOxEO17NfRs+ynuVohwI1P EJUGHM+2UB3v7aO/7hBlcoCW+Sr7n5L9syL0R5ukZRGby2lyvxS94LErjvPf2Ezs RLP8Yzps0RFh1dQgkZ/8W6ahjHzsF58Of3Q3aI4oTlCYgTIOy6GclrS7t3bna34= =MRpK -----END PGP SIGNATURE----- --pUD0mHcrKSWoAPRTL0L4l2eTlCath5icq-- From nobody Sat Mar 26 20:35:33 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8770712D0C0 for ; Sat, 26 Mar 2016 20:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 TO1USbzhUsdb for ; Sat, 26 Mar 2016 20:35:29 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E75112D0AE for ; Sat, 26 Mar 2016 20:35:28 -0700 (PDT) X-ASG-Debug-ID: 1459049726-06daaa714d74d470001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id f9GMsQGAHY2rqBF2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2016 23:35:26 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0266.001; Sat, 26 Mar 2016 23:35:25 -0400 From: "Rahman, Akbar" To: Hannes Tschofenig Thread-Topic: draft-ietf-core-http-mapping-07 -- was Re: [core] Agenda X-ASG-Orig-Subj: RE: draft-ietf-core-http-mapping-07 -- was Re: [core] Agenda Thread-Index: AQHRhrW2zt+iXgwlSE+anWbkGv875Z9sHFAAgAAL2oCAABFFQIAAZQgA///3f1A= Date: Sun, 27 Mar 2016 03:35:24 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BA6E2D9@NABESITE.InterDigital.com> References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <36F5869FE31AB24485E5E3222C288E1F5BA6E252@NABESITE.InterDigital.com> <56F71670.5010403@gmx.net> In-Reply-To: <56F71670.5010403@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.11] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1459049726 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28200 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-http-mapping-07 -- was Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 27 Mar 2016 03:35:31 -0000 Hi Hannes, >Klaus provided an extensive review for which received a detailed answer (a= round 6 months later). Yes, the delay was exceptionally long because as we indicated in our email: ".. apologies for the long delay in answering your comments. None of the = authors were able to make it to last November's IETF meeting where we had w= anted to speak to you directly to resolve some of the issues. This resulte= d in an overall delay to the entire process. However, we were recently abl= e to coordinate a point by point response to comments. Please review and t= ell if us you agree with the responses..." >What I haven't seen is a confirmation from Klaus saying that he is happy w= ith the way how the authors/editors handled his review. Basically, there wa= s no discussion about the issues raised on the list. His review lead to a n= umber of changes throughout the document, as it can easily be seen from the= diff. Yes, so we decided to incorporate the comments directly into the draft and = allow everyone in the WG to see the changes as parsing all the impacts from= Email discussion is difficult. Our major hope is that we can have a good = review and discussion in Buenos Aires and get Klaus and hopefully the rest = of the WG to agree (or disagree) with the changes so that we can close the = WGLC. >Kepeng provided feedback saying that the document should be experimental b= ut I didn't see a response (and the document is still informational). Yes, Klaus asked a similar question in his review, and we proposed an answe= r in our email to the WG (see Authors Response #1) as follows: "We propose to leave the document as Informational as there is good precede= nce for this. For example, a random search of Informational RFCs in the IE= TF stream shows that many Informational RFCs use RFC2119 language." That is why we had not answered directly to Kepeng (i.e. we assumed he woul= d see our response in the Email to Klaus). Though obviously your question= indicates that our approach was not the clearest. >I asked a question about the mapping of HTTP parameters to CoAP options is= . The conclusion was that there is no one-to-one mapping since there is no = feature parity. As such, there is probably some text in the document that d= escribes the limitations. (I haven't checked it yet.) We have guidance for mapping of HTTP parameter to selected CoAP options in = Sections 6 and 7: https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#section-6 https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#section-7 (Also, of course, the original CoAP RFC7252 had some guidance for this topi= c in https://tools.ietf.org/html/rfc7252#section-10.2 ) >I believe the HTTP-CoAP mapping document shows that any type of gateway is= somewhat complex even for something as simple as a mapping from CoAP to HT= TP (and vice versa). I suspect you guys have worked on an implementation to= get all the details into the document. As you know, the draft focuses on the reverse HTTP-CoAP proxy case, as the = feeling in the WG was that the forward proxy case was well specified in RFC= 7252. Two of the authors had separate early implementations of the reverse= HTTP-CoAP proxy. Since then there appears to be other open source impleme= ntations of various versions of the draft as discussed in F2F meetings and = also apparent through Google. >From your judgement do you believe there are no further open issues with t= he document or do you see any concerns with the small number of WGLC review= s? Did you reach out to some other implementers to get their input? In my opinion, if we can close Klaus' comments we are in good shape. We ha= d multiple expert reviews of the draft over the years so we feel it has bee= n reviewed quite extensively overall. No, we did not reach out specificall= y to any other implementers for their input at the WGLC as the WG discussio= n on the topic especially over many F2F meetings has been quite vocal and a= ctive. (Please note that we started the I-D that spawned this WG draft in = January 2012. So we have been working on and discussing this topic for ove= r 4 years). Best Regards, Akbar -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Saturday, March 26, 2016 7:09 PM To: Rahman, Akbar Cc: core@ietf.org WG ; Carsten Bormann Subject: draft-ietf-core-http-mapping-07 -- was Re: [core] Agenda Hi Akbar, thanks for the quick feedback and for the details. I took a look at the mailing list and noticed that the draft has gotten ver= y little feedback during the WGLC. Given the number of people who had provi= ded reviews earlier during the process (as captured in the acknowledgement = section) one would hope that those folks could also briefly look at the doc= ument and say something (even if it is only a 'I have read it and it looks = good.' comment.) Klaus provided an extensive review for which received a detailed answer (ar= ound 6 months later). What I haven't seen is a confirmation from Klaus sayi= ng that he is happy with the way how the authors/editors handled his review= . Basically, there was no discussion about the issues raised on the list. H= is review lead to a number of changes throughout the document, as it can ea= sily be seen from the diff. Kepeng provided feedback saying that the document should be experimental bu= t I didn't see a response (and the document is still informational). I asked a question about the mapping of HTTP parameters to CoAP options is.= The conclusion was that there is no one-to-one mapping since there is no f= eature parity. As such, there is probably some text in the document that de= scribes the limitations. (I haven't checked it yet.) I believe the HTTP-CoAP mapping document shows that any type of gateway is = somewhat complex even for something as simple as a mapping from CoAP to HTT= P (and vice versa). I suspect you guys have worked on an implementation to = get all the details into the document. >From your judgement do you believe there are no further open issues with th= e document or do you see any concerns with the small number of WGLC reviews= ? Did you reach out to some other implementers to get their input? Ciao Hannes On 03/26/2016 10:24 PM, Rahman, Akbar wrote: > Hi Hannes, > > >> For many of the other WG items (e.g., CoRE Resource Directory, >> draft-ietf-core-interfaces, draft-ietf-core-http-mapping, >> draft-ietf-core-links-json-04) it is not clear what the open issues are = since the document authors do not seem to either use the WG issue tracker o= r haven't touched it for a while. > > > Here is a summary of the status for draft-ietf-core-http-mapping: > > 1) From IETF-94 (Yokohama) minutes > > https://www.ietf.org/proceedings/94/minutes/minutes-94-core > > "A post WGLC check on draft-ietf-core-http-mapping-07 revealed remaining = outstanding comments." > > > 2) Here is our recent Email to the list to close these remaining > outstanding comments (from Klaus) > > https://www.ietf.org/mail-archive/web/core/current/msg06866.html > > > 3) Here is our update of the draft (to -08) that incorporates nearly all = the comments: > > https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#appendix-A > > > "Changes from ietf-07 to ietf-08: > > o Addressed WGLC review comments from Klaus Hartke as per the > correspondence of March 9, 2016 on the CORE WG mailing list." > > > > >> Do we know who is going to attend the meeting to assign presenters to th= e individual items? > > From the Wiki that Carsten just made > > https://github.com/core-wg/ietf95/wiki > > > ".HTTP Mapping (15) Thomas Fossati (Akbar is the backup) > > draft-ietf-core-http-mapping-08 2016-03-19 > > Objective: Review updates to address the WGLC comments from Klaus Hartke" > > > > >> I would like to avoid being in a meeting where nobody knows what is bein= g decided. > > Yes, I agree. Do the above clarify the points for draft-ietf-core-http-m= apping? Please tell us if you need any more information from the authors. > > > > Best Regards, > > > Akbar > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > Sent: Saturday, March 26, 2016 12:05 PM > To: Carsten Bormann > Cc: core@ietf.org WG > Subject: Re: [core] Agenda > > Hi Carsten, > > thanks for putting up a Wiki. > > For the Block Transfer draft it is obviously difficult to predict what th= e IESG comments will be; hence a short slot is appropriate. > > For many of the other WG items (e.g., CoRE Resource Directory, > draft-ietf-core-interfaces, draft-ietf-core-http-mapping, > draft-ietf-core-links-json-04) it is not clear what the open issues are s= ince the document authors do not seem to either use the WG issue tracker or= haven't touched it for a while. > > Could this be done before the meeting starts? This would allow folks to p= repare for the discussion. I would like to avoid being in a meeting where n= obody knows what is being decided. > > draft-ietf-core-links-json-04 does not seem to be listed as a separate it= em on the agenda? > > Do we know who is going to attend the meeting to assign presenters to the= individual items? > > Ciao > Hannes > > PS: Btw, I am not volunteering to be the WG secretary. The group has two = chairs and you guys should be able to handle this task easily. > > PPS: I still believe that SENML, COOL/COMI, and the security discussion r= equires too much preparation for the group upfront so that it will actually= distract everyone. > > On 03/26/2016 04:22 PM, Carsten Bormann wrote: >> Hi Hannes, >> >> thanks for volunteering as the new WG secretary. >> >> I have put up the current status with respect to slot requests at >> >> https://github.com/core-wg/ietf95/wiki >> >> This is a wiki, so I'm asking the discussion leaders for the slots to >> update the information right there. >> >> We need to get more detailed objectives for the items; it is not >> sufficient to have an item on the agenda, we also need to know what >> needs to be decided. >> >> Any slot request that is missing? >> >> Any other input on time needed, priorities? >> >> Andrew and I have to put in a revised agenda by Monday, so items >> where do don't have a discussion leader and detailed objectives are a >> bit endangered. >> >> Gr=FC=DFe, Carsten >> >> >> >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> I thought I should kick of a discussion about the agenda items for >>> the upcoming IETF meeting. Too early to have that discussion? I >>> don't think so given that the meeting is roughly in a week. >>> >>> I would like to see the following items discussed: >>> >>> 1) Resource Directory >>> 2) CORE Interfaces >>> 3) Block Transfer >>> 4) CoAP over TCP >>> 5) CoAP/HTTP Mapping >>> 6) Representing CoRE Formats in JSON and CBOR >>> >>> Let us try to finish some stuff. >>> >>> For that reason I don't want to see anything else on that agenda. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core > From nobody Sun Mar 27 03:59:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9A612D169 for ; Sun, 27 Mar 2016 03:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws-FxdARopfj for ; Sun, 27 Mar 2016 03:59:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF9D12D168 for ; Sun, 27 Mar 2016 03:59:40 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LjIBr-1aB3yd0ir9-00dU2x; Sun, 27 Mar 2016 12:59:24 +0200 To: "Rahman, Akbar" References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <36F5869FE31AB24485E5E3222C288E1F5BA6E252@NABESITE.InterDigital.com> <56F71670.5010403@gmx.net> <36F5869FE31AB24485E5E3222C288E1F5BA6E2D9@NABESITE.InterDigital.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F7BD0D.3020600@gmx.net> Date: Sun, 27 Mar 2016 12:59:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BA6E2D9@NABESITE.InterDigital.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G8m2jpeVl84hdTjjE2LWnHoNBIbR2HLcQ" X-Provags-ID: V03:K0:s+9QvA8y3ge5JPatowIAu/82Xa0KuD6LohZlNSfKq5RH58izCFY 3SKqz6Fi2T2Yye+LNae8Com8xVJ8+QC1Q5X700EIMpNCIYma6ue3/vMX8SuVtyduVFX1T99 L0EjPjEkxjZl6O4GqaIVCfMfvvIBGPQTCk+enzabC2NYDenCWSZCvLCmO1qaFrCfVrAwuK/ iOZow5GWn2pvAMHCqJgVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:sZaAGRu1qlg=:x0lON34Ww4s6/QaCT3bCLs 0RVDdIHRPOUm7uZT2d+YPBbHqarK8ft4zKHH9FylvKcoa2aWsA1B+ZvfXWdKdhJDaBKAcEa7s zfXfYfL3iiTGEqj4Ft6tNDH3nfPU4A1dS8DZWQvxkV6yLJy3Cwgivut7tPY+aB+ZyUCRtJPlS UIgc83gR7MyVxMboUvF86pR2TPh280fmiNw/ONNW2wNrsn8X6rAe7iJ/ZvhYlYxBQA0pUuGlp LXAzBvHBjzf27AUWhJVSF8ovAVuWybI5+0MHhVp8wFZc/YnNUYH5lydJ7+bLTo8UfT3Kf2Icv 7m05Ohf/WoFu3wPL3thAg7foSxnBA3TaL8fCkgZUkw7zSd6xsMIi2nCC1qdcuQXM6OvVbSslM Y9F6v8ooIMXdKD7jysedOF0UEoODm6OqhTsWJoyOKOM+AAL+/7R8b5mFri/oDmlCM3UckbUte AmTlyPZiPTbdfHHKv2UIk4rYf7jLKbJ2jdas5Bhi5NzMlV2WvmjRrJ8/+J6/O7YXvPj/bg1sn eFW7jzkJk825TtYg+6n56fGmEAxw3VJ/rsAngGHCYDTHFNg28cs88QfbzMUz+omjqNEiLOXVy DJQkNCncFMtguMG5gf4W3Ochf+EJygV/djbo4Fy1ODsVAdqrOEaPRVUhfaNpGVBH/AocQDw76 /dLzCIvb5gzhjU5WMsl0qDCESxlI4w9lHGzuh8n1aE8Vb3Y+Jf+cnM9j2LzvtWbSQ3zSeZlpp +LmiPAzALqbrOL5HFA07T1sE2CdJwnWdn7xe65kXmrA8U2oD5n9zZUhi+Os= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-http-mapping-07 -- was Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 27 Mar 2016 10:59:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G8m2jpeVl84hdTjjE2LWnHoNBIbR2HLcQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the quick response, Akbar. On 03/27/2016 05:35 AM, Rahman, Akbar wrote: >> Kepeng provided feedback saying that the document should be >> experimental but I didn't see a response (and the document is still >> informational). > Yes, Klaus asked a similar question in his review, and we proposed an > answer in our email to the WG (see Authors Response #1) as follows: >=20 > "We propose to leave the document as Informational as there is good > precedence for this. For example, a random search of Informational > RFCs in the IETF stream shows that many Informational RFCs use > RFC2119 language." >=20 > That is why we had not answered directly to Kepeng (i.e. we assumed > he would see our response in the Email to Klaus). Though obviously > your question indicates that our approach was not the clearest. I see the use of RFC 2119 language and the document type as orthogonal. I personally do not have a strong opinion about the question of whether the document should be Informational or Experimental (in general, irrespectively of the content of the document). I will review the document sometime during next week to see whether I can provide any comments. It might be good to reach out to implementers nevertheless since the question about implementation status typically has to be included in the shepherd writeup. I believe the main audience for this type of document are home gateway vendors. Ciao Hannes --G8m2jpeVl84hdTjjE2LWnHoNBIbR2HLcQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW970NAAoJEGhJURNOOiAtrg8H/2PHCagF9hcWjEHty7qvcuXc fbo++pxAC0jjlWC91/s/Iv+fDPOsTHgScqyK4ewQgWn2cHXmPIdesFSsyiD3VU52 Jrr0UElj4uUhClpQ7gHnN5iH8RkBU+nJJ7vgHqgOOzb7L66yzB2xcwI+fSsSgRxq ekh4RMKr6VXFbvHoJC5IyC5zk5y+bI0XL/EGosbLXcj62VmS8t+6o8G3l4oEkQuZ 2KP9B6CX0n4cc6XHc+7oe1A9SLdTPY9ZrtP6/y4kKyU8GN95Pu3hZU+CFNIilubP JztWL9H64uqLNJLEab9dYVtWRi2de6mVLmbkbxLk3o2F2+nPuAipfccZE6Y71d8= =U7rn -----END PGP SIGNATURE----- --G8m2jpeVl84hdTjjE2LWnHoNBIbR2HLcQ-- From nobody Sun Mar 27 08:24:06 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB712D179 for ; Sun, 27 Mar 2016 08:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 1dhFh_j-dCtq for ; Sun, 27 Mar 2016 08:24:02 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 68FA112D151 for ; Sun, 27 Mar 2016 08:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459092236; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=xA3xTjtlFTjzifC1yh7LlEgWTwAo7EmQ17i4sziWUtQ=; b=YpMiNvR56H2Y6534sW4gnEewiklGrBTjHHCk8mJU6g0oDKOO+Kdok2V7PzpDmg6ZUBE0XGFoLVlkmPQ5Y1r2nBoRPBT6jqzPUo7XzMwKvXiZ7ckhz82a1UQzCtSfzwH/uLU/hwfeY5QAKkTFwctrJ/Rlx0L23gcPOrA/Ge0HEj8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03275; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_----4eC1Suy_1459092230; Received: from 10.22.36.105(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sun, 27 Mar 2016 23:23:53 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 27 Mar 2016 23:23:56 +0800 From: "Kepeng Li" To: Hannes Tschofenig , Carsten Bormann Message-ID: Thread-Topic: [core] Agenda References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> In-Reply-To: <56F6B333.2060105@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 27 Mar 2016 15:24:05 -0000 > For many of the other WG items (e.g., CoRE Resource Directory, > draft-ietf-core-interfaces, draft-ietf-core-http-mapping, > draft-ietf-core-links-json-04) it is not clear what the open issues are > since the document authors do not seem to either use the WG issue > tracker or haven't touched it for a while. About draft-ietf-core-links-json-04, one open issue is to keep consistency with CoRE Resource Directory draft. Especially in section 8 of CoRE Resource Directory draft, it introduced two new link format attributes: ins and exp. We want to encode these two attributes into JSON and CBOR formats. If there is any change (e.g. add more attributes or remove these attributes) in Resource Directory draft, we need to keep up-to-date. I am not sure if we have other open issues, Akbar or Carsten can add. Kind Regards Kepeng =E5=9C=A8 27/3/16 12:05 am=EF=BC=8C "Hannes Tschofenig" =E5=86=99= =E5=85=A5: >Hi Carsten, > >thanks for putting up a Wiki. > >For the Block Transfer draft it is obviously difficult to predict what >the IESG comments will be; hence a short slot is appropriate. > >For many of the other WG items (e.g., CoRE Resource Directory, >draft-ietf-core-interfaces, draft-ietf-core-http-mapping, >draft-ietf-core-links-json-04) it is not clear what the open issues are >since the document authors do not seem to either use the WG issue >tracker or haven't touched it for a while. > >Could this be done before the meeting starts? This would allow folks to >prepare for the discussion. I would like to avoid being in a meeting >where nobody knows what is being decided. > >draft-ietf-core-links-json-04 does not seem to be listed as a separate >item on the agenda? > >Do we know who is going to attend the meeting to assign presenters to >the individual items? > >Ciao >Hannes > >PS: Btw, I am not volunteering to be the WG secretary. The group has two >chairs and you guys should be able to handle this task easily. > >PPS: I still believe that SENML, COOL/COMI, and the security discussion >requires too much preparation for the group upfront so that it will >actually distract everyone. > >On 03/26/2016 04:22 PM, Carsten Bormann wrote: >> Hi Hannes, >>=20 >> thanks for volunteering as the new WG secretary. >>=20 >> I have put up the current status with respect to slot requests at >>=20 >> https://github.com/core-wg/ietf95/wiki >>=20 >> This is a wiki, so I'm asking the discussion leaders for the slots to >> update the information right there. >>=20 >> We need to get more detailed objectives for the items; it is not >> sufficient to have an item on the agenda, we also need to know what >> needs to be decided. >>=20 >> Any slot request that is missing? >>=20 >> Any other input on time needed, priorities? >>=20 >> Andrew and I have to put in a revised agenda by Monday, so items where >> do don't have a discussion leader and detailed objectives are a bit >> endangered. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>=20 >>=20 >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> I thought I should kick of a discussion about the agenda items for the >>> upcoming IETF meeting. Too early to have that discussion? I don't think >>> so given that the meeting is roughly in a week. >>> >>> I would like to see the following items discussed: >>> >>> 1) Resource Directory >>> 2) CORE Interfaces >>> 3) Block Transfer >>> 4) CoAP over TCP >>> 5) CoAP/HTTP Mapping >>> 6) Representing CoRE Formats in JSON and CBOR >>> >>> Let us try to finish some stuff. >>> >>> For that reason I don't want to see anything else on that agenda. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> 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 From nobody Sun Mar 27 09:57:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A012D151 for ; Sun, 27 Mar 2016 09:57:05 -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 8na8wfXGqa7k for ; Sun, 27 Mar 2016 09:57:03 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEE612D134 for ; Sun, 27 Mar 2016 09:57:03 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 1C55EFB883; Sun, 27 Mar 2016 18:57:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Eszqjx8VBlj7; Sun, 27 Mar 2016 18:57:00 +0200 (CEST) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 12F41FB8A1; Sun, 27 Mar 2016 18:56:59 +0200 (CEST) Message-ID: <56F810DB.5050308@tzi.org> Date: Sun, 27 Mar 2016 18:56:59 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Kepeng Li References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 27 Mar 2016 16:57:05 -0000 Kepeng Li wrote: > We want to encode these two attributes into JSON and CBOR formats. Right, giving them a numeric label (for the CBOR version) was the technical change from -03 to -04. However, there is no strict need to make this kind of change, as encoding with a text label is fine, too; the numeric label is just an optimization. So we might want to decide to just ship the formats at some point, even if we know the world is going to continue to change around us. (We also might want to decide to generalize the JSON/CBOR link formats along the lines of what is being discussed in T2TRG. Probably the best of both worlds is to find a way to do this that is a highly decoupled extension of what we have, so we can put the extension point into the current format but gather some experience before actually defining such an extension. I hope we can work this out before Buenos Aires...) Grüße, Carsten From nobody Sun Mar 27 12:31:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2212D1A4 for ; Sun, 27 Mar 2016 12:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAr2K9IkvKOx for ; Sun, 27 Mar 2016 12:31:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553FF12D0B8 for ; Sun, 27 Mar 2016 12:31:44 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMk99-1afZq60f1z-008XIW for ; Sun, 27 Mar 2016 21:31:41 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F8351E.20304@gmx.net> Date: Sun, 27 Mar 2016 21:31:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Hb6cl6urHbbeCGn4U27pR4T4F8wx224EV" X-Provags-ID: V03:K0:P67Cm4a/vDaWXtDoVCqtEAst25ZvAcbPiAA2G9LTp1sND6puSO4 v1Ui3bv9efA0iW+bP+/l/OxR4gAjnVmByCEUxnnZY3QjUfGDy0MOBrB5VDthZeCDZBihF+3 L3JN4WWHeBt+dAA/1AwQJrt+qsc5J+mwo5zQcOJIUp4uVbEGDdVUJSq+DQCWHtQjz64rbRO hGaHx1YcUfleZNTdkHQ5w== X-UI-Out-Filterresults: notjunk:1;V01:K0:KyKWqjlPY8Y=:G9w/0SoCtpU1sxu3BV3nH5 FDuzNKT85xlkSQtrsqF3Bp7Kv9y1Y4KfdvxxdhyePTBy99iQZn8JMT8atOdAZwUG4ao7bg4xl l3YMODZDS5rTT9QrgPEdu1uK04lPJZmen2McF161kGUbhhY9Z6wOPM3rYyNdcHJ/jiXcIAytQ /u7D+HjaITI53xVHJiX5RraHApbR4NU88jCQZOlqDrNUg92CMJlXp/1vI6FVDor18Vc63BNIP KpGEVtZGgtkadFzl1MyDEuTQIVP/Ml0GSXi/6lHJVDjMAWsiRNzp0FXX6YshmY2iac5733ecP PM2v2yOk13upQ7W52d7+XEsMSH54dQVfsKJmXXg3WHgaGn/X4skqgX5iYYCzdjMOnr+KN948H F7c8O4wmrb4MAzNZGtjkNdUFzSZsu6voN4OrlU9pzwudsD9aIi11d9plNBE0mv6PSYmYEQgr+ gv8z+svuSoEc0bSL/cyoyjIlVAkty/w/LUdWrczqq9W/91X21D2nKKDpdCUwJRnegUV6PCn6M wt4LRCOzyhK4tKWZAPj1ekDtztZZiODdzGmGTJSfGYlp4W7mJjkhkfdx2jACFpGZ1eAxK2pNv UzYe/UvvgaMfuz1GPF4BoJY6etC3/cN8YezxcyHOlXujmzhnRlt1tUWyoT3uo2sValfDtfdKu AW3BCQO9oM/SqavN75cNk2fzHYZYkJ+wCNpeBQDZ6cVhQmsf5r04M2XL8PHoF+J0wbpPOBR/A 3kikFhe6wBmwGfbGUv8YSddLb24ktp+hf6qo1RYW03EAngmSaHdmFB43mrU= Archived-At: Subject: [core] draft-ietf-core-http-mapping-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 27 Mar 2016 19:31:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Hb6cl6urHbbeCGn4U27pR4T4F8wx224EV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I had the chance to review the draft-ietf-core-http-mapping-08 and the document looks good to me from a technical point of view. Impressive amount of work. I had one question about the assumptions made about the client. The client embeds the CoAP URI (Target CoAP URI) into the HTTP URI (HC Proxy URI). In order to make this transformation it first needs to know it. Of course, you can assume that the client got manually configured but is this realistic? What are the options for a client to learn the Target CoAP URI? Ciao Hannes PS: I wonder whether the document title should be changed from 'Guidelines for HTTP-CoAP Mapping Implementations' to 'Implementation Guidelines for HTTP-CoAP Reverse Proxies' --Hb6cl6urHbbeCGn4U27pR4T4F8wx224EV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+DUeAAoJEGhJURNOOiAtHXsIAKJK8wqGLGcLu5ntMP0fDCdM sE44x7SYT54VzuN3IVtitAlo91lwe48K/Dg9AXAgLIuhMY56y2bmzsehmmjJaZwW NaZpId3upf5e44mJoxDJBHA2QCwavCLpCdoyd4Hi/kaaUFeCPXaNDZgN31uLpftC BDYMDgp4ayM/4J3JBR5Niwnad+/QJ7AelrnCqFCJJuwFjQn2q3nkLNrTSU63pRfT 28A0pVHcssAmAwSXoErYZCOXAHMOe772spvm1tWD+9rw4YjkkpkwxqNpf3LHycA7 E3eypaUK9rD4Q55cnHMBLQVgVoDwV/VNvZgWIMRSVf6PI0N2+3aZut3wEs1jEg0= =MimU -----END PGP SIGNATURE----- --Hb6cl6urHbbeCGn4U27pR4T4F8wx224EV-- From nobody Sun Mar 27 19:22:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C012D0B0 for ; Sun, 27 Mar 2016 19:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gMajhPuJzOGZ for ; Sun, 27 Mar 2016 19:22:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53F312D0A3 for ; Sun, 27 Mar 2016 19:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NOnRV6DICnUuZe2nUC52Iqb1nWQBM93I7Vt0HVc41S8=; b=My3x8zyY2Mabsztq+RM4jvyY5dKvod/9gN70dYTUqEsFbXLGOeizbWQlwLVXN5NQnOf8qBHPQPeqY5oIkObtpQGmJvdhWzyz9yUNkEQb0qnUI9OrGUyEnLr9IwFAe0GTZZUA2YLCawhf21QfwkLuHp0ysH0AwYOGf4U0IY+h484= Received: from BY2PR0301MB0693.namprd03.prod.outlook.com (10.160.63.148) by BY2PR0301MB0696.namprd03.prod.outlook.com (10.160.63.150) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 28 Mar 2016 02:22:50 +0000 Received: from BY2PR0301MB0693.namprd03.prod.outlook.com ([10.160.63.148]) by BY2PR0301MB0693.namprd03.prod.outlook.com ([10.160.63.148]) with mapi id 15.01.0434.023; Mon, 28 Mar 2016 02:22:50 +0000 From: Luyuan Fang To: "core@ietf.org WG" Thread-Topic: draft-fang-core-coap-pubsub-failure-detection-00.txt Thread-Index: AdGIkMDG2mzEJIl/R+W3Qnm4GVLE3A== Date: Mon, 28 Mar 2016 02:22:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [73.254.145.178] x-ms-office365-filtering-correlation-id: 92c39e34-8884-49fc-7354-08d356afdc19 x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0696; 5:n90+7Lg3Dk6NXPm9uLye87EWEPhj0Q0ie6J20JQzRn3y1GVrShmHi0chGk2ZTDo8cgPbmDTepiQzH6epdhXrUWjRkNzSxKmdoY3+G7aj+vyn1thE80EQVokMfd5FbxoLmSPmLG/ODyDnKclbUVmbkQ==; 24:5/K80Ea+XjSqzO27Jndko2Vmmy1ODLmSMe8hmL9nlnhlFZGwAC31ffJvKtJ9Q1XXjh0KR+ZeQWhdg0uk1H845G2lbArBv8qrTrugHtP+APg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0696; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR0301MB0696; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0696; x-forefront-prvs: 0895DF8FFD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(53754006)(10090500001)(33656002)(50986999)(15975445007)(77096005)(561944003)(586003)(54356999)(5008740100001)(19580395003)(189998001)(110136002)(87936001)(10400500002)(11100500001)(10290500002)(5005710100001)(92566002)(2900100001)(5003600100002)(450100001)(15188555004)(81166005)(102836003)(86612001)(99286002)(6116002)(230783001)(76576001)(122556002)(5002640100001)(107886002)(86362001)(2906002)(3846002)(5004730100002)(66066001)(3660700001)(1096002)(3280700002)(1220700001)(74316001)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0696; H:BY2PR0301MB0693.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2016 02:22:49.9262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0696 Archived-At: Subject: [core] draft-fang-core-coap-pubsub-failure-detection-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 02:22:54 -0000 SGkgYWxsLA0KDQpJIHBvc3RlZCBkcmFmdC1mYW5nLWNvcmUtY29hcC1wdWJzdWItZmFpbHVyZS1k ZXRlY3Rpb24tMDAudHh0LiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhbmct Y29yZS1jb2FwLXB1YnN1Yi1mYWlsdXJlLWRldGVjdGlvbi0wMC5odG1sDQoNClNvbWUgb2YgdGhl IGNoYXJhY3RlcmlzdGljcyBvZiBDb0FQIG1ha2UgaXQgYSBncmVhdCBjYW5kaWRhdGUgZm9yIGZh c3QgZmFpbHVyZSBkZXRlY3Rpb24gb2YgbmV0d29yayBlbGVtZW50IGluIHRoZSBoeXBlci1zY2Fs ZSBkYXRhY2VudGVyIGFuZCBjbG91ZC4gDQoNClRoZSBleGlzdGluZyBkcmFmdC1rb3N0ZXItY29y ZS1jb2FwLXB1YnN1Yi0wNCBpcyBwcm9wb3NpbmcgZXh0ZW5zaW9ucyB0byBDb0FQIHRvIHN1cHBv cnQgdGhlIHB1Yi9zdWIgcGFyYWRpZ20sIHdoaWNoIHdvdWxkIG1ha2UgQ29BUCBldmVuIG1vcmUg YXR0cmFjdGl2ZSBmb3Igb3VyIHB1cnBvc2VzLg0KDQpJbiBvdXIgZHJhZnQsIHdlIHByb3Bvc2Ug dHdvIGFkZGl0aW9uYWwgZXh0ZW5zaW9ucyB0aGF0IHdvdWxkIGJlIHZlcnkgdXNlZnVsIGluIHRo ZSBmYXVsdCBkZXRlY3Rpb24gdXNlIGNhc2UsIGFuZCBmb3Igb3RoZXIgdXNlIGNhc2VzIGFzIHdl bGwuIFRoZSBmaXJzdCBleHRlbnNpb24gaXMgdGhlIGFkZGl0aW9uIG9mIExhc3QgV2lsbCBUZXN0 YW1lbnQgKExXVCkgZnVuY3Rpb25hbGl0eS4gV2UgYmVsaWV2ZSBMV1QgaXMgYW4gZXh0cmVtZWx5 IHVzZWZ1bCBjb25jZXB0IHRoYXQgZ29lcyBoYW5kLWluLWhhbmQgd2l0aCB0aGUgcHViL3N1YiBw YXJhZGlnbSwgYW5kIGlzIGlkZWFsbHkgZGVzaWduZWQgZm9yIHRoZSBmYXVsdCBkZXRlY3Rpb24g dXNlIGNhc2UuIFRoZSBzZWNvbmQgZXh0ZW5zaW9uIHRoYXQgd2UgcHJvcG9zZSBpcyBmdW5jdGlv bmFsaXR5IHRvIGFkZHJlc3MgdGhlIFNpbmdsZSBQb2ludCBvZiBGYWlsdXJlIGlzc3VlIG9mIHRo ZSBicm9rZXIgaW4gdGhlIHB1Yi9zdWIgcGFyYWRpZ20uIENsZWFybHksIHRoaXMgaXNzdWUgcmVx dWlyZXMgYW4gZWZmZWN0aXZlIHNvbHV0aW9uIGluIG9yZGVyIHRvIG1ha2UgQ29BUCB3aXRoIHB1 Yi9zdWIgZXh0ZW5zaW9uIHN1aXRhYmxlIGZvciBmYXVsdCBkZXRlY3Rpb24uDQoNClRoaXMgZHJh ZnQgcHJvdmlkZXMgdGhlIGJhY2tncm91bmQgb2YgdGhlIHByb2JsZW0gd2UgYXJlIHRyeWluZyB0 byBzb2x2ZSwgYW5kIGFuIGluaXRpYWwgcHJvcG9zYWwgZm9yIHRoZSBleHRlbnNpb25zLiANCg0K QXMgY2xvdWQgcHJvdmlkZXJzLCB3ZSBoYXZlIGFuIHVyZ2VudCBuZWVkIHRvIGZpbmQgbGlnaHR3 ZWlnaHQgc29sdXRpb25zIHRvIHNpbXBsaWZ5LCBleHBlZGl0ZSwgYW5kIGltcHJvdmUgZmF1bHQg ZGV0ZWN0aW9uIGluIG91ciBuZXR3b3JrLiBXZSBiZWxpZXZlIENvQVAgY2FuIGJlY29tZSBhbiBp bXBvcnRhbnQgaW5ncmVkaWVudCB0byBzb2x2ZSB0aGlzIGNydWNpYWwgaXNzdWUgZm9yIG91ciBi dXNpbmVzcy4gT3VyIGltbWVkaWF0ZSBwdXJwb3NlIHdpdGggdGhpcyBkcmFmdCBpcyB0byBnZXQg dGhlIGRpc2N1c3Npb24gZ29pbmcgaW4gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgSUVURiA5NSBt ZWV0aW5nLCBhbmQgd2UgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiB3b3JraW5nIHdpdGggb3RoZXJz IGluIHRoZSBXRyB0byByYXBpZGx5IHByb2dyZXNzIHRoaXMgaW1wb3J0YW50IHRvcGljLiANCg0K VGhhbmtzLA0KTHV5dWFuDQo= From nobody Mon Mar 28 03:44:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62F012D85C for ; Mon, 28 Mar 2016 03:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax41ALA4twbi for ; Mon, 28 Mar 2016 03:44:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A574A12D85F for ; Mon, 28 Mar 2016 03:44:25 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M6SE3-1ZnaKs2zzn-00yQdJ; Mon, 28 Mar 2016 12:44:14 +0200 To: Carsten Bormann References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F90AFF.5080809@gmx.net> Date: Mon, 28 Mar 2016 12:44:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F6B708.4080805@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tWGtlDvSgIer8bNDVkrhBi54dXSKsOxiw" X-Provags-ID: V03:K0:G5svLU/I2vRReeAhxZnzUSYlml9IV42qXKGVw+0evKjxgHdqm71 aGKJ1Y57UnnIGR0ge/J71Fq61nSIqPeprrUFO+ZfceaFVwd3sxE7ET0nyN8Y4LhYTDDo6Op RzXwJ+CA/QhQMHGC1DFdRNHGLHlXT5+6GxhxlKvS1J3wQ5EwqKshOcpFKNOm/69+ROdsAZH Mz9j9n9p8YdOYXgt+ASKA== X-UI-Out-Filterresults: notjunk:1;V01:K0:lLlms6vrIrE=:44tb95CZL9gSOp7beSyBRN mha53JsU0B9vMpUCRPLGXpICb8pDLbZ21P+CWYr86huyo58gfA2WaFjPGTQIN59LpvYcO/+M4 CUE8VxmpVSTj6F46G2+tR3hymCyBn66NQXr4eEHQZesodxd6FKp2nCBYZV2FwXz8idbEN0DF7 mwu+lbQ1C0DTkZ2YXFCXinFdCAjrZu+F0tdl41cbM0qZC4WpLOKz/VQhVIZBEa7Jy9n/FaBZm Tvh2MWOjkEyN/SNNSuK8PkUUGx9026fUMSPlFXqHL+nuZ78Ud5yMk0M0L+/UMfIwuqF7kMsod du47n8jcyNj5wpfX0H0WYRZFDUi9sASlWYSKw8d/OnAS03i+4SpH0ep7YDxS6hofE2qpw7ffc oZU1HcN3NwNOLRdRQ1pvXizxEC2ZtEAHLm26vFM8ZQvOmIpAXHllQ+OuuCvdRPCjqNFuWMdFh a6aXSxJeoPHbELcZz10U6qR+eRMTdc7YcamkVju+rrluo8PY2QRS4ouasqU/sZM0xdgwoFS3s PNySEsNI6Yg9Nui3AW2EcxAAVLPHlJpbKqGdE1G1WIl2npdjJZIZUQFheGnEqT+wQ/GQiuE0p lJoqmf1j+AcdzHge3TO1rRnKFUFRvBqi0j2pryUHHqtTJxdT98LVwIWgxkt0uQRAmZ7ckfkG4 Qjdsw82AdQdmp51wY7KKNA9jCc3kkyBZ03NCbdTtNl25/PFgNS+S3Idqa5In1C6ZRi2CQq71I Ok54LOP7XIidsrt3cU3dJDWzm0MWAF+xowmULUUQo1bPc3xyROikF588yWw= Archived-At: Cc: "core@ietf.org WG" Subject: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 10:44:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tWGtlDvSgIer8bNDVkrhBi54dXSKsOxiw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, I have re-read the Blockwise Transfer draft and the document does not give me the impression that there is any specific need to tie it to Object Security. Can you explain what the relationship is? I hope there is no plan to make the completion of Blockwise transfer dependent on the progress of object security. Ciao Hannes On 03/26/2016 05:21 PM, Carsten Bormann wrote: >> For the Block Transfer draft it is obviously difficult to predict what= >> > the IESG comments will be; hence a short slot is appropriate. > Exactly. > The one issue that has taken a while to resolve at the end was the > interaction with Object Security, we can discuss that part there, and > G=C3=B6ran has volunteered to lead that discussion. >=20 --tWGtlDvSgIer8bNDVkrhBi54dXSKsOxiw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+Qr/AAoJEGhJURNOOiAt4YgH/0Bz3pim45AO8dHjAyT6CiHx kcVCLQdYli305752XAQxB/SNVwfZjCLoYDtBTLiXyZqhMXpvPvuT9lf6VP/M/562 a9xWxHLwm4fS0w90ZSYsNsiAbWGnT3jWJslmS01quNn+mUeqQ9HTtw6yGQmT5Xo5 Wcqo9pBg6xXLmgWQy69dH0KZtmwvdpEOGz8tk8pQu3nehBKfLYjrPxofankXzYDQ b4zzqh544fr1vgQfXRcm1iCbWwC0Tbq5zGzrUnllmHrsoN5rhvlF/he9VwYJnav4 kF+kfNT9pYwma13Hi73J3+vpoYZk2RoRgUbot2qZjxP4AsXb4rMq+Hx9x1DoiCg= =sPou -----END PGP SIGNATURE----- --tWGtlDvSgIer8bNDVkrhBi54dXSKsOxiw-- From nobody Mon Mar 28 04:48:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACBD12D8A6 for ; Mon, 28 Mar 2016 04:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUwl_rq-JENY for ; Mon, 28 Mar 2016 04:48:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AF412D88C for ; Mon, 28 Mar 2016 04:48:27 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LZiQy-1a1a440Kp2-00lUP4 for ; Mon, 28 Mar 2016 13:48:24 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:48:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bnDwmiSG4KpxT7At93Aqnsbxqsb5haBSN" X-Provags-ID: V03:K0:ZZtQvuYZ841K5Y+pMfEys6RPrgpaQh3I6hHnpGe37ySUd433rv5 XZoyAllgAmndVDgqxDjA3VbTjUNE1bEp+0oCl7KGh8gbw5zKru0t+Z7VCId6OkrYdcJwYwX LGuDme2IpJsRuunHjNl7EKWlzQfQQ0T+zAIYaiw4L9RV4l+eNN5uIWiOsLm1ooMiHTbaBXb iM/nRgEOmrc2FesoAA2qw== X-UI-Out-Filterresults: notjunk:1;V01:K0:F+RvPhFHdMI=:WB/vmpEfjnd1xyB4iABezg pG8zot8Ew5gQ7CN9cgbnbQfwm9WKxP1zMLHLjQwXve5/44vMvAll9Rq1/a3c9X94GIxmWSvru pemtjBngX7lqq82P6gh6d4j1o6Ew9MTH4kIAPeRp+lDF/RJiIc8LWLHUTFjF1QzqwweInTcgq WYTCIltetZ64a50Lse7Ll4eg1gnrA4zr7CajN29K7TyW4sXoWT/Fe47cSNogbCN+vBIOISShx 6C6PrpxH/3gtigpWsSscQWwurbH5gauZ07eFbkdGOJG+WfaB5lD+3QG0WfSNshmxdGxkB75yS u730ygmibF0FdEeHAK+3xFyuH73btCcfTpCVYEHaktZmUHYQhNrPK/ghyppAJo5NIRF+T2RFI Ou3T7tssaGPQT6I6TbIcdWonsV7NxKroTXuSR6Od9sAfKZaRsidQvH+Z0r56xubMYZ36kG68/ Tdg0n0iBgc7OczysWp0fBWS2+6uR6+IqnEQLFvVTR/iaUbjVo2X2EHqxMkGI/rkF/HNiOc4p3 bwOSexW7U+60iowvUsZEcTkvHyEuNd0+hx9E0/cZcAHz5veI0S35q0yRkqcRD1fzoQ4L9AXfD crbkCI/sK5kSK8UX4TuuAokxJcNfWEG8stB8dYXoB+xxJJhPhgc5GY8MVGuw+qW1i+HFdckPI zm31mCpVu1D0lrQ4vq7jCG3i3HceMuPVC2fcdKpXYpsU9UMHCnkPTs1VuZAZMq2ezUMYUASC0 z4c9QHkmUvLTS4s654L867X5cpFop3pi1DJqSzlvqe6DP2scUDRrzbpOHRg= Archived-At: Subject: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 11:48:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bnDwmiSG4KpxT7At93Aqnsbxqsb5haBSN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I reviewed draft-ietf-core-resource-directory-07 and I have a few comments/questions. ** Open Issues Are the issues listed in https://trac.tools.ietf.org/wg/core/trac/report/1, namely * Ticket #372: https://trac.tools.ietf.org/wg/core/trac/ticket/372 * Ticket #383: https://trac.tools.ietf.org/wg/core/trac/ticket/383 still open? The document notes that there is an open issue regarding patch (see Section 5.6). What exactly is the question that needs to be answered? ** Terminology * The term endpoint in this document is different from the terminology used in the web environment. You might want to state that in the definition since this can easily lead to confusion. Although the CoAP RFC is referenced with regards to the definition it is not the same definition as in the RD draft. Furthermore, the definition of endpoint in Section 2 is different from Section 3. Section 2 says: " Endpoint (EP) is a term used to describe a web server or client in [RFC7252]. In the context of this specification an endpoint is used to describe a web server that registers resources to the Resource Directory. An endpoint is identified by its endpoint name, which is included during registration, and is unique within the associated domain of the registration. Section 3 says: " An endpoint is a web server associated with a scheme, IP address and port (called Context), thus a physical node may host one or more endpoints. " RFC 7252 says: " An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association." I don't think that Section 3 again needs to define terminology when this was already done in Section 2. It would be good to know why the terminology from RFC 7252 couldn't be re-used. I suspect that there is some difference. Then, it would be good to know whether the term refers only to a web server or also a client, whether it applies only to CoAP or also other protocols (such as HTTP), and how an endpoint is identified. Regarding the term Resource Directory: The draft sometimes uses RD and sometimes uses the term 'directory server'. I guess that these terms are used interchangeable and for that reason I would say that in the terminology section. Finally, the term 'client' is not defined although it is shown in Figure 1 (architecture). ** MTI What functionality is mandatory to implement? For example, as it can be seen from the LWM2M section in the appendix the OMA LWM2M protocol does not implement everything defined in this spec and I wonder whether it is still a compliant implementation. Another example: DNS-SD is described in the document and the reference to DNS-SD is normative. Do I need to implement the DNS-SD part for an RD implementation to claim conformance to this specification? ** Terminology: Installation tool vs. Commissioning Tool Section 4.2 talks about the 'installation tool' and Appendix 12.1 calls it 'Commissioning Tool'. I think it would be good to define the term in Section 2 and then use the same term throughout the document. Section 6.1 talks about a 'a management entity' even though I am not sure it refers to the same concept as an 'installation tool' or a 'Commissioning Tool'. Later in Section 6.1 the term 'Manager' is used. ** Simple Directory Discovery Section 1 motivates the specification and says Section 4, however, defines a discovery technique and says: " Not all endpoints hosting resources are expected to know how to implement the Resource Directory Function Set (see Section 5) and thus explicitly register with a Resource Directory (or other such directory server). Instead, simple endpoints can implement the generic Simple Directory Discovery approach described in this section. An RD implementing this specification MUST implement Simple Directory Discovery. However, there may be security reasons why this form of directory discovery would be disabled. " =46rom this text I don't understand what the differences between Section = 4 and Section 5 is. As an implementer, why would I want to select the "complex" discovery when I have a simple discovery technique that is mandatory to implement. It would be good to say what the pros & cons are and why this technique is there in the first place. There are also two approaches defined: " An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds. The body of the POST request is either o empty, in which case the directory server is encouraged by this POST request to perform GET requests at the requesting server's default discovery URI. or o a non-empty link-format document, which indicates the specific services that the requesting server wants to make known to the directory server. " Why do I want to have two ways to do the same thing? Couldn't we just pick one? ** Finding a Directory Server Section 4.1 describes different ways to find a discovery server. While it only lists them without giving any guidance on which approach would be most useful in what situation it is reasonably easy to understand. Section 5.1 again talks about discovery and pretty much repeats the same approaches again. I would shorten the description. It is enough to explain it once. ** Figure 1: Architecture I believe the architecture diagram is incomplete. It does not show the installer/commissioning tool, which is mentioned in various sections throughout the document. ** Figure 2: Resource Directory Information Hierarchy This is a nice figure but it would be even nice if it uses some existing notation. In UML, for example, you could use a class diagram. The benefit of re-using existing diagram structures is that people may have an easier time to understand what you mean and you could indicate what the relationship between the different classes are. For example, you can easily express that a domain consists of zero or more endpoints. ** Figures I noticed that all figures showing message exchanges are pretty useless for two reasons: a) You cannot express the necessary information in them. b) You always included the same information again in a non-diagram form afterwards. Here is an example: " EP RD | | | ----- GET /.well-known/core?rt=3Dcore.rd* ------> | | | | | | <---- 2.05 Content ";rt=3D"core.rd" ------- | | | Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* Res: 2.05 Content ;rt=3D"core.rd";ct=3D"application/link-format+cbor", ;rt=3D"core.rd-lookup";ct=3D"application/link-format+cbor"= , ;rt=3D"core.rd-group";ct=3D"application/link-format+cbor" " It would probably be easier to just do the following instead: " >> EP ---- Request -----> RD GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* >> EP <---- Response ---- RD 2.05 Content ;rt=3D"core.rd";ct=3D"application/link-format+cbor", ;rt=3D"core.rd-lookup"; ct=3D"application/link-format+cbor", ;rt=3D"core.rd-group"; ct=3D"application/link-format+cbor" Figure 7: Endpoint discovering an RD. " ** Function Set I have been confused about the strange term 'Function Set' for a while and when I read through the document I got the impression that it is nothing more than a REST API. Do I understand it correctly? ** Register a Group Section 6.1 talks about ways to create a group and it says: " Configuration of the endpoints themselves is out of scope of this specification. Such an interface for managing the group membership of an endpoint has been defined in [RFC7390]. " What type of configuration is outside the scope? ** Lighting Installation Example Why does this example talk about DNS? Is it possible to split the example into two parts, one where DNS-SD is used and another one where it isn't used? Additionally, I have been told that luminaries in a commercial building are installed and commissioned before a network is up and running. I think that the lighting example could show the group concept quite nicely and that's what it should focus on. ** Security Considerations " DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. " Why does this specification say that DTLS or TLS is optional to use? It should mandate the use of DTLS/TLS! The following text should be elsewhere in the document: " An Endpoint is determined to be unique by an RD by the Endpoint identifier parameter included during Registration, and any associated TLS or DTLS security bindings. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint. " Why is there only a SHOULD for mutual authentication in the following paragraph? Where in the certificate should the endpoint identifier go? I would reference the DTLS/TLS profile document for that purpose. Why is there only an identifier matching for the certificate-based approach required? What about the pre-shared secret key mechanism? What about the raw public key mechanism (where the public key is the identifier)? (There would be the possibility to say that the endpoint is just the fingerprint to keep it shorter.) " Every operation performed by an Endpoint or Client on a resource directory SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key or Certificate based security. Endpoints using a Certificate MUST include the Endpoint identifier as the Subject of the Certificate, and this identifier MUST be checked by a resource directory to match the Endpoint identifier included in the Registration message. " Why is access control optional? To me it appears that the document is full of authorization decisions starting with the provisioning, the registration, the lookup, and various other operations. I would at least reference the work we do in ACE since it could be the building block that is needed to offer an authorization story. " Access control SHOULD be performed separately for the RD Function Set and the RD Lookup Function Set, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD. Such access control SHOULD be performed in as fine-grained a level as possible. For example access control for lookups could be performed either at the domain, endpoint or resource level. " Why does the DoS text talk about 'services that run over UDP unprotected"? This section should talk about amplification attacks only and those are related to the access control aspects. In my understanding you cannot really run RD without DTLS/TLS security at all since it would be very problematic from a security and privacy point of view. Also, referencing some Cisco CVE is not really useful here. Ciao Hannes --bnDwmiSG4KpxT7At93Aqnsbxqsb5haBSN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+RoKAAoJEGhJURNOOiAtSRcH/Al6PNezU1oEMZn2dnHaR6VQ EeX0lM79lftI7HodNnrrEX2Rvkte9Kv/uYPA3nSvq6WVgpN3ub2Q2f4HF3e8RHNx oQeHg8Z0MZhm0C+N0SCvBYAtf9l8S/80U1OuuYaA3Zf5I0mtd3ckKbbZtJmuPFBW 2YM3O8a+dJFWdCv3ogwOFJnbzs0hefkqfEU0J1LcnlQg2znj3JyPA8C+QGZtdb1v yNKrlXWtMzNuskToFsR415epVvu42rMl4YB3BS2Xk5mpmA5CsKyYaGDkUKN1NP8x Wsego6CRbKTDVPex1XtQ7ebqNplU93k/Uxey/YEaXgDthDTJgEi/bp7DDV3Jpuc= =Kju4 -----END PGP SIGNATURE----- --bnDwmiSG4KpxT7At93Aqnsbxqsb5haBSN-- From nobody Mon Mar 28 05:14:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2484F12D8E6 for ; Mon, 28 Mar 2016 05:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 LfUrj-z8cL4L for ; Mon, 28 Mar 2016 05:14:39 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8050E12D199 for ; Mon, 28 Mar 2016 05:14:37 -0700 (PDT) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id D44A3C5A4E; Mon, 28 Mar 2016 14:14:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 6C7IQUiWGKRF; Mon, 28 Mar 2016 14:14:34 +0200 (CEST) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 761B1C5A4F; Mon, 28 Mar 2016 14:14:33 +0200 (CEST) Message-ID: <56F92027.9060308@tzi.org> Date: Mon, 28 Mar 2016 14:14:31 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> <56F90AFF.5080809@gmx.net> In-Reply-To: <56F90AFF.5080809@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 12:14:41 -0000 Hi Hannes, > I have re-read the Blockwise Transfer draft and the document does not > give me the impression that there is any specific need to tie it to > Object Security. > > Can you explain what the relationship is? After the last call completed, we had a discussion on the IETF mailing list how to employ object security in a block-wise transfer that spans proxies. If you secure only the complete representation, the cache in a proxy might be poisoned by fake blocks, and you get an availability problem. If you secure each of the blocks (and have a way for the proxy to be part of a security association needed so it also can verify the blocks), you can prevent that, but you still have to secure the way the entire representation is composed from those blocks, and that might mean additional components are needed in an object security protocol. I agree that none of these considerations have a bearing on the block-wise protocol itself, and this also was the resolution we reached after the discussion. But it was useful to have the discussion, and it will inform the discussion about object security. > I hope there is no plan to make the completion of Blockwise transfer > dependent on the progress of object security. No, as far as the CoRE WG is concerned, block-wise is done. It is currently in IESG evaluation and on the agenda of the 2016-04-21 IESG telechat; Matthias Kovatsch is the shepherd. Grüße, Carsten From nobody Mon Mar 28 05:26:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7259912D187 for ; Mon, 28 Mar 2016 05:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKSOEMAbqfYP for ; Mon, 28 Mar 2016 05:26:32 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA55F12D169 for ; Mon, 28 Mar 2016 05:26:31 -0700 (PDT) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 405B541C084; Mon, 28 Mar 2016 14:26:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 55eerTwGUain; Mon, 28 Mar 2016 14:26:28 +0200 (CEST) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 853B741C087; Mon, 28 Mar 2016 14:26:28 +0200 (CEST) Message-ID: <56F922F2.9060203@tzi.org> Date: Mon, 28 Mar 2016 14:26:26 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56F91A0A.5060804@gmx.net> In-Reply-To: <56F91A0A.5060804@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 12:26:34 -0000 Hi Hannes, thank you for this extremely useful review. Many great observations, both around terminology and presentation, and around the relationship to other efforts such as authorization. Something to chew on for Buenos Aires... Let me pick one item as it has a direct bearing on the meeting agenda: Hannes Tschofenig wrote: > The document notes that there is an open issue regarding patch (see > Section 5.6). What exactly is the question that needs to be answered? The question is simply whether we will be able to finish adding the PATCH methods to CoAP (see draft-vanderstok-core-etch) on the same timeline as the time needed for completing the RD document. Some of us are optimistic that this is possible, some think the way to use PATCH with RD should be added as a separate document. But for the discussion of the functionality of the RD, it makes sense to keep the PATCH functionality in context, assuming we can always take out section 5.6 even at a late stage if we run into a problem with PATCH. That's why it is part of -07. Grüße, Carsten From nobody Mon Mar 28 06:06:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A759212D914 for ; Mon, 28 Mar 2016 06:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 e776eJH8rBiW for ; Mon, 28 Mar 2016 06:06:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2F712D912 for ; Mon, 28 Mar 2016 06:06:19 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 14AADE5F6FB5; Mon, 28 Mar 2016 13:06:15 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2SD6HNS026398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2016 13:06:17 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2SD6FgU026520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Mar 2016 15:06:16 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 28 Mar 2016 15:05:56 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] draft-ietf-core-http-mapping-08 Thread-Index: AQHRiF9RI7sacfk9YUWgAhMCeuCp1Z9uw5mA Date: Mon, 28 Mar 2016 13:05:56 +0000 Message-ID: References: <56F8351E.20304@gmx.net> In-Reply-To: <56F8351E.20304@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <87A461D3EE4BCA42A9B6A47DD0F1E5DE@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-http-mapping-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 13:06:22 -0000 Hi Hannes, thanks very much for the review. On 27/03/2016 20:31, "core on behalf of Hannes Tschofenig" wrote: >I had one question about the assumptions made about the client. The >client embeds the CoAP URI (Target CoAP URI) into the HTTP URI (HC Proxy >URI). In order to make this transformation it first needs to know it. I'm assuming 'to know it' refers to the CoAP URI, right? >Of course, you can assume that the client got manually configured but is >this realistic? >What are the options for a client to learn the Target CoAP URI? Consider the following two scenarios: 1. Legacy HTTP application. This guy needs to talk to a CoAP resource and it hasn't got a CoAP stack. It is realistic to assume that it has been pre-configured with the HC Proxy URI that maps to the CoAP resource (e.g. an actuator of some sort). 2. Mobile app. This thing is hosted in a device that can roam from the home net to the public Internet. As such, it's realistic to assume that it's got plenty of chances to discover the CoAP URI of interest while attached to the home net (either via link-format or RD based discovery) and, later on, use the (discovered or statically configured) URI mapping convention to access the target CoAP resource via the public Internet. Cheers, t From nobody Mon Mar 28 06:36:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3712D957 for ; Mon, 28 Mar 2016 06:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jckMhC-nownc for ; Mon, 28 Mar 2016 06:36:44 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F3A12D107 for ; Mon, 28 Mar 2016 06:36:43 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-99-56f933699544 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.98.22880.96339F65; Mon, 28 Mar 2016 15:36:41 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Mon, 28 Mar 2016 15:36:41 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig Thread-Topic: [core] Block Transfer and Object Security .... Re: Agenda Thread-Index: AQHRiN7QrElu1ST8/UiJ0vOten3L1J9uo36AgAA4dAA= Date: Mon, 28 Mar 2016 13:36:41 +0000 Message-ID: References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> <56F90AFF.5080809@gmx.net> <56F92027.9060308@tzi.org> In-Reply-To: <56F92027.9060308@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7jW6m8c8wg6X7jCyOTLnLarHv7Xpm i6U777E6MHss3rSfzWPJkp9MHtMWZQYwR3HZpKTmZJalFunbJXBl7Lmzgqngi0zFtr5b7A2M U2S6GDk5JARMJD7O3MQOYYtJXLi3nq2LkYtDSOAIo8Te/XdZQRJCAksYJdZ3GYHYbAIuEg8a HjGB2CIChhLXZ04Hq2EWcJN4/Pk/cxcjB4ewgLvE1SWyECUeEsd2PWSHsK0k1v84AlbOIqAq ceTUDDCbV8BCYsPTrYwQezcySkxYfAdsPqeAukTvZYgGRqDjvp9awwSxS1zi1pP5TBBHC0gs 2XOeGcIWlXj5+B9YvaiAnsTtjrVQjylJLLr9mQnkNmYBTYn1u/QhxlhLbHh8Eep8RYkp3RB3 8goISpyc+YRlAqPELCTbZiF0z0LSPQtJ9ywk3QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWl lmxiBEblwS2/dXcwrn7teIhRgINRiYf3QfiPMCHWxLLiytxDjBIczEoivHVGP8OEeFMSK6tS i/Lji0pzUosPMUpzsCiJ87J9uhwmJJCeWJKanZpakFoEk2Xi4JRqYLQyTpig/7D4tfTNCQZu etO8onbHhGa0y9yde1yI/XZRZUjpiqC04MKONr5XHXxzvI84Tjr0Snfy5DzRrfWyN3e+kT57 K3i+gPq+V78Fztu9XMSVFjh9tsdTlSVP7a7n7vGYzPgha9m10BWhiuu7ox70/pBu157outAy dr1k3gzrarFHtZoRk5RYijMSDbWYi4oTAeoUkDzGAgAA Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 13:36:51 -0000 SGkgSGFubmVzDQoNCkNvbXBsZW1lbnRpbmcgQ2Fyc3RlbuKAmXMgZXhwbGFuYXRpb246DQoNClRo ZXJlIGlzIGEgY29uZmxpY3QgYmV0d2VlbiBiZWluZyBhYmxlIHRvIHByb3RlY3QgYSBtZXNzYWdl IGZyYWdtZW50DQplbmQtdG8tZW5kIGJldHdlZW4gZW5kcG9pbnRzIGFuZCBnaXZpbmcgYW55IGlu dGVybWVkaWF0ZSBub2RlIHRoZSByaWdodCB0bw0KcmVmcmFnbWVudCBhIG1lc3NhZ2UuIEJsb2Nr IG9wZXJhdGlvbnMgcGVyZm9ybWVkIGJ5IHByb3hpZXMgY2Fubm90IGJlDQp2ZXJpZmllZCB3aGlj aCBoYXMgdHdvIGNvbnNlcXVlbmNlcy4gQmxvY2t3aXNlIGNhbm5vdCBiZSBkaXJlY3RseSBhcHBs aWVkDQp0byBzZWN1cmUgbWVzc2FnZSBmcmFnbWVudGF0aW9uLCBhbmQgdGhlIEJsb2NrIG9wdGlv biBvcGVucyB1cCBmb3IgRG9TIGJ5DQphbnkgb24tcGF0aCBhZHZlcnNhcnkuIEkgZm91bmQgdGhp cyBzZXJpb3VzIGVub3VnaCB0byB3YXJyYW50IGEgc2VjdXJpdHkNCmNvbnNpZGVyYXRpb24sIHdo aWNoIGlzIGluY2x1ZGVkIGluIC0xOS4NCg0KSXQgdHVybnMgb3V0IHRoYXQgd2hpbGUgcGxhaW50 ZXh0IENvQVAgYmxvY2sgb3B0aW9ucyBwYXNzaW5nIHByb3hpZXMNCmNhbm5vdCBiZSBwcm90ZWN0 ZWQgaW4gdGhlIHdheSAgYmxvY2t3aXNlIHdvcmtzLCB0aGV5IGNvdWxkIHBvdGVudGlhbGx5IGJl DQp1c2VkIGVuZC10by1lbmQgaWYgeW91IHdlcmUgY2VydGFpbiB0aGVyZSB3ZXJlIG5vIGNoYW5n ZXMgYmVpbmcgbWFkZSBpbg0KdHJhbnNmZXIsIGFuZCB0aGF0IGlzIHNvbWV0aGluZyBhbiBvYmpl Y3Qgc2VjdXJpdHkgc29sdXRpb24gY291bGQgYmUgdXNlZA0KZm9yLiBUaGlzIGlzIG9uZSBvZiB0 aGUgdG9waWNzIEnigJlkIGxpa2UgdG8gZGlzY3VzcyBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbg0K b24gdGhlIENvUkUgYWdlbmRhLg0KDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTYtMDMtMjggMTQ6MTQs ICJjb3JlIG9uIGJlaGFsZiBvZiBDYXJzdGVuIEJvcm1hbm4iDQo8Y29yZS1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBjYWJvQHR6aS5vcmc+IHdyb3RlOg0KDQo+SGkgSGFubmVzLA0KPg0K Pj4gSSBoYXZlIHJlLXJlYWQgdGhlIEJsb2Nrd2lzZSBUcmFuc2ZlciBkcmFmdCBhbmQgdGhlIGRv Y3VtZW50IGRvZXMgbm90DQo+PiBnaXZlIG1lIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlcmUgaXMg YW55IHNwZWNpZmljIG5lZWQgdG8gdGllIGl0IHRvDQo+PiBPYmplY3QgU2VjdXJpdHkuDQo+PiAN Cj4+IENhbiB5b3UgZXhwbGFpbiB3aGF0IHRoZSByZWxhdGlvbnNoaXAgaXM/DQo+DQo+QWZ0ZXIg dGhlIGxhc3QgY2FsbCBjb21wbGV0ZWQsIHdlIGhhZCBhIGRpc2N1c3Npb24gb24gdGhlIElFVEYg bWFpbGluZw0KPmxpc3QgaG93IHRvIGVtcGxveSBvYmplY3Qgc2VjdXJpdHkgaW4gYSBibG9jay13 aXNlIHRyYW5zZmVyIHRoYXQgc3BhbnMNCj5wcm94aWVzLg0KPklmIHlvdSBzZWN1cmUgb25seSB0 aGUgY29tcGxldGUgcmVwcmVzZW50YXRpb24sIHRoZSBjYWNoZSBpbiBhIHByb3h5DQo+bWlnaHQg YmUgcG9pc29uZWQgYnkgZmFrZSBibG9ja3MsIGFuZCB5b3UgZ2V0IGFuIGF2YWlsYWJpbGl0eSBw cm9ibGVtLg0KPklmIHlvdSBzZWN1cmUgZWFjaCBvZiB0aGUgYmxvY2tzIChhbmQgaGF2ZSBhIHdh eSBmb3IgdGhlIHByb3h5IHRvIGJlDQo+cGFydCBvZiBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIG5l ZWRlZCBzbyBpdCBhbHNvIGNhbiB2ZXJpZnkgdGhlIGJsb2NrcyksDQo+eW91IGNhbiBwcmV2ZW50 IHRoYXQsIGJ1dCB5b3Ugc3RpbGwgaGF2ZSB0byBzZWN1cmUgdGhlIHdheSB0aGUgZW50aXJlDQo+ cmVwcmVzZW50YXRpb24gaXMgY29tcG9zZWQgZnJvbSB0aG9zZSBibG9ja3MsIGFuZCB0aGF0IG1p Z2h0IG1lYW4NCj5hZGRpdGlvbmFsIGNvbXBvbmVudHMgYXJlIG5lZWRlZCBpbiBhbiBvYmplY3Qg c2VjdXJpdHkgcHJvdG9jb2wuDQo+DQo+SSBhZ3JlZSB0aGF0IG5vbmUgb2YgdGhlc2UgY29uc2lk ZXJhdGlvbnMgaGF2ZSBhIGJlYXJpbmcgb24gdGhlDQo+YmxvY2std2lzZSBwcm90b2NvbCBpdHNl bGYsIGFuZCB0aGlzIGFsc28gd2FzIHRoZSByZXNvbHV0aW9uIHdlIHJlYWNoZWQNCj5hZnRlciB0 aGUgZGlzY3Vzc2lvbi4gIEJ1dCBpdCB3YXMgdXNlZnVsIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24s IGFuZCBpdA0KPndpbGwgaW5mb3JtIHRoZSBkaXNjdXNzaW9uIGFib3V0IG9iamVjdCBzZWN1cml0 eS4NCj4NCj4+IEkgaG9wZSB0aGVyZSBpcyBubyBwbGFuIHRvIG1ha2UgdGhlIGNvbXBsZXRpb24g b2YgQmxvY2t3aXNlIHRyYW5zZmVyDQo+PiBkZXBlbmRlbnQgb24gdGhlIHByb2dyZXNzIG9mIG9i amVjdCBzZWN1cml0eS4NCj4NCj5ObywgYXMgZmFyIGFzIHRoZSBDb1JFIFdHIGlzIGNvbmNlcm5l ZCwgYmxvY2std2lzZSBpcyBkb25lLg0KPkl0IGlzIGN1cnJlbnRseSBpbiBJRVNHIGV2YWx1YXRp b24gYW5kIG9uIHRoZSBhZ2VuZGEgb2YgdGhlIDIwMTYtMDQtMjENCj5JRVNHIHRlbGVjaGF0OyBN YXR0aGlhcyBLb3ZhdHNjaCBpcyB0aGUgc2hlcGhlcmQuDQo+DQo+R3LDvMOfZSwgQ2Fyc3Rlbg0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Y29y ZSBtYWlsaW5nIGxpc3QNCj5jb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQoNCg== From nobody Mon Mar 28 07:45:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0C12D988 for ; Mon, 28 Mar 2016 07:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0v_mDbT4OsJ for ; Mon, 28 Mar 2016 07:45:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4F412D9B3 for ; Mon, 28 Mar 2016 07:45:01 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MNIO5-1adhiy26XJ-006t22; Mon, 28 Mar 2016 16:44:49 +0200 To: Carsten Bormann References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> <56F90AFF.5080809@gmx.net> <56F92027.9060308@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F94362.8000706@gmx.net> Date: Mon, 28 Mar 2016 16:44:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F92027.9060308@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R7OU0mnc3xP6vk59vL5u03MJhj5Fs4Mrl" X-Provags-ID: V03:K0:c+WG/8N3y1b6zHehBnvU1tGhMZFdWsTsBsPw8tU6iipaI88vB8P T4jgFqoQp9eVFFQY3oHnDf79VnkryPmFIDZ2maFb+qZcjHZM/bB3yUXB1qyL4wTFXq+X242 7JzxGW1lCJYFGzQCtTuwk26dZdW7fSKFy/Y8Gm5ZOoRWs36oerogxe2ZekTNppkXTnS0rUb CghHPkjRm2hOP12DgdpMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+rk5tzaesx4=:9Co7BQXlUG2Tj0Y/UX5q7R ZpEUfyrSlIF1F9ZpIABYs7jN0mk0eA1yb7ggnCBvK/c60drEJpMPtWkDRdTB1Q2HzKdDBep6g NQZGfYfHVFf9nD/TodLCBmubbFQO0VK1hRH/q5dBHZY9NLHBCTBV4Wh0QH161fT//nfYyNnNs +4HI02xkua6IWu1n11jFsRtfppCWZx4Q1hFBHnWhIDJxCzm1RVWkUDB1+Puc7Fd9tkWs/a/DV g/1f8UOWwCUWKiIazGGA0Ik21RTVEXbbCLeM8BE+ToW3B9EOQTlOU3mF0gp1xLiUkltqF3mcN Bq9ccX8vL1TFMFhhHGXhiwpbCI9Y+EcB/UUa2eQpc1VsIv34TF5bTUKaipI9v8EpPn9zfaJtb XIUfv8G7D7XBp5TjblKynKixnjE20t7nAXO2TWNmvtGtX5XSyDOMXNKx1NmJj7xF+Z8DwSzaf HRY6Kg/C99PuDboWKiq9hNckPMDCQcMF+0mSw9RNsBFIRhY5Kq/ECLHO7cb3pa+AqF90WekLY JubN2e6Vwz/JyYYwlfu8NjKr9RM6q5Gk7tWHIfChhKp0576PgWYLaUGZUSzSs7Cpnmj5fcHtc 5zIsu/QgZvswVBecmBQJG3Ej09HfurMQwwIOMIsEsFN0w5jQJfEivR3+skDbdELA3L1C5h6ZI 4ZJUSp1L5khSFxNBMJhWgUAR7rVJYUEMObyGsNoOuI8ntn7TrtvOkXIC/J4Y9gu5EMI1LgkUh g1eZN/WbUPPMylFkqlXe4d9zqYPNRom7lM0Q91+xbleH7cCMmz4KSie/r/U= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 14:45:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R7OU0mnc3xP6vk59vL5u03MJhj5Fs4Mrl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, the observation that a proxy has negative impacts on security when * hop-by-hop communication security is used in combination with * terminating that communication at the proxy is nothing that relates to the blockwise transfer itself. In general, in such a setup the proxy has the power to change the content, re-arrange data, inject new data, etc. I understand that end-to-end security is important in such cases and of course raises the question about the use of intermediaries in the first place (particularly if they are supposed to make all sorts of computations, like aggregation and analysis, on that data). Ciao Hannes On 03/28/2016 02:14 PM, Carsten Bormann wrote: > Hi Hannes, >=20 >> I have re-read the Blockwise Transfer draft and the document does not >> give me the impression that there is any specific need to tie it to >> Object Security. >> >> Can you explain what the relationship is? >=20 > After the last call completed, we had a discussion on the IETF mailing > list how to employ object security in a block-wise transfer that spans > proxies. > If you secure only the complete representation, the cache in a proxy > might be poisoned by fake blocks, and you get an availability problem. > If you secure each of the blocks (and have a way for the proxy to be > part of a security association needed so it also can verify the blocks)= , > you can prevent that, but you still have to secure the way the entire > representation is composed from those blocks, and that might mean > additional components are needed in an object security protocol. >=20 > I agree that none of these considerations have a bearing on the > block-wise protocol itself, and this also was the resolution we reached= > after the discussion. But it was useful to have the discussion, and it= > will inform the discussion about object security. >=20 >> I hope there is no plan to make the completion of Blockwise transfer >> dependent on the progress of object security. >=20 > No, as far as the CoRE WG is concerned, block-wise is done. > It is currently in IESG evaluation and on the agenda of the 2016-04-21 > IESG telechat; Matthias Kovatsch is the shepherd. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --R7OU0mnc3xP6vk59vL5u03MJhj5Fs4Mrl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+UNiAAoJEGhJURNOOiAt21IH/jKSVBkoQq3OT17iD7nUufc7 aosm7qpaJrNKKkE5wTAWeuNk0qo+YwjdB3JpMfUZ69AEOWCHnoWsck0M9MBybk4u n4VE4QLN8cADzhv4cEZ+Ui7ACFwzx0ZHqVVcR+WW7Jg/Bdksxic7/mxeSiVTXijV 8p9bhYFbNsPhsat3FClsIi+DhkCCRVA6qehW4xo8i+xKOdZH5/DOo5xczO0maf3p BkPLfVN7t4vKYFLSy0+eVDrZZYxTEQHC79J6t6lI+sTgwES8IsPODqsVA0c/YhF7 /VZYQ2xXOaGu5IuDiz9catyLbENk1pBHYx1lVhQbL3XBjqk+KR/n8o60ZPiSWAI= =NLtO -----END PGP SIGNATURE----- --R7OU0mnc3xP6vk59vL5u03MJhj5Fs4Mrl-- From nobody Mon Mar 28 07:49:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA80A12DA66 for ; Mon, 28 Mar 2016 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkTNPmo4J1MP for ; Mon, 28 Mar 2016 07:49:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A0412DA3F for ; Mon, 28 Mar 2016 07:48:52 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Ld3t6-1a2jLE2OLw-00iByh; Mon, 28 Mar 2016 16:48:43 +0200 To: Carsten Bormann References: <56F91A0A.5060804@gmx.net> <56F922F2.9060203@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F94446.7040900@gmx.net> Date: Mon, 28 Mar 2016 16:48:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F922F2.9060203@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LVAJeVehl6TQTSnnQfWqveVAqNBIsAw4b" X-Provags-ID: V03:K0:wyKSpUD8gseDRAcz7yOUWhgX50utWQVZAb5VEVbQXrl7ZB1u2OY 4TozUlYhoPvSMe0uDabwsTEEbMRaXgQcTfL5Czr2gck+pB2aPGJ/qLIiuRz7B8YGBF82rFF 0C8JauvHnLdo+BcPQp5ekYpInQ1WfQWe0/VjbmXaR4q8jmIpNnJ/Q3xFQS3il3dXRT919if vW+CuMMXvq5e/hYIOH3oA== X-UI-Out-Filterresults: notjunk:1;V01:K0:WKm9pvkYyi0=:78GksxrRWqb+SwW/JhXE+S wdExoxPJ4vQyrR+Sz3d0hPlcJNW5kTYhdLXxX7tPJhQlxnsopKZJeIIpo2srQrJcSXiT9V5FT VvrR3GGtMExocvHhPdCg6C1wfchKsQrmRmr8yAnUid+cOKqqcVUq99LbxCltdC9j533O/aEIT zD7uECMYk8Xw2uTRLUPBkAh98PMArQcQttDMydsUoDN6UMURsUw6NTmhTmVGaVBpKwZZ7Xx8i rNb76Y117ON+07sUrLac1d73r+TMU9yl+opLuEUWA8eqVhJ4VyZtOjYmFs1strMaJyJld+p7E 8++0hIxWMNhb1U3HsXx0a/kxZ3ZJALIiTl5SGy458vH4rjYtr7Tk6QbhlzRRMJxfoAToHBBEC UpUopHojm+fX706t1qihrqrgu+WLaEju1VF38g8Oa9SWlJBVC8Pz0Tkx2uz8yWbfCTjP52MvV oPZnz2n/WSOAZvRVtcHP4JJCHIgtq8rEjfCXnybYXDySv4dDi3UpuN/gdCqU7YMpOD3LH9Eal AxyludfbUxR9JQT0kINs9+bokbtrdBnzXS2ynfQqNEEdpIcyzjAS5pQznV1JTPDpZu3Rm9iBV h3OR+rNvg5GyI76VuGshEg/j6J6BalOmd5Z7atocCGBBfz1gEXCrBs1Hv/y+tT+38b3YnYZI9 B6eEA4tx/x2p9v5PUpljwQLmvV8uBOEA8pnaatSqNdHKQOkdII0Liw/gnDftc60i+owdiLSad 01SAHxa8/oqsDQCtGcadv04UC9qzf3GB1s9sNkLqlYuZxyAEUlBvBP7b2lg= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 14:49:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LVAJeVehl6TQTSnnQfWqveVAqNBIsAw4b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, Carsten. This has helped me a lot since I have not been following the patch debate. It sounds like a challenging task to predict the completion date of draft-vanderstok-core-etch. I would certainly appreciate if the RD document gets leaves the working group at latest end of May. On 03/28/2016 02:26 PM, Carsten Bormann wrote: > The question is simply whether we will be able to finish adding the > PATCH methods to CoAP (see draft-vanderstok-core-etch) on the same > timeline as the time needed for completing the RD document. Some of us= > are optimistic that this is possible, some think the way to use PATCH > with RD should be added as a separate document. But for the discussion= > of the functionality of the RD, it makes sense to keep the PATCH > functionality in context, assuming we can always take out section 5.6 > even at a late stage if we run into a problem with PATCH. > That's why it is part of -07. --LVAJeVehl6TQTSnnQfWqveVAqNBIsAw4b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+URIAAoJEGhJURNOOiAtOFAH/3RplMMwzJTxo12hUeIL1KcW PzUj2GFXZew8UpAU4LjxhLhYTUhjjrDpDHdTmF4M9weI+hkVSBgZH+UiITfKzN3g POAIAsmVe/xK0Hucg3ON4WTZghbDu2T81UgQn7o5zo4QoS68Gv3I+AaRCS9aBhwu rnL3YW9UMCtewf+Att/iMN6yJ9sB/oEuc4jHadhXsQgQI0RoKRC3Fgxx2Q03O7bY ssV1FiqNwpiGhCPHrMg1v4GejYOOwdPGInqOKRD7ol9wM53DX//m+E9oOnzD1+jU tF8KMwuD0jYGDe/zabY4C+hnQ+b/1Xd+43TuKkalO2yiotOMTQUfRsNSdIgttgY= =GNOC -----END PGP SIGNATURE----- --LVAJeVehl6TQTSnnQfWqveVAqNBIsAw4b-- From nobody Mon Mar 28 07:54:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CBE12DA87 for ; Mon, 28 Mar 2016 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyRQ2OQUQRP0 for ; Mon, 28 Mar 2016 07:54:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EFF12DA79 for ; Mon, 28 Mar 2016 07:52:49 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzXTy-1ZhEWS2K70-014n4e; Mon, 28 Mar 2016 16:52:46 +0200 To: "Fossati, Thomas (Nokia - GB)" , "core@ietf.org WG" References: <56F8351E.20304@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F94540.90401@gmx.net> Date: Mon, 28 Mar 2016 16:52:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R0MJC0RVrEePmv9jOxAqiiJ0CbQ9gQB8n" X-Provags-ID: V03:K0:BEnjdOnKIlr5dkMTDhmFUEqhysB6/RI3nRoGGvwQ06taIT3v8tQ i3eI9igaFXzExwt3cJI6Il/xZBtfyikdmMQdx3Kqnk9xDxsVdYyF5HuykHHKv97TeN9Laur dpnwrLrxg76qm/JBYxqZeDaS8jxepfb0EyC2UR4OdhwcDkrYRGWECZ4jTU/pJjUeUqkr4eu HeoFeBLWekYg5zPX4J8vQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:vaXBkdicjwk=:6RysTOpmiv3SQJxFAJMa1+ IBTB728QuTRrvTg2Qlr0XjFsxioh2My3TFr3mIRhzq+HsPVmfMoWDwDSqtlvJN14c1dMsdnhR UsNlwmCYBZ3VGOEbCoiianet98FDXs7M9J5OoIAP2kI6vPtnj2eDPaBeHUBfaS4dyO++8uCtN kc7VlUc59t0xPHdKZ7AiPPUk0fEUnhg1kw/me5fz/ht66za2NQNbxFRdBlso5eqUmJiySJzvt +uI7gvMlHoaOg7BS1aiCAMW1uyXMQ/ypySs4UOUyQFBDirD264hnZqARrAkxrYy2qBF/VqE90 bDZvHzzzbuEJHqPbuM3ylvCn2TfBGGZOOnXA7NBB+viKvAx/drs8KmuNhtmD5CZosNnZgkkmb M4uLAVrULwnpT4DH8UX60p4lLhXEDfCZJOpbO4900LM7CJvQOrWRGbqoW4wtRQQYY2EmjzUpc cDObJFPm3YY5KzqeckA0J7edxk21EQS9ESeOcoTvodzx3DDhCdWyUv0rYR7TF+CmKLddLe2TL RgiNnJ0ZVIm2jk4ivv+u9A7a5aGjfDdOtJXrQbiM5g8YLrppSE96Xp/qS51cTjGB03LNAfKOr 2q6LT+xLO5RELlPkY69i+dNCQC9gtVpyikIw4e6Am2yWSy3vjufS5KgLKP1ZKCvKj5c9V+pne nsanBl3pl1ltVtFBHuluTTtQRipKNczFx5PqadBLSSbAwRxiN5W4HB4alddeeO4zyqGSKCwlq X+yCqeFB1Imi/KtdjUWGWJPc6Sx6AKqnXvVFEboTbX8xgJFko3nLZMIiNFI= Archived-At: Subject: Re: [core] draft-ietf-core-http-mapping-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 14:54:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R0MJC0RVrEePmv9jOxAqiiJ0CbQ9gQB8n Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Thomas, On 03/28/2016 03:05 PM, Fossati, Thomas (Nokia - GB) wrote: > Hi Hannes, thanks very much for the review. >=20 > On 27/03/2016 20:31, "core on behalf of Hannes Tschofenig" > wrote: >> I had one question about the assumptions made about the client. The >> client embeds the CoAP URI (Target CoAP URI) into the HTTP URI (HC Pro= xy >> URI). In order to make this transformation it first needs to know it. >=20 > I'm assuming 'to know it' refers to the CoAP URI, right? Yes. >=20 >> Of course, you can assume that the client got manually configured but = is >> this realistic? >> What are the options for a client to learn the Target CoAP URI? >=20 > Consider the following two scenarios: >=20 > 1. Legacy HTTP application. This guy needs to talk to a CoAP resource = and > it hasn't got a CoAP stack. It is realistic to assume that it has been > pre-configured with the HC Proxy URI that maps to the CoAP resource (e.= g. > an actuator of some sort). >=20 > 2. Mobile app. This thing is hosted in a device that can roam from the= > home net to the public Internet. As such, it's realistic to assume tha= t > it's got plenty of chances to discover the CoAP URI of interest while > attached to the home net (either via link-format or RD based discovery)= > and, later on, use the (discovered or statically configured) URI mappin= g > convention to access the target CoAP resource via the public Internet. Do we have any insight into whether anyone (e.g., Nokia -- formerly Alcatel-Lucent) is deploy this technology in such a way? Are we guessing here how things could work or are we capturing some deployment experience? I will ask our folks but would be very surprised if they do it in that way. I believe (and I have to verify it) that we just do the mapping between HTTP and CoAP internally to the RD-alike function (more precisely within the LWM2M server). Ciao Hannes >=20 > Cheers, t >=20 --R0MJC0RVrEePmv9jOxAqiiJ0CbQ9gQB8n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+UVAAAoJEGhJURNOOiAtWrkH+wcjJQNF+osvc71TlyLBTqad HmabQ6ZwoOnXZCCAxImSdXcr2ynXla7Z0R5jjd8fOniyy8VyKZRP/HEonkpH7Vh1 L+3GbM+trdGSSBBWOK/wW1CR8lc+qasOTpE4GnJNxxvelavjFzLXdEKTVY9TJMEB OGkNX5GG6By4cIS5v1HxobBHholjQtAOBeaobIR3rhOUco9Uf97DVh1BbusTQW7P LwRlmSn1W7nqiFwFbmz3y+lSTh2ip7WBKxCC8Y4fXBBT6Z4aFA65SwzCOFZ3kQhk hWZTYZ74Wk5CWIpaX0v6WesCqQhJSj7zWUAcMusyKv+P6Obf8tY9c9d83F1nYQg= =sMw7 -----END PGP SIGNATURE----- --R0MJC0RVrEePmv9jOxAqiiJ0CbQ9gQB8n-- From nobody Mon Mar 28 08:01:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDA012DAF9 for ; Mon, 28 Mar 2016 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X65rwEtHofV for ; Mon, 28 Mar 2016 08:01:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C680312DA88 for ; Mon, 28 Mar 2016 07:59:07 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lwnem-1ZeUSv0kcC-016RzP; Mon, 28 Mar 2016 16:58:57 +0200 To: =?UTF-8?Q?G=c3=b6ran_Selander?= References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> <56F90AFF.5080809@gmx.net> <56F92027.9060308@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F946B3.8020309@gmx.net> Date: Mon, 28 Mar 2016 16:58:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MGcQsDDItlARo5xblgo05JH8hMbRrWHdV" X-Provags-ID: V03:K0:0JhW4ymMEWDnIM1rXkJwHkhnV36XiZe472rX7G6j7BCkDFxaWtq /ShhN8Rw/TZjjg8bv1SkSnZMzB8CtNqScyFmrFMPWYbTTjwtIvfbZ+bi6zENIxnHW2aMf5/ /bhTifIrBWCMPLUGIpHT0F5Fr7VNRcklQijzV0Hnk3oP2fFU1Ez4CKttgXJOlsN59ndWLtJ 3kUcBdCDQeAf58xHbfOtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:XgZpHi1xle4=:o8wAiAbfqLO2lNwe8z/GCx pNAtJg3/y3ThG8/K4BFkPHiBLsmmcdN2XMN+Bd+RcIwEPBOQpb+4rknDkZbRP7PsXwicO73OQ 9Ho+2onHnv53nGHfecFCkoT3EDdaLoKl6tGVR5/4HBDV/gxhriFYbZLtdJG9qxm13IaEy22cq kl85/AbFJkiifcfHkF5q9dBcPyQfyi5Yi/9Q1S/yYp5l1fhYddgZAhcOQTASj7d6gQPKtKx9/ +XFkbRIqXE2jbAkXTfYTlH7SukbpH5sLrcTlDPRwzoYX1ieROAxPekfrAiqoF2jo2XeFDVRAk 6wBQYhlZv1WIXAWN85y8jO0fSG5a/fN3kECNfc7Cg80+mZKbN6aOaGNHt445F6g2Thvrk/+Or PLh/bNuBDbslUhxFUy2obYBEMbn1kq8JVXjtkGmV6RvCAgXK1TWh3GfCKD7AQ6Pbyt0TqN6by GS0KLE0lye7lz4pIBd4u61ZwLNUIwTvgtNE34Fi2LAXcE1SVvbd3qUmmlnEWJfCQqXal09mxA Q8fE5GcIMgwBt4P9juAPHBLeJnNYkDN+AX4QMuDjxODrWCqaHOcHI/2j/e6WVMH2zGjKi/h10 WnxmrpHjpmmXFVfS/uciTgHJ4t0NtFWRNiGXV3i0u5dWzur7+wWFrF0bjbj4nkQB0TgRIxSI4 EJPguKGflpUX5ucnzlI7E7pYiUkLibSLBE2JmX1+UBDZxCxI9MB9fXyHH5vAn6OdUVj/kuxtC Lt6gn8obnZXLa0Xru73ObaM8Xpm8kxIpVh1OTXUFHESJ0e9p5oYRS3g0lzU= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 15:01:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MGcQsDDItlARo5xblgo05JH8hMbRrWHdV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Goeran, normally you would do the following: 1) You take the entire payload (for example a firmware image). 2) You add some security protection in the front. 3) Then, you make it available for download. 4) A server may then chunk it into pieces and delivery them separately using the Blockwise Transfer mechanism. 5) The client receives all the pieces, puts them together, verifies the signature or MAC, and then updates the firmware. This sequence of steps should be the same regardless of whether there is a proxy that caches pieces or not. So, what exactly is the concern here? Ciao Hannes On 03/28/2016 03:36 PM, G=C3=B6ran Selander wrote: > Hi Hannes >=20 > Complementing Carsten=E2=80=99s explanation: >=20 > There is a conflict between being able to protect a message fragment > end-to-end between endpoints and giving any intermediate node the right= to > refragment a message. Block operations performed by proxies cannot be > verified which has two consequences. Blockwise cannot be directly appli= ed > to secure message fragmentation, and the Block option opens up for DoS = by > any on-path adversary. I found this serious enough to warrant a securit= y > consideration, which is included in -19. >=20 > It turns out that while plaintext CoAP block options passing proxies > cannot be protected in the way blockwise works, they could potentially= be > used end-to-end if you were certain there were no changes being made in= > transfer, and that is something an object security solution could be us= ed > for. This is one of the topics I=E2=80=99d like to discuss in the secur= ity section > on the CoRE agenda. >=20 > G=C3=B6ran >=20 >=20 >=20 > On 2016-03-28 14:14, "core on behalf of Carsten Bormann" > wrote: >=20 >> Hi Hannes, >> >>> I have re-read the Blockwise Transfer draft and the document does not= >>> give me the impression that there is any specific need to tie it to >>> Object Security. >>> >>> Can you explain what the relationship is? >> >> After the last call completed, we had a discussion on the IETF mailing= >> list how to employ object security in a block-wise transfer that spans= >> proxies. >> If you secure only the complete representation, the cache in a proxy >> might be poisoned by fake blocks, and you get an availability problem.= >> If you secure each of the blocks (and have a way for the proxy to be >> part of a security association needed so it also can verify the blocks= ), >> you can prevent that, but you still have to secure the way the entire >> representation is composed from those blocks, and that might mean >> additional components are needed in an object security protocol. >> >> I agree that none of these considerations have a bearing on the >> block-wise protocol itself, and this also was the resolution we reache= d >> after the discussion. But it was useful to have the discussion, and i= t >> will inform the discussion about object security. >> >>> I hope there is no plan to make the completion of Blockwise transfer >>> dependent on the progress of object security. >> >> No, as far as the CoRE WG is concerned, block-wise is done. >> It is currently in IESG evaluation and on the agenda of the 2016-04-21= >> IESG telechat; Matthias Kovatsch is the shepherd. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --MGcQsDDItlARo5xblgo05JH8hMbRrWHdV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW+UazAAoJEGhJURNOOiAt+hwH/2Khzg/4Zev923lb0IPK1ONi aXtEz7hlod2GuXytySQNmzWvoeG+tT8dTjbpvTg2QrN3/NsQkgOD8h4MW0IDDn5K KhNCUrRVAI3XX16HUORC7CTDK+pPorzJ6L+9VCFSexIl2/nrtpxSbXGi+RsWna0X GcUEX0glRbfX1xe8BV+89najKM+d6S9RcwD0BOFMmzLQ8tthejvtJbkXUXLsa7M2 ns2qRh9bmgkM9RUz0AvcGheGgE98OY9VTXME+sYeW4dgSHma5p4pZ2GdOmRceY4X PTUS8ZZt3+dRUVlDkhicoBTH8FOZyPB0DmEN7ywtsHAJMnvJnFtW4YHbcjme/MU= =fquJ -----END PGP SIGNATURE----- --MGcQsDDItlARo5xblgo05JH8hMbRrWHdV-- From nobody Mon Mar 28 08:53:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5648112DBF2 for ; Mon, 28 Mar 2016 08:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VLJesBWtivTg for ; Mon, 28 Mar 2016 08:53:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECB612DBCB for ; Mon, 28 Mar 2016 08:51:09 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 39A71B7DD4C7E; Mon, 28 Mar 2016 15:51:04 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2SFp6cC005393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2016 15:51:07 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2SFp5ks029615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Mar 2016 17:51:06 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 28 Mar 2016 17:51:05 +0200 From: "Fossati, Thomas (Nokia - GB)" To: EXT Hannes Tschofenig , "Fossati, Thomas (Nokia - GB)" , "core@ietf.org WG" Thread-Topic: [core] draft-ietf-core-http-mapping-08 Thread-Index: AQHRiF9RI7sacfk9YUWgAhMCeuCp1Z9uw5mAgAANHgCAACEIAA== Date: Mon, 28 Mar 2016 15:51:05 +0000 Message-ID: References: <56F8351E.20304@gmx.net> <56F94540.90401@gmx.net> In-Reply-To: <56F94540.90401@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-http-mapping-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 15:53:25 -0000 Hi Hannes, On 28/03/2016 15:52, "EXT Hannes Tschofenig" wrote: >>>Of course, you can assume that the client got manually configured but is >>> this realistic? >>> What are the options for a client to learn the Target CoAP URI? >>=20 >> Consider the following two scenarios: >>=20 >> 1. Legacy HTTP application. This guy needs to talk to a CoAP resource >>and >> it hasn't got a CoAP stack. It is realistic to assume that it has been >> pre-configured with the HC Proxy URI that maps to the CoAP resource >>(e.g. >> an actuator of some sort). >>=20 >> 2. Mobile app. This thing is hosted in a device that can roam from the >> home net to the public Internet. As such, it's realistic to assume that >> it's got plenty of chances to discover the CoAP URI of interest while >> attached to the home net (either via link-format or RD based discovery) >> and, later on, use the (discovered or statically configured) URI mapping >> convention to access the target CoAP resource via the public Internet. > >Do we have any insight into whether anyone (e.g., Nokia -- formerly >Alcatel-Lucent) is deploy this technology in such a way? > >Are we guessing here how things could work or are we capturing some >deployment experience? I will ask our folks but would be very surprised >if they do it in that way. Mine is just guesswork on our use cases #1 and #3 (https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#section-4). I'll check with the relevant Nokia/ALU people shortly. Also, my co-editors might want to chime in here :-) >I believe (and I have to verify it) that we just do the mapping between >HTTP and CoAP internally to the RD-alike function (more precisely within >the LWM2M server). Great, could you expand a bit on this, please? I guess it'd be good to capture this aspect in the document. In particular, we had a small sub-sub-section in -07 about RD based discovery (https://tools.ietf.org/html/draft-ietf-core-http-mapping-07#section-5.4.1) which we removed because it seemed slightly off topic and thus potentially confusing. Is it what you are talking about, or something else? Cheers, t From nobody Mon Mar 28 09:27:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A884B12DB8F for ; Mon, 28 Mar 2016 09:27:50 -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 bpv6V-ztIod9 for ; Mon, 28 Mar 2016 09:27:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AA912DB1B for ; Mon, 28 Mar 2016 09:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u2SGRieY007010 for ; Mon, 28 Mar 2016 18:27:44 +0200 (CEST) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qYfTD4l5vzDCj0 for ; Mon, 28 Mar 2016 18:27:44 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id 191so20849554wmq.0 for ; Mon, 28 Mar 2016 09:27:44 -0700 (PDT) X-Gm-Message-State: AD7BkJLs9OwrQ5kwBPShPRlXEOlL8rXz1mve8dK7w8kU4MpCmrVz3mQ+LP4QKqiXPJHcy8QQ0CHdG0U2IMfxZQ== X-Received: by 10.195.12.113 with SMTP id ep17mr28508158wjd.102.1459182464368; Mon, 28 Mar 2016 09:27:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.47.167 with HTTP; Mon, 28 Mar 2016 09:27:04 -0700 (PDT) In-Reply-To: <56F58BE5.7050400@gmx.net> References: <56F58BE5.7050400@gmx.net> From: Klaus Hartke Date: Mon, 28 Mar 2016 18:27:04 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #394 - CoAP over TCP: Server name indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 16:27:50 -0000 Hannes Tschofenig wrote: > " > Should the FQDN of the server be set during connection setup (e.g., > using the TLS Server Name Indication (SNI) extension), or should the > FQDN of the server be specified in each request? > " > > The FQDN for the SNI is set during the TLS/DTLS handshake (in the > ClientHello). The client cannot convey the SNI later in the exchange. In CoAP, we have the Uri-Host Option [1] which can be included in CoAP requests to indicate the FQDN of the server. In CoAP over UDP a client can target a different virtual server with each request. In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. The question is what CoAP over TCP should do. One option is to include a Uri-Host option in each request, like CoAP over UDP. Then only one connection would be needed for all virtual servers running on the same IP address. Another option is to add a minimal handshake-like message to CoAP over TCP. I have no particular preference, but I think it's important that CoAP over TCP, TLS and WebSockets are consistent and no protocol behaves wildly different from the others. Klaus [1] https://tools.ietf.org/html/rfc7252#section-5.10.1 From nobody Mon Mar 28 09:34:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5684F12DB64 for ; Mon, 28 Mar 2016 09:34:37 -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 oednMpJo8Ss7 for ; Mon, 28 Mar 2016 09:34:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF7612DAEA for ; Mon, 28 Mar 2016 09:34:35 -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 u2SGYWO2023582 for ; Mon, 28 Mar 2016 18:34:32 +0200 (CEST) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qYfd45QHVzDCj4 for ; Mon, 28 Mar 2016 18:34:32 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id p65so105551847wmp.1 for ; Mon, 28 Mar 2016 09:34:32 -0700 (PDT) X-Gm-Message-State: AD7BkJKq4JZDvGSV4kDsuCIDSruPdmldoE8WCiNRIF/cdrvZRwXAqdp0WoAsIrUfbRr11ke6NErqhO1wuN3irg== X-Received: by 10.195.12.113 with SMTP id ep17mr28532811wjd.102.1459182872220; Mon, 28 Mar 2016 09:34:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.47.167 with HTTP; Mon, 28 Mar 2016 09:33:52 -0700 (PDT) In-Reply-To: <56F58BF2.2070203@gmx.net> References: <56F58BF2.2070203@gmx.net> From: Klaus Hartke Date: Mon, 28 Mar 2016 18:33:52 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #395 - CoAP over TCP: Session Resumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 16:34:37 -0000 Hannes Tschofenig wrote: > " > Should each connection be independent from all other connections, or > should it be possible to set up a connection (e.g., registering to > observe multiple resources), disconnect and resume the connection at a > later time? > (I'm leaning towards independent connections.) > " > > When DTLS / TLS client communicates with a server then it typically > establishes a session cache to allow session resumption. [...] To clarify, the question is about sessions at the CoAP level, not at the DTLS/TLS level. Should it be possible to send a CoAP request, close the TCP connection, reconnect and receive the response? Klaus From nobody Mon Mar 28 09:44:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4F12D50F for ; Mon, 28 Mar 2016 09:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 6gnpCD9d1smU for ; Mon, 28 Mar 2016 09:44:44 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3F412D167 for ; Mon, 28 Mar 2016 09:44:43 -0700 (PDT) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 9E175C5A50; Mon, 28 Mar 2016 18:44:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Hv6gGhCL_drY; Mon, 28 Mar 2016 18:44:41 +0200 (CEST) X-Originating-IP: 93.199.229.85 Received: from nar.local (p5DC7E555.dip0.t-ipconnect.de [93.199.229.85]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 3D7A1C5A3C; Mon, 28 Mar 2016 18:44:40 +0200 (CEST) Message-ID: <56F95F77.5060405@tzi.org> Date: Mon, 28 Mar 2016 18:44:39 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Klaus Hartke References: <56F58BF2.2070203@gmx.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #395 - CoAP over TCP: Session Resumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 16:44:45 -0000 Klaus Hartke wrote: > Should it be possible to send a CoAP request, close the TCP > connection, reconnect and receive the response? Without a checkpointing protocol, this is hard to ensure. The requesting endpoint cannot be really sure that its request made it before the connection closure. Similarly, the responding end might have to resend the response after resumption. Finally, the server could have lost the state in the time there was no connection. Similarly, the client might have crashed between the time it received the response and was able to process it. (A true session layer protocol can solve this. But there seems to be a reason these are rarely used in the Web today.) I don't mind if someone wants to work on such a session layer protocol, but this should not be part of base CoAP-over-TCP; the CoAP-level protocol state should share the fate of the TCP connection. Grüße, Carsten From nobody Mon Mar 28 09:47:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6B212DA42 for ; Mon, 28 Mar 2016 09:47: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 9zdEY8oSNzrC for ; Mon, 28 Mar 2016 09:47: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 3565B12DA2D for ; Mon, 28 Mar 2016 09:47: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u2SGlC97021771 for ; Mon, 28 Mar 2016 18:47:12 +0200 (CEST) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qYfvh5cdqzDCjN for ; Mon, 28 Mar 2016 18:47:12 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id 191so21365896wmq.0 for ; Mon, 28 Mar 2016 09:47:12 -0700 (PDT) X-Gm-Message-State: AD7BkJKWszQShxJNUEGRVg2gbi+EwmTmqHhUUJv5jgdhXqCo+Ky+XPJROJhlSPAOdGbwCwuRFVRPMMWkTRx5Ig== X-Received: by 10.194.174.197 with SMTP id bu5mr32146485wjc.23.1459183632365; Mon, 28 Mar 2016 09:47:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.47.167 with HTTP; Mon, 28 Mar 2016 09:46:32 -0700 (PDT) In-Reply-To: <56F95F77.5060405@tzi.org> References: <56F58BF2.2070203@gmx.net> <56F95F77.5060405@tzi.org> From: Klaus Hartke Date: Mon, 28 Mar 2016 18:46:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Ticket #395 - CoAP over TCP: Session Resumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 16:47:18 -0000 Carsten Bormann wrote: > I don't mind if someone wants to work on such a session layer protocol, > but this should not be part of base CoAP-over-TCP; the CoAP-level > protocol state should share the fate of the TCP connection. +1 Klaus From nobody Mon Mar 28 11:39:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9152412DAB8 for ; Mon, 28 Mar 2016 11:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 D7jonultm3rK for ; Mon, 28 Mar 2016 11:39:04 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7359D12D904 for ; Mon, 28 Mar 2016 11:39:04 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1CE2CA4AD3E32; Mon, 28 Mar 2016 18:38:59 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2SId2GD012388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2016 18:39:02 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2SId0Om018142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Mar 2016 20:39:01 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 28 Mar 2016 20:39:01 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Fossati, Thomas (Nokia - GB)" , "EXT Hannes Tschofenig" , "core@ietf.org WG" Thread-Topic: [core] draft-ietf-core-http-mapping-08 Thread-Index: AQHRiF9RI7sacfk9YUWgAhMCeuCp1Z9uw5mAgAANHgCAACEIAIAALuuA Date: Mon, 28 Mar 2016 18:39:00 +0000 Message-ID: References: <56F8351E.20304@gmx.net> <56F94540.90401@gmx.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <43788E107A905646AEF7A0717A600673@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] draft-ietf-core-http-mapping-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 18:39:06 -0000 Hi Hannes, let me unwind the stack to your original question: On 28/03/2016 16:51, "Fossati, Thomas (Nokia - GB)" wrote: >On 28/03/2016 15:52, "EXT Hannes Tschofenig" >wrote: >>>>Of course, you can assume that the client got manually configured but >>>>is >>>> this realistic? >>>> What are the options for a client to learn the Target CoAP URI? I've just spoken with the Nokia/ALU product people. Their response is that their preference would be to leave these discovery aspects to the implementation. (This is Nokia/ALU's point of view: Akbar and/or Sal might have different opinions). Cheers, t From nobody Mon Mar 28 12:25:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0604912D118 for ; Mon, 28 Mar 2016 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p0QCILIRvzh5 for ; Mon, 28 Mar 2016 12:25:46 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 D08AB12D54F for ; Mon, 28 Mar 2016 12:25:43 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id tt10so105166980pab.3 for ; Mon, 28 Mar 2016 12:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=pVkFjuGiROwNQAYblGyNouI6aSQog41Vxh6ZSY2c5Lc=; b=AvOHja+EI+JW66fVehFo/zrhGYl2uqqfL1QFP7IpAYulu2lwjEkYzDkA42Tq4n/T0I dHEu5Jabk4e3LEUiVKQ0/DPAs1D/FmDP185cpQjqnWfFDddGMtGQxBOII1iFo8e39s+1 GVx2kTO+pKnFyI9Ur9cqfwlPtPxbglWJPd6zHWunpNkUNOBubj8p//iDRqbDQPGexQs9 eHhixV6sEnSiWSfp3rAnEauFiBwzehg73zlenmJEMx5AzBeAbbPQLx2aT8+zmC6M0veU wEW8jJ90HCwJ7yygQ9eVJhdu/t2YjnMFQ1KGtMVpW6+pt/mw/JdC/iwXoAGgBSX13nEy NzRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pVkFjuGiROwNQAYblGyNouI6aSQog41Vxh6ZSY2c5Lc=; b=iqlkEjz4BCHiV966Wc+VsT0Sy8qukpeooA1dcuPHyAztb71VA9koYR4WbbB2BWN7MO idt8xoFX1g3RXYXvhU/Qb40QvtSSb8jroKIIQYBduWtK81isC8CoQJoZYA4QYNI8XvE+ xIUa+QS/cKtrAjmcenirZ7GkvPC4WqkPyblt6grEHroOQ64wt9qPsHhiI+Q4R1rCc2sF jfLETWTs3HZz5eTLVOCM1r+PfJskt+btPiUuDHH+yHZwOosKhazz2JMCO39yMmaXOtRH LJhOHGSgd4fu4ipS3scsFzf178X+BnGVxhmMknUEwQtgTMW6hLLYAnc4yyauamkaNXY4 Tilw== X-Gm-Message-State: AD7BkJI1cyNjKYjCx0LB8Jx6swDX7441edt4r+za2CQUyAdQQBDV6f76fMNVnkNiNVM7Xg== X-Received: by 10.66.153.101 with SMTP id vf5mr44690163pab.131.1459193143410; Mon, 28 Mar 2016 12:25:43 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id e6sm37505441pfj.71.2016.03.28.12.25.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 12:25:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A46FB3C1-2B0C-46F6-A872-9A1F90B63ADE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 12:25:40 -0700 Message-Id: <269CAEEE-C611-48CF-871A-62A9C09E33A7@gmail.com> References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 19:25:48 -0000 --Apple-Mail=_A46FB3C1-2B0C-46F6-A872-9A1F90B63ADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii These have been addressed and should be ready to be closed. > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > Are the issues listed in > https://trac.tools.ietf.org/wg/core/trac/report/1 = , namely > * Ticket #372: https://trac.tools.ietf.org/wg/core/trac/ticket/372 = > * Ticket #383: https://trac.tools.ietf.org/wg/core/trac/ticket/383 = > still open? >=20 --Apple-Mail=_A46FB3C1-2B0C-46F6-A872-9A1F90B63ADE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii These have been addressed and should be ready to be = closed.

On Mar 28, 2016, at 4:48 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:

Are the issues listed in
https://trac.tools.ietf.org/wg/core/trac/report/1, namely
* Ticket #372: https://trac.tools.ietf.org/wg/core/trac/ticket/372
* Ticket #383: https://trac.tools.ietf.org/wg/core/trac/ticket/383
still open?


= --Apple-Mail=_A46FB3C1-2B0C-46F6-A872-9A1F90B63ADE-- From nobody Mon Mar 28 12:54:51 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A7712DB51 for ; Mon, 28 Mar 2016 12:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Zt8EJcgskK9a for ; Mon, 28 Mar 2016 12:54:48 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 2EA9A12DB35 for ; Mon, 28 Mar 2016 12:54:47 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id n5so144742985pfn.2 for ; Mon, 28 Mar 2016 12:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=T9twlhLbBO3oxoY+r8AZmlzUWwEBa1Xp292GZg0sylY=; b=JURanosybR2I37NXLLvRbKq1IRQmgRuQdtMsV/4xTQAnlBC1AKtLGip/RNUgDtweHY W4DthVeQPZXeidTl23/LCFDhO3F/NGfv6PuQiokpgRjA3FHVIDW8lewqp0QOxIOyEnTx oKDM0MZsZ4KwoGAEyFc/C7NcoT+4XIa0K15OjKD8AgAogMQ5h+bf9UiCrId9P7JQfv7W kxCZ0FVfIgk+JHL6HHeyJStGShUbx9nHa6nBEjDEyuj5GuSNSdikanfzONCdbAeLNpg1 SGegsbP6iL0u/oK+HsRWhhgQGWlEIdwd5+xHFvAmr0HWJYVDBX7cfMwbQAAaDbznr/gj FizA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=T9twlhLbBO3oxoY+r8AZmlzUWwEBa1Xp292GZg0sylY=; b=FX9RwM7+/s8q0p/h3DSTB08e+p2w9wH2FDbCfQCSLCA9YVxSwoOgQstggRsRTu3C3j 9bqEV8SP4RLN/mVXFynTTAYAEjPjn5OZ9Aym/tLl/Ojy7tqN9+wQR7W/bczTS8rivRnY Bp5Z1DeasI7P6LoHr4XQumTYaYs/83Tc6KYpZGyeyWr0tL3arRZ6rV9oFJDnhk6XkkP7 GGo+T1+gLDLDHh6ZXz1y/EwkkBPBWCkfaoB0nrDRwEaXHfzl3uFcH9JBMSkmM+I5H40j p4bVyCGprazYOEGMblCGUDMgrsJmmw8+9l9Kgg1XjPJkD4O9oFb/plFfhNXJ73oyj1Y4 ix/A== X-Gm-Message-State: AD7BkJIMbZan3s2RmUChIm+Cu2411bjrhN8rWaIXGEZ6dgdaMexuZUOI6g1O47DQs8Zj2Q== X-Received: by 10.98.74.6 with SMTP id x6mr45139824pfa.80.1459194887491; Mon, 28 Mar 2016 12:54:47 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id u64sm37601491pfa.86.2016.03.28.12.54.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 12:54:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BCF853A2-F030-4276-842C-1420249982CB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 12:54:44 -0700 Message-Id: <49BB90D2-003A-45D4-AF4F-60548817628F@gmail.com> References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 19:54:50 -0000 --Apple-Mail=_BCF853A2-F030-4276-842C-1420249982CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Regarding "endpoint" I think the difference is that an RFC7252 defined endpoint may register = a set of links associated with a mandatory endpoint name, which becomes = in CoRE RD a representation of an "endpoint".=20 In CoRE RD an endpoint is that entity described by the attribute "ep". = It has a default associated server address, unless the links are = registered with an explicit context attribute (e.g. registering the link = ;con=3Dcoap://[2002::17]:5683;rt=3Dtemp rd-lookup could return = the link ;rt=3Dtemp) I agree that we can make this a lot clearer and have one normative = reference, which is used consistently thereafter. An endpoint is associated with a client, which is the entity that POSTs = the links to the rd resource to register itself. RD is expected to infer = the server address of the registered links from the network address of = the registering client, unless explicitly overridden by the "con" link = attribute. Maybe the confusion it that there is a registering client that is = associated with the endpoint (ep=3D) being = registered, and there are other clients that do lookup operations. The = client interacting with rd-lookup is not an endpoint wrt. the lookup = operation, but may be associated with some registered endpoint. Also, there is nothing prohibiting a client from registering any number = of "endpoints" with different sets of links in them, each representing = some different exposed set of capabilities. They are only required to = have unique endpoint identifiers. So maybe there is too much implication = of a one-to-one correspondence with a server name or network address. = There isn't any such constraint. An endpoint identifier in CoRE RE only = identifies a link bundle that is registered, but does have a default = server address. Another thing that may need clarification is how a RD uses the IP = address of a registering client to provide the complete URL to the = rd-lookup interface. If the context of a link is registered (using the = con attribute) it sould be used as in the above example. This seems like a particularly difficult concept and I hope the only = problem is bad descriptive text. If this is the case, we can fix it now. Maybe we should create an issue for this and make a good description of = the problem? Best regards, Michael > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > It would be good to know why the terminology from RFC 7252 couldn't be > re-used. I suspect that there is some difference. Then, it would be = good > to know whether the term refers only to a web server or also a client, > whether it applies only to CoAP or also other protocols (such as = HTTP), > and how an endpoint is identified. --Apple-Mail=_BCF853A2-F030-4276-842C-1420249982CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Regarding "endpoint"

I think the difference is that an RFC7252 defined endpoint = may register a set of links associated with a mandatory endpoint name, = which becomes in CoRE RD a representation of an = "endpoint". 

In CoRE RD an endpoint is that entity described by the = attribute "ep". It has a default associated server address, unless the = links are registered with an explicit context attribute (e.g. = registering the link </temp>;con=3Dcoap://[2002::17]:5683;rt=3Dtemp rd-lookup could return the = link  <coap://[2002::17]:5683/temp>;rt=3Dtemp)

I agree that we can = make this a lot clearer and have one normative reference, which is used = consistently thereafter.

An endpoint is associated with a client, which is the entity = that POSTs the links to the rd resource to register itself. RD is = expected to infer the server address of the registered links from the = network address of the registering client, unless explicitly overridden = by the "con" link attribute.

Maybe the confusion it that there is a = registering client that is associated with the endpoint (ep=3D<endpoint= identifier>) being registered, and there are other clients that do = lookup operations. The client interacting with rd-lookup is not an = endpoint wrt. the lookup operation, but may be associated with some = registered endpoint.

Also, there is nothing prohibiting a client from registering = any number of "endpoints" with different sets of links in them, each = representing some different exposed set of capabilities. They are only = required to have unique endpoint identifiers. So maybe there is too much = implication of a one-to-one correspondence with a server name or network = address. There isn't any such constraint. An endpoint identifier in CoRE = RE only identifies a link bundle that is registered, but does have a = default server address.

Another thing that may need clarification is how a RD uses = the IP address of a registering client to provide the complete URL to = the rd-lookup interface. If the context of a link is registered (using = the con attribute) it sould be used as in the above example.

This seems like a = particularly difficult concept and I hope the only problem is bad = descriptive text. If this is the case, we can fix it now.

Maybe we should create = an issue for this and make a good description of the problem?

Best regards,

Michael



On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

It would be good to know why the terminology = from RFC 7252 couldn't be
re-used. I suspect that = there is some difference. Then, it would be good
to know whether the term refers only to a web = server or also a client,
whether it applies only to = CoAP or also other protocols (such as HTTP),
and how an endpoint is = identified.

= --Apple-Mail=_BCF853A2-F030-4276-842C-1420249982CB-- From nobody Mon Mar 28 13:03:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2AF12D93A for ; Mon, 28 Mar 2016 13:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1v574N0RrjCj for ; Mon, 28 Mar 2016 13:03:32 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 3376812DB1A for ; Mon, 28 Mar 2016 13:03:32 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id u190so145474312pfb.3 for ; Mon, 28 Mar 2016 13:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LD6DqMZZoGJtADRlzbenDxj4sxISIcTJuyoNnuubOG8=; b=ShvnBq718685Ya2ZZ3yGKL7Ou5c1eZ5l8dbm0dNjW8J3Xz3dE819LPN3QWFhjGpnK9 WsW6DGIdvKUqqDsb5OsFChFoA1USbTaJz90SgmXMTc3DWie2JR+cKDdLKvN1AVyepBEb orql0ZEQomCej+H6wDIoupLIhGLcHQtoSsx3LP8qq1sHylZD84O6IHULd8F+Hj1cwBKA GkNyCK0kYvWh5cDyH6Cvwjb+DbaFLIIDcCLddYI3FWTqekc9W3P1qP9X6+14+gIJ64cX EoNJvtvbg5CUMslKuWuiWvGkEJaeA7bOOhVPH5lGpyO5VTED1uL9XCXqTjcgqujiVaEp MTZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LD6DqMZZoGJtADRlzbenDxj4sxISIcTJuyoNnuubOG8=; b=DH5ZMOm8TbbmVCCi3cT7JBK24xGv9eb1Uajjsb7frogqRPCgGT2EDTn0/awDVzgWXK xOJfH/YSUqWWyA+UEkd4pDeD0aZ108QJ6fimAlYhstbcJYP5OD248pFlZCN0h+lraJdd LPO4ScmXQi5bYaBpC9pdgVkihRB10avw7aS0wyZizSkDfwj5YjJF6jRWfNOfd4ZwLy9H 7BHJ7C7vDN3A/lBL+b2oxJ1x42LFFZRAUEq/o1LImdho4MwBBkOZeoiDoOZafmdQrp9Y FOCeh+fDnoZSgQVDqytaVBWuuaXQHS9fG721JyWXLUXD4kVzj0jF4SV7pPs5H7KuO8Rp jtzQ== X-Gm-Message-State: AD7BkJIiPRUyl6GoEdsYyEI9FCLXnUjZ7/i0cWRruwwV+EEZeEascLVs3UArkbAgpJ+Z7w== X-Received: by 10.98.72.29 with SMTP id v29mr45090071pfa.71.1459195411805; Mon, 28 Mar 2016 13:03:31 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id e87sm37623978pfb.76.2016.03.28.13.03.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 13:03:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6F4CB98-A502-4AB9-B97E-FAD8C074BF13" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:03:29 -0700 Message-Id: References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 20:03:34 -0000 --Apple-Mail=_E6F4CB98-A502-4AB9-B97E-FAD8C074BF13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, this is not well specified.=20 rd-group and rd-lookup could be considered optional since they are = defined as function sets.=20 I believe that a single default domain should be specified with = optionally more than one named domain, since the "d" parameter is = optional on registration.=20 I think these 2 clarifications would allow an implementation like LWM2M = to use only the rd function set. DNSSD should not be mandatory. So here we should create an issue to track and resolve. Michael > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > What functionality is mandatory to implement? >=20 > For example, as it can be seen from the LWM2M section in the appendix > the OMA LWM2M protocol does not implement everything defined in this > spec and I wonder whether it is still a compliant implementation. >=20 > Another example: DNS-SD is described in the document and the reference > to DNS-SD is normative. Do I need to implement the DNS-SD part for an = RD > implementation to claim conformance to this specification? --Apple-Mail=_E6F4CB98-A502-4AB9-B97E-FAD8C074BF13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, this is not well specified. 

rd-group and rd-lookup could be = considered optional since they are defined as function = sets. 

I = believe that a single default domain should be specified with optionally = more than one named domain, since the "d" parameter is optional on = registration. 

I think these 2 clarifications would allow an implementation = like LWM2M to use only the rd function set.

DNSSD should not be = mandatory.

So = here we should create an issue to track and resolve.

Michael

On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

What functionality is mandatory to = implement?

For example, as it can be = seen from the LWM2M section in the appendix
the OMA LWM2M protocol does not implement = everything defined in this
spec and I wonder whether = it is still a compliant implementation.

Another example: DNS-SD is described in the = document and the reference
to DNS-SD is normative. Do = I need to implement the DNS-SD part for an RD
implementation to claim conformance to this = specification?

= --Apple-Mail=_E6F4CB98-A502-4AB9-B97E-FAD8C074BF13-- From nobody Mon Mar 28 13:06:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741CF12D871 for ; Mon, 28 Mar 2016 13:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 18v5B8G3vq-6 for ; Mon, 28 Mar 2016 13:06:29 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 DA7C512DB91 for ; Mon, 28 Mar 2016 13:06:17 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 4so145339324pfd.0 for ; Mon, 28 Mar 2016 13:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9/5p/WS8F3FvdLSyOIem2xjFZuSVcgkbAMLbquCB7MU=; b=RRM5YrQPdqivxu7NHx7U2N0aD9kYPJykXYppYdjG7Ja2ZLPsHxzqSUM83/+BolYY1p z6NyLP36KQwc0Nj0PLmWOg5SY7B2zMAf1rVdg+csnwCWQ0ptWVG3ISJjd+eMW3pq6qof sUk4XKuuGeuDCsDCQh+m9/iv/g0V3SALVjCMptfiyv93n22GqD5ylAmhkLL9lnV32Lng 5VZAB7VSwW3Y25ObTwggn2/eXSstaEYCvl0+urkj0R0RusIbZ61D28LpPuMCmhgC7cZ3 bmo+E5R8o7eXDFLmAeKgCL8triFwN3em2N0D9D0pAlKR9V0sS3QhhZw+LQ8Vd5saClqL aMwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9/5p/WS8F3FvdLSyOIem2xjFZuSVcgkbAMLbquCB7MU=; b=QPb7qzExoQEblJvmZ81F+MgR/jiorVQtv3iYzgCqDn5nu1nCqJEBWt5z5OsryCquJ0 bdYUoQpdzkGF1zwS7z7HKsw13MXOet3n8GAekL55FUyZ1bJZqQowI2eFMM6FhwpVVu9d UBhyrhzVPTpsaJP6Fpvzb2tl2N5oEabPiLW1S3urVA1mBxzfC8HNsZyXrWDTQ1Zn1+dk 36TJO68CAaX2QnMbyzJr3CRZdeZp0n6SA1kmubRLaOASMW/gLzZ2jX51IEu8TX4Jhs1a YplmckwUqL3C7KRhTB+RGpRbzcEYpQy2tQiRfoeRB9K/W+UdmR9OQrIKCqpLJR/oTdwU aAkg== X-Gm-Message-State: AD7BkJKaBLWrs42tnYtAH1/NuoQ0kq9wTJAizndPoVUCYZsQKOogFZYHeyn8w5qoZ+I3tQ== X-Received: by 10.98.14.2 with SMTP id w2mr45637754pfi.35.1459195577317; Mon, 28 Mar 2016 13:06:17 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id kl14sm12556610pab.23.2016.03.28.13.06.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 13:06:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C541E67-08B6-4B88-AF88-863E5F61F606" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:06:15 -0700 Message-Id: <0A7D5FC6-DCBB-4544-8C62-D8AD9C0595CC@gmail.com> References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 20:06:33 -0000 --Apple-Mail=_7C541E67-08B6-4B88-AF88-863E5F61F606 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK, that seems reasonable. The commissioning tool is a sort of proxy = client for RD operations. We could settle on one term for this. Again, create an issue so we can track resolution ? > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > ** Terminology: Installation tool vs. Commissioning Tool >=20 > Section 4.2 talks about the 'installation tool' and Appendix 12.1 = calls > it 'Commissioning Tool'. I think it would be good to define the term = in > Section 2 and then use the same term throughout the document. >=20 > Section 6.1 talks about a 'a management entity' even though I am not > sure it refers to the same concept as an 'installation tool' or a > 'Commissioning Tool'. Later in Section 6.1 the term 'Manager' is used. --Apple-Mail=_7C541E67-08B6-4B88-AF88-863E5F61F606 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii OK, that seems reasonable. The commissioning tool is a sort = of proxy client for RD operations.
We could settle on one = term for this.

Again, create an issue so we can track resolution ?

On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

** Terminology: Installation tool vs. = Commissioning Tool

Section 4.2 talks about = the 'installation tool' and Appendix 12.1 calls
it 'Commissioning Tool'. I think it would be = good to define the term in
Section 2 and then use the = same term throughout the document.

Section 6.1 talks about a 'a management entity' = even though I am not
sure it refers to the same = concept as an 'installation tool' or a
'Commissioning Tool'. Later in Section 6.1 the = term 'Manager' is used.

= --Apple-Mail=_7C541E67-08B6-4B88-AF88-863E5F61F606-- From nobody Mon Mar 28 13:07:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690CB12DB6C for ; Mon, 28 Mar 2016 13:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 s72Rc-27eXpR for ; Mon, 28 Mar 2016 13:07:26 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 A027612D93A for ; Mon, 28 Mar 2016 13:07:26 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id u190so145541323pfb.3 for ; Mon, 28 Mar 2016 13:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=kTjqeVEJYYeDh9LTlCX6BpgZfLNN/jBmai3wXiZ7iNk=; b=hJA32MGvcNR/af6AKJLToyRlKAZoRY/8m5+sPXTB3S+gwJ+IbcOkkmZlpxE4c+LlVv pejUVwoqImBrJsdl+ZSeSVy/xQ3YqdGnm6wEfQmvWt6XV0ivt8gPG9S3dacSdzII/dUr FW7WgcPdMUB/XAEJ37+sDFAAN0wPycMnJ7zLxcXPhK/UHJzY0/+hu3VgrZg3PtL1if6o kt09VpXoZFT8emk4B3kbd/UaahSk7r55s7L+VDMjohbQd1vtixdA7ZOqKGXTBwLhDBwJ MuHBG3eN/IBGGByU3gjA4j8tKLIc+RTIjDeOMRm0T3EDHadFSgyQF0EBTqlnOLGKearW 1SGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kTjqeVEJYYeDh9LTlCX6BpgZfLNN/jBmai3wXiZ7iNk=; b=eYeTb2JQFk7S8PQ3kDlma8KcuXIqNNX3Yz8obryDOJ8FMBM8D6gjrdzDcN7mIQ+8Fo +FAaJOBRZWxKtiefw4hUTGmRcfJTD0ECMQ17WoO0qgSqW4iMPijDmtLlxzZxNZkOJLCk gdf5RaJaINAmuNXRtnMOcrYdqrXU4dRt7lexIYbLO0Lqsfg/oXT6cHlDSSWO+1tzN5Pw SeS9ouhJN6jW6RmMc1auIbXaPMxMimXGR0JWJUJnVr+QXAaZKx4Sj6CDjX9X89R+TiGD QRUn35E4uSiU7QsET3TudnXf7MCtKEMBuuwz/RRcpNF5aw7OPidyEYMl+tJklMeTf/Ng UWIQ== X-Gm-Message-State: AD7BkJIrnWF4RMkoJicUSpkDbMMt4dUcY8pIwn0R5lP4TRRhoyOSZbbkCMRe3krrtROuEg== X-Received: by 10.98.34.18 with SMTP id i18mr46142069pfi.26.1459195646283; Mon, 28 Mar 2016 13:07:26 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 79sm37631651pfq.65.2016.03.28.13.07.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 13:07:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D0998CE-CFF7-4639-9394-1F87507E96EF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:07:24 -0700 Message-Id: References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 20:07:28 -0000 --Apple-Mail=_0D0998CE-CFF7-4639-9394-1F87507E96EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with this. The flow diagrams are also inconsistent with the text = for the same example > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > I noticed that all figures showing message exchanges are pretty = useless > for two reasons: >=20 > a) You cannot express the necessary information in them. > b) You always included the same information again in a non-diagram = form > afterwards. >=20 > Here is an example: >=20 > " > EP RD > | | > | ----- GET /.well-known/core?rt=3Dcore.rd* ------> | > | | > | | > | <---- 2.05 Content ";rt=3D"core.rd" ------- | > | | >=20 >=20 >=20 > Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* = >=20 > Res: 2.05 Content > ;rt=3D"core.rd";ct=3D"application/link-format+cbor", > ;rt=3D"core.rd-lookup";ct=3D"application/link-format+cbor"= , > ;rt=3D"core.rd-group";ct=3D"application/link-format+cbor" > " >=20 > It would probably be easier to just do the following instead: >=20 > " >>> EP ---- Request -----> RD >=20 > GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd* = >=20 >=20 >>> EP <---- Response ---- RD >=20 > 2.05 Content > ;rt=3D"core.rd";ct=3D"application/link-format+cbor", > ;rt=3D"core.rd-lookup"; > ct=3D"application/link-format+cbor", > ;rt=3D"core.rd-group"; > ct=3D"application/link-format+cbor" >=20 --Apple-Mail=_0D0998CE-CFF7-4639-9394-1F87507E96EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I agree with this. The flow diagrams are also inconsistent = with the text for the same example

On = Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

I noticed that all figures showing message = exchanges are pretty useless
for two reasons:

a) You cannot express the necessary information = in them.
b) You always included the = same information again in a non-diagram form
afterwards.

Here is an example:

"
       EP =             &n= bsp;           &nbs= p;            =          RD
       | =             &n= bsp;           &nbs= p;            =            |=
       | = ----- GET /.well-known/core?rt=3Dcore.rd* ------> |
       | =             &n= bsp;           &nbs= p;            =            |=
       | =             &n= bsp;           &nbs= p;            =            |=
       | = <---- 2.05 Content "</rd>;rt=3D"core.rd"  ------- = |
       | =             &n= bsp;           &nbs= p;            =            |=



  Req: GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd*

  Res: 2.05 Content
  </rd>;rt=3D"core.rd";ct=3D"application/link-f= ormat+cbor",
  </rd-lookup>;rt=3D"core.rd-lookup";ct=3D"appl= ication/link-format+cbor",
  </rd-group>;rt=3D"core.rd-group";ct=3D"applic= ation/link-format+cbor"
"

It would probably be easier to just do the = following instead:

"
EP ---- Request -----> RD

      GET coap://[ff02::1]/.well-known/core?rt=3Dcore.rd*


EP <---- Response ---- RD

     2.05 = Content
     </rd>;rt=3D"core.rd";ct=3D"= application/link-format+cbor",
     </rd-lookup>;rt=3D"core.rd-= lookup";
          &nb= sp;       ct=3D"application/link-format= +cbor",
     </rd-group>;rt=3D"core.rd-g= roup";
          &nb= sp;      ct=3D"application/link-format+cbor"=


= --Apple-Mail=_0D0998CE-CFF7-4639-9394-1F87507E96EF-- From nobody Mon Mar 28 13:14:40 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59D12DBE9 for ; Mon, 28 Mar 2016 13:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 e8YGpMgJcWtk for ; Mon, 28 Mar 2016 13:14:36 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 9C7C912DBC5 for ; Mon, 28 Mar 2016 13:14:36 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id u190so145664504pfb.3 for ; Mon, 28 Mar 2016 13:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=t3Kqm4mw6I0uoadXxZi/sIwjSM9UMroocXKl+M848L8=; b=Y9YY2rSLav2liJ5aJi3UoRcHdtdGFil1VLj1m6jy1lWw8AyOOKLRjK9SV4RTusylpw iJjjKOhDXBF+B6YVD+Kl8zhTZ07ZBMypMW9xUx5OQyACKwj8+UelLI8A3wq8XzVMYTGT cyqBgWzZnL79l6IV1IbUpAmyGzSXFymQ7bolbTQ2t+mY3PVV5esSECqvQrCZLSD45V5B GhI6AuHs88MJ0sCdZPo+8dRr2soS0x8mdmOEPcLa6PlEowV0JNohW+iu9StJS++FwhuE PBZT3HZvq1WMcly6ageG6BZ+jwL2TRXE9n9rHkjBowoWeIGwGnSaLtECNWDduA6/XTCo Wigw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=t3Kqm4mw6I0uoadXxZi/sIwjSM9UMroocXKl+M848L8=; b=BL7HUJtwCKZlwcDiAVbtaYuKQz3p5NSHnmKXAHz7e1NKTM4k+5c+3OBfOw1sW9YlFG e5zGX+b/lEwUx/Ihh6ohxUfp24SNuwr6qiGKc4TVjxYdRwKacTYB/rCENO4dL9N6DF1Z v65Ib2lrJ+LLsC3zy7Ugx7GsIjGH6PhVCvDVcflNiM860rv8czehTM6n2AwLTfLamUX8 iX8DwMJLuNZfD8e71B727bARUMR7FUz3ZgAIitGuTM4YdnGYnD7Laef/LCeuF4J+WLh7 tsADJYVavPXQyO4O8JZq1mKti74m/+n+4Db2tw/o3bNrI2ZeD9sTxjPs1hsJMQecF0ab bRuA== X-Gm-Message-State: AD7BkJJRak6+ElKtR27QmpF1EGVduxo3jTKG4++ccpNhgBaPleNkE/XGeVvF4nmZFSkqsw== X-Received: by 10.98.8.196 with SMTP id 65mr45150385pfi.53.1459196076252; Mon, 28 Mar 2016 13:14:36 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id xs10sm37763170pab.4.2016.03.28.13.14.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 13:14:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3CCCFD14-B4C8-49C2-A88B-E0E979665DAB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:14:34 -0700 Message-Id: <30F131E5-1FA7-4061-A606-D9DFE954CC59@gmail.com> References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 20:14:39 -0000 --Apple-Mail=_3CCCFD14-B4C8-49C2-A88B-E0E979665DAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It's definitely confusing as it is.=20 Maybe section 4 could focus on discovery of RD services only, and this = could be removed from the function set definition of section 5. Section = 4 could be about how to fine an RD, and section 5 could be about how to = use an RD. Another issue to track? Michael > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > ** Simple Directory Discovery >=20 > Section 1 motivates the specification and says >=20 > Section 4, however, defines a discovery technique and says: >=20 > " > Not all endpoints hosting resources are expected to know how to > implement the Resource Directory Function Set (see Section 5) and > thus explicitly register with a Resource Directory (or other such > directory server). Instead, simple endpoints can implement the > generic Simple Directory Discovery approach described in this > section. An RD implementing this specification MUST implement = Simple > Directory Discovery. However, there may be security reasons why = this > form of directory discovery would be disabled. > " >=20 > =46rom this text I don't understand what the differences between = Section 4 > and Section 5 is. As an implementer, why would I want to select the > "complex" discovery when I have a simple discovery technique that is > mandatory to implement. It would be good to say what the pros & cons = are > and why this technique is there in the first place. >=20 > There are also two approaches defined: >=20 > " > An endpoint that wants to make itself discoverable occasionally = sends > a POST request to the "/.well-known/core" URI of any candidate > directory server that it finds. The body of the POST request is > either >=20 > o empty, in which case the directory server is encouraged by this > POST request to perform GET requests at the requesting server's > default discovery URI. >=20 > or >=20 > o a non-empty link-format document, which indicates the specific > services that the requesting server wants to make known to the > directory server. > " >=20 > Why do I want to have two ways to do the same thing? Couldn't we just > pick one? >=20 > ** Finding a Directory Server >=20 > Section 4.1 describes different ways to find a discovery server. While > it only lists them without giving any guidance on which approach would > be most useful in what situation it is reasonably easy to understand. >=20 > Section 5.1 again talks about discovery and pretty much repeats the = same > approaches again. I would shorten the description. It is enough to > explain it once. >=20 --Apple-Mail=_3CCCFD14-B4C8-49C2-A88B-E0E979665DAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It's definitely confusing as it is. 

Maybe section 4 could focus on = discovery of RD services only, and this could be removed from the = function set definition of section 5. Section 4 could be about how to = fine an RD, and section 5 could be about how to use an RD.

Another issue to = track?

Michael

On Mar 28, 2016, at 4:48 AM, = Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

** Simple Directory Discovery

Section 1 motivates the specification and = says

Section 4, however, = defines a discovery technique and says:

"
  Not all = endpoints hosting resources are expected to know how to
  implement the Resource Directory = Function Set (see Section 5) and
  thus explicitly register with a = Resource Directory (or other such
  directory server).  Instead, = simple endpoints can implement the
  generic Simple Directory Discovery = approach described in this
  section. =  An RD implementing this specification MUST implement = Simple
  Directory = Discovery.  However, there may be security reasons why = this
  form of = directory discovery would be disabled.
"

=46rom this text I don't = understand what the differences between Section 4
and Section 5 is. As an implementer, why would I = want to select the
"complex" discovery when I = have a simple discovery technique that is
mandatory to implement. It would be good to say = what the pros & cons are
and why this technique is = there in the first place.

There are also two = approaches defined:

"
  An endpoint that wants to make = itself discoverable occasionally sends
  a POST request to the = "/.well-known/core" URI of any candidate
  directory server that it finds. =  The body of the POST request is
  either

  o  empty, in which case the = directory server is encouraged by this
     POST request to = perform GET requests at the requesting server's
     default discovery = URI.

  or

  o  a non-empty link-format = document, which indicates the specific
     services that the = requesting server wants to make known to the
     directory = server.
"

Why do I want to have two ways to do the same = thing? Couldn't we just
pick one?

** Finding a Directory Server

Section 4.1 describes different ways to find a = discovery server. While
it only lists them without = giving any guidance on which approach would
be most useful in what situation it is = reasonably easy to understand.

Section 5.1 again talks about discovery and = pretty much repeats the same
approaches again. I would = shorten the description. It is enough to
explain it once.


= --Apple-Mail=_3CCCFD14-B4C8-49C2-A88B-E0E979665DAB-- From nobody Mon Mar 28 13:29:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7EF12D19B for ; Mon, 28 Mar 2016 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mWZZperThqrH for ; Mon, 28 Mar 2016 13:29:50 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 BC7A012D1A0 for ; Mon, 28 Mar 2016 13:29:50 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id u190so145923960pfb.3 for ; Mon, 28 Mar 2016 13:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=MG8L0WI++PEiX9KWwV5+fW+vRn/4P7tZZjLG12ESnfY=; b=bew8mXpervWv+2uIfvKpQh95rSK7wM1QiQjZMiPjW7/9BGhiscwCYSEx+rHp5wmo9Z J8fq0uveQV5iyG5itDZ3AQ/6dTilhQ1ZcLNqdx4joJQ+0TNW939o7s/H3xJmhZ5/G6/g FwqwBJoZ85QDXOjunU2Pdaodx5R0pz0NYynqhncrbu3ER2TI20qWLOlnDhf0JO0pA1f7 ExSBhl+hBgbV0qtI/kPMkyCvI7V6p67ZZ3W/c8hVsZboFioGeSJv9/X7ahWPtdIFUBXy tm3wsTbiIUGg+TVxXD9Iz+VdRHYXWm1NX7NTPdtPs0Wy1JgsykgYfosSm5Qc3H5/Xl47 BIlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MG8L0WI++PEiX9KWwV5+fW+vRn/4P7tZZjLG12ESnfY=; b=gDpqNZDBkjRqEvE08ZxDwiWPWAiBjWEfyS6XFofsY4vH7VCgG9U420b6pwcur6FqFJ oHAOtwFqOPVTqDfOJcHL6d0rjHeP1ylIUmmMcPhfoCqGoyW4+KL+IqHjASDBuySlRBxG ko11kqnwgTPlSx1xqIvCAZ/VZy92kww0pM2XFrN4hGT+Zkt22GHUlFgukHd3CqxbDr3w MTyU/RLAS7vRh4zE3dkQhtkMjulh0U4lriPDqvspSjCVGUfPuoxN/yC9ytR6QVzorx92 yQHBlSGw0vyK6sl105D6mO9CGIW/26KvPi8VnerEeb3ZDIVWw4q3Puyvj3geG+6+CKSz z0Nw== X-Gm-Message-State: AD7BkJLcDYyMkNpkwf/CrdjRVfgYr7ci4kYDZeCq1RgSs1e/1AKT8XTJmp4PV5dswRmCtA== X-Received: by 10.98.93.12 with SMTP id r12mr46056027pfb.64.1459196990351; Mon, 28 Mar 2016 13:29:50 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id c9sm37679096pfd.90.2016.03.28.13.29.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 13:29:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_ABD183F2-BCD7-42CF-A05C-79D620F1171C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:29:48 -0700 Message-Id: References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 20:29:52 -0000 --Apple-Mail=_ABD183F2-BCD7-42CF-A05C-79D620F1171C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, a function set is a form of REST API definition. It defines the = expected requests, responses, options, and formats of messages to effect = particular operations and state changes on resources. It is a structured = way we (Shelby? Vial?) defined to represent such information in some = IETF drafts.=20 The idea is there is a resource like /rd for registering and another = resource like /rd-lookup for discovery and another /rd-group for group = functions. Each of these represents different functions and the name = "function set" was chosen. Is function set too much new conceptual language for something we = already know? Is there a suggestion for a better way to describe it, = like maybe "this is the REST API for registering things in RD", and = "This is the REST API for looking up things in an RD"? BTW, some more formal descriptive alternatives are WADL, Hydra, RAML, = RESTdesc, HAL, JSON Hyper-Schema, Siren, UBER and some other less well = known languages. Each of these has a targeted use case that is a little = different from what we are doing, but could be adapted. We try to use = WADL in CoRE Interfaces... Best regards, Michael > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > ** Function Set >=20 > I have been confused about the strange term 'Function Set' for a while > and when I read through the document I got the impression that it is > nothing more than a REST API. Do I understand it correctly? --Apple-Mail=_ABD183F2-BCD7-42CF-A05C-79D620F1171C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, a function set is a form of REST API definition. It = defines the expected requests, responses, options, and formats of = messages to effect particular operations and state changes on resources. = It is a structured way we (Shelby? Vial?) defined to represent such = information in some IETF drafts. 

The idea is there is a resource like = /rd for registering and another resource like /rd-lookup for discovery = and another /rd-group for group functions. Each of these represents = different functions and the name "function set" was chosen.

Is function set too much = new conceptual language for something we already know? Is there a = suggestion for a better way to describe it, like maybe "this is the REST = API for registering things in RD", and "This is the REST API for looking = up things in an RD"?

BTW, some more formal descriptive = alternatives are WADL, Hydra, RAML, RESTdesc, HAL, JSON Hyper-Schema, = Siren, UBER and some other less well known languages. Each of these has = a targeted use case that is a little different from what we are doing, = but could be adapted. We try to use WADL in CoRE Interfaces...

Best = regards,

Michael


On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

** Function Set

I have been confused about the strange term = 'Function Set' for a while
and when I read through = the document I got the impression that it is
nothing more than a REST API. Do I understand it = correctly?

= --Apple-Mail=_ABD183F2-BCD7-42CF-A05C-79D620F1171C-- From nobody Mon Mar 28 13:33:25 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9012D13A for ; Mon, 28 Mar 2016 13:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 y_WNYxlblC6Y for ; Mon, 28 Mar 2016 13:33:22 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 3DA5912D547 for ; Mon, 28 Mar 2016 13:33:22 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id x3so145679059pfb.1 for ; Mon, 28 Mar 2016 13:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9q3wvTyUcbImD6M0BZvCR5sZXq8BOBzVE+md6k2bGgE=; b=O5XS5aGwRIQPX6rw1vGVmKsL/M/Ns1qJQ0GX72rmtgj+7GBuYxBLsqI0x1Xq8C0Ft1 X8+IMbkzchQg3lsXRbDqdkHBeEgvWcGBXgYEjTYvxXtG8CXfo7CuxJ1n12WI/u2mmrYd KG5PbxgoyeLB7gwUh0ZcKkFOjTSMmEpq1obsUrb4/oyygwMDe7MCTGnX9cqYHfsRyFay BkSVFPvuDzajmgY97St5omPNURGNWExpeEh4GyGHwChhP9z9f1h3G94LTV2KBcoTNZkz Ct8nHGMVxQ48njN6coEq7m4oRUwyStaGOwwrF5MA+DShU2cVs+NNOsxRKBpDOKhz/sNg EdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9q3wvTyUcbImD6M0BZvCR5sZXq8BOBzVE+md6k2bGgE=; b=JOfOZGPiOtYTXIbLUnkHpev93BK5Fc03Sb8BN+L/X8E6hxAoVTmzUqK2CRAQqUs33J sDBgQrKoAuG19Fr5uD7eWfqCQJp/z7RUfsB0YnZnyvP74SmLruZQic9yWz/PtN07MZzR wIpljC3UPZKh67a9TbSfCUdsi0vpIkW2d9vO0gUNHN5McW8VUoqz6popB9kGlioBhZqs 7Ou8uRBcG8qnuRu7O770HslPc2da25N2M+VtlxNmA6JvIo+9VH43XOcCiO269XFeE6aZ /fuLCLOGXAnEaGKAL7nVKy+r3mo2DpKfCV4NTP9ENKGbgsgVk+MvH+YO5RbxIVbl01cs CDIA== X-Gm-Message-State: AD7BkJIEMmgXhNkReKtJvq0Jcbw/1qgyLoC2LbgZbwyrtG48jk2m/O1q3LFNxU0S3A4p2A== X-Received: by 10.98.70.67 with SMTP id t64mr45662879pfa.110.1459197201841; Mon, 28 Mar 2016 13:33:21 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id wx3sm37798918pab.25.2016.03.28.13.33.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 13:33:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E2DAEB67-3154-4A52-A5B9-17CD5FBD0C5F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 13:33:19 -0700 Message-Id: <46CB6ABD-F1FB-4E23-96F8-8E3B8DA41E0F@gmail.com> References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 20:33:24 -0000 --Apple-Mail=_E2DAEB67-3154-4A52-A5B9-17CD5FBD0C5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DNSSD is not important to the use of RD, but we were asked to show an = example if integration of DNSSD with CoRE RD. I agree this example goes a little to deep into resource discovery using = DNSSD as an alternative to RD, and could be more focused on the use of = DNSSD to find RDs and endpoints, but then make much more use of = rd-lookup to discover resources. Michael > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > ** Lighting Installation Example >=20 > Why does this example talk about DNS? Is it possible to split the > example into two parts, one where DNS-SD is used and another one where > it isn't used? >=20 > Additionally, I have been told that luminaries in a commercial = building > are installed and commissioned before a network is up and running. >=20 > I think that the lighting example could show the group concept quite > nicely and that's what it should focus on. >=20 --Apple-Mail=_E2DAEB67-3154-4A52-A5B9-17CD5FBD0C5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii DNSSD is not important to the use of RD, but we were asked to = show an example if integration of DNSSD with CoRE RD.

I agree this example goes a little to = deep into resource discovery using DNSSD as an alternative to RD, and = could be more focused on the use of DNSSD to find RDs and endpoints, but = then make much more use of rd-lookup to discover resources.

Michael

On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

** Lighting Installation Example

Why does this example talk about DNS? Is it = possible to split the
example into two parts, = one where DNS-SD is used and another one where
it isn't used?

Additionally, I have been told that luminaries = in a commercial building
are installed and = commissioned before a network is up and running.

I think that the lighting example could show the = group concept quite
nicely and that's what it = should focus on.


= --Apple-Mail=_E2DAEB67-3154-4A52-A5B9-17CD5FBD0C5F-- From nobody Mon Mar 28 14:10:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF7212D155 for ; Mon, 28 Mar 2016 14:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZGfuedsmTo9X for ; Mon, 28 Mar 2016 14:10:47 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 091FD12DB74 for ; Mon, 28 Mar 2016 14:10:47 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id td3so106162531pab.2 for ; Mon, 28 Mar 2016 14:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=GWQDqM3qQo8K6rUYgNI4AU0Hejk4nJv2InOYnfakKRI=; b=hFHC4QpaSKiqGfX/rqax+tmEGjixZwMd/B+WfNHkLxi7EPitl4V6KwQQ9HJgLjk8D6 xUcFrknJwuZleneJTA8f84tzuys51QLYZrrNRpAhHVo24NfyXjwxSLnZh419OQLIkGxS 8OaZeG4v+Ao+ulM3qH2kl52wOrjFzhzzx7ZevqhajbiWMQ2xHBIeNobrLq5eyFPK0Rsx JaHjPs8Y8sO4Ay7PhuSp4sr2V8fAreTZl1nC5Cmr/owXOOJS6i7mhmK3CnULZ5PtUcxj dwJlR9++LZynJlZqTMY+58qTA9Nl7ojoTXQNhru5OFv4ytu1zdy2uRtN59HY4j6se0TS fDDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GWQDqM3qQo8K6rUYgNI4AU0Hejk4nJv2InOYnfakKRI=; b=hIMMYwSAijBZFaHazbvSzMy9WStdKKNlHN28N5DLZtix/tJvjlr6g7uxRXJfkgrRBL 4nlAOHdM/3ca+vBxzuNbClZJteS/QofEL/o3yUsd5ZW2cYdDEJnoRxK+zz6AUXWpw5TJ OQ0s3fckAw54WEHVuNqVhh5W2JHXaGz14WLr+8thtTXyaymfBv8XPY+XvB3e46RBnQnJ 6GxX7xu5usGFSVz0uAYNEy0ofoTq2I2l9gjsKCQG5EcIc0yj6eGLCZu+G2r7rdVo1R/0 zlVe54/2AXbe16Atu6VAokh3j6uBPdKx/nRJkYjMSpJGg45pXJfkc/+KLcKLhkUIIwjo cK0Q== X-Gm-Message-State: AD7BkJItHxuZ5ZFcelBv+3c80mbmURQmGRy4GIxXtRoMTxYnwG/jXS2Wvsx0Nafu+P5fFQ== X-Received: by 10.67.7.1 with SMTP id cy1mr46504650pad.123.1459199446482; Mon, 28 Mar 2016 14:10:46 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id g23sm37805488pfg.35.2016.03.28.14.10.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 14:10:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F54BA35-0730-42FB-87AC-7BB1D4053950" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56F91A0A.5060804@gmx.net> Date: Mon, 28 Mar 2016 14:10:44 -0700 Message-Id: <9EA5EFEB-89D7-483A-B210-48DDE411DEBF@gmail.com> References: <56F91A0A.5060804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 28 Mar 2016 21:10:48 -0000 --Apple-Mail=_9F54BA35-0730-42FB-87AC-7BB1D4053950 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Security Consideration section here could be augmented by a security = policy section. It seems like we should define security policy for Resource Directories, = Registration, and Discovery. This is a recurring question in other = bodies as well, like W3C WoT IG. There may be some fundamental patterns = to consider in a broader use case context. Who is registering and who is = discovering, and what is the relationship that can be managed through = RD? Are there use cases in ACE or other groups that would inform this? MIchael > On Mar 28, 2016, at 4:48 AM, Hannes Tschofenig = wrote: >=20 > ** Security Considerations >=20 > " > DTLS or TLS based security SHOULD be used on > all resource directory interfaces defined in this document. > " >=20 > Why does this specification say that DTLS or TLS is optional to use? = It > should mandate the use of DTLS/TLS! >=20 --Apple-Mail=_9F54BA35-0730-42FB-87AC-7BB1D4053950 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The Security Consideration section here could = be augmented by a security policy section.

It seems like we should define security = policy for Resource Directories, Registration, and Discovery. This is a = recurring question in other bodies as well, like W3C WoT IG. There may = be some fundamental patterns to consider in a broader use case context. = Who is registering and who is discovering, and what is the relationship = that can be managed through RD?

Are there use cases in ACE or other = groups that would inform this?

MIchael

On = Mar 28, 2016, at 4:48 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

** Security Considerations

"
DTLS or TLS based security = SHOULD be used on
  all resource = directory interfaces defined in this document.
"

Why does this = specification say that DTLS or TLS is optional to use? It
should mandate the use of DTLS/TLS!


= --Apple-Mail=_9F54BA35-0730-42FB-87AC-7BB1D4053950-- From nobody Mon Mar 28 19:23:16 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CBA12D178 for ; Mon, 28 Mar 2016 19:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLDAUI-uINup for ; Mon, 28 Mar 2016 19:23:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115D612D0B3 for ; Mon, 28 Mar 2016 19:23:10 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-ba-56f9e70cc42e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 19.F1.22880.C07E9F65; Tue, 29 Mar 2016 04:23:09 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 04:23:08 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Hannes Tschofenig Thread-Topic: [core] draft-koster-core-coap-pubsub-04 Thread-Index: AQHRhRN1IMgCuAevLUCNxWSiiKmJYp9vmC8A Date: Tue, 29 Mar 2016 02:23:08 +0000 Message-ID: References: <56F2AD00.7010407@gmx.net> In-Reply-To: <56F2AD00.7010407@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7tC7v859hBksnsVnse7ue2WLpznus FtPaz7M7MHvsnHWX3WPxpv1sHkuW/GQKYI7isklJzcksSy3St0vgyniyYz5jwW3uipsfOpga GDdzdjFyckgImEisau1mhLDFJC7cW8/WxcjFISRwhFHi6JbJrBDOEkaJ/heLmEGq2ATsJSav +QjWISJgKHF95nRWEJtZIEzi5u3V7CC2MNDUSycfs0PUmEr8W/WcDcI2kph2qQlsDouAqsTU B/1gNbxAMxcu2Qw2R0hATWLL6blgcU4BdYmVE16C1TMCXff91BomiF3iEreezGeCuFpAYsme 88wQtqjEy8f/WCFsJYlFtz9D1etJ3Jg6hQ3CtpbYsmA9C4StLbFs4WtmiBsEJU7OfMIygVF8 FpIVs5C0z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbhwS2/dXcw rn7teIhRgINRiYc3YeXPMCHWxLLiytxDjBIczEoivE5PgUK8KYmVValF+fFFpTmpxYcYpTlY lMR52T5dDhMSSE8sSc1OTS1ILYLJMnFwSjUwtq2bGpn2eFqta2LB5eU7X3O+05U/rPerklWo WCHnlUtCykeJt0Y7TzX/qNB4++BPvY7VktkXrSJ7mOSeLQ44zLiwT4/vzBqe554eZfqK/x6t Zt1i2zlfV+i22hIXxnmfF9z5FHrzcMHKCTWepttK54kFKcfmXj9w8WHR5AKJI+7eJ7fw5d6t V2Ipzkg01GIuKk4EALoGwh++AgAA Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-koster-core-coap-pubsub-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 02:23:13 -0000 Hi Hannes, > On 23 Mar 2016, at 11:49, Hannes Tschofenig w= rote: >=20 > Hi authors, Hi all, >=20 > I was wondering about the status of , > which describe functionality to allow "sleeping nodes" to outsource > state storage to some other node. >=20 > Currently draft-koster-core-coap-pubsub-04 is not a working group draft, > there is no milestone on the charter, and there has been no update of > the document for this IETF meeting. >=20 > Nevertheless, the CORE charter talks about this item: > " > CoAP will support various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes > and sends the current temperature to a proxy that has subscribed, when > the proxy receives a request over HTTP for that temperature resource, it > can respond with the last seen value instead of trying to query the > Device which is currently asleep. > " >=20 > So, what is the roadmap for this item? The milestones and other WG formalities we can fix once the charter is appr= oved (almost there, right?), but we are working on the draft. Unfortunately= we didn't manage to update it for this meeting but we're planning to submi= t updated version soon. We believe the the draft basic functionality is pre= tty mature by now and if we do further extensions in separate drafts we sho= uld be able to progress this as WG item relatively fast. Cheers, Ari= From nobody Mon Mar 28 23:48:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555E812D164 for ; Mon, 28 Mar 2016 23:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 g6UsG17IHE2s for ; Mon, 28 Mar 2016 23:48:13 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 1CEE612D132 for ; Mon, 28 Mar 2016 23:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=evwA5XG7i7YIscLMrYDYQK0Bx+roODZbiDXx8Up1t7A=; b=evWqQyyxEKO7hcbOomwuQG8f9o smtMDwGrkdmItCsxVaruQs7/PFcfqhYj6v6dobKnPvarN47IkmYBv9jGi6SQbNMeru+fm711/mmB/ /yOpu6NYlQjJiJoSWRILi392zUXuuyZHefV42iB7a28pomZdrR3KNkM4GEYbloZAscOY8zReFz5Ua 7xcwrAPgxAZrxLIDHUVREbbSRUUCzW8yRHP6amwtPjDJ8OZeMD8j0o541+J3xPuQC4fRQ+eOVKesx LXdQrI/ltTolY1f06GNnLWIH8gKw7GsBEBd2XvxqzjnFJofTW74QP1OVQugKs6FZK1b2HpB9q92DY AJvN0ZzA==; Received: from ppp118-209-160-233.lns20.mel8.internode.on.net ([118.209.160.233]:59255 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aknRj-003ZY1-5C for core@ietf.org; Tue, 29 Mar 2016 17:48:11 +1100 To: core@ietf.org References: <56F58BEC.60502@gmx.net> From: Christian Groves Message-ID: <56FA2522.6040502@nteczone.com> Date: Tue, 29 Mar 2016 17:48:02 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F58BEC.60502@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] Ticket #394 - CoAP over TCP: Ping/pong X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 06:48:14 -0000 Hello Hannes, If using ICE https://tools.ietf.org/html/rfc7675 could be used as a keepalive for CoAP. Although the 30s freshness period may be too short for constrained devices. Regards, Christian On 26/03/2016 6:05 AM, Hannes Tschofenig wrote: > In https://trac.tools.ietf.org/wg/core/trac/ticket/394 Klaus provided > feedback for the CoAP over TCP draft and wrote: > > " > Do we need ping/pong messages to keep an idle connection alive through NATs? > " > > There are various options for doing keeping state at NATs (and stateful > packet filtering firewalls) alive: > > - Normally, an application performs retransmissions to keep state > information alive (at the server side and also at intermediate devices). > > - TCP also offers a keep-alive message. > > - There is functionality in TLS (the heartbeat messages) that allow a > state to be kept alive but those are obviously only available when you > use TLS/DTLS. The DTLS/TLS profile document talks about those. > > It would be interesting to hear what the experience with these > mechanisms is. I will check with our guys. Does anyone have feedback? > > Ciao > Hannes > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 29 00:08:00 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981912D541 for ; Tue, 29 Mar 2016 00:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 s-k9gXh5jBAQ for ; Tue, 29 Mar 2016 00:07:58 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 D123F12D510 for ; Tue, 29 Mar 2016 00:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=PQz8R4InA22kvli5WOOLdcVdsikdsoc0tizlR2hlk4c=; b=Ksw5xfXYDc5xtSuqhV0kvYkJXA QteBtFSxDLlPfpetJdohAui69+3vtYfZxO2SOzqo3o5o+bcJIZD8jjqaP9FxndM6caaR4So4u/geQ eDlHtWYG6ay353b5uOGt/PxzdH3cBsmJ2NBaUoXnNHv1Cs3X39GeCAWpoEpkWC3FoLQKa5/QUL3as ARDr5CoA8O6AwupbwEbLOYe3oDI9xW4tMoL4dpyNyGCS8ZtW+AV+3Y4PUste3xjLOnOc+VFYFVSMD rLr+2lWIZ1aT+vtkm+iEftaQmUnLI+qSkTDRUUP2qU6/TKy/wpycXWE7pkE4fqBmh60T5fleNscdD OaAH5wSw==; Received: from ppp118-209-160-233.lns20.mel8.internode.on.net ([118.209.160.233]:59841 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aknkp-003bRg-7m for core@ietf.org; Tue, 29 Mar 2016 18:07:55 +1100 To: core@ietf.org References: <56F58BF2.2070203@gmx.net> From: Christian Groves Message-ID: <56FA29C2.9040307@nteczone.com> Date: Tue, 29 Mar 2016 18:07:46 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F58BF2.2070203@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [core] Ticket #395 - CoAP over TCP: Session Resumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 07:07:59 -0000 My understanding is that TLS1.3 (https://tools.ietf.org/html/draft-ietf-tls-tls13-12)is deprecating session resumption. So it may not be good to rely on that mechanism. Regards, Christian On 26/03/2016 6:05 AM, Hannes Tschofenig wrote: > In https://trac.tools.ietf.org/wg/core/trac/ticket/395 Klaus provided > feedback for the CoAP over TCP draft and wrote: > > " > Should each connection be independent from all other connections, or > should it be possible to set up a connection (e.g., registering to > observe multiple resources), disconnect and resume the connection at a > later time? > (I'm leaning towards independent connections.) > " > > When DTLS / TLS client communicates with a server then it typically > establishes a session cache to allow session resumption. This is a > feature that is recommended to be used in the DTLS profile document. > There is also an additional version of the session resumption that does > not require the server to maintain any session state but the state is > stored in a ticket, cached at the client and later presented. This > feature is called 'session resumption without server-side state' and > defined in RFC 5077. > > In any case, if there is already cached information established from a > prior exchange then the client should try to re-use that information to > accelerate the TLS handshake. The performance benefit are large when a > ciphersuite with public key cryptography is used during the full handshake. > > My recommendation is to follow the guidance given in the DTLS profile. I > do, however, believe it would be useful to reference the DTLS profile > draft and to reference the appropriate section. > > Did I correctly address your feedback? > > Ciao > Hannes > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 29 02:57:22 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB09C12D5E9 for ; Tue, 29 Mar 2016 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1WDKHxXeJ7E for ; Tue, 29 Mar 2016 02:57:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F219E12D5E2 for ; Tue, 29 Mar 2016 02:57:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-12-56fa517b11fe Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.18.23401.B715AF65; Tue, 29 Mar 2016 11:57:16 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 11:57:05 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig Thread-Topic: [core] Block Transfer and Object Security .... Re: Agenda Thread-Index: AQHRiQJfozlE0Zss2kOk94eHNyee8p9wMKwA Date: Tue, 29 Mar 2016 09:57:04 +0000 Message-ID: References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> <56F90AFF.5080809@gmx.net> <56F92027.9060308@tzi.org> <56F946B3.8020309@gmx.net> In-Reply-To: <56F946B3.8020309@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <6A3BE89B5571E546B25A1EEDEA49442B@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7gW5N4K8wg7cneSyOTLnLarHv7Xpm i6U777E6MHss3rSfzWPJkp9MHtMWZQYwR3HZpKTmZJalFunbJXBl3F0jXTDFraLjVi97A+Ma ly5GTg4JAROJBc+6mCFsMYkL99azdTFycQgJHGGUeD9nJxNIQkhgCaPEiX5hEJtNwEXiQcMj sLiIgKHE9ZnTWUFsZgE3icef/4MNEgayZ2y9wQxR4y6xaMY0KNtI4tXzCWC9LAKqEqtXnGYD sXkFLCR2tz9hgVj8m1Hi8YLn7CAJTgF1iQ/zTrKA2IxA130/tYYJYpm4xK0n85kgrhaQWLLn PNQHohIvH/8DO0hUQE/idsdadoi4kkTjkidAcQ6gXk2J9bv0IcZYS/T9vAl1v6LElO6H7BD3 CEqcnPmEZQKjxCwk22YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgRG5cEtv612MB587niIUYCDUYmHN2HlzzAh1sSy4srcQ4wSHMxKIrzlAb/ChHhTEiurUovy 44tKc1KLDzFKc7AoifOyfbocJiSQnliSmp2aWpBaBJNl4uCUamCM5Dm592san0zVRk3BXPeC v0mnCyx7L925wJF0esNpg+dfAuUcX1/9qGK3p3t/u4vDwbj1f3oc1vRM5ukTDk26XZfwfMm3 KX8Md18Q4GA62sx7tqd2q/Xqyw+2qxqqu0uFtwQosKjv8Zj6cfLFVeceCfKv5PzJVf8pe26Y 9oSrTPHp2YyHbhorsRRnJBpqMRcVJwIA9D05KMYCAAA= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 09:57:21 -0000 SGkgSGFubmVzLA0KDQpTdWNoIGEgc29sdXRpb24gb25seSBpcyBub3QgdmVyeSByb2J1c3QgYWdh aW5zdCBkZW5pYWwgb2Ygc2VydmljZSB1bmxlc3MNCnRoZXJlIGlzIGFkZGl0aW9uYWwgc2VjdXJp dHkgYXQgbG93ZXIgbGF5ZXIgb3IgdGhhdCBpdCBpcyBwb3NzaWJsZSB0bw0KcHJvdGVjdCBmcmFn bWVudHMgaW4gc2l6ZXMgb2YgY2VydGFpbiB1cHBlciBsaW1pdCBzdWNoIGFzIGluIEhUVFAgY29u dGVudA0KZW5jcnlwdGlvbi4gSW4gdGhlIGNhc2Ugb2YgYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJp dHkgb25seSwgb25lIHdvdWxkIHRodXMNCmhhdmUgdG8gaW52ZW50IHNvbWV0aGluZyBsaWtlIHRo ZSBsYXR0ZXIuIFdoaWxlIHRoaXMgaXMgcG9zc2libGUsIGl0IHdvdWxkDQpiZSB2ZXJ5IHVuZm9y dHVuYXRlIGlmIGZvciBlYWNoIENvQVAgImZlYXR1cmUiIGJlaW5nIGRlZmluZWQsIHlvdSBuZWVk IHRvDQpzZXBhcmF0ZWx5IGRlZmluZSB0aGUgY29ycmVzcG9uZGluZyAiZTJlIHNlY3VyZSBmZWF0 dXJlIiwgaW5zdGVhZCBvZg0KbWFraW5nIHRoZXNlIGNvbnNpZGVyYXRpb25zIGJlZm9yZSBzdGFu ZGFyZGl6aW5nIHRoZSBmZWF0dXJlIGluIHF1ZXN0aW9uLg0KSW4gcGFydGljdWxhciBhcyBpbiB0 aGUgY2FzZSBvZiBCbG9jayB3aGVyZSBhbGwgZmVhdXJlcyBvZiBhIHNlY3VyZQ0KZnJhZ21lbnRh dGlvbiBzY2hlbWUgYXJlIHByZXNlbnQgaWYgeW91IG9ubHkgd2VyZSBhYmxlIHRvIGFwcGx5IGlu dGVncml0eQ0KcHJvdGVjdGlvbiBvZiBlYWNoIENvQVAgYmxvY2sgbWVzc2FnZSBiZXR3ZWVuIHRo ZSBlbmRwb2ludHMuDQoNClRoYXQgaXMgdGhlIHByb2JsZW0gc3RhdGVtZW50LiBJbiB0ZXJtcyBv ZiBzb2x1dGlvbiwgaXQgYWN0dWFsbHkgc2VlbXMNCnBvc3NpYmxlIHRvIHNlcGFyYXRlIG9wdGlv bnMgaW50ZW5kZWQgZm9yIHByb3hpZXMgZnJvbSBvcHRpb25zIGludGVuZGVkDQpmb3IgZW5kcG9p bnRzIHdpdGhvdXQgYWRkaXRpb25hbCBpbnRydXNpb24gb24gQ29BUC4gVGhpcyBtZWFucyB0aGF0 IHlvdQ0KY2FuIHJldXNlIEJsb2NrLCB3aGljaCBhbHRob3VnaCB3YXNuJ3QgZGVzaWduZWQgZm9y IGVuZC10by1lbmQgc2VjdXJpdHksDQpvZiBjb3Vyc2UgZG9lcyB3b3JrIGluIHRoZSBhYnNlbnNl IGludGVybWVkaWFyaWVzIG1ha2luZyBjaGFuZ2VzLg0KDQpTaW5jZSB5b3Ugc2VlbSB0byBiZSBp bnRlcmVzdGVkIGluIHRoZSBkZXRhaWxzIGhlcmUgaXQgZ29lczogVGhlDQphcHBsaWNhdGlvbiBs YXllciBzZWN1cml0eSBzb2x1dGlvbnMgcHJlc2VudGVkIHNvIGZhciB3aGljaCBhcmUgYXBwbGlj YWJsZQ0KdG8gMy4xIGFuZCAzLjIgb2YgZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJl cXMgYXJlIGJhc2VkIG9uDQp3cmFwcGluZyBhbiB1bnByb3RlY3RlZCBDb0FQIG1lc3NhZ2UgaW4g YSBDT1NFIG9iamVjdCBhbmQgc2VuZCB0aGlzIGluIGENCigicHJvdGVjdGVkIikgQ29BUCBtZXNz YWdlLiAgVGhlIGlkZWEgZm9yIHNpbXVsdGFuZW91c2x5IG1hbmFnaW5nDQplbmQtdG8tZW5kIGFu ZCBwcm94eSBvcHRpb25zIGlzIGJhc2VkIG9uIHRoZSBjb25jZXB0IG9mIOKAnGR1cGxpY2F0ZeKA nQ0Kb3B0aW9ucyBpbnRyb2R1Y2VkIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBPU0NPQVA6IEZv ciBjZXJ0YWluIG9wdGlvbnMgd2UNCm1heSBhbGxvdyB0aGUgdXNlIG9mIGFuIOKAnGlubmVy4oCd IG9wdGlvbiBlbmNyeXB0ZWQgaW5zaWRlIHRoZSBDT1NFIG9iamVjdA0KaW50ZW5kZWQgZm9yIHRo ZSBlbmRwb2ludCwgYW5kIGFuIOKAnG91dGVy4oCdIG9wdGlvbiBpbiB0aGUgb3B0aW9ucyBwYXJ0 IG9mDQpwcm90ZWN0ZWQgQ29BUCBtZXNzYWdlIGludGVuZGVkIGZvciBhIHByb3h5Lg0KDQpUaGUg YmxvY2sgb3B0aW9ucyBjb3VsZCBwb3RlbnRpYWxseSBiZSB1c2VkIGluIHRoaXMgd2F5LCBhbGxv d2luZyB0aGUNCnNlbmRpbmcgZW5kcG9pbnQgdXNpbmcgYW4gaW5uZXIgYmxvY2sgb3B0aW9uIHRv IGZyYWdtZW50IGEgbGFyZ2UgbWVzc2FnZQ0Kd2hlcmUgZWFjaCBmcmFnbWVudCBjYW4gYmUgcHJv dGVjdGVkIGVuZC10by1lbmQuIFRoaXMgYWxsb3dzIGZvciBhIHBvbGljeQ0Kb2YgYW4gdXBwZXIg bGltaXQgZm9yIGZyYWdtZW50cyB3aGljaCBjYW4gYmUgdmVyaWZpZWQsIHRoZSBsYWNrIG9mIHdo aWNoDQp3YXMgb25lIG9mIHRoZSBjb25jZXJucy4NCg0KVGhlc2Ugc2VjdXJlIGZyYWdtZW50cyBj YW4sIGlmIG5lY2Vzc2FyeSwgaW4gdHVybiBiZSBmcmFnbWVudGVkIGJ5IGEgcHJveHkNCnVzaW5n IGFuIG91dGVyIGJsb2NrIG9wdGlvbi4gVGhlIHJlY2VpdmluZyBlbmRwb2ludCB0aGVuIGZpcnN0 IGRlZnJhZ21lbnRzDQp0aGUgcHJvdGVjdGVkIENvQVAgbWVzc2FnZSwgdGhlbiB2ZXJpZmllcyBh bmQgZGVjcnlwdHMsIHRoZW4gYWZ0ZXINCnZlcmlmeWluZyBhbmQgZGVjcnlwdGluZyBhbGwgcHJv dGVjdGVkIGZyYWdtZW50cywgZGVmcmFnbWVudHMgdGhlDQp1bnByb3RlY3RlZCBDb0FQIG1lc3Nh Z2Ugd2hpY2ggYmVjb21lcyB2ZXJpZmllZCBieSB0aGlzIHByb2Nlc3MuIChUaGUNCm91dGVyIGFu ZCBpbm5lciBvcHRpb25zIG1heSBiZSBpbmRlcGVuZGVudCwgc28gZWl0aGVyIHRoZSBlbmRwb2lu dCBvciB0aGUNCnByb3h5IG9yIGJvdGggZnJhZ21lbnQsIHRoZSBzY2VuYXJpbyBhYm92ZSBpcyB0 aGUgY2FzZSBvZiDigJxib3Ro4oCdLCB3aGljaCBvZg0KY291cnNlIGlzIHRoZSBtb3N0IGNvbXBs aWNhdGVkLikNCg0KVGhpcyBpcyBpbiBicmllZiB3aGF0IEkgcHJvcG9zZSB0byBkaXNjdXNzIGlu IHRoZSBDb1JFIFdHIHVuZGVyIHRoZSB0b3BpYw0Kb2YgImJsb2Nrd2lzZSIgaW4gdGhlIHNlY3Vy aXR5IHNlY3Rpb24uDQoNCg0KR8O2cmFuDQoNCg0KDQoNCk9uIDIwMTYtMDMtMjggMTY6NTgsICJI YW5uZXMgVHNjaG9mZW5pZyIgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KDQo+ SGkgR29lcmFuLA0KPg0KPm5vcm1hbGx5IHlvdSB3b3VsZCBkbyB0aGUgZm9sbG93aW5nOg0KPg0K PiAxKSBZb3UgdGFrZSB0aGUgZW50aXJlIHBheWxvYWQgKGZvciBleGFtcGxlIGEgZmlybXdhcmUg aW1hZ2UpLg0KPiAyKSBZb3UgYWRkIHNvbWUgc2VjdXJpdHkgcHJvdGVjdGlvbiBpbiB0aGUgZnJv bnQuDQo+IDMpIFRoZW4sIHlvdSBtYWtlIGl0IGF2YWlsYWJsZSBmb3IgZG93bmxvYWQuDQo+IDQp IEEgc2VydmVyIG1heSB0aGVuIGNodW5rIGl0IGludG8gcGllY2VzIGFuZCBkZWxpdmVyeSB0aGVt IHNlcGFyYXRlbHkNCj51c2luZyB0aGUgQmxvY2t3aXNlIFRyYW5zZmVyIG1lY2hhbmlzbS4NCj4g NSkgVGhlIGNsaWVudCByZWNlaXZlcyBhbGwgdGhlIHBpZWNlcywgcHV0cyB0aGVtIHRvZ2V0aGVy LCB2ZXJpZmllcyB0aGUNCj5zaWduYXR1cmUgb3IgTUFDLCBhbmQgdGhlbiB1cGRhdGVzIHRoZSBm aXJtd2FyZS4NCj4NCj5UaGlzIHNlcXVlbmNlIG9mIHN0ZXBzIHNob3VsZCBiZSB0aGUgc2FtZSBy ZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlcmUgaXMNCj5hIHByb3h5IHRoYXQgY2FjaGVzIHBpZWNl cyBvciBub3QuDQo+DQo+U28sIHdoYXQgZXhhY3RseSBpcyB0aGUgY29uY2VybiBoZXJlPw0KPg0K PkNpYW8NCj5IYW5uZXMNCj4NCj5PbiAwMy8yOC8yMDE2IDAzOjM2IFBNLCBHw7ZyYW4gU2VsYW5k ZXIgd3JvdGU6DQo+PiBIaSBIYW5uZXMNCj4+IA0KPj4gQ29tcGxlbWVudGluZyBDYXJzdGVu4oCZ cyBleHBsYW5hdGlvbjoNCj4+IA0KPj4gVGhlcmUgaXMgYSBjb25mbGljdCBiZXR3ZWVuIGJlaW5n IGFibGUgdG8gcHJvdGVjdCBhIG1lc3NhZ2UgZnJhZ21lbnQNCj4+IGVuZC10by1lbmQgYmV0d2Vl biBlbmRwb2ludHMgYW5kIGdpdmluZyBhbnkgaW50ZXJtZWRpYXRlIG5vZGUgdGhlIHJpZ2h0DQo+ PnRvDQo+PiByZWZyYWdtZW50IGEgbWVzc2FnZS4gQmxvY2sgb3BlcmF0aW9ucyBwZXJmb3JtZWQg YnkgcHJveGllcyBjYW5ub3QgYmUNCj4+IHZlcmlmaWVkIHdoaWNoIGhhcyB0d28gY29uc2VxdWVu Y2VzLiBCbG9ja3dpc2UgY2Fubm90IGJlIGRpcmVjdGx5DQo+PmFwcGxpZWQNCj4+IHRvIHNlY3Vy ZSBtZXNzYWdlIGZyYWdtZW50YXRpb24sIGFuZCB0aGUgQmxvY2sgb3B0aW9uIG9wZW5zIHVwIGZv ciBEb1MNCj4+YnkNCj4+IGFueSBvbi1wYXRoIGFkdmVyc2FyeS4gSSBmb3VuZCB0aGlzIHNlcmlv dXMgZW5vdWdoIHRvIHdhcnJhbnQgYSBzZWN1cml0eQ0KPj4gY29uc2lkZXJhdGlvbiwgd2hpY2gg aXMgaW5jbHVkZWQgaW4gLTE5Lg0KPj4gDQo+PiBJdCB0dXJucyBvdXQgdGhhdCB3aGlsZSBwbGFp bnRleHQgQ29BUCBibG9jayBvcHRpb25zIHBhc3NpbmcgcHJveGllcw0KPj4gY2Fubm90IGJlIHBy b3RlY3RlZCBpbiB0aGUgd2F5ICBibG9ja3dpc2Ugd29ya3MsIHRoZXkgY291bGQgcG90ZW50aWFs bHkNCj4+YmUNCj4+IHVzZWQgZW5kLXRvLWVuZCBpZiB5b3Ugd2VyZSBjZXJ0YWluIHRoZXJlIHdl cmUgbm8gY2hhbmdlcyBiZWluZyBtYWRlIGluDQo+PiB0cmFuc2ZlciwgYW5kIHRoYXQgaXMgc29t ZXRoaW5nIGFuIG9iamVjdCBzZWN1cml0eSBzb2x1dGlvbiBjb3VsZCBiZQ0KPj51c2VkDQo+PiBm b3IuIFRoaXMgaXMgb25lIG9mIHRoZSB0b3BpY3MgSeKAmWQgbGlrZSB0byBkaXNjdXNzIGluIHRo ZSBzZWN1cml0eQ0KPj5zZWN0aW9uDQo+PiBvbiB0aGUgQ29SRSBhZ2VuZGEuDQo+PiANCj4+IEfD tnJhbg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNi0wMy0yOCAxNDoxNCwgImNvcmUgb24gYmVo YWxmIG9mIENhcnN0ZW4gQm9ybWFubiINCj4+IDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+PiANCj4+PiBIaSBIYW5uZXMsDQo+Pj4NCj4+ Pj4gSSBoYXZlIHJlLXJlYWQgdGhlIEJsb2Nrd2lzZSBUcmFuc2ZlciBkcmFmdCBhbmQgdGhlIGRv Y3VtZW50IGRvZXMgbm90DQo+Pj4+IGdpdmUgbWUgdGhlIGltcHJlc3Npb24gdGhhdCB0aGVyZSBp cyBhbnkgc3BlY2lmaWMgbmVlZCB0byB0aWUgaXQgdG8NCj4+Pj4gT2JqZWN0IFNlY3VyaXR5Lg0K Pj4+Pg0KPj4+PiBDYW4geW91IGV4cGxhaW4gd2hhdCB0aGUgcmVsYXRpb25zaGlwIGlzPw0KPj4+ DQo+Pj4gQWZ0ZXIgdGhlIGxhc3QgY2FsbCBjb21wbGV0ZWQsIHdlIGhhZCBhIGRpc2N1c3Npb24g b24gdGhlIElFVEYgbWFpbGluZw0KPj4+IGxpc3QgaG93IHRvIGVtcGxveSBvYmplY3Qgc2VjdXJp dHkgaW4gYSBibG9jay13aXNlIHRyYW5zZmVyIHRoYXQgc3BhbnMNCj4+PiBwcm94aWVzLg0KPj4+ IElmIHlvdSBzZWN1cmUgb25seSB0aGUgY29tcGxldGUgcmVwcmVzZW50YXRpb24sIHRoZSBjYWNo ZSBpbiBhIHByb3h5DQo+Pj4gbWlnaHQgYmUgcG9pc29uZWQgYnkgZmFrZSBibG9ja3MsIGFuZCB5 b3UgZ2V0IGFuIGF2YWlsYWJpbGl0eSBwcm9ibGVtLg0KPj4+IElmIHlvdSBzZWN1cmUgZWFjaCBv ZiB0aGUgYmxvY2tzIChhbmQgaGF2ZSBhIHdheSBmb3IgdGhlIHByb3h5IHRvIGJlDQo+Pj4gcGFy dCBvZiBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIG5lZWRlZCBzbyBpdCBhbHNvIGNhbiB2ZXJpZnkg dGhlDQo+Pj5ibG9ja3MpLA0KPj4+IHlvdSBjYW4gcHJldmVudCB0aGF0LCBidXQgeW91IHN0aWxs IGhhdmUgdG8gc2VjdXJlIHRoZSB3YXkgdGhlIGVudGlyZQ0KPj4+IHJlcHJlc2VudGF0aW9uIGlz IGNvbXBvc2VkIGZyb20gdGhvc2UgYmxvY2tzLCBhbmQgdGhhdCBtaWdodCBtZWFuDQo+Pj4gYWRk aXRpb25hbCBjb21wb25lbnRzIGFyZSBuZWVkZWQgaW4gYW4gb2JqZWN0IHNlY3VyaXR5IHByb3Rv Y29sLg0KPj4+DQo+Pj4gSSBhZ3JlZSB0aGF0IG5vbmUgb2YgdGhlc2UgY29uc2lkZXJhdGlvbnMg aGF2ZSBhIGJlYXJpbmcgb24gdGhlDQo+Pj4gYmxvY2std2lzZSBwcm90b2NvbCBpdHNlbGYsIGFu ZCB0aGlzIGFsc28gd2FzIHRoZSByZXNvbHV0aW9uIHdlIHJlYWNoZWQNCj4+PiBhZnRlciB0aGUg ZGlzY3Vzc2lvbi4gIEJ1dCBpdCB3YXMgdXNlZnVsIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24sIGFu ZCBpdA0KPj4+IHdpbGwgaW5mb3JtIHRoZSBkaXNjdXNzaW9uIGFib3V0IG9iamVjdCBzZWN1cml0 eS4NCj4+Pg0KPj4+PiBJIGhvcGUgdGhlcmUgaXMgbm8gcGxhbiB0byBtYWtlIHRoZSBjb21wbGV0 aW9uIG9mIEJsb2Nrd2lzZSB0cmFuc2Zlcg0KPj4+PiBkZXBlbmRlbnQgb24gdGhlIHByb2dyZXNz IG9mIG9iamVjdCBzZWN1cml0eS4NCj4+Pg0KPj4+IE5vLCBhcyBmYXIgYXMgdGhlIENvUkUgV0cg aXMgY29uY2VybmVkLCBibG9jay13aXNlIGlzIGRvbmUuDQo+Pj4gSXQgaXMgY3VycmVudGx5IGlu IElFU0cgZXZhbHVhdGlvbiBhbmQgb24gdGhlIGFnZW5kYSBvZiB0aGUgMjAxNi0wNC0yMQ0KPj4+ IElFU0cgdGVsZWNoYXQ7IE1hdHRoaWFzIEtvdmF0c2NoIGlzIHRoZSBzaGVwaGVyZC4NCj4+Pg0K Pj4+IEdyw7zDn2UsIENhcnN0ZW4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gY29yZSBtYWlsaW5nIGxpc3QNCj4+PiBjb3JlQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+ PiANCg0K From nobody Tue Mar 29 02:57:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4921A12D5F9 for ; Tue, 29 Mar 2016 02:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKcpTn5DbDtW for ; Tue, 29 Mar 2016 02:57:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5FD12D5FE for ; Tue, 29 Mar 2016 02:57:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-33-56fa5185f159 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.28.23401.5815AF65; Tue, 29 Mar 2016 11:57:25 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 11:57:24 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Carsten Bormann Thread-Topic: [core] Block Transfer and Object Security .... Re: Agenda Thread-Index: AQHRiN7QrElu1ST8/UiJ0vOten3L1J9uo36AgAAqAACAAWN8AA== Date: Tue, 29 Mar 2016 09:57:23 +0000 Message-ID: References: <56F56B0F.9070508@gmx.net> <56F6A942.4010405@tzi.org> <56F6B333.2060105@gmx.net> <56F6B708.4080805@tzi.org> <56F90AFF.5080809@gmx.net> <56F92027.9060308@tzi.org> <56F94362.8000706@gmx.net> In-Reply-To: <56F94362.8000706@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7lm5r4K8wg5Yd/BZHptxltdj3dj2z xdKd91gdmD0Wb9rP5rFkyU8mj2mLMgOYo7hsUlJzMstSi/TtErgy5k/pYyr4olTxZdsT9gbG BqUuRg4OCQETiTMzZbsYOYFMMYkL99azdTFycQgJHGGUeHfpBDNIQkhgCaPEmmkuIDabgIvE g4ZHTCC2iECwxMVLP8BsZgE1iUdLz7GAzBQWcJe4ukQWosRD4tiuh+wgYREBJ4mGNd4gYRYB VYk7W8+wgti8AhYSD3Y+YYTYdI5R4sqGchCbU0BdYs3h9+wgNiPQad9PrYHaJC5x68l8JoiT BSSW7DnPDGGLSrx8/A9spqiAnsTtjrXsEHEliUW3PzOBnMAsoCmxfpc+xBhriYcb/7NC2IoS U7ofskOcIyhxcuYTlgmMErOQbJuF0D0LSfcsJN2zkHQvYGRdxShanFpcnJtuZKSXWpSZXFyc n6eXl1qyiREYjwe3/LbawXjwueMhRgEORiUe3oSVP8OEWBPLiitzDzFKcDArifCWB/wKE+JN SaysSi3Kjy8qzUktPsQozcGiJM7L9ulymJBAemJJanZqakFqEUyWiYNTqoFR5YxI8MufPSw6 LqKX2jh9mu1enuOWvHDQ3OXZxb13/wp88Fh5KXNljGH560fJR69qeKsz/KiR3sS+xqTh/RpG 5u9drz6s7c8q2XPj4+nDubkeC0/M/mBt2tNXYdDL5iOXXWxbNX/mXPmPq178/mx6dlnJyhYd xpRTIb/ntN7jVVr8kn3er7ltSizFGYmGWsxFxYkAlkR76sMCAAA= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Block Transfer and Object Security .... Re: Agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 09:57:40 -0000 SGkgSGFubmVzLA0KDQpPbiAyMDE2LTAzLTI4IDE2OjQ0LCAiY29yZSBvbiBiZWhhbGYgb2YgSGFu bmVzIFRzY2hvZmVuaWciDQo8Y29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBoYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCg0KPkhpIENhcnN0ZW4sDQo+DQo+dGhlIG9i c2VydmF0aW9uIHRoYXQgYSBwcm94eSBoYXMgbmVnYXRpdmUgaW1wYWN0cyBvbiBzZWN1cml0eSB3 aGVuDQo+ICogaG9wLWJ5LWhvcCBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGlzIHVzZWQgaW4gY29t YmluYXRpb24gd2l0aA0KPiAqIHRlcm1pbmF0aW5nIHRoYXQgY29tbXVuaWNhdGlvbiBhdCB0aGUg cHJveHkNCj5pcyBub3RoaW5nIHRoYXQgcmVsYXRlcyB0byB0aGUgYmxvY2t3aXNlIHRyYW5zZmVy IGl0c2VsZi4NCg0KU2VlIHByZXZpb3VzIG1haWwuDQoNCj4NCj5JbiBnZW5lcmFsLCBpbiBzdWNo IGEgc2V0dXAgdGhlIHByb3h5IGhhcyB0aGUgcG93ZXIgdG8gY2hhbmdlIHRoZQ0KPmNvbnRlbnQs IHJlLWFycmFuZ2UgZGF0YSwgaW5qZWN0IG5ldyBkYXRhLCBldGMuDQo+DQo+SSB1bmRlcnN0YW5k IHRoYXQgZW5kLXRvLWVuZCBzZWN1cml0eSBpcyBpbXBvcnRhbnQgaW4gc3VjaCBjYXNlcyBhbmQg b2YNCj5jb3Vyc2UgcmFpc2VzIHRoZSBxdWVzdGlvbiBhYm91dCB0aGUgdXNlIG9mIGludGVybWVk aWFyaWVzIGluIHRoZSBmaXJzdA0KPnBsYWNlIA0KDQpJbnRlcm1lZGlhcmllcyBjYW4gYWxzbyBw ZXJmb3JtIGEgc2VjdXJpdHkgZnVuY3Rpb24gYnkgcHJvdGVjdGluZw0KYXZhaWxhYmlsaXR5IGlu IHRlcm1zIG9mIGNvbW11bmljYXRpb24gcmVzb3VyY2VzIGFuZCBwb3dlciBjb25zdW1wdGlvbiBv Zg0KY29uc3RyYWluZWQgZW5kcG9pbnRzLiBJIGRvbuKAmXQgc2VlIHRoaXMgYXMgYmxhY2sgb3Ig d2hpdGUsIGJ1dCBhcw0KY29uZmxpY3RpbmcgcmVxdWlyZW1lbnRzIHdoZXJlIGRpZmZlcmVudCB0 cmFkZS1vZmZzIGFyZSBwcmVmZXJyZWQNCmRlcGVuZGluZyBvbiB0aGUgc2NlbmFyaW8uIFRoaXMg aXMgdGhlIHRvcGljIG9mDQpkcmFmdC1oYXJ0a2UtY29yZS1lMmUtc2VjdXJpdHktcmVxcywgaXQg d291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciB5b3VyDQpjb21tZW50cyBvbiB0aGF0Lg0KDQoN Cj4ocGFydGljdWxhcmx5IGlmIHRoZXkgYXJlIHN1cHBvc2VkIHRvIG1ha2UgYWxsIHNvcnRzIG9m DQo+Y29tcHV0YXRpb25zLCBsaWtlIGFnZ3JlZ2F0aW9uIGFuZCBhbmFseXNpcywgb24gdGhhdCBk YXRhKS4NCg0KVGhvc2Uga2luZCBpbnRlcm1lZGlhcmllcyBhcmUgY3VycmVudGx5IG91dCBvZiBz Y29wZSBpbiB0aGUgZHJhZnQNCnJlZmVyZW5jZWQgYWJvdmUsIGJ1dCBvbmUgb2YgdGhlIHRvcGlj cyBmb3IgZGlzY3Vzc2lvbiBpbiB0aGF0IHNsb3Qgb24gdGhlDQpDb1JFIGFnZW5kYSBpcyB3aGF0 IGtpbmQgb2YgaW50ZXJtZWRpYXJpZXMgdGhpcyBhbmFseXNpcyBzaG91bGQgZW5jb21wYXNzLg0K Q3VycmVudGx5IGl0IGlzIGZvcndhcmQgcHJveHkgYW5kIHB1Yi1zdWIgYnJva2VyLCB3ZSBhcmUg Y29uc2lkZXJpbmcgdG8NCmFkZCByZXZlcnNlIHByb3h5IGFuZCB0cmFuc2xhdGlvbmFsIHByb3h5 IChlLmcuIEhUVFAtQ29BUCkuDQoNCkfDtnJhbg0KDQoNCg0KPg0KPkNpYW8NCj5IYW5uZXMNCj4N Cj5PbiAwMy8yOC8yMDE2IDAyOjE0IFBNLCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQo+PiBIaSBI YW5uZXMsDQo+PiANCj4+PiBJIGhhdmUgcmUtcmVhZCB0aGUgQmxvY2t3aXNlIFRyYW5zZmVyIGRy YWZ0IGFuZCB0aGUgZG9jdW1lbnQgZG9lcyBub3QNCj4+PiBnaXZlIG1lIHRoZSBpbXByZXNzaW9u IHRoYXQgdGhlcmUgaXMgYW55IHNwZWNpZmljIG5lZWQgdG8gdGllIGl0IHRvDQo+Pj4gT2JqZWN0 IFNlY3VyaXR5Lg0KPj4+DQo+Pj4gQ2FuIHlvdSBleHBsYWluIHdoYXQgdGhlIHJlbGF0aW9uc2hp cCBpcz8NCj4+IA0KPj4gQWZ0ZXIgdGhlIGxhc3QgY2FsbCBjb21wbGV0ZWQsIHdlIGhhZCBhIGRp c2N1c3Npb24gb24gdGhlIElFVEYgbWFpbGluZw0KPj4gbGlzdCBob3cgdG8gZW1wbG95IG9iamVj dCBzZWN1cml0eSBpbiBhIGJsb2NrLXdpc2UgdHJhbnNmZXIgdGhhdCBzcGFucw0KPj4gcHJveGll cy4NCj4+IElmIHlvdSBzZWN1cmUgb25seSB0aGUgY29tcGxldGUgcmVwcmVzZW50YXRpb24sIHRo ZSBjYWNoZSBpbiBhIHByb3h5DQo+PiBtaWdodCBiZSBwb2lzb25lZCBieSBmYWtlIGJsb2Nrcywg YW5kIHlvdSBnZXQgYW4gYXZhaWxhYmlsaXR5IHByb2JsZW0uDQo+PiBJZiB5b3Ugc2VjdXJlIGVh Y2ggb2YgdGhlIGJsb2NrcyAoYW5kIGhhdmUgYSB3YXkgZm9yIHRoZSBwcm94eSB0byBiZQ0KPj4g cGFydCBvZiBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIG5lZWRlZCBzbyBpdCBhbHNvIGNhbiB2ZXJp ZnkgdGhlIGJsb2NrcyksDQo+PiB5b3UgY2FuIHByZXZlbnQgdGhhdCwgYnV0IHlvdSBzdGlsbCBo YXZlIHRvIHNlY3VyZSB0aGUgd2F5IHRoZSBlbnRpcmUNCj4+IHJlcHJlc2VudGF0aW9uIGlzIGNv bXBvc2VkIGZyb20gdGhvc2UgYmxvY2tzLCBhbmQgdGhhdCBtaWdodCBtZWFuDQo+PiBhZGRpdGlv bmFsIGNvbXBvbmVudHMgYXJlIG5lZWRlZCBpbiBhbiBvYmplY3Qgc2VjdXJpdHkgcHJvdG9jb2wu DQo+PiANCj4+IEkgYWdyZWUgdGhhdCBub25lIG9mIHRoZXNlIGNvbnNpZGVyYXRpb25zIGhhdmUg YSBiZWFyaW5nIG9uIHRoZQ0KPj4gYmxvY2std2lzZSBwcm90b2NvbCBpdHNlbGYsIGFuZCB0aGlz IGFsc28gd2FzIHRoZSByZXNvbHV0aW9uIHdlIHJlYWNoZWQNCj4+IGFmdGVyIHRoZSBkaXNjdXNz aW9uLiAgQnV0IGl0IHdhcyB1c2VmdWwgdG8gaGF2ZSB0aGUgZGlzY3Vzc2lvbiwgYW5kIGl0DQo+ PiB3aWxsIGluZm9ybSB0aGUgZGlzY3Vzc2lvbiBhYm91dCBvYmplY3Qgc2VjdXJpdHkuDQo+PiAN Cj4+PiBJIGhvcGUgdGhlcmUgaXMgbm8gcGxhbiB0byBtYWtlIHRoZSBjb21wbGV0aW9uIG9mIEJs b2Nrd2lzZSB0cmFuc2Zlcg0KPj4+IGRlcGVuZGVudCBvbiB0aGUgcHJvZ3Jlc3Mgb2Ygb2JqZWN0 IHNlY3VyaXR5Lg0KPj4gDQo+PiBObywgYXMgZmFyIGFzIHRoZSBDb1JFIFdHIGlzIGNvbmNlcm5l ZCwgYmxvY2std2lzZSBpcyBkb25lLg0KPj4gSXQgaXMgY3VycmVudGx5IGluIElFU0cgZXZhbHVh dGlvbiBhbmQgb24gdGhlIGFnZW5kYSBvZiB0aGUgMjAxNi0wNC0yMQ0KPj4gSUVTRyB0ZWxlY2hh dDsgTWF0dGhpYXMgS292YXRzY2ggaXMgdGhlIHNoZXBoZXJkLg0KPj4gDQo+PiBHcsO8w59lLCBD YXJzdGVuDQo+PiANCg0K From nobody Tue Mar 29 05:18:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4712D75F for ; Tue, 29 Mar 2016 05:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5t_bn0N2X1ow for ; Tue, 29 Mar 2016 05:18:22 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B712E12D75C for ; Tue, 29 Mar 2016 05:18:21 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud6.xs4all.net with ESMTP id boJL1s00d4VN29601oJLDg; Tue, 29 Mar 2016 14:18:20 +0200 Received: from 2001:983:a264:1:98c9:ca61:9568:1397 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 29 Mar 2016 14:18:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Mar 2016 14:18:20 +0200 From: peter van der Stok To: Hannes Tschofenig Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <56F94446.7040900@gmx.net> References: <56F91A0A.5060804@gmx.net> <56F922F2.9060203@tzi.org> <56F94446.7040900@gmx.net> Message-ID: X-Sender: stokcons@xs4all.nl (Kd9t+Oyovm0/7YU6zyD/xYWIcDYaBZvt) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 12:18:23 -0000 +1 Peter Hannes Tschofenig schreef op 2016-03-28 16:48: > Thanks, Carsten. This has helped me a lot since I have not been > following the patch debate. It sounds like a challenging task to > predict > the completion date of draft-vanderstok-core-etch. > > I would certainly appreciate if the RD document gets leaves the working > group at latest end of May. > > On 03/28/2016 02:26 PM, Carsten Bormann wrote: >> The question is simply whether we will be able to finish adding the >> PATCH methods to CoAP (see draft-vanderstok-core-etch) on the same >> timeline as the time needed for completing the RD document. Some of >> us >> are optimistic that this is possible, some think the way to use PATCH >> with RD should be added as a separate document. But for the >> discussion >> of the functionality of the RD, it makes sense to keep the PATCH >> functionality in context, assuming we can always take out section 5.6 >> even at a late stage if we run into a problem with PATCH. >> That's why it is part of -07. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 29 06:08:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A75012D7D7 for ; Tue, 29 Mar 2016 06:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y02ch5ntHiPn for ; Tue, 29 Mar 2016 06:08:05 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A92412D17A for ; Tue, 29 Mar 2016 06:08:05 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud6.xs4all.net with ESMTP id bp831s01R4VN29601p836Q; Tue, 29 Mar 2016 15:08:03 +0200 Received: from 2001:983:a264:1:98c9:ca61:9568:1397 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 29 Mar 2016 15:08:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Mar 2016 15:08:03 +0200 From: peter van der Stok To: Hannes Tschofenig Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <56F91A0A.5060804@gmx.net> References: <56F91A0A.5060804@gmx.net> Message-ID: <5ce8ad7619979857b2921c2f9c784070@xs4all.nl> X-Sender: stokcons@xs4all.nl (1exxNpcG3IEtMvT/Y0UPHmz+dnx1eO1J) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 13:08:12 -0000 Hi Hannes, thanks for the comments, see below. Hannes Tschofenig schreef op 2016-03-28 13:48: > Hi all, > > I reviewed draft-ietf-core-resource-directory-07 and I have a few > comments/questions. > > Another example: DNS-SD is described in the document and the reference > to DNS-SD is normative. Do I need to implement the DNS-SD part for an > RD > implementation to claim conformance to this specification? Good question. I think the extra attributes of section 8 are part of the implementation. The DNS-SD mapping that uses them can be RECOMMENDED. > > ** Terminology: Installation tool vs. Commissioning Tool > > Section 4.2 talks about the 'installation tool' and Appendix 12.1 calls > it 'Commissioning Tool'. I think it would be good to define the term in > Section 2 and then use the same term throughout the document. > > Section 6.1 talks about a 'a management entity' even though I am not > sure it refers to the same concept as an 'installation tool' or a > 'Commissioning Tool'. Later in Section 6.1 the term 'Manager' is used. YEP, good catch. > ** Register a Group > > Section 6.1 talks about ways to create a group and it says: > > " > Configuration of the endpoints > themselves is out of scope of this specification. Such an interface > for managing the group membership of an endpoint has been defined in > [RFC7390]. > " > > What type of configuration is outside the scope? Managing group membership and their MC addresses. > > ** Lighting Installation Example > > Why does this example talk about DNS? Is it possible to split the > example into two parts, one where DNS-SD is used and another one where > it isn't used? > > Additionally, I have been told that luminaries in a commercial building > are installed and commissioned before a network is up and running. The example tries to remove any suspicion that it describes the one and only way of setting up. The purpose is to show a number of aspects. > > I think that the lighting example could show the group concept quite > nicely and that's what it should focus on. How is the group concept in the example unclear? About a year ago you started the discussion about the the scope of the example, but regrettably we did not come to a conclusion. For the moment I really want this RD going to its conclusion. Do you think the example would benefit when sections 12.1.1 and 12.1.3 are removed? That can be done rather quickly. Nevertheless, I will regret removing the part of the example describing the use of the ins and exp format attributes, because at the moment of writing there was a strong wish for it, but I can live without that part of the example. Peter From nobody Tue Mar 29 06:21:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C2B12D1AB; Tue, 29 Mar 2016 06:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_ZYqxmmNgog; Tue, 29 Mar 2016 06:21:32 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id C07D712D7ED; Tue, 29 Mar 2016 06:21:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQDUgPpW/wQXEqxdgmKBH326dgENgXAXAQmFbAKBYxQBAQEBAQEBgQuEQQEBAQMBAQEBawsFCwsHBgEDAwECFhIHJx8JCAYKAQgbiAQWrwcBAQGRRQEBAQEBAQEBAQEBAQEBAQEBAQEBFoR0Z4UGhCU4DRKCCUsYgisFhV2IHzuJNYFShxKCbIQdhE2IWoYSiH0eAQGCQAUZgVFkAYh5AQEB X-IPAS-Result: A2DPAQDUgPpW/wQXEqxdgmKBH326dgENgXAXAQmFbAKBYxQBAQEBAQEBgQuEQQEBAQMBAQEBawsFCwsHBgEDAwECFhIHJx8JCAYKAQgbiAQWrwcBAQGRRQEBAQEBAQEBAQEBAQEBAQEBAQEBFoR0Z4UGhCU4DRKCCUsYgisFhV2IHzuJNYFShxKCbIQdhE2IWoYSiH0eAQGCQAUZgVFkAYh5AQEB X-IronPort-AV: E=Sophos;i="5.24,410,1454956200"; d="scan'208";a="68787610" In-Reply-To: <56F6BB11.5050808@tzi.org> References: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org> <56F6BB11.5050808@tzi.org> To: Carsten Bormann MIME-Version: 1.0 X-KeepSent: 94E0AA30:CBE7A9DD-65257F85:0044BAD9; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Tue, 29 Mar 2016 18:51:23 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF528 | October 8, 2015) at 03/29/2016 18:51:24, Serialize complete at 03/29/2016 18:51:24 Content-Type: multipart/alternative; boundary="=_alternative 00495EB365257F85_=" Archived-At: Cc: trac+core@zinfandel.tools.ietf.org, core , core@ietf.org Subject: Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 13:21:34 -0000 This is a multipart message in MIME format. --=_alternative 00495EB365257F85_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The ongoing work on CoAP over Websockets will be really useful so far as = running CoAP in an enterprise network (with firewalls having port = filtering) is concerned. Websocket does not add too much overhead as well. = Running CoAP on TCP in the enterprise scenario still needs to raise = special request to the network administrator to open ports. So, would = really like to see the CoAP on Websocket work to mature. = Is there any implementation available for this = draft-savolainen-core-coap-websockets-06 please? = The "CoAP on TCP" and "CoAP on Websocket" both fundamentally solve the = problem of running CoAP on reliable transport. So both work should = progress in tandem. May be it can be viewed like "CoAP over TCP" forming = the generalization while "CoAP over Websocket" becoming a specialization = with version determination and payload length identification off- loaded = to Websocket mechanism. May be, the scenario of huge data transfer becomes = a special case which gets well handled by the Websocket variant keeping = the TCP-only variant less complicated. = Regarding the reported results on block-wise transfer on TCP, I am = assuming that both end points were connected over an all-TCP transport. In = block-transfer the application layer flow-control mechanism makes every = block transfer a closed loop exchange. That contributes to the overall = latency as well. While running on TCP-only transport probably we can do = away with the application layer flow control mechanism and make the block = transfers completely open-loop (NON + No-Response ?). (And BERT relieves = us a bit on the fragment size constrains). The last block (M=3D0) should = trigger a response from the server indicating the state of the request = execution (assuming a PUT/ POST). However, not sure if block-wise transfer will be required for a TCP-only = transport between the end-points. However, the following statement should have been modified a bit. = >> Of course, we may not need to use Block Transfer in CoAP when we = already use CoAP over TCP. It may be relevant when we have all through TCP. Of course block-mode will = be required with the TCP variant of CoAP in order to talk to the classical = CoAP (I mean RFC 7252) end-point with constrains as nicely mentioned in = section 4.1 of draft-ietf-core-coap-tcp-tls-01. = Sorry if I have missed anything due to lack of attention to the chain of = discussions on these topics. = Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: Carsten Bormann To: trac+core@zinfandel.tools.ietf.org Cc: core@ietf.org Date: 03/26/2016 10:09 PM Subject: Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding = Approach Sent by: "core" > We have not taken the performance aspect of larger file transfers = (e.g., > transfer of a 4MB firmware update) into account when we made the > solution decision in Yokohama. The reason why the OIC/OCF take such > large file transfers into account is because of their desire to use = CoAP > also for non-constrained devices. Actually, we did discuss larger transfers in Yokohama (although the word "performant" only occurs once in the minutes, specifically where Matthias reported on the IoTivity work). The understanding was that an extension to -block like draft-bormann-core-block-bert would reduce the performance gap between a 16-bit (L1) and a 32-bit length (L3), if needed. The sentiment in the room was a bit against creating a dialect of CoAP with much larger payload sizes than the ones recommended in section 4.6 of RFC 7252, but we didn't really have much input on this to work from. So this particular question really reduces to: Should CoAP be extended to provide payload sizes well over 64 KiB over TCP, TLS? (The Websockets framing already provides the capability, up to 16 EiB.) Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 00495EB365257F85_= MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,
The ongoing work on CoAP over Websoc= kets  will be really useful so far as running CoAP in an enterprise network (with firewalls having port filtering) is concerned. Websocket does not add too much overhead as well. Running CoAP on TCP in the enterprise scenar= io still needs to raise special request to the network administrator to open ports. So, would really like to see the CoAP on Websocket work to mature.

Is there any implementation available for this draft-savolainen-core-coap-websockets-06= please?

The "CoAP on TCP" and &quo= t;CoAP on Websocket" both fundamentally solve the problem of running CoAP on reliable transport. So both work should progress in tandem. May be it can be viewed like "CoAP over TCP" forming the generalization while "CoAP over Websocket" becoming a specialization with version determination and payload length identification off- loaded to Websocket mechanism. May be, the scenario of huge data transfer becomes a special case which gets well handled by the Websocket variant keeping the TCP-only variant less complicated.

Regarding the reported results on bl= ock-wise transfer on TCP, I am assuming that both end points were connected over an all-TCP transport. In block-transfer the application layer flow-control mechanism makes every block transfer a closed loop exchange. That contribut= es to the overall latency as well. While running on  TCP-only transport probably we can do away with the application layer flow control mechanism and make the block transfers completely open-loop (NON + No-Response ?). (And BERT relieves us a bit on the fragment size constrains). The last block (M=3D0) should trigger a response from the server indicating the state of the request execution (assuming a PUT/ POST).
However, not sure if block-wise tran= sfer will be required for a TCP-only transport between the end-points.

However, the following statement sho= uld have been modified a bit.
>> Of course, we may not need to use Block Transfer in CoAP when we already use CoAP over TCP.
It may be relevant when we have all through TCP. Of course block-mode will be required with the TCP variant of CoAP in order to talk to the classical CoAP (I mean RFC 7252) end-point with constrains as nicely mentioned in section 4.1 of draft-ietf-core-coap-= tcp-tls-01.  

Sorry if I have missed anything due to lack of attention to the chain of discussions on these topics.
 
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________



From:     =    Carsten Bormann <cabo@tz= i.org>
To:     &n= bsp;  trac+core@zinfandel.tools.i= etf.org
Cc:     &n= bsp;  core@ietf.org
Date:     =    03/26/2016 10:09 PM
Subject:   &nbs= p;    Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach
Sent by:   &nbs= p;    "core" <core-bounces@ietf.org>



>  We have not taken the performance aspect of larger file transfers (e.g.,
>  transfer of a 4MB firmware update) into account when we made the
>  solution decision in Yokohama. The reason why the OIC/OCF take such
>  large file transfers into account is because of their desire to use CoAP
>  also for non-constrained devices.

Actually, we did discuss larger transfers in Yokohama (although the word
"performant" only occurs once in the minutes, specifically where<= br> Matthias reported on the IoTivity work).  The understanding was that an
extension to -block like draft-bormann-core-block-bert would reduce the
performance gap between a 16-bit (L1) and a 32-bit length (L3), if
needed.  The sentiment in the room was a bit against creating a dialec= t
of CoAP with much larger payload sizes than the ones recommended in
section 4.6 of RFC 7252, but we didn't really have much input on this to
work from.

So this particular question really reduces to:  Should CoAP be extende= d
to provide payload sizes well over 64 KiB over TCP, TLS?  (The
Websockets framing already provides the capability, up to 16 EiB.)

Gr=FC=DFe, Carsten

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

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 00495EB365257F85_=-- From nobody Tue Mar 29 07:02:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2037812D80E for ; Tue, 29 Mar 2016 07:02:09 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SryB97QdtSpF for ; Tue, 29 Mar 2016 07:02:07 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 E1DB212D18C for ; Tue, 29 Mar 2016 07:02:06 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id tt10so14255230pab.3 for ; Tue, 29 Mar 2016 07:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W7gxzdG9ertuqJQ58WWaZxQo1ACNKs9T6OKD2q3lWFY=; b=ZN97B38PpwPDn3K8CEJUly9JMvq/80K++VIzurHgXHnpBIFaDcb/Oj1yWUdJMCJj6u OK4HbNB+l2HDFqoKCy4F5jvgUJDuE8c4er4Rrqv/3bJxpj36loPlKxokUqtZm2oHDVC1 wfixwz2ltl1RSnTvZdq+bZILjA0ecaDlcxSCBmICKHcBDAjnhxyUEntar8H7gAhGa1Cc qS/JHstHnsqzPSGm8/ezemGU1qkQ2Jzn3DBrpu364BU+M9xlJcCv3Nx6bt8RoNRZC1Cs AKBvuG6XXnUoNelLrip97sK7Yh4qPBe1Xe4N3BccXHdIbQfm+MWBTkTuQ5iawywdq/iH YDmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W7gxzdG9ertuqJQ58WWaZxQo1ACNKs9T6OKD2q3lWFY=; b=CyyZWE4bpIMQJsXhFbnLwda5T0qHNwMopkt2uH4K2SpHZyBw/+2iniDfnfuY46nqpS m1pGQULb+fYuHm40aFyrcqujL6xNRNUZjICzMM84m6MztFFixSTwJmaxp/RMjBlgpAs7 d+Y11n1K5piYbWa0PPwXMEBorjfJ8dDA53fwDaUxQ4lOuZI2h52zpbcOadoCJpCSX5Og GmfEg+y6TrUaRHAL+YyWLzcoQObTwhYxB3AZloGhcPHG6PchxXUVhuuWbbTRLWU9YBmG xWZqggudnNc3wZre/b0U/vAW/MilLAUM68ZAIS0+CrfsnTzwZ3eMz1Da8Amo70FVN4Gc 5A4A== X-Gm-Message-State: AD7BkJJXffaG4ErCzyi4Wm4OrUvzHrQdNPZv+atBAX1pW1ZOeGt6nyO9d+e7dEFNFPLoUQ== X-Received: by 10.66.100.228 with SMTP id fb4mr3674780pab.84.1459260126506; Tue, 29 Mar 2016 07:02:06 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id w20sm43601671pfi.31.2016.03.29.07.02.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 07:02:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Tue, 29 Mar 2016 07:02:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39F355FB-8696-42B2-A598-1B478C74AFD2@gmail.com> References: <56F2AD00.7010407@gmx.net> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-koster-core-coap-pubsub-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 14:02:09 -0000 Hi Peter, Does it make sense to add support to pubsub for the requirements in the = sleepy node draft? It doesn't seem to be that much different. Most of = what's needed is incremental: 1. Discovery of registered topics on a broker by reading in = /well-known/core=20 2. Auto-registration of topics from the broker to an RD (already can be = done using RD pull mode by sending the RD an empty post if the links are = already in .well/known core) 3. Only allow the endpoint that registered links to publish - is this = really needed? I didn't see an obvious use case or story presented in = the sleepy node draft. if so, is it not a security issue as well as a = protocol question?=20 4. Describe separate roles in the architecture for registering, = discovering, reading, configuring, and communicating. Good idea. 5. Queueing messages to sleepy nodes; inform a sleepy node about pending = data by sending links in the response payload of a PUT/POST from the = sleepy node - This may require some fundamental changes to the way some = CoAP servers work, but it seems theoretically possible to return a = payload on PUT and POST within CoAP specifications. If you are not planning to take the sleepy node draft to standards = track, pubsub could be a reference implementation. We already have 2 = implementations of pubsub that I know of, and inquiries on other work in = progress. We may also be able to evaluate these additions with the = existing implementations. Best regards, Michael > On Mar 23, 2016, at 8:48 AM, peter van der Stok = wrote: >=20 >=20 >> PS: What is the relationship to the draft-zotti-core-sleepy-nodes-04? > We wrote sleepy node draft to show that pubsub does not cover all = sleepy node aspects. > Secondly, I think that pubsub should be developed independent of = sleepy node requirements >=20 > Peter >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Mar 29 07:44:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7212D88C for ; Tue, 29 Mar 2016 07:44:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 oVDYj1HVaSI8 for ; Tue, 29 Mar 2016 07:44:15 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 EA0E812D890 for ; Tue, 29 Mar 2016 07:44:14 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id x3so15802361pfb.1 for ; Tue, 29 Mar 2016 07:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=crnTJ4sLuh/lpXG5b9utF9vekzjfVIhqw2Iwrn2vWjc=; b=X26LZDRz8OJ+gCiWrX9pG8n3ocQ86aESSuJBSVTxvYmSv6RgpQJn59F/1LRBIEjLHu FNrDHGqKUFlK5U3GNzPnqqcwGX/yGWRLfcFowGSEgcLPk6gcmy0qDxYMhfUO1oodLtXj +fC3lMiQIEe7mkAZ6l16hnW3rmBMR/3Vp4JZJjQAtPI/eHBlpZz6efzNcsUjh30wGffM 5t1LNp/W5iDbmPY9pEy6Sxb9BzuNTu345Tjrpn53r8bDgKxnjYtmqQiSRje1YbDlGip9 +162NYzdOjhvDkM9dePAbtpYxMiEVNjrPzRTbeAq8+4F57/1rpso1Dg5O7OKdeL9a+ou 9spA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=crnTJ4sLuh/lpXG5b9utF9vekzjfVIhqw2Iwrn2vWjc=; b=TO9XuLcvjmiGRljGWNZHjPLkgJ8v72pgjMKpL8zBY/vvh8bHiBQukfuv73g1qBEfIj ObdVbHbIBoOrQwZQFT7gISohpODjQXtO//fuTtfIS6lQdOEnjdsLuyK15/H0d9BVjyuo his46h8rBS9zEjDfLH4SB3FQioXMYzeNgK3axoQt38hsH2uhh8tOKMWZC2MOUluK5aRU cDU9N+5tWhtfbkGZXKGt+Qs3ZtX3wj1nXxoHNbxKoXf9Ke68aAG0UDIUHmIQtWi5tgIQ HMhceMs4VflaawZTu8Nf14r0ZT6RchDljtObjX4mDvRcdJnRP9yNzEVTiHsrP+aSPSci PNNA== X-Gm-Message-State: AD7BkJJsIgKCwti646WmhCLChtqWp+OnU1M/MZTtaPgi43A2okMF0HIBrKTvjanzhfGdWw== X-Received: by 10.98.13.216 with SMTP id 85mr3946859pfn.143.1459262654534; Tue, 29 Mar 2016 07:44:14 -0700 (PDT) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id z13sm43814736pfi.5.2016.03.29.07.44.13 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 07:44:13 -0700 (PDT) From: Michael Koster Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 29 Mar 2016 07:44:12 -0700 To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [core] CoRE Interfaces draft roadmap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 29 Mar 2016 14:44:17 -0000 Hi, I would like to summarize the current state of the CoRE Interfaces draft = and start discussion on coming up with a roadmap for this draft. The bulk of the CoRE Interfaces draft describes a set reusable interface = types, which are meant to be used a a hypermedia control to define = resource structure and behavior, independently of the media types a = resource may expose. Many of the defined interfaces are collection types, and there is a = general description of collections and details on how the different = specified collection types work. The draft also defines the concept of link binding, which is a way to = create a hyperlink from one resource to another for automatically = communicating asynchronous state updates.=20 The defines a set of resource observation and notification controls = (pmin, pmax, lt, gt, and st) that enable an observince client or binding = to specify filter conditions for asynchronous notification using observe = or link bindings. Additionally, the draft defines the consept of a RETS API function set, = and proposes a function set definition style using URI templates and = WADL. This draft is being reorganized to clearly separate three main areas, 1. = interface definitions and collections, 2. Observation and notification = including link bindings, and 3. Function set definition. It has been proposed to separate the 3 main areas into separate drafts. Observe, notifications, and binding: OMA LWM2M normatively uses the notification attributes, and we have = taken a lot of effort to align this section with LWM2M, also making a CR = to LWM2M in the process. There is some ongoing development around link = bindings and extending the obeserve attributes with another use case = that requires 3 new optional attributes. Interfaces and collections: OCF (used to be OIC) borrows heavily from this draft. Their resource = model is based on interface types and uses the terminology from this = draft. Their implementation is considerably different, and is still in = the process of being developed. We could work with the OCF and converge = the interface and collection definition to include OCF collection types, = and influence the OCF collection types to be aligned with the eventual = RFC. Function sets: This concept was reused to some extent in Resource Directory and CoAP = Pubsub drafts to specify how functions like registration, publish, = subscribe, etc are mapped to a REST API. There seems to be confusion = about whether this is some formal methodology and how useful it is. Do = we want to propagate another conceptiual abstraction around REST APIs, = particularly as this is not well aligned with the T2TRG work on REST = APIs. I think it might be a good idea to do the following: 1. Focus the interfaces draft exclusively on interfaces and collections, = and make it clear that this is not the IETF officialy endorsed way to = use REST. Build compatibility with OCF collections to the most = reasonable extent, otherwise, try to fnid best practice guidance.=20 2. Create a separate draft to describe observe attributes and = notification control. Get OMA to refer to this draft for their = notification attributes. Keep it simple and focused. 3. Tone down the formality of function set definition and remove the = perception that CoRE Interfaces defines REST function sets. Instead, = find some descriptive language that accomplishes the same thing in RD, = Pubsub, Interfaces, and other drafts that want to define REST API = profiles for mapping functions. Best regards, MIchael From nobody Wed Mar 30 04:55:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630CE12D667 for ; Wed, 30 Mar 2016 04:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AO_9WKqGjKeP for ; Wed, 30 Mar 2016 04:55:54 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4008D12D676 for ; Wed, 30 Mar 2016 04:55:44 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud6.xs4all.net with ESMTP id cBvi1s00s4VN29601BviwV; Wed, 30 Mar 2016 13:55:42 +0200 Received: from 2001:983:a264:1:c423:5de4:f16a:c161 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 30 Mar 2016 13:55:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 30 Mar 2016 13:55:42 +0200 From: peter van der Stok To: Michael Koster Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <39F355FB-8696-42B2-A598-1B478C74AFD2@gmail.com> References: <56F2AD00.7010407@gmx.net> <39F355FB-8696-42B2-A598-1B478C74AFD2@gmail.com> Message-ID: <5aab6070c8251de36883cfb785b4fa54@xs4all.nl> X-Sender: stokcons@xs4all.nl (E7JH0rKMG4904Gg295r0bqqciP4jJKOe) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-koster-core-coap-pubsub-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 11:55:57 -0000 Hi Michael, Not sure what you mean. Do you mean additions to the pubsub draft that are sleepy node focussed? Or do you mean references from sleepy node draft to pubsub draft to show how pubsub could be used in the sleepy node context. Teresa and I intended to do the latter once the pubsub draft became stable. Peter Michael Koster schreef op 2016-03-29 16:02: > Hi Peter, > > Does it make sense to add support to pubsub for the requirements in > the sleepy node draft? It doesn't seem to be that much different. Most > of what's needed is incremental: > > 1. Discovery of registered topics on a broker by reading in > /well-known/core > 2. Auto-registration of topics from the broker to an RD (already can > be done using RD pull mode by sending the RD an empty post if the > links are already in .well/known core) > 3. Only allow the endpoint that registered links to publish - is this > really needed? I didn't see an obvious use case or story presented in > the sleepy node draft. if so, is it not a security issue as well as a > protocol question? > 4. Describe separate roles in the architecture for registering, > discovering, reading, configuring, and communicating. Good idea. > 5. Queueing messages to sleepy nodes; inform a sleepy node about > pending data by sending links in the response payload of a PUT/POST > from the sleepy node - This may require some fundamental changes to > the way some CoAP servers work, but it seems theoretically possible to > return a payload on PUT and POST within CoAP specifications. > > If you are not planning to take the sleepy node draft to standards > track, pubsub could be a reference implementation. We already have 2 > implementations of pubsub that I know of, and inquiries on other work > in progress. We may also be able to evaluate these additions with the > existing implementations. > > Best regards, > > Michael > >> On Mar 23, 2016, at 8:48 AM, peter van der Stok >> wrote: >> >> >>> PS: What is the relationship to the draft-zotti-core-sleepy-nodes-04? >> We wrote sleepy node draft to show that pubsub does not cover all >> sleepy node aspects. >> Secondly, I think that pubsub should be developed independent of >> sleepy node requirements >> >> Peter >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 30 05:27:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C544612D718 for ; Wed, 30 Mar 2016 05:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jUDPvRpnZ7hJ for ; Wed, 30 Mar 2016 05:27:01 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39C912E1C6 for ; Wed, 30 Mar 2016 05:19:48 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud6.xs4all.net with ESMTP id cCKm1s00d4VN29601CKmqf; Wed, 30 Mar 2016 14:19:47 +0200 Received: from 2001:983:a264:1:c423:5de4:f16a:c161 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 30 Mar 2016 14:19:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 30 Mar 2016 14:19:46 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <4a4ce267870454a5cfed45ffdd39ff90@xs4all.nl> X-Sender: stokcons@xs4all.nl (+9ysHX3NxGWZxQzI1aRY0kVfFvmCryka) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] core management topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 12:27:04 -0000 Hi Carsten, I saw that the objective of the management topic is the definition of new steps. Andy and I are quite ready to present (5-10 mins) the adaptations we did to the comi draft, given the recommendations of ietf94. It will be difficult to explain all current documents for this topic, their overlap, and purpose in one single talk. Can you do suggestions to proceed such that the WG can do some recommendation on the future progress. It will be nice to receive a clear signal from the WG on this subject (continuation and how). Greetings, Peter -- From nobody Wed Mar 30 05:51:18 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4904212E216 for ; Wed, 30 Mar 2016 05:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Sstql7sDrmKg for ; Wed, 30 Mar 2016 05:51:15 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF23712D6F0 for ; Wed, 30 Mar 2016 05:40:12 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud6.xs4all.net with ESMTP id cCg91s02n4VN29601Cg9K5; Wed, 30 Mar 2016 14:40:09 +0200 Received: from 2001:983:a264:1:c423:5de4:f16a:c161 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 30 Mar 2016 14:40:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 30 Mar 2016 14:40:09 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (mR0zykcF0za6ZL1h9jtr+yvyWNtoJDrw) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 12:51:17 -0000 Hi Michel et al, I find the current representation of the SID rather confusing, both within the examples as the CBOR encoding. The numeric values serving as YANG identifier are represented as differences with respect to a hierarchical higher value. It would be more clear if the operator aspect was shown in the examples: e.g. +15 instead of 15. It is not clear to me why the operation is with respect to the parent schema node. Could it not just be the former identifier? Efficiency considerations may then indicate a reordering of the nodes, but that is not prohibitive for the handling of the contents. From the above you may understand that I do not like misusing the "integer" type in CBOR to annotate Delta's. It makes the interpretation of the CBOR types application dependent, and I don't think that is a good direction to go. My recommendation is to develop a new CBOR element to denote the deltas. Greetings, Peter From nobody Wed Mar 30 06:13:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6689012D6DF for ; Wed, 30 Mar 2016 06:13:34 -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 7HYylzpKtWSo for ; Wed, 30 Mar 2016 06:13:32 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8022012D0C1 for ; Wed, 30 Mar 2016 06:01:46 -0700 (PDT) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B874B41C093; Wed, 30 Mar 2016 15:01:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8S_-o5jYmqB8; Wed, 30 Mar 2016 15:01:43 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0222D41C0CA; Wed, 30 Mar 2016 15:00:42 +0200 (CEST) Message-ID: <56FBCDF9.4040106@tzi.org> Date: Wed, 30 Mar 2016 15:00:41 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: consultancy@vanderstok.org References: <4a4ce267870454a5cfed45ffdd39ff90@xs4all.nl> In-Reply-To: <4a4ce267870454a5cfed45ffdd39ff90@xs4all.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] core management topic X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 13:13:34 -0000 Hi Peter, I have asked the cool people what they want to do. I think the focus should be on what we have in common, and whether we can have a clean base on which hash and sid are a minor divergence in the way of identifying things, that actually can work well together. We need to find out at this meeting what the WG documents should be, going forward. (The charter process supporting this still isn't completed, but at least we already have enough yes positions to progress, just waiting for six more positions, and an IESG telechat date on 2016-04-21, which is going to be a very full agenda, so there will be little frivolous tinkering.) Oh, and we need to take some time in the hallways to convince our new responsible AD Alexey that COMI/COOL is the bee's knees. Grüße, Carsten peter van der Stok wrote: > Hi Carsten, > > I saw that the objective of the management topic is the definition of > new steps. > > Andy and I are quite ready to present (5-10 mins) the adaptations we did > to the comi draft, given the recommendations of ietf94. > > It will be difficult to explain all current documents for this topic, > their overlap, and purpose in one single talk. > Can you do suggestions to proceed such that the WG can do some > recommendation on the future progress. > > It will be nice to receive a clear signal from the WG on this subject > (continuation and how). > > Greetings, > > Peter > > From nobody Wed Mar 30 07:07:04 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7268412D154 for ; Wed, 30 Mar 2016 07:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.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 18f_hrcy8INO for ; Wed, 30 Mar 2016 07:06:50 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E3112D6B8 for ; Wed, 30 Mar 2016 07:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QxnqZ/l/ygzSeNmT02suNF4xAxnVsQdBwhPVesY6WlM=; b=EQ2t3wYy9RrdIf7+uU2/7/XWzEyq4oK1t4mUI5l3HZGa0fb9r7GvAwTENr9qf/LBUTi6ZMc+yREfpD+4OjDd1QGe8FTHsgwMLCrtGPeHjEwmjlRLogHrutBmiQUowc1Aju9gsrbUBKof+KJnpwDnYpJbh9iH/y45FvgBYeYS6cE= Received: from VI1PR06MB1839.eurprd06.prod.outlook.com (10.165.237.157) by VI1PR06MB1838.eurprd06.prod.outlook.com (10.165.237.156) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 30 Mar 2016 14:06:22 +0000 Received: from VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) by VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) with mapi id 15.01.0447.024; Wed, 30 Mar 2016 14:06:22 +0000 From: Somaraju Abhinav To: Core , "consultancy@vanderstok.org" Thread-Topic: [core] COOL SID representation Thread-Index: AQHRioLe5GqMa+RWbUu/bcg3J5tLN59yA8E0 Date: Wed, 30 Mar 2016 14:06:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tridonic.com; x-originating-ip: [132.245.226.21] x-ms-office365-filtering-correlation-id: 6aa62a91-5fd3-43f3-534b-08d358a4793d x-microsoft-exchange-diagnostics: 1; VI1PR06MB1838; 5:0zOpYyUjIyDUeVE7Fm2a9WEZaAFot3xUQ8QeIx3eMsYUOMqcvOtTOw3ecBBmF23fvFf6vqbaiY+jY4uC6xnD8JZ8P0Z3xgUz/Br7Mcdsxe7v8obbgwki4bgWvdT/gm6WRSKmF4XMij9lg6S1zWH1GQ==; 24:Qi1ab0x3kGkX1uAdT+AYVDzIvHcCPqYTkie//6FA/YlrbD91RQOaegDMUDTLfP/9Yk1nI1Q2RUOSWmBolWlmsCvWDiwTCUSrEFZTfsYb7WA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1838; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1838; x-forefront-prvs: 08978A8F5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(77096005)(15975445007)(107886002)(5002640100001)(86362001)(11100500001)(5001770100001)(2950100001)(2900100001)(92566002)(5008740100001)(122556002)(19580395003)(19580405001)(10400500002)(66066001)(5890100001)(76576001)(2501003)(87936001)(2906002)(5003600100002)(102836003)(1220700001)(3660700001)(3846002)(6116002)(586003)(50986999)(74316001)(81166005)(3280700002)(33656002)(189998001)(106116001)(5004730100002)(54356999)(76176999)(1096002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1838; H:VI1PR06MB1839.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2016 14:06:21.9596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1838 Archived-At: Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 14:07:03 -0000 Hi Peter, please see comments inline. Regards, Abhinav _______________________________________ Hi Michel et al, I find the current representation of the SID rather confusing, both within the examples as the CBOR encoding. The numeric values serving as YANG identifier are represented as differences with respect to a hierarchical higher value. It would be more clear if the operator aspect was shown in the examples: e.g. +15 instead of 15. [AS] I am not sure I fully understand where you want +15 instead of 15. Cou= ld you please point out a line number in a document where this change might= help. It is not clear to me why the operation is with respect to the parent schema node. Could it not just be the former identifier? Efficiency considerations may then indicate a reordering of the nodes, but that is not prohibitive for the handling of the contents. [AS] The problem is here is with repeated deltas - if we use former values = to calculate deltas then we might get the same delta more than once when en= coding an object. CBOR keys can not be used to identify which element withi= n the object we are referring to unless we impose an order on the elements = within the object. From the above you may understand that I do not like misusing the "integer" type in CBOR to annotate Delta's. It makes the interpretation of the CBOR types application dependent, and I don't think that is a good direction to go. My recommendation is to develop a new CBOR element to denote the deltas. [AS] The content-format cool+cbor, clearly tells any application that the k= eys are delta encoded. I am not sure there is a need to add to an already p= ublished RFC considering any application can use this content-format option= to indicate that the keys are delta encoded. Greetings, Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. From nobody Wed Mar 30 07:15:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEAA12D6A1 for ; Wed, 30 Mar 2016 07:15:35 -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 MbV5Kp0U1c1y for ; Wed, 30 Mar 2016 07:15:33 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A573C12D0F3 for ; Wed, 30 Mar 2016 07:15:33 -0700 (PDT) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id CC018172097; Wed, 30 Mar 2016 16:15:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id I0AXb_Gm4hRS; Wed, 30 Mar 2016 16:15:30 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E3FC317211B; Wed, 30 Mar 2016 16:15:29 +0200 (CEST) Message-ID: <56FBDF7C.70004@tzi.org> Date: Wed, 30 Mar 2016 16:15:24 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Somaraju Abhinav References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 14:15:35 -0000 Somaraju Abhinav wrote: > [AS] The problem is here is with repeated deltas - if we use former values to calculate deltas then we might get the same delta more than once when encoding an object. CBOR keys can not be used to identify which element within the object we are referring to unless we impose an order on the elements within the object. That is not the only problem: maps are not order-preserving in CBOR (a property CBOR inherits from JSON). So "former" may not even be a meaningful concept within the set of keys in a map. So far, using the parent as the base for the delta is the best we've come up with. It also is very simple to implement, as in a given context the delta for a specific item is always going to be the same. Grüße, Carsten From nobody Wed Mar 30 10:01:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E0212D7F5 for ; Wed, 30 Mar 2016 10:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrZ2qUySp411 for ; Wed, 30 Mar 2016 10:01:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06C112D6E7 for ; Wed, 30 Mar 2016 10:01:17 -0700 (PDT) Received: from [192.168.10.140] ([179.9.22.47]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MXqaN-1aGM503vNP-00WpJ2 for ; Wed, 30 Mar 2016 19:01:14 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FC065C.4050404@gmx.net> Date: Wed, 30 Mar 2016 19:01:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3d5kkCchlggFkKatMjqdV12hItJG2mrXQ" X-Provags-ID: V03:K0:VPFgVTVPDnj+O2fPXC5r2tNNayzHMto8a2AhgL4pZLAapr/Jxdi eHqb1bKqJy9Rruqhy5sOjUuGkVi0bkdbwVPiIXZntgZh0dhP/iwWEFI46QGqIDG0QMODsHs yZyk1Gr4FfcAkjmovqIDxBwllte4HrNw2g0ekWXPB9xpDsukaWun9yL9hrI0T44I8BisWeB 76eSHlqIFeRrEkXzT1P5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:d6qAyCT0FaM=:GAfIp3YfXCv5T6Ol58wGBg ibSGc/IyrbRqj2HhXwKFM3qv/2XL/eRNUNq33kNNFrpW5aX/uzQ4VcCRosut9kTUcfSTDGIZt 95ZfgpYuW+btK/h9Hv8Fndykgkf3YTzJUjBbjmvTa/aGwdZ4VxWXC4y+Za/omGERgN9xiTrhx K/JtKRd1Luk+S7NmL9jIbYeKYYXDCBKyacLnqBPW5E3bUzyIFoewokaiAyk2B5eSjuGFeIMvb Hi5wQXKSXod4iAQdtqbFw9ckzRIAHN7VCc1C+PAYOmDY5saqfBhFjd18RnTv0JQRQ0uAyJ92F jfj8lXYwE5aYHFQzRq65Y2xzos20RzIz+Dq5Ba/mYxgxBoTLhwjwq74bo+3q0mImDr51+GMKp 7uvp4P2MSthEMcqeBurrHyATlvGBdFcyUi1fVwgglaPoAZvaCN54QtI2tnPSkmKLZ/tZoifUY Yzg7ZQuOMMh7rTZaPcvLJNw9K+DBSspIPYjrGYa8Y65t96Mh/ek1oskztuuDXMPGjWwnc6SZA hKNMcMnPiRUJjjBra/Gm2AG9JWxB68IGLyyE3y6YQFeMuSwvrkfnECO7A7ERqrgfTqFaeGfs4 GdgjVz7sNX7lhT6tVxvrvmXv8vsIXSVDAKlj9acpSMmwIXKvSKlQI7VtHHb6Lk969TYyjOZ0t 93DA0RoCcZKQFB4L37yA1SopS1buuTAlF4Ajtxr1JYSyRAoH0Ei8B+j99FivD31UhqmMjH+JT Dvouh2HLLuFy5Cr+GInHsZnwuQTEwkyJoSWNhJpqXTblgmJnvpN53CrIdvQ= Archived-At: Subject: [core] draft-ietf-core-interfaces-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 17:01:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3d5kkCchlggFkKatMjqdV12hItJG2mrXQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I read through draft-ietf-core-interfaces-04. Overall, the document raises a lot of questions and still needs lots of work. I wonder whether this work has been adopted as a WG item a bit too early in the process before enough experience has been gained with this type of functionality. From an interoperability goal point of view I believe this is exploring a territory, which I would call dynamic discovery. Learning meta-data about resources offered by an IoT device is already complex, particularly if one wants to do something with that data. Then, dynamically discovering the interaction model is even harder. The target audience for such a document are developers and, maybe even system architects, who need to first understand the value of this functionality. Currently, the document is IMHO only understandable to a small number of experts due to the way it is written. =46rom the recent IAB IOTSI workshop I am wondering whether other solutio= n approaches are also viable or even more desirable. For example, Matthias presented the HATEOS approach with https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf that seems (in my limited understanding) tries to accomplish the same goal. Michael described another approach in https://www.iab.org/wp-content/IAB-uploads/2016/03/draft-koster-t2trg-hyp= ertext-language-00.txt https://www.iab.org/wp-content/IAB-uploads/2016/03/Thing-Description-as-E= nabler-of-Semantic-Interoperability-on-the-Web-of-Things.pdf describes the approach from the W3C. While there is a lot of dynamic discovery happening without pre-configuration but in the end, as these workshop position papers illustrate, there is always some prior information that has to be assumed. What is the level of pre-configuration needed with this solution approach. =46rom a document status point of view this is a clear example of an Experimental RFC. I am also not sure whether there is a normative reference to SENML and whether WADL is the 'state-of-the-art' way to describe the structure. What is purpose of the WADL in this document: documentation, Code generation, testing? I wonder whether we could spent some time during the CORE WG session to discuss what goals we want to accomplish in the group regarding this work and how to approach the topic overall given the work that has been done so far. The suggestions Michael made in his status update to the CORE mailing list regarding splitting the current document and getting them aligned with the work in other organizations makes sense to me. Ciao Hannes --3d5kkCchlggFkKatMjqdV12hItJG2mrXQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/AZcAAoJEGhJURNOOiAtP00IAIe3ByMb0fhq489UE/KO8bF0 Y/pkreHmhLW2hTCo3JOhtaK0b8CkjQr9O8Zbysa+JwT2UQuPd77y4CTRrskkb9+f 0n9voRRz92bTdOY/20wZ4OyXD4iE6SfXclbFZeP/vhSuWfYIiicyKITr/ioUrMsW dZOZQFoZ/5dUnqK8t5BNAt1GJ+s4Nikw7bXcWc3MDBfXZ8ybN19G+XXKVVrzgqlS tjDJqj2scYj6jngQ/5iXOcSLGlLrp2pDqGE3LSY8417ADCXpJUJ9z+JFGCGBWoVD rcNNWoQnlibnrg1A0+Tup/4Dg3ssgcWfTsBsg/AF3Kc5fpZSNJUgxnbNKAbL59s= =TgpT -----END PGP SIGNATURE----- --3d5kkCchlggFkKatMjqdV12hItJG2mrXQ-- From nobody Wed Mar 30 10:01:44 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7174312D6E1 for ; Wed, 30 Mar 2016 10:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnHeT-JJp7gx for ; Wed, 30 Mar 2016 10:01:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E85512D7EC for ; Wed, 30 Mar 2016 10:01:26 -0700 (PDT) Received: from [192.168.10.140] ([179.9.22.47]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lp3sy-1a6lcG25My-00eppe for ; Wed, 30 Mar 2016 19:01:25 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FC0667.1000804@gmx.net> Date: Wed, 30 Mar 2016 19:01:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XdGVcuRCoRPu6PBsi6H2qS6Sf7Ev2XRaL" X-Provags-ID: V03:K0:ZWhfZdzargaP/g19H2FKOOSjSpgGUsKXYVQZ1LFgzmn3eAV0rpR Y1kvHILThqXkYflNP0qEVPilXsQzZ21OnSaEh70/iUXBjyq6uaVi1+DToOdz55nzRBATDA+ 6N/z6IrFMAKpo/+MFnKUFPvC4Zlbx2YiAkicBcq+xzCp/xGkItV3fV0uaBIBwOKe5ACkv9r VzQZbxeXYl+lF7H7N2XmA== X-UI-Out-Filterresults: notjunk:1;V01:K0:mhM9FvT2k6E=:XSvVm1c3WojtIqa4JbayXN wL2hGtIFnkCgJvXvRtS8gKgdwDrRL/ilyMbnYoqU57TR8HMcBCKpB1OgKQu34s4X23q+JsRla WcIhJ+SqkdF8iZmtNSE2CXFrVHGkhEJaNz01ylXrVeB62bA/e1mOBfT3ngnx1fSKLdBpLtT8a 24ypdojqbF6kZTp6x9djRG7cCgvzSI8pU9TutoppFJl7sXhvGodcIdgIJvwf9hlZ7NoIEL2rV YZ2MDXWMm53fsWORXE/amXv6Rq/KUo0yl5eFqlMpFrKtLWjXupgTdngR3xOHVMtdfMzdYdsgE TlCZoL4a1LwL63dCARae1FGadq2S/TxDyGXpDY+IAxeBY4gD25dbWJC6JiUNhaTLHIktNAWeY gL9LlCDwjCGrN4v1RY2jHabsUOKlc31yzckwC0qHW/1nprQ9w4Thk7x8L9FWuOMhbGhJX+J6F E6+Ei9ip39qDH/SnmFAjhGy4X/uY0/iRyvnpMPPXbkwwcPrP8y4miF3GKhXK8CXRnXLxF9vU3 YxRZ1JWLB+lqT6QN2rKUHY9Ja4V2hAjH5cA2j/qr8PeOokaXdkGpm0C1688RifngtBZl10dsZ RaKYpVNclsFGMLd/o7wuKhwxd1lfka5ydidfL6+t0cdaPdS/nTxs6XyXuJR0m5193TEVggZwa T4KGWbpYMHkB+k2shIqtHI2CWRwHSn0V7ToI3rcOc29RLcHF1MGRnc8/sONgBK7ec2wJFnFer Rvndcg3/RKBa1mZS2S3alKv200ENopNvcXJ0JJbSn5pyhNMJXXOVk3Z+dYs= Archived-At: Subject: [core] draft-ietf-core-links-json-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 17:01:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XdGVcuRCoRPu6PBsi6H2qS6Sf7Ev2XRaL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I read through draft-ietf-core-links-json-04. The document is conceptually fairly easy and I believe the document is in good shape. The core assumption of the document is that there is a need to encode the link formats in different formats, namely JSON and CBOR, rather than plain-text. I don't know whether this working assumption is a good idea since it will obviously reduce interoperability since now devices will suddenly have to deal with three different formats rather than just one. Additionally, the document contains mapping of the formats defined in RFC 7390 "Group Communication for CoAP" into CBOR. While this sounds reasonable the text somehow does not fit into this document. I personally would prefer if that text gets added to a revised version of the group communication draft instead. There are a few TODO's in the document: * Page 6 says "Is this the right list of attribute names?" and I wonder whether the attribute names actually matter that much. * Page 7 says "(more examples to be added.)". There are, however, plenty of examples in the document and so I was wondering whether this is line is just a left-over from past times. * The acknowledgement section is almost empty and I am wondering whether this is a reflection of the review status. If that's the case then the situation is not looking good. How strong is the support for this document? * The security consideration section also says TBD but since we are only defining alternative encodings of already existing functionality I cannot see additional concerns. * Page 13 states "Should the IP address/port number information be represented in a more compact way?". I am wondering whether this question hasn't surfaced already in other discussions about CBOR encoding= ? Additionally, since you are referencing the mapping rules from RFC 74049 I am not sure it makes sense to change those in this section. * Appendix A points to a simple reference implementation. That's a good idea. What is the status of it? I prefer that these TODOs are added to the issue tracker, if they are still valid. One additional remark: The document uses the term 'Information Model' and I wonder whether you would call CDDL an information modelling language. I prefer graphical representations, such as an UML class diagram or an entity relationship diagram since you are less likely to generate code form these simple structures. Since you brought CDDL again into the picture there is the obvious question about the status of CDDL. The structure described here is really simple and hence there is the question whether CDDL is needed at all. Ciao Hannes --XdGVcuRCoRPu6PBsi6H2qS6Sf7Ev2XRaL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/AZoAAoJEGhJURNOOiAtIIcH/RcgVWsPajrqxzJru3P/0FgZ Jp+xm3CinyH9rg2xXGL3eFd+TpM33d4NcLKAlpH/BImV+FSz37OWhXupJ2HmoxFn UQssacIz6TxkzWdzNXY4mN0YaMPRNWwJj1G/tnksB/sp3Sf19HOZAjH6nax2QMuk Bu7IrcHbTq61Nz6D3RP1fSYBwMRfZFWz1juQknJIZn9c0EaP7ItYw3A4cRWWq4/8 PgIYs14gWyPz5Sv19E1o66yfI4a2tXdnYvvj03BExzLMaJ647THiIICUTRwiJDv0 kXBcSjKbJgita4V+4OZ++BKcIXi4m2/82c11FBEMHYP4BabDy49+b9bep1vJVMU= =+xTN -----END PGP SIGNATURE----- --XdGVcuRCoRPu6PBsi6H2qS6Sf7Ev2XRaL-- From nobody Wed Mar 30 10:02:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0218E12D7EC for ; Wed, 30 Mar 2016 10:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WUPjBXOkgqQ for ; Wed, 30 Mar 2016 10:01:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A0F12D807 for ; Wed, 30 Mar 2016 10:01:38 -0700 (PDT) Received: from [192.168.10.140] ([179.9.22.47]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQ2zr-1ahkrD07Sl-005E2K for ; Wed, 30 Mar 2016 19:01:36 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FC0673.2020707@gmx.net> Date: Wed, 30 Mar 2016 19:01:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TUWqEMHCPi36tuJ2nDlb68Om0VfFfqBEM" X-Provags-ID: V03:K0:JsxPCbKl3lKrshjJLe1XdIa3O9dum/sYcRmo//bexSEbPWu2MUN ZCoxsmRR8S6uSFy91ggp6BJJtbT8RFj6uG/BqeLvr5WfSPl5eE9IMrXYCRbdQcN80c8i6qR Ov62Up0ZmOWSXD0s7oZ3z/v1itUBtQLyi+s4PoVQ2qlSa9+XyYMpw1JQN6EzW43XfYRVjvR QYaTun0EapygYU/WKKojQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:oURAkqucZno=:DIp7AmTkEd6gzFZgvy+goz Tlt+HcP08JDj8EIyXxLx7699g25/oZPUOn4t1EaK9gcBi7F8KsVm5Y2VKHszInodZXJV6F/B+ kW2nIYfvpr6L14CyqChKrbIbfQl41zgzlNKi86zGpGLxu8Jm+usjN1BRmzJN/evPF1mgR3Yhx +3DQFVd4xHrti/oSQg1HUSnGQ0BLtadtJk61wtNUHR5VEj5FBtyJ7S1IbGu6QGx9rdgQgqbpr pTsj/BarnIH49imDu312/GbQHfdPk65VxMRpO4q296dZcfab9f7J2Wli8lST0uiAx4q2f4Zyu NwKUhLGXP02P+mAVfVJgkTtJ0qz/KsNIzD2grqAQ/oM52hu+a5mcdBsjXm1gG2UH1NmcZMYJe PfNpsnWJ/KXdBOWBa52m6AfFDX29MFm5+mh16kzCE+37lrQC+q/fYY5uk8hn89jCMey2gYUW9 8YdAJopJbfhd9TP89aHR6zekgAbNUTIJ5pfPFxJD0xcmQC7mhpwDXmIA4evDJDKCiWZr8MOnI G9UEWCNmhFHys53Ah7nAwAZNzHXdnGedVAI0qDVC7fV3UZ6SKXZt1MXQxy9CT6K/0h+DraLFB ZdOrR5u85iZm+n52rtihe5LCafjkjyHHHmDztd2YVf54XtTklqxCh0jxqm1a0Q3i3x8ZrwH+Y Z3yhuxIpJEF8MXKUTwN3ccTWWcikuEdgnB5ahYV9tBwnY7fupMVdkLk0XLihOKucnSIiVcuWk OyzTlid2ybsmYJWmnRAyEvRM6mBXHhlgCeIVVh6DYvybZBHyiKDhW/LdtJ4= Archived-At: Subject: [core] CoAP over TCP: Extending the shim Header Payload X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 17:01:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TUWqEMHCPi36tuJ2nDlb68Om0VfFfqBEM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Klaus and I had a brief call yesterday to discuss his review in more detail. It became clear from his review comments that our current approach of offering a simple shim header with length information is insufficient. Various issues on the working group tracker reveal this pattern, as discussed on the mailing list. I would like to therefore suggest to change the shim header in the following way*: A command field that allows to differentiation the following types of payloads: - KEEPALIVE - MSG - ERROR - CONFIG The semantic is the following: a) MSG: This is the current header structure (minus the version field). The structure of this shim header is the same in the forwards and in the backwards direction. b) KEEPALIVE: Here we could exchange an empty payload or one that is similar to the TLS heartbeat. A KEEPALIVE exchange can be initiated by client as well as the server. The recipient must respond with a KEEPALIVE message back to the initiator. c) ERROR: This payload is sent in response to a MSG, KEEPALIVE or a CONFIG message. It indicates at least the following errors: - INVALID_LENGTH: Length information does not match the provided size. - PROTOCOL_VERSION: The protocol version the client has attempted to negotiate is recognized but not supported. - DECODE_ERROR: Any other parsing failure of the provided shim header. - UNRECOGNIZED_NAME: This error is sent in response to a SNI that isn't understood by the server. - UNEXPECTED_MESSAGE: An inappropriate message was received. This happens when the client or the server provide a message that does not match the expected message. d) CONFIG: This message could be structured similar to the ClientHello/ServerHello exchange offered by DTLS/TLS. The client initiates a CONFIG exchange and the server responds with a CONFIG message or returns an error. Subsequent to a CONFIG exchange MSG packets are exchanged unless the configuration information can be obtained via other means, such as via the use of TLS. The CONFIG message sent by the client to the server indicates the supported version and server name indication (and potentially other features) whereas the server only selects the version (or other features) from the client-provided list or returns an ERROR message instead. When TLS is used then this message is likely not needed since the functionality is already provided by TLS. How does this sound? Ciao Hannes PS: Funny enough I encountered a similar situation with a somewhat different protocol recently. I have been contributing to the FIDO Alliance U2F BLE specification where we also noticed that a simple length field as a shim is insufficient and then added protocol functionality for error messaging and a keepalive mechanisms. --TUWqEMHCPi36tuJ2nDlb68Om0VfFfqBEM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/AZzAAoJEGhJURNOOiAtufcH/iDDa1oGidqg5k8xHieKR9JF 3jbmpul2tdpBPjLVcFgMQI2eV97eVWudYTa1B+1VbprfQFby6whHiLUeR1mSrUQL 67TlsiDnFDFt01IiZe+OvAmfOh+RxYo+xyOQ+mT5NXhiikrQyiRi8/qeMdQm0IBo iXWlQRBvsmzRpX3PG4pV605li1VcGeQF2NjYRCG6zArci29iD4TpP4HuADibYKUS f3/EnV7RsX/vlbsueySCSBvf9R2s/R/oNUQrL6RYPL50GiyyF4exs6xdY+S3JT7g eEV0v0P8/P31XQ6TBIl+P/2R7vJkhYFrtnuWZvDzmkyzXsj6D+AtxB9Ib+g5OqY= =ynzM -----END PGP SIGNATURE----- --TUWqEMHCPi36tuJ2nDlb68Om0VfFfqBEM-- From nobody Wed Mar 30 10:06:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0F712D6E5 for ; Wed, 30 Mar 2016 10:06:05 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7ku2OIiMStZt for ; Wed, 30 Mar 2016 10:06:02 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 38E9312D5B8 for ; Wed, 30 Mar 2016 10:06:02 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 4so47688243pfd.0 for ; Wed, 30 Mar 2016 10:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oi4P7kVxJenM10D5JkhT2wuqjEc+9Nm/l3RSLGsWg6c=; b=nPqkR9QK3X9G0SUa5fEbTHRUNUr4ePT6uTkcX8eO41mBawsSkM6j5iTS7TdOFmLmG3 F9hP8IfXSon50GQLrQ/GOea/UBW4V5164qCnigeCtQ3UikHdibAbj5uOIXS77bkgNDkX uNStgDCoKgazBdek+uLGZzAoeAvl4HfUcCO3HEnOUb1g7vbiF0pmWl+PEceEk4+92mNe tfpfuVHKC3XMKvquI2N03LEU6Ukpp0A+z+3V1yrDo5uS2+X5h9mTjUY3TQr56daw5lDm zOYS+mzXXrTSi460OwRkQhcWoMjJZtSZMCPhyufuNolIsUcg5R6/7t58zAI2NJ9NnLLX CIbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oi4P7kVxJenM10D5JkhT2wuqjEc+9Nm/l3RSLGsWg6c=; b=m9uSuXOuSVLGdzqXLVFoM+3e91x9b0MEAsQoeLQb5vaeJnbhhAuLNCwn6y8/YaoE6m wGOgFCFWZc2XWnqY7EJVBGRWeoXuq3AUMdBXEafbGMhYYYx2YkKAwi3ufntr9rN7Cifj 6popVeLvBZRBugj/5gp+FtUihQa+ION2C6cOffda/8holQIIeQqqL6SbfUK/fplpnpU/ 3/eusQdtmNosI/sSXJbS/n4NTgHjiPAkIQpm2F7+y4qQ73DeBYxs2/40mDsn1Wzd4H3M uoqA9s5QsoiJKVABSyAdN/lnl5kPxMMoFSC6tJ5TrFpNlVgHaFFRRMtrlvJitt0jJPhv 4rPA== X-Gm-Message-State: AD7BkJLwFdtpJDa0FrzCR/Zl7ZMznJrxp+3mOpVOWbx6smgFS0DdRNbaCdCvEpcDXbDUlg== X-Received: by 10.98.73.142 with SMTP id r14mr14950723pfi.140.1459357561860; Wed, 30 Mar 2016 10:06:01 -0700 (PDT) Received: from [172.28.32.167] ([162.246.216.202]) by smtp.gmail.com with ESMTPSA id ll7sm7293412pab.6.2016.03.30.10.06.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 10:06:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <5aab6070c8251de36883cfb785b4fa54@xs4all.nl> Date: Wed, 30 Mar 2016 10:05:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F2AD00.7010407@gmx.net> <39F355FB-8696-42B2-A598-1B478C74AFD2@gmail.com> <5aab6070c8251de36883cfb785b4fa54@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-koster-core-coap-pubsub-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 17:06:05 -0000 Some of the use cases in the sleepy node draft may make sense to include = in the pubsub design. We could discuss each item listed and decide = whether it makes sense to add support in pubsub. We could get feedback = from implementers. Also, store and forward would be a better way than queueing to describe = delivery of a message to a sleepy node. Michael > On Mar 30, 2016, at 4:55 AM, peter van der Stok = wrote: >=20 > Hi Michael, >=20 > Not sure what you mean. > Do you mean additions to the pubsub draft that are sleepy node = focussed? > Or do you mean references from sleepy node draft to pubsub draft to = show how pubsub could be used in the sleepy node context. > Teresa and I intended to do the latter once the pubsub draft became = stable. >=20 > Peter >=20 >=20 > Michael Koster schreef op 2016-03-29 16:02: >> Hi Peter, >> Does it make sense to add support to pubsub for the requirements in >> the sleepy node draft? It doesn't seem to be that much different. = Most >> of what's needed is incremental: >> 1. Discovery of registered topics on a broker by reading in = /well-known/core >> 2. Auto-registration of topics from the broker to an RD (already can >> be done using RD pull mode by sending the RD an empty post if the >> links are already in .well/known core) >> 3. Only allow the endpoint that registered links to publish - is this >> really needed? I didn't see an obvious use case or story presented in >> the sleepy node draft. if so, is it not a security issue as well as a >> protocol question? >> 4. Describe separate roles in the architecture for registering, >> discovering, reading, configuring, and communicating. Good idea. >> 5. Queueing messages to sleepy nodes; inform a sleepy node about >> pending data by sending links in the response payload of a PUT/POST >> from the sleepy node - This may require some fundamental changes to >> the way some CoAP servers work, but it seems theoretically possible = to >> return a payload on PUT and POST within CoAP specifications. >> If you are not planning to take the sleepy node draft to standards >> track, pubsub could be a reference implementation. We already have 2 >> implementations of pubsub that I know of, and inquiries on other work >> in progress. We may also be able to evaluate these additions with the >> existing implementations. >> Best regards, >> Michael >>> On Mar 23, 2016, at 8:48 AM, peter van der Stok = wrote: >>>> PS: What is the relationship to the = draft-zotti-core-sleepy-nodes-04? >>> We wrote sleepy node draft to show that pubsub does not cover all = sleepy node aspects. >>> Secondly, I think that pubsub should be developed independent of = sleepy node requirements >>> Peter >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 30 10:55:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED6112D844 for ; Wed, 30 Mar 2016 10:55:33 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UpA9Zo3JsL5t for ; Wed, 30 Mar 2016 10:55:31 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 BC03912D840 for ; Wed, 30 Mar 2016 10:55:31 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id td3so45918238pab.2 for ; Wed, 30 Mar 2016 10:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C4P2Pqirx8AL+5zZugXnZDDWm9BiR13iPEePe8wOsh8=; b=eTgjLfbtwGkjydpVdKvRCHeFVLLUVVQW5L35FFiD5Fe9bNijixaz0RqSDo7fgGVuQR oqqHV+4wehXproi6eZnzy4sTIZY6ihgevl1U9eGDdUqbg31vEK964i8nBP8sCFOzEgUS qNYYPvv8YRQpRXdVhtJYKVBYFmyj1zEvCF1Uhz6Ahn/bViKrt5oQNjh43s9l1rioF9Jn 29R4YGUHhxpRvxomIQxggq+yAipTlk4fSLV5ZWvB4nSBI2Gu6DvNSd3TOSnx9sBAnVT+ kjxOBK8HHdMau/d2Wu0iX/ExJxGKsJTl2axWDrTnCgYAER+CZQ+VGOnBNJD87M/1OJ3K k/oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C4P2Pqirx8AL+5zZugXnZDDWm9BiR13iPEePe8wOsh8=; b=W6sxk1t95nIEIVjWyP/Pd9NhmaoiWlGu1pgBgA80D0DZE43rI1vnNZsDUjb8q5cCm/ SfuDXSgmSHrUv42TU+pUuEN1OI4P3FQxBht7VHC3aXxkV3aAkvTOcqzHQNRTsmR9+XJm Gfj/btrEczp9i+EZzESrfMkVwSBGVk7AmNU+pjgVn9SEOC9Butc17lXL69tjvBnhYfAb PHD48nRx+nbD9cwTNtVrneLeJ5G89dXwh6rsyQYmnh/tyvp0v09D0QfqMOkJiOvf+D6t +3EEj8jIs0XjNlCMBvKIdEr2iX1x8MQxMp8ra5Fih7gsJ2ZpIkSs4IxZiXzWbe4HZ6TQ bwAg== X-Gm-Message-State: AD7BkJLNvUviNv+/WKz1prKZ0KNwH3d20zfrWexCqwK40hpsiCoB32Vonws3PzX62jMPfQ== X-Received: by 10.67.23.161 with SMTP id ib1mr14785460pad.156.1459360531330; Wed, 30 Mar 2016 10:55:31 -0700 (PDT) Received: from [172.28.32.167] ([162.246.216.202]) by smtp.gmail.com with ESMTPSA id e87sm7429104pfb.76.2016.03.30.10.55.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 10:55:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56FC0667.1000804@gmx.net> Date: Wed, 30 Mar 2016 10:55:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2654E4AD-E86C-4114-8853-AEEDE5212568@gmail.com> References: <56FC0667.1000804@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-links-json-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 17:55:34 -0000 The default media type for links in CoRE is CoRE Link-format (RFC6690), = which is not the same as text/plain. There is a fairly simple state = machine parser which is not so different from processing other = serializations. FWIW, I process link-format into a map (or right into = triples), which is how the JSON and CBOR representations work. I believe that offering CoRE link-format in JSON and CBOR serializations = improves the broader interoperability picture, as it will enable = link-format and Resource Directory to be usable across other ecosystems = that already use CoAP with JSON or CBOR formats (OCF, ZigBee clusters) = and to interoperate with web tools that use JSON serializations.=20 It seems to be more effective to offer multiple serializations than to = try to force everyone to use one serialization. This way, we can all = share a common data model and lexicon for link attributes and relations, = and use common implementations of Resource Directory, helping to unify = discovery. This vocabulary can be used by other discovery methods as = well, e.g. URL beacons. At the same time, some ecosystems may choose to = specify content formats and some of those that do so far are going for = CBOR. I think the draft should focus on the mapping and not try to go too much = into optimization. JSON and CBOR are both important, CBOR for = constrained "ecosystems" and JSON for ease of integration into web and = enterprise based systems. Best regards, Michael > On Mar 30, 2016, at 10:01 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I read through draft-ietf-core-links-json-04. The document is > conceptually fairly easy and I believe the document is in good shape. >=20 > The core assumption of the document is that there is a need to encode > the link formats in different formats, namely JSON and CBOR, rather = than > plain-text. I don't know whether this working assumption is a good = idea > since it will obviously reduce interoperability since now devices will > suddenly have to deal with three different formats rather than just = one. >=20 > Additionally, the document contains mapping of the formats defined in > RFC 7390 "Group Communication for CoAP" into CBOR. While this sounds > reasonable the text somehow does not fit into this document. I > personally would prefer if that text gets added to a revised version = of > the group communication draft instead. >=20 > There are a few TODO's in the document: >=20 > * Page 6 says "Is this the right list of attribute names?" and I > wonder whether the attribute names actually matter that much. >=20 > * Page 7 says "(more examples to be added.)". There are, however, > plenty of examples in the document and so I was wondering whether this > is line is just a left-over from past times. >=20 > * The acknowledgement section is almost empty and I am wondering > whether this is a reflection of the review status. If that's the case > then the situation is not looking good. How strong is the support for > this document? >=20 > * The security consideration section also says TBD but since we are > only defining alternative encodings of already existing functionality = I > cannot see additional concerns. >=20 > * Page 13 states "Should the IP address/port number information be > represented in a more compact way?". I am wondering whether this > question hasn't surfaced already in other discussions about CBOR = encoding? > Additionally, since you are referencing the mapping rules from RFC > 74049 I am not sure it makes sense to change those in this section. >=20 > * Appendix A points to a simple reference implementation. That's a > good idea. What is the status of it? >=20 > I prefer that these TODOs are added to the issue tracker, if they are > still valid. >=20 > One additional remark: The document uses the term 'Information Model' > and I wonder whether you would call CDDL an information modelling > language. I prefer graphical representations, such as an UML class > diagram or an entity relationship diagram since you are less likely to > generate code form these simple structures. >=20 > Since you brought CDDL again into the picture there is the obvious > question about the status of CDDL. The structure described here is > really simple and hence there is the question whether CDDL is needed = at > all. >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Mar 30 12:06:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BB712D8C4 for ; Wed, 30 Mar 2016 12:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 CJ_WgNjY50Kp for ; Wed, 30 Mar 2016 12:06:26 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F095A12D8C8 for ; Wed, 30 Mar 2016 12:06:25 -0700 (PDT) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 5FB69C5A50; Wed, 30 Mar 2016 21:06:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YOlodYixzWVD; Wed, 30 Mar 2016 21:06:22 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 78B29C5A46; Wed, 30 Mar 2016 21:06:21 +0200 (CEST) Message-ID: <56FC23AB.1080007@tzi.org> Date: Wed, 30 Mar 2016 21:06:19 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56FC0673.2020707@gmx.net> In-Reply-To: <56FC0673.2020707@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] CoAP over TCP: Extending the shim Header Payload X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 19:06:33 -0000 I didn't write this up yet, but it seems I'll have to. Any extension to the shim header will soon grow into a protocol that is as complex as CoAP itself. Instead, we should simply re-use a protocol that we already have: CoAP. (If we really need to do all of this; I'm not convinced yet.) See below for how (I haven't checked the details against your new protocol, but it's the gist I'm after here). Grüße, Carsten # Signaling messages Signaling messages are structured like any other CoAP message; they have a code, a token, options, and optionally a payload. The code for a signaling message comes from the 7.xx space. Option numbers for signaling messages are specific to the message code, i.e., they do not share the number space with CoAP options for request/response messages or with signaling messages using other codes. Signaling options can be elective or critical; if a signaling message option is critical and not understood by the receiver, it MUST abort the connection. (If the option is understood but somehow cannot be carried out, the option defines how to handle the error.) Payloads in signaling messages are diagnostic payloads, unless otherwise determined by a signaling message option. Five types of signaling messages are defined: * Capability messages: indicate a capability to the peer. Most capability options will be elective. Capability indications are cumulative, i.e., a capability message without any option is a no-operation (and can be used as such). (An option that is given might override a previous value for the same option; the option defines how to handle this, if needed.) Most options are defined only for the first message in the connection. * Ping, pong: A ping message is responded to by a pong message with the same token. No options are defined for Ping messages in this specification, but options might be defined later. As with all signaling messages, the receiver of a ping or pong message MUST ignore elective options it does not understand. * Release. A release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown; the details are in the options. A release message will normally be replied to by a release message as soon as possible by the receiver; only then is the connection closed. (To do: define who actually closes the TCP connection.) * Abort. An abort message indicates that the sender is unable to continue maintaining the connection and cannot even wait for an orderly release; the sender shuts down the connection immediately after the abort (and may or may not wait for a release or abort message in the inverse direction). Release and abort messages indicate one or more reasons using elective options. ## Discussion Capability messages remove the perceived need for versioning. (Versioning is great for keeping incompatible implementations from accidentally trying to talk to each other, but is not a good evolution strategy.) An effect similar to the ping/pong message can be achieved by creating a resource that has appropriate no-operations semantics (e.g., returns an empty payload on a GET or returns the payload given on a POST). Handling the function as a signaling message keeps the resource name space clean of such resources. The need for orderly release only becomes apparent in the presence of non-idempotent requests such as POST. It does not solve the problem that a connection that breaks in an uncontrolled way keeps the status of that request unclear. From nobody Wed Mar 30 12:32:56 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6D412D8F1 for ; Wed, 30 Mar 2016 12:32:55 -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 9aDEJ9jaeG09 for ; Wed, 30 Mar 2016 12:32:52 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEC912D8F3 for ; Wed, 30 Mar 2016 12:32:52 -0700 (PDT) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id DC31FA809B; Wed, 30 Mar 2016 21:32:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MHCgesJMkUCN; Wed, 30 Mar 2016 21:32:19 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BBD7EA80C4; Wed, 30 Mar 2016 21:32:18 +0200 (CEST) Message-ID: <56FC29C1.5000601@tzi.org> Date: Wed, 30 Mar 2016 21:32:17 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56FC0667.1000804@gmx.net> In-Reply-To: <56FC0667.1000804@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-links-json-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 19:32:55 -0000 Hannes Tschofenig wrote: > One additional remark: The document uses the term 'Information Model' > and I wonder whether you would call CDDL an information modelling > language. I certainly wouldn't. CDDL is a language for describing data structures, and thus belongs to the data model level. It just so happens that the data structures chosen in this specification to represent RFC 6690's information model are simple enough that CDDL is sufficient to illustrate them in a concise form. > I prefer graphical representations, such as an UML class > diagram or an entity relationship diagram since you are less likely to > generate code form these simple structures. Non sequitur -- can you explain the "since"? (The section header of 2.2 is indeed somewhat misleading, because after quickly discussing the RFC 6690 information model, it focuses on how to map that to JSON's (and CBOR's) data model.) > Since you brought CDDL again into the picture there is the obvious > question about the status of CDDL. The structure described here is > really simple and hence there is the question whether CDDL is needed at > all. (I think we already noticed in COSE that you don't like formal techniques such as ABNF or CDDL that much.) Some people benefit from them. Is it "needed"? Formal definitions are never needed, you can do everything in English. The entirety of mathematical notation is just a shortcut to make math more comprehensible to those that practice it. Grüße, Carsten From nobody Wed Mar 30 12:58:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD45612D91E for ; Wed, 30 Mar 2016 12:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu5hy8Ad7eXE for ; Wed, 30 Mar 2016 12:58:33 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE6912D91C for ; Wed, 30 Mar 2016 12:58:32 -0700 (PDT) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 385DC41C074; Wed, 30 Mar 2016 21:58:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id u8uZPtOeBd6q; Wed, 30 Mar 2016 21:58:29 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 4E9C441C087; Wed, 30 Mar 2016 21:58:29 +0200 (CEST) Message-ID: <56FC2FE3.1020802@tzi.org> Date: Wed, 30 Mar 2016 21:58:27 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56FC0667.1000804@gmx.net> In-Reply-To: <56FC0667.1000804@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-links-json-04 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 30 Mar 2016 19:58:35 -0000 Hi Hannes, here is a bit more detail information: Hannes Tschofenig wrote: > Additionally, the document contains mapping of the formats defined in > RFC 7390 "Group Communication for CoAP" into CBOR. While this sounds > reasonable the text somehow does not fit into this document. I > personally would prefer if that text gets added to a revised version of > the group communication draft instead. I don't think there is an intention to revise RFC 7390 soon. Of course, we could make a separate document out of this material, but it is pretty straightforward to put it in here. I don't really care much either way, it just seemed expedient. > There are a few TODO's in the document: > > * Page 6 says "Is this the right list of attribute names?" and I > wonder whether the attribute names actually matter that much. With RD potentially still moving, this is a running to do. We probably want to ship this one together with RD, at which point the to do is done. > * Page 7 says "(more examples to be added.)". There are, however, > plenty of examples in the document and so I was wondering whether this > is line is just a left-over from past times. The example doesn't have an attribute that is present more than once (array-formed on the JSON/CBOR side); it also has no attribute without a value (true on the JSON/CBOR side). Maybe still worth doing another example. > * The acknowledgement section is almost empty and I am wondering > whether this is a reflection of the review status. If that's the case > then the situation is not looking good. How strong is the support for > this document? The early reviewers became co-authors, and there wasn't too much change needed after that. But we can probably dig out the names of the previous reviewers. > * The security consideration section also says TBD but since we are > only defining alternative encodings of already existing functionality I > cannot see additional concerns. Again, more like a running to do. > * Page 13 states "Should the IP address/port number information be > represented in a more compact way?". I am wondering whether this > question hasn't surfaced already in other discussions about CBOR encoding? > Additionally, since you are referencing the mapping rules from RFC > 74049 I am not sure it makes sense to change those in this section. RFC 7049 says: This section gives non-normative advice about converting between CBOR and JSON. Implementations of converters are free to use whichever advice here they want. So the question is whether something should be added here. Input would be useful from those who care about the RFC 7390 data structures. (By now, we have other CBOR mappings of IP addresses, so maybe we can simply borrow from, say, GRASP: ipv4-address = bytes .size 4 ipv6-address = bytes .size 16 and combine that with an optional port number, as in groupaddress = [ address: ipv4-address / ipv6-address, ? port: uint .size 2] Maybe.) > * Appendix A points to a simple reference implementation. That's a > good idea. What is the status of it? It was meant to be part of the CoAP gem, but then the maintainers of that decided not to do link-format at all for the moment. So it is still not published. Would you like to see it here? Most of it is a link-format parser; parsers tend to be arcane... Grüße, Carsten From nobody Thu Mar 31 00:43:04 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B3212D528 for ; Thu, 31 Mar 2016 00:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KgAxluXG5AVw for ; Thu, 31 Mar 2016 00:43:00 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659DC12D0ED for ; Thu, 31 Mar 2016 00:42:59 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.215]) by smtp-cloud6.xs4all.net with ESMTP id cXiu1s00T4eRkWy01XiukN; Thu, 31 Mar 2016 09:42:54 +0200 Received: from 2001:983:a264:1:f102:72b3:9cc6:7242 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 31 Mar 2016 09:42:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 31 Mar 2016 09:42:54 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <56FBDF7C.70004@tzi.org> References: <56FBDF7C.70004@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (pZ3ASpWXeG7a+l0tousTgLnUuazxcK5V) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 07:43:03 -0000 Hi all, Personally, I think it is more evident to write a new I-D that describes a new CBOR element with a "difference semantics" than changing the meaning of the element type. I like to point out what the YANG to CBOR specification says about element 0: "Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using a CBOR unsigned integer data item (major type 0)." and nothing about differences. > Somaraju Abhinav wrote: >> [AS] The problem is here is with repeated deltas - if we use former >> values to calculate deltas then we might get the same delta more than >> once when encoding an object. CBOR keys can not be used to identify >> which element within the object we are referring to unless we impose >> an order on the elements within the object. > > That is not the only problem: maps are not order-preserving in CBOR (a > property CBOR inherits from JSON). So "former" may not even be a > meaningful concept within the set of keys in a map. Stating that the media-type puts a meaning to the order of the elements in the payload seems more logic to me than changing the meaning of the type. And looking at the example in the cool language I-D I get confused about the hierarchy. I do understand the 1529, which is 1529 + 0, where 0 comes from the parent. But I don't understand the 179; Are the parents of 1529 and 179 different? "/system-state/clock" (SID 1708) does not look like a child of "/interfaces/interface" (SID 1529) . Probably I am missing something fundamental. The examples in the text are nice but an explanation how one gets to the numbers in the examples following the rules would be helpful. Peter [ 1529, { 4 : "eth0", # name (SID 1533) 1 : "Ethernet adaptor", # description (SID 1530) 5 : 1179, # type (SID 1534), identity ethernetCsmacd 2 : true # enabled (SID 1531) }, 179, # clock (SID 1708) { 1 : "2015-02-08T14:10:08Z09:00", # boot-datetime (SID 1709) 2 : "2015-04-04T09:32:51Z09:00" # current-datetime (SID 1710) } 13, 60 # timezone-utc-offset (SID 1721) ] From nobody Thu Mar 31 04:17:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4512D12B for ; Thu, 31 Mar 2016 04:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Zw77mw_IgsQi for ; Thu, 31 Mar 2016 04:17:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD7412D127 for ; Thu, 31 Mar 2016 04:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VnkjrXYp6hBrGA3kng0rXSPXF9nZtBcc4MqiMwlAfCg=; b=w0/JDlZkdoMFMsXf9WyBZi7+fmZs9b7rz288yEalL3zBRsWeJ1FUB6zHmQhpyghGzs2VMaC1LCIOh2d5/SENNtWxN+KkVNdqMvCbjtggcHHKCP47NWIzG499n822UGtED16MUfvF6pk6TXSQTT9Gd0A9HKTulupxA0OeFixAqE4= Received: from SN1PR06MB1774.namprd06.prod.outlook.com (10.162.132.148) by SN1PR06MB1773.namprd06.prod.outlook.com (10.162.132.147) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 31 Mar 2016 11:16:25 +0000 Received: from SN1PR06MB1774.namprd06.prod.outlook.com ([10.162.132.148]) by SN1PR06MB1774.namprd06.prod.outlook.com ([10.162.132.148]) with mapi id 15.01.0443.017; Thu, 31 Mar 2016 11:16:26 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Carsten Bormann Thread-Topic: [core] COOL SID representation Thread-Index: AQHRioLe9YC4kcsTek+wcq535Vsfz59yBaaAgAAChwCAASSrAIAAM2mw Date: Thu, 31 Mar 2016 11:16:25 +0000 Message-ID: References: <56FBDF7C.70004@tzi.org> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [24.225.215.88] x-ms-office365-filtering-correlation-id: 1bea7412-d1fe-49d4-924c-08d35955e662 x-microsoft-exchange-diagnostics: 1; SN1PR06MB1773; 5:Le6mNLvorIeUr8TyysMzQDX+Yahsd873bDTSJM0MRe2+WjF4nIpYj4bYobGI8gzmirglvoGLWwNJfqVh8q+ZpyHgVg/jIjAG6rAR1y4OVB5cCJP+r4x/0h+PqU/NchW4tU/tQQpbxMBczgBtGAVHxQ==; 24:73ebftHnnOCIWaps9OP1YBLN1yW+jfDTaBuGcqbyqEX1Q8QQDLA2Jla54FTvqdig5+pSkTKav8R5xgJklFawrMor1uNUiHIIFP55HlsNZRQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1773; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR06MB1773; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1773; x-forefront-prvs: 0898A6E028 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(377454003)(24454002)(13464003)(54356999)(2900100001)(5003600100002)(50986999)(19580395003)(33656002)(15975445007)(19580405001)(2950100001)(66066001)(2906002)(87936001)(76176999)(93886004)(74316001)(586003)(3846002)(5008740100001)(106116001)(6116002)(1096002)(102836003)(4326007)(81166005)(1220700001)(2501003)(77096005)(99286002)(76576001)(5001770100001)(3280700002)(86362001)(5004730100002)(189998001)(92566002)(122556002)(10400500002)(5002640100001)(3660700001)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR06MB1773; H:SN1PR06MB1774.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 11:16:25.4183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1773 Archived-At: Cc: Core Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 31 Mar 2016 11:17:34 -0000 Hi Peter The semantic of deltas are defined in the context of a YANG container, not = in the context unsigned integers (uint8, uint16, uint32 and uint64). For YANG containers, the YANG to CBOR mapping draft also supports: - JSON names encoded within the CBOR map as CBOR text string data item (maj= or type 3) - YANG hashes encoded within the CBOR map as CBOR byte string data item (ma= jor type 2) Since we don`t need deltas in other contexts, I don't see the need for a ne= w I-D. Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: March-31-16 3:43 AM To: Carsten Bormann Cc: Core Subject: Re: [core] COOL SID representation Hi all, Personally, I think it is more evident to write a new I-D that describes a = new CBOR element with a "difference semantics" than changing the meaning of= the element type. I like to point out what the YANG to CBOR specification says about element = 0: "Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using a CBOR unsigned integer data item (major type 0)." and nothing about differences. > Somaraju Abhinav wrote: >> [AS] The problem is here is with repeated deltas - if we use former=20 >> values to calculate deltas then we might get the same delta more than=20 >> once when encoding an object. CBOR keys can not be used to identify=20 >> which element within the object we are referring to unless we impose=20 >> an order on the elements within the object. >=20 > That is not the only problem: maps are not order-preserving in CBOR (a=20 > property CBOR inherits from JSON). So "former" may not even be a=20 > meaningful concept within the set of keys in a map. Stating that the media-type puts a meaning to the order of the elements in = the payload seems more logic to me than changing the meaning of the type. And looking at the example in the cool language I-D I get confused about th= e hierarchy. I do understand the 1529, which is 1529 + 0, where 0 comes from the parent. But I don't understand the 179; Are the parents of 1529 and 179 different? "/system-state/clock" (SID 1708) does not look like a child of "/interfaces= /interface" (SID 1529) . Probably I am missing something fundamental. The examples in the text are nice but an explanation how one gets to the nu= mbers in the examples following the rules would be helpful. Peter [ 1529, { 4 : "eth0", # name (SID 1533) 1 : "Ethernet adaptor", # description (SID 1530) 5 : 1179, # type (SID 1534), identity ethernetCsmacd 2 : true # enabled (SID 1531) }, 179, # clock (SID 1708) { 1 : "2015-02-08T14:10:08Z09:00", # boot-datetime (SID 1709) 2 : "2015-04-04T09:32:51Z09:00" # current-datetime (SID 1710) } 13, 60 # timezone-utc-offset (SID 1721) ] _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Mar 31 05:14:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB3112D5EE for ; Thu, 31 Mar 2016 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFUAGEYWdg4X for ; Thu, 31 Mar 2016 05:14:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B074112D5E8 for ; Thu, 31 Mar 2016 05:14:14 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ldq55-1a43XV242d-00j0pr; Thu, 31 Mar 2016 14:14:03 +0200 To: Carsten Bormann References: <56FC0673.2020707@gmx.net> <56FC23AB.1080007@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FD148E.30009@gmx.net> Date: Thu, 31 Mar 2016 14:14:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FC23AB.1080007@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uXk2jPXte1NRL5F4UvTMdIBOVNahcCFS4" X-Provags-ID: V03:K0:DnslQAWch3U8Zua+dc20QX/xWdAVr7jzf6+nd1z4ZRcWo+AM2Vd eDfHIqnE6vHVx1SlXtx5E/yQ6B/wwsWiS7UfwC8FL9+4OBydfHiA7z4TZnq1jm6LJzUiCXD GSSmzd9RVQe/MWE6uwii2xQ88cro/RJk+B6IrDAkREyrCNRca2REJpo93aBVa1mLGKB70oB Ym/8sqIdRRJb9ladB7CVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:sdJ9FFycCr0=:4KbmVvx/1tyNWGudBb8aHM DaEQ9i3YMqmwKn10S7jIVJaVYz0WPQYM798XOYs3hBwFhPqnox/i0ClL6WehhqZajGGP2FFew s9FfT4Y2snuRQTpW+lD/h9JfXGr75Ff8rX7vUL+oYxJC+VWwZY0F0Io2hQ9/retSe94kGKT2U 6R+Vg/UBBfXUHcoajzgVBEF0K8KgYI4AkqmAr84n6AL3G9GA5z5YpUFt0Zt23JO1p+0Wqu59J 9ltYv0TAczFihQkYQRnxNyYX5PJq1yXh9tJ/sFXS4TclRs/d9xDlhGQ6k7cSly69X9DAKiHsO AEmH5mAzI15Ry4yCEKYA/lvjfAp+1V4e+AsZ/mxMS8ElPdz60bEK/PHL6hxzYkA4nJ78/zwpz kbiWrEJo7NIJIBa2X57C/ZKfMf3rlVF4Ex0JE1KoSbwk8Ax7J6h6mXgJhwllHPVpD5z/M8fmH jud8GE50i3d2C1o1pnnZ1NfOg+np0ZbAjTmq6gm1v1YI6t7kfqqyXukZxft6NQHosxmZmfNG9 4uGFk9UthwN1plRX271hNU1A779vod7IqWrRN/A3fh+XaW9kNNUtCoOYJ1AeRzuZFJCOW7uG3 sPQNOwYbeuny/dgQ0xcavwmllH31T9rFqyClgdhA+p+emCCT+i7vdUHbCPymgnuV2hwnEThiU Cb+6LVoPPQZCChnNi98xINRG/x5PK/YmpTxBPoZg2hkZBTEn9VPwmR4pCV1l5S8Y2PyZfYXAC 3db5XyFFEhME0aI4zj5B1RMN57fh49rosuBbl666sJ/UcxGPVecXdd8awcc= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] CoAP over TCP: Extending the shim Header Payload X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 31 Mar 2016 12:14:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uXk2jPXte1NRL5F4UvTMdIBOVNahcCFS4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, In my write-up I intentionally avoided describing what encoding to use and, as you write below, maybe CoAP messages are the right encoding for these types of message exchange. Whether that's indeed the case will have to get analysed. **IMHO it is important to answer the question whether WG participants see the need to provide these features.** Maybe there are other options. At the beginning we thought we could get away with a very simplistic shim header and we are done with it. Now, it appears that this is not really the case. I would like to have various folks interested in the CoAP over TCP and TLS look at this to see whether the additional complexity is worth the effort. As alternatives I see the following: * Stick with the shim header and just not provide any of the advanced features (with all the disadvantages that come along with it). * Switch to a different protocol altogether (such as HTTP/2) for those cases where a TCP-alike behavior is needed. * Use CoAP over TLS over TCP only (without the ability to use CoAP over TCP) since TLS already provides various for the features (such as version negotiation, server naming, etc.) we are looking for. Ciao Hannes On 03/30/2016 09:06 PM, Carsten Bormann wrote: > I didn't write this up yet, but it seems I'll have to. >=20 > Any extension to the shim header will soon grow into a protocol that is= > as complex as CoAP itself. >=20 > Instead, we should simply re-use a protocol that we already have: CoAP.= >=20 > (If we really need to do all of this; I'm not convinced yet.) >=20 > See below for how (I haven't checked the details against your new > protocol, but it's the gist I'm after here). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > # Signaling messages >=20 > Signaling messages are structured like any other CoAP message; they > have a code, a token, options, and optionally a payload. > The code for a signaling message comes from the 7.xx space. >=20 > Option numbers for signaling messages are specific to the message > code, i.e., they do not share the number space with CoAP options for > request/response messages or with signaling messages using other > codes. > Signaling options can be elective or critical; if a signaling message > option is critical and not understood by the receiver, it MUST abort > the connection. (If the option is understood but somehow cannot be > carried out, the option defines how to handle the error.) >=20 > Payloads in signaling messages are diagnostic payloads, unless > otherwise determined by a signaling message option. >=20 > Five types of signaling messages are defined: >=20 > * Capability messages: indicate a capability to the peer. Most > capability options will be elective. Capability indications are > cumulative, i.e., a capability message without any option is a > no-operation (and can be used as such). (An option that is given > might override a previous value for the same option; the option > defines how to handle this, if needed.) Most options are defined > only for the first message in the connection. >=20 > * Ping, pong: A ping message is responded to by a pong message with > the same token. No options are defined for Ping messages in this > specification, but options might be defined later. As with all > signaling messages, the receiver of a ping or pong message MUST > ignore elective options it does not understand. >=20 > * Release. A release message indicates that the sender does not want > to continue maintaining the connection and opts for an orderly > shutdown; the details are in the options. A release message will > normally be replied to by a release message as soon as possible by > the receiver; only then is the connection closed. (To do: define > who actually closes the TCP connection.) >=20 > * Abort. An abort message indicates that the sender is unable to > continue maintaining the connection and cannot even wait for an > orderly release; the sender shuts down the connection immediately > after the abort (and may or may not wait for a release or abort > message in the inverse direction). >=20 > Release and abort messages indicate one or more reasons using elective > options. >=20 > ## Discussion >=20 > Capability messages remove the perceived need for versioning. > (Versioning is great for keeping incompatible implementations from > accidentally trying to talk to each other, but is not a good > evolution strategy.) >=20 > An effect similar to the ping/pong message can be achieved by creating > a resource that has appropriate no-operations semantics (e.g., returns > an empty payload on a GET or returns the payload given on a POST). > Handling the function as a signaling message keeps the resource name sp= ace > clean of such resources. >=20 > The need for orderly release only becomes apparent in the presence of > non-idempotent requests such as POST. > It does not solve the problem that a connection that breaks in an > uncontrolled way keeps the status of that request unclear. >=20 --uXk2jPXte1NRL5F4UvTMdIBOVNahcCFS4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/RSOAAoJEGhJURNOOiAty/cH/1PFygZ0EuW+pymzPWUSA7Y4 mXSaOIEY9EPnamZ90Y5664fe0cfuWGYiyhmh2DJl07vr6RzSuKqfcJQycDXobHay cisjClN/tRWVMblvjE2LCiQDpojvFUWujf+WgXusldCevEXTr5k3xV0O+vm5O4Ah JCK7mRPhokooGDPu5Kom1+xTrSFUnb+N86KZNJY8uem8OtySlGztvUH86jzELQR5 dP0SS6ko6lYDxgIK6QzW5KPAu94bKbH3IbYAbATuGIX8geDCgWcGjW27JgiRcuCS pFBzFK+xlXw6dmL7eTruIwvFOWVaw56c8JR+0LWNZK+o+alhHbmMx4EQ1psoV2E= =WNTt -----END PGP SIGNATURE----- --uXk2jPXte1NRL5F4UvTMdIBOVNahcCFS4--