From nobody Tue Nov 1 08:30: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 9763C129AA6; Tue, 1 Nov 2016 08:30:31 -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 FBQBLqb9BRzn; Tue, 1 Nov 2016 08:30:29 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0137.outbound.protection.outlook.com [104.47.38.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFBD129AB6; Tue, 1 Nov 2016 08:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rlUHUzknxgNVNW+HFnXmDyPGJX8X9lKgKDCNFJVwq4U=; b=QQfH4mDVVN5xhRtSD4eW0Fbchl2ihyFHkab1EKoSYKL/xi2zDF5JYO/s0TBenv7qMeQE7YKPOP7qzVEZARMC6/4uHjl3RJSobv79k8u7mzZmKG24OYnyZ329OaMC0+HYTqgjzhnHlALSndLH1KPbeyITbiow8LYwhAXYXSNEjbk= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2611.namprd06.prod.outlook.com (10.173.145.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 1 Nov 2016 15:30:27 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0679.015; Tue, 1 Nov 2016 15:30:26 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Anima-bootstrap , Core Thread-Topic: [core] Fwd: New Version Notification for draft-vanderstok-core-coap-est-00.txt Thread-Index: AQHSMfbT9L6wtjR1qUmGz/IT6U8mBaDEQd4g Date: Tue, 1 Nov 2016 15:30:26 +0000 Message-ID: References: <147775346922.30618.14590857285848221161.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BN6PR06MB2611; 7:B7fYQN55Pn5Q8pLf3MApLWHjyW1bBoshhLdSY0U3ck5lmUvUv2uCNZzy35XShCT8WWsQFMgTx2JVoGmxniSp0c574hDlutqTyayAPn8nlncPMBVLcRQMd33g9ZBrhE0eJhEHF5oG+rDvOXPc0G7+4ZRgmzwVmxt2KVVLKDcy6jUvMx9oF/hiZwkBLt+k9pyBJCWhZWLhiY9/yMSrbtZAEFbm30xhw2xbzentIermciwYPk/FS/Kc1dVNQIpz1ZJTqpeH11qsYJl2/nISPJsuRX4n/OOURGNP1k90zwCcWy+pVzx9qotu17Kl06L7GeLfD2bdLA7f3yYZzoFZKz/HS1M9nnsGNx+kByqj1iC9EOY= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(377424004)(13464003)(189002)(2950100002)(7736002)(54356999)(15975445007)(5002640100001)(2900100001)(77096005)(76176999)(15650500001)(8676002)(50986999)(81166006)(86362001)(230783001)(81156014)(8936002)(3660700001)(101416001)(92566002)(2501003)(586003)(122556002)(74316002)(3280700002)(33656002)(9686002)(31430400001)(68736007)(2906002)(305945005)(107886002)(5660300001)(99286002)(105586002)(66066001)(189998001)(5001770100001)(3846002)(106116001)(6116002)(76576001)(102836003)(7846002)(19580405001)(7696004)(97736004)(19580395003)(87936001)(4001150100001)(10400500002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2611; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 5a183daa-99a4-4415-4fc9-08d4026c011d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB2611; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN6PR06MB2611; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2611; x-forefront-prvs: 01136D2D90 received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 01 Nov 2016 15:30:26.2392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2611 Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-coap-est-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: Tue, 01 Nov 2016 15:30:31 -0000 Hi Peter In section 3 of "draft-vanderstok-core-coap-est-00", "Server-generated key"= is listed as supported. This service returns two components, a PKCS8 containing the private key mat= erial and a PKCS7 containing the device certificate chain. In RFC7030, this information is returned using a Content-Type: multipart/mi= xed. How this is supported in "draft-vanderstok-core-coap-est-00"? REQ: POST /.well-known/est/serverkeygen (Content-Format: application/p= kcs10) // Certificate request carry in a PKCS10 =20 RES: 2.05 Content (Content-Format: ???) // Private key material for this node car= ry in a PKCS8 // Certificate and associated PKI for thi= s node carry in a PKCS7 Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Saturday, October 29, 2016 11:12 AM To: Anima-bootstrap ; Core Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-coa= p-est-00.txt Dear all, we have submitted a new draft Enrollment over Secure Transport (EST) over = coaps to make BRSKI over coap possible. We expect (parts of) this draft to be integrated with coap-bootstrap draft = of pritikin and Kampanakis. This draft removes EST functionality not absolutely needed within the conte= xt we expect the BRSKI deployment for low-resource devices. Greetings, Peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-core-coap-est-00.t= xt Datum: 2016-10-29 17:04 Afzender: internet-drafts@ietf.org Ontvanger: "Peter van der Stok" , "Peter Van de= r Stok" , "Sandeep Kumar"=20 , "Sandeep S. Kumar" A new version of I-D, draft-vanderstok-core-coap-est-00.txt has been successfully submitted by Peter van der Stok and posted to the IET= F repository. Name: draft-vanderstok-core-coap-est Revision: 00 Title: EST based on DTLS secured CoAP (EST-coaps) Document date: 2016-10-29 Group: Individual Submission Pages: 15 URL: =20 https://www.ietf.org/internet-drafts/draft-vanderstok-core-coap-est-00.txt Status: =20 https://datatracker.ietf.org/doc/draft-vanderstok-core-coap-est/ Htmlized: =20 https://tools.ietf.org/html/draft-vanderstok-core-coap-est-00 Abstract: Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Provisioning these devices in a secure manner with keys (often called security bootstrapping) used to encrypt and authenticate messages is the subject of Bootstrapping of Remote Secure Key Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra]. Enrollment over Secure Transport (EST) [RFC7030], based on TLS and HTTP, is used for BRSKI. This document defines how low-resource devices are expected to use EST over DTLS and CoAP. 6LoWPAN fragmentation management and minor extensions to CoAP are needed to enable EST over DTLS-secured CoAP (EST-coaps). 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 Nov 1 08:55: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 1DD43129460; Tue, 1 Nov 2016 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85AuawNi3OBd; Tue, 1 Nov 2016 08:55:09 -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 DC815129AB2; Tue, 1 Nov 2016 08:55:04 -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 uA1Ft0MX002818; Tue, 1 Nov 2016 16:55:00 +0100 (CET) Received: from nar-4.local.mail (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3t7bQq70dLz7xmx; Tue, 1 Nov 2016 16:54:59 +0100 (CET) Date: Tue, 1 Nov 2016 16:34:25 +0100 From: Carsten Bormann To: Michel Veillette , "=?utf-8?Q?consultancy=40vanderstok.org?=" , Anima-bootstrap , Core Message-ID: In-Reply-To: References: <147775346922.30618.14590857285848221161.idtracker@ietfa.amsl.com> X-Mailer: Airmail (390) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5818bad3_28ba0ee2_9528" Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-vanderstok-core-coap-est-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: Tue, 01 Nov 2016 15:55:12 -0000 --5818bad3_28ba0ee2_9528 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sending around MIME messages between constrained devices doesn=E2=80=99t = strike me as the optimal way forward. =46ortunately, we have COSE, which would be an easy way to combine a key = wrap with some signing info. Gr=C3=BC=C3=9Fe, Carsten On 1 November 2016 at 16:30:43, Michel Veillette (michel.veillette=40tril= liantinc.com) wrote: Hi Peter =20 In section 3 of =22draft-vanderstok-core-coap-est-00=22, =22Server-genera= ted key=22 is listed as supported. =20 This service returns two components, a PKCS8 containing the private key m= aterial and a PKCS7 containing the device certificate chain. =20 In R=46C7030, this information is returned using a Content-Type: multipar= t/mixed. =20 How this is supported in =22draft-vanderstok-core-coap-est-00=22=3F =20 REQ: POST /.well-known/est/serverkeygen (Content-=46ormat: application/pk= cs10) =20 // Certificate request carry in a PKCS10 =20 RES: 2.05 Content (Content-=46ormat: =3F=3F=3F) =20 // Private key material for this node carry in a PKCS8= =20 // Certificate and associated PKI for this node carry= in a PKCS7 =20 Regards, =20 Michel =20 -----Original Message----- =20 =46rom: core =5Bmailto:core-bounces=40ietf.org=5D On Behalf Of peter van = der Stok =20 Sent: Saturday, October 29, 2016 11:12 AM =20 To: Anima-bootstrap ; Core = =20 Subject: =5Bcore=5D =46wd: New Version Notification for draft-vanderstok-= core-coap-est-00.txt =20 Dear all, =20 we have submitted a new draft Enrollment over Secure Transport (EST) over= coaps to make BRSKI over coap possible. =20 We expect (parts of) this draft to be integrated with coap-bootstrap draf= t of pritikin and Kampanakis. =20 This draft removes EST functionality not absolutely needed within the con= text we expect the BRSKI deployment for low-resource devices. =20 Greetings, =20 Peter =20 -------- Oorspronkelijke bericht -------- =20 Onderwerp: New Version Notification for draft-vanderstok-core-coap-est-00= .txt =20 Datum: 2016-10-29 17:04 =20 Afzender: internet-drafts=40ietf.org =20 Ontvanger: =22Peter van der Stok=22 , =22Pe= ter Van der Stok=22 , =22Sandeep Kumar=22 =20 , =22Sandeep S. Kumar=22 =20 A new version of I-D, draft-vanderstok-core-coap-est-00.txt =20 has been successfully submitted by Peter van der Stok and posted to the I= ET=46 repository. =20 Name: draft-vanderstok-core-coap-est =20 Revision: 00 =20 Title: EST based on DTLS secured CoAP (EST-coaps) =20 Document date: 2016-10-29 =20 Group: Individual Submission =20 Pages: 15 =20 URL: =20 https://www.ietf.org/internet-drafts/draft-vanderstok-core-coap-est-00.tx= t =20 Status: =20 https://datatracker.ietf.org/doc/draft-vanderstok-core-coap-est/ =20 Htmlized: =20 https://tools.ietf.org/html/draft-vanderstok-core-coap-est-00 =20 Abstract: =20 Low-resource devices in a Low-power and Lossy Network (LLN) can =20 operate in a mesh network using the IPv6 over Low-power Personal Area =20 Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. =20 Provisioning these devices in a secure manner with keys (often called =20 security bootstrapping) used to encrypt and authenticate messages is =20 the subject of Bootstrapping of Remote Secure Key Infrastructures =20 (BRSKI) =5BI-D.ietf-anima-bootstrapping-keyinfra=5D. Enrollment over =20 Secure Transport (EST) =5BR=46C7030=5D, based on TLS and HTTP, is used fo= r =20 BRSKI. This document defines how low-resource devices are expected =20 to use EST over DTLS and CoAP. 6LoWPAN fragmentation management and =20 minor extensions to CoAP are needed to enable EST over DTLS-secured =20 CoAP (EST-coaps). =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. = =20 The IET=46 Secretariat =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 core mailing list =20 core=40ietf.org =20 https://www.ietf.org/mailman/listinfo/core =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 core mailing list =20 core=40ietf.org =20 https://www.ietf.org/mailman/listinfo/core =20 --5818bad3_28ba0ee2_9528 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

 

As editor, my aspiration is to publish coap-tcp-t= ls-06 for a second WGLC between December 16-19th. I have editorial issues t= o address and a few minor normative issues that I’ll raise on the mai= ling list. The main blocking point is https://githu= b.com/core-wg/coap-tcp-tls/issues/11. We need to find a way to quickly = move forward and reach rough consensus.

 

Here is my plan that I've reviewed with Jaime and= others:

 

Following the CoRE WG meeting on Wednesday, I've = had several conversations with people who needed to consult with their orga= nizations before sharing positions on this issue. Please share details abou= t your concrete positions and deployment plans/models (if possible) on the mailing list as soon as possible. Rememb= er that many people did not hear the microphone discussions on Wednesday - = so this is an opportunity to educate the WG. (I appreciate that we're trave= lling and then there is a holiday week for the US participants. Do the best you can.)

 

My perception was that some of the discussion on = Wednesday was not focused on CoAP+TCP and its scenarios. Please ensure = that you’re addressing this specific case rather than constrained dev= ices in general or CoAP+UDP. Also, remember that we all share the same goals even if we’re proposing different s= olutions – to ensure that CoAP+TCP addresses these guidelines (wh= ich are the best we have now):

 

Security Challenges For= the Internet Of  Things (2011):

It is essential tha= t IoT protocol suites specify a mandatory to implement but optional to use security solution. This w= ill ensure security is available in all implementations, but configurable t= o use when not necessary (e.g., in closed environment).

 

I'll use your information and RFC7252 as a starti= ng point for a pull request. I plan to schedule a conference call with Hann= es, Juan Perez, and G=F6ran Selander (or Francesca Palombini) late in the w= eek of December 5th based on availability. We’ll iterate on the pull request and then present to the broader wo= rking group for review during the week of December 12th.

 

Thanks,

…Brian

 

--_000_CY1PR03MB2380309CAFC2D3E9A485122883B00CY1PR03MB2380namp_-- From nobody Thu Nov 17 23:10: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 28D57129646 for ; Thu, 17 Nov 2016 23:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 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, RP_MATCHES_RCVD=-1.497, 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 GjVcAIiSr535 for ; Thu, 17 Nov 2016 23:10:38 -0800 (PST) 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 D180A12959C for ; Thu, 17 Nov 2016 23:10:37 -0800 (PST) Received: from [192.168.91.156] ([36.226.192.69]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MDE6y-1bzubz2Z36-00GXKr; Fri, 18 Nov 2016 08:10:33 +0100 To: Brian Raymor , "core@ietf.org WG" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 18 Nov 2016 08:10:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="v3fN7RL2mXlTbFxcQLNC7LIKJMhvux08k" X-Provags-ID: V03:K0:ZUfolv8j8UW+lSlvKA4uiFoNDViViqdkNHq05HBCuJFV1Ze04L7 MQzzrfp2HzI8cBbhAzX0oBinpamQqejF2Y56JrOT/PDV5ogrbOeqFpYiz6e5hJHB2SzJjMa 44F0s2IBHd1jlUss65/Kq8e7jGHGsvKClX0uQFVynVtn7y0QlhmS2nZBwuavjfq9+ygJNDf 3SeEp3O4ErZRffYlJtVlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:2DyRsncThoI=:qjfcTe4D0DPwCELm5hXL6E Nnx201twPMqTc0ewOoAU84kiZzE0Jd4FVbjeJWYW8GAR0qZFvn39gk56QAnBXfC1c2/aH31/i Z863AY1OiONS7TmqAd1OlJn0XVKvtXO7OwFqLwt+NtPkSESaP8uqBH2//QXUiOKDqnCh/uHLo hm3iTC2g9h0D+dbKOU/D833CMS734V2OA8L1/qB3nRtd9pA8DLoPKvRC+jofjdi5/7a1YnnrP w9F/IBo7GiGg62o8y4LrO+WUEFe2zvy3qaxLT0PWWHNX0H2ZQVy5AmK748IFr+zF5Nd4C6yKU Wh6BUJ3s5Gdzuzfp17bYxfR5izAtXKTMhQ3w8d1KEwnOjxJY1VwN9aEZZczmDVrT4GySTncYA Euc1ma/i8VrUhG6ynb9oKMT8C6pZ+Xvq+gJkOGRdhntVh8Q9PdhvKrl/4ng3yc+PqBWrM8wgA eWXmZGC+TdDuc1SLX2gi4/szWyuXJs6Wq7b9efazbrTLiIQU3zs45fQLy8jD7Pv0gS18nhMhN m0XGzQP9OIC9LbyZtdSmX6F6ZQb00hbeZoMgFQLv1nI3sMaBJjzKz5fjHNxm/MhU1vUmI1qH6 MiHtSokmwVhag3MavcHynR9KYSum3tnt9wRaM3ZCzlKgopIQLw20QIC6xpqGuFb5uRttaucud 5L4SPu1TJZUN4RwaXyymVhucKlK4m7sAyZZIEEbJHavhU46BVKBscgHRgY2qCuGmvhhe8Laa2 RZm+oQKe9p02JlWfgYRV0k8zO3hKIIQoJPu56ZEr3qjphCzoUMqOfxEwWGM= Archived-At: Subject: Re: [core] Next steps for coap-tcp-tls 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 Nov 2016 07:10:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v3fN7RL2mXlTbFxcQLNC7LIKJMhvux08k Content-Type: multipart/mixed; boundary="8DBc7cPkUc49xvSdTiiBVi2OXed647qAo"; protected-headers="v1" From: Hannes Tschofenig To: Brian Raymor , "core@ietf.org WG" Message-ID: Subject: Re: [core] Next steps for coap-tcp-tls References: In-Reply-To: --8DBc7cPkUc49xvSdTiiBVi2OXed647qAo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Brian, your proposal to start with RFC7252 as a starting point but I am wondering why there is a need for a second WGLC. Normally, we just take the feedback from the WGLC, incorporate it into the document and then send it to the IESG (if the WGLC comments are not dramatic). Ciao Hannes On 11/18/2016 08:06 AM, Brian Raymor wrote: > =20 >=20 > As editor, my aspiration is to publish coap-tcp-tls-06 for a second WGL= C > between December 16-19th. I have editorial issues to address and a few > minor normative issues that I=92ll raise on the mailing list. The main > blocking point is https://github.com/core-wg/coap-tcp-tls/issues/11. We= > need to find a way to quickly move forward and reach rough consensus. >=20 > =20 >=20 > Here is my plan that I've reviewed with Jaime and others: >=20 > =20 >=20 > Following the CoRE WG meeting on Wednesday, I've had several > conversations with people who needed to consult with their organization= s > before sharing positions on this issue. Please share details about your= > concrete positions and deployment plans/models (if possible) on the > mailing list as soon as possible. Remember that many people did not hea= r > the microphone discussions on Wednesday - so this is an opportunity to > educate the WG. (I appreciate that we're travelling and then there is a= > holiday week for the US participants. Do the best you can.) >=20 > =20 >=20 > My perception was that some of the discussion on Wednesday was not > focused on CoAP+TCP and its scenarios. Please ensure that you=92re > addressing this specific case rather than constrained devices in genera= l > or CoAP+UDP. Also, remember that we all share the same goals even if > we=92re proposing different solutions =96 to ensure that CoAP+TCP addre= sses > these guidelines (which are the best we have now): >=20 > =20 >=20 > Security Challenges For the Internet Of Things > (2011):= >=20 > /It is essential that IoT protocol suites specify a *mandatory to > implement but optional to use security solution*. This will ensure > security is available in all implementations, but configurable to use > when not necessary (e.g., in closed environment)./ >=20 > =20 >=20 > I'll use your information and RFC7252 as a starting point for a pull > request. I plan to schedule a conference call with Hannes, Juan Perez, > and G=F6ran Selander (or Francesca Palombini) late in the week of Decem= ber > 5th based on availability. We=92ll iterate on the pull request and then= > present to the broader working group for review during the week of > December 12th. >=20 > =20 >=20 > Thanks, >=20 > =85Brian >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --8DBc7cPkUc49xvSdTiiBVi2OXed647qAo-- --v3fN7RL2mXlTbFxcQLNC7LIKJMhvux08k 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYLqlkAAoJEGhJURNOOiAtKhEH/A/0CIyIB6H0R91829eY+LNs 4ZQE2KkZkt2iom0Efnhj3EK5xppYUa+b0IP7Zv+vT6PUjSefKS9hmvHOpLppryYC jnnRTvP5ytN9/XMHRJWLn0b3SjuNe+Nwq7dRrzxPqhSoodUDhm1bF8pHfIeK62/M 3AhYusTie4izlqDskCxl4HvEutjjzOwOC8TlI7X/NUy9nQmjjGmcebW66PBrZu8a CwJRxm+6IVU1/ilXQlV98No4RV2pxF0h8lvRvxo4wuEEZA3W+wB6JFeN96LP7qTt 1CtjLOQk7gbrSOq6Af/HMECcFysM9HdsSZhW54fYrA13b+VMBtTmoFj59HqQ9rI= =vzXs -----END PGP SIGNATURE----- --v3fN7RL2mXlTbFxcQLNC7LIKJMhvux08k-- From nobody Thu Nov 17 23:18: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 F40F0129646 for ; Thu, 17 Nov 2016 23:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 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, RP_MATCHES_RCVD=-1.497, 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 4hwq8taM4KBL for ; Thu, 17 Nov 2016 23:18:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 5B3C712959C for ; Thu, 17 Nov 2016 23:18:03 -0800 (PST) Received: from [192.168.91.156] ([36.226.192.69]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MfVzj-1cREWS2muR-00P6Yl; Fri, 18 Nov 2016 08:18:00 +0100 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "core@ietf.org WG" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <8694cf86-d694-adc4-3d95-b69ad01648b4@gmx.net> Date: Fri, 18 Nov 2016 08:17:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kALQv8KmsqGr6wSaOls7a9QudU6uXDQnW" X-Provags-ID: V03:K0:7GNxJ3yRNdaBvIotodJ9ej312n7A6VM2gKeFdeVl4lYiE+PAovX hfyWMlZfthxNHP8kbfUCgT661VuAetd9iKTV8bvCSeO/Zz3n3iuQsYnvgPUiMm8ALJlNScY jkCd38lMroarRg/FuLTQDzd0fOanl7wf3y+cEPUBFnqho33GKiR5WzEM9WfNVyCa6X/jME6 EDI+MwNH2zYa3L8+rz1eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:1C8/yuTHkac=:KmMmYykKW6RWmzgwk4fTCQ nE7iufmTHeEw+tHmexushUr7Im0T+Xg9EUluDMsA91ldg+GRHSR2RXWb3K4c1hht20GzbvX9L Joapq1RBP/dzIYf2mrzWLOPAMwLlWMAqDwx6iVnBHotyv5AbgdT0oT8DOrEtNFYG1cQVsQsxj tUHeXeqpmgL2ScYse9pgYiFgZ5fH0xqe0CQmZrI+6oV9kI+AoOB25uWY8zKHUN4TG4mUJVy96 cGKnZluO/Jv2qFcTK7kq2A1T/JlkSRXOdqu7P1Qvn0y3cK7GrLLD6E4rWq8a/Xu3bRuM3lDpR CRZhCdY6IKR5yplIOeP++i7cv10SU7J3Fv03SA3nkmKFPhth9G3TF3tEfjCW9yPpdQXRtZOGo w6ZmAbDVVz/g3CakR7SNoocNBk5Ak4r+PQ1P0zx3yKpEQDHPlIwiLuCkY+xnGaZ+5zP8RQbUD UDwDP5yyzgavyVqUnm0hR5dHYOuTWsmZdvL7z4MMFBtj/y4qCBv5HVrbJjVChiUnjgjWfZUlt PrvqXwL9iji7pFXJt9SOmm2nieccOAbz0XS3GzAoBVSs2niIeXr4EmvdPgr/uxX+Mdc1upnJu L+kfBR8OOTF0+XE3pt2ZfdUV93QAmnXGOWf/iPKm1BWEHy4Vd/2zzqb0PO9Fr03nvK06cR816 dx1zWo0XgSuYeAKSWCieAgFewT5HShC1n6lTtSFCxwHYBwWzdSMLt2u7ugFm+o65cRfFropUu Z8p47oo4C5CUTbmx8AJwuZnGOm6Ud8AK8+vINk25c5o7qDGnVgttWsfArDw= Archived-At: Subject: Re: [core] Security aspects in CoAP over TCP 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 Nov 2016 07:18:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kALQv8KmsqGr6wSaOls7a9QudU6uXDQnW Content-Type: multipart/mixed; boundary="6gHrv5uw5lC1cAEh6x4kpl2h4HWrmvnVW"; protected-headers="v1" From: Hannes Tschofenig To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "core@ietf.org WG" Message-ID: <8694cf86-d694-adc4-3d95-b69ad01648b4@gmx.net> Subject: Re: [core] Security aspects in CoAP over TCP References: In-Reply-To: --6gHrv5uw5lC1cAEh6x4kpl2h4HWrmvnVW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ~snip~ > But, again, the discussion here should not be about OSCOAP, it is about= > allowing other security protocols for CoAP in the same way as RFC7252 d= oes. The discussion started with the question about what should be stated as mandatory-to-implement (MTI). The problem is that the discussion then turned into OSCOAP vs. TLS. I argue that we should have TLS as MTI. --6gHrv5uw5lC1cAEh6x4kpl2h4HWrmvnVW-- --kALQv8KmsqGr6wSaOls7a9QudU6uXDQnW 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYLqskAAoJEGhJURNOOiAtrZoH/R2xzs3+MbTTZRFbxCC3i81+ f2WofolvSW2+2n2P0xbovOWuGz+MXrUDvfEaUejEeFKxrQUmxTySKO4rQeroKl8b 4KxF68BtYGegS92jDHHV7Lhc/ovJGoS8PMZ/NDoYNRCCCilu1o4hjAcHlaV7wb8V gftl2PLtslvua/8EdSr0XvSbjFgQC68HLkzW9VI6TQqzG/mR7aAASy9VzZSo9Sg6 U6uznRzEgm93gaYmrQXVaOwWC/mttVpHltZGR6vJ7MrUR+oBkuTu+bz4sNc7wAKz B1ci/ueT889XwFeCjQObx2+lSaTKpj0lWhfV4TuTLpfQNG714abYSOUMGzmXBDg= =1FDJ -----END PGP SIGNATURE----- --kALQv8KmsqGr6wSaOls7a9QudU6uXDQnW-- From nobody Thu Nov 17 23:29: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 845EB129410 for ; Thu, 17 Nov 2016 23:29:02 -0800 (PST) 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 dLwPMIDAJ6JF for ; Thu, 17 Nov 2016 23:29:00 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0107.outbound.protection.outlook.com [104.47.41.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB0C1293E9 for ; Thu, 17 Nov 2016 23:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ba/zLE3JzCP5k/TQYZg75X5PMG2kDgo1R93vYwpduCU=; b=gH8o08sOeC/7epn3xkWXu47A7jWylbDzk7vJsc6743PMlZhqsNwdfR9PI73brQu7CoXjRQf1cMufYMePueGpSNcEhVZlZi6LhVCKSlzqasjPoH1GA8hXfIQt7LcKtIvUMaEq3pELu6Y4mnB5Tr3VodsYFSl5JFWKuIaINalCKSA= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2378.namprd03.prod.outlook.com (10.166.207.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Fri, 18 Nov 2016 07:28:58 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0734.007; Fri, 18 Nov 2016 07:28:57 +0000 From: Brian Raymor To: Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] Next steps for coap-tcp-tls Thread-Index: AdJBZy/pRagtkvg4Sdm9GOeDdbeLvQAA6ayAAABQOwA= Date: Fri, 18 Nov 2016 07:28:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [58.123.138.206] x-microsoft-exchange-diagnostics: 1; CY1PR03MB2378; 7:mBAAsf1GRnyVwh8aPz5CpM5GccqNHTNdawND3Mv3zXAEdVlftK91dZCuQeytoSDVl228OeAr1ChnkRmK+lUpy4ZswifPcCbRh7FUUBjw6FoGojmEM+9cnCOCCZjIYP2aK9HWEbsF/GsPLJi8ctLOjxA/xrRBrv4QOWsqgpoBc4YHhjA9zXrsR1QH+mNWEnZkS0qWABmiIsQLP3GJ36njpFLVNtSuoEkO50LbMoP2HYsBJUULGeGCfXwree9092P1ZUO2osHCJUlklkUcg1fmnOCrqIuTlPXKeuOOdTmDL8iL5hoxM1Aaf6xOIby4ZIR3MDwmI2GVDzy5tldE/qLR9mSSFS7S/zyeHxBR57qHmga4Hc/75+4I3tumXGygOAcW x-ms-office365-filtering-correlation-id: fae38506-d5c7-472d-7281-08d40f848f44 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2378; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045074)(6040281)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061324)(6041223)(6046074)(6042181)(6072148)(6047074); SRVR:CY1PR03MB2378; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2378; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(377454003)(13464003)(52024003)(199003)(5005710100001)(81156014)(3846002)(10290500002)(10090500001)(8936002)(8676002)(81166006)(87936001)(68736007)(77096005)(74316002)(6506003)(33656002)(122556002)(8990500004)(66066001)(102836003)(305945005)(38730400001)(5660300001)(6116002)(97736004)(9686002)(5001770100001)(7696004)(86612001)(54356999)(50986999)(76176999)(76576001)(106356001)(229853002)(105586002)(2906002)(101416001)(107886002)(86362001)(561944003)(2900100001)(7846002)(92566002)(3660700001)(230783001)(7736002)(2950100002)(99286002)(189998001)(3280700002)(12290500005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2378; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 07:28:57.8248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2378 Archived-At: Subject: Re: [core] Next steps for coap-tcp-tls 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 Nov 2016 07:29:02 -0000 Hi Hannes- In part, I asked Jaime for a second WGLC because of the limited participati= on in the first WGLC.=20 We've scheduled a second WGLC for WebPush. I felt that it really polished t= he draft for broader review which was noted in the IESG comments. Measure twice. Cut once. ...Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, November 18, 2016 4:10 PM To: Brian Raymor ; core@ietf.org WG Subject: Re: [core] Next steps for coap-tcp-tls Hi Brian, your proposal to start with RFC7252 as a starting point but I am wondering why there is a need for a second WGLC. Normally, we just take the feedback from the WGLC, incorporate it into the document and then send it to the IESG (if the WGLC comments are not dramatic). Ciao Hannes On 11/18/2016 08:06 AM, Brian Raymor wrote: > =20 >=20 > As editor, my aspiration is to publish coap-tcp-tls-06 for a second WGLC > between December 16-19th. I have editorial issues to address and a few > minor normative issues that I'll raise on the mailing list. The main > blocking point is https://github.com/core-wg/coap-tcp-tls/issues/11. We > need to find a way to quickly move forward and reach rough consensus. >=20 > =20 >=20 > Here is my plan that I've reviewed with Jaime and others: >=20 > =20 >=20 > Following the CoRE WG meeting on Wednesday, I've had several > conversations with people who needed to consult with their organizations > before sharing positions on this issue. Please share details about your > concrete positions and deployment plans/models (if possible) on the > mailing list as soon as possible. Remember that many people did not hear > the microphone discussions on Wednesday - so this is an opportunity to > educate the WG. (I appreciate that we're travelling and then there is a > holiday week for the US participants. Do the best you can.) >=20 > =20 >=20 > My perception was that some of the discussion on Wednesday was not > focused on CoAP+TCP and its scenarios. Please ensure that you're > addressing this specific case rather than constrained devices in general > or CoAP+UDP. Also, remember that we all share the same goals even if > we're proposing different solutions - to ensure that CoAP+TCP addresses > these guidelines (which are the best we have now): >=20 > =20 >=20 > Security Challenges For the Internet Of Things > (2011): >=20 > /It is essential that IoT protocol suites specify a *mandatory to > implement but optional to use security solution*. This will ensure > security is available in all implementations, but configurable to use > when not necessary (e.g., in closed environment)./ >=20 > =20 >=20 > I'll use your information and RFC7252 as a starting point for a pull > request. I plan to schedule a conference call with Hannes, Juan Perez, > and G=F6ran Selander (or Francesca Palombini) late in the week of Decembe= r > 5th based on availability. We'll iterate on the pull request and then > present to the broader working group for review during the week of > December 12th. >=20 > =20 >=20 > Thanks, >=20 > .Brian >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Fri Nov 18 00:14: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 8BE961294C1 for ; Fri, 18 Nov 2016 00:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BnhJt6raOnc for ; Fri, 18 Nov 2016 00:14:45 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 46223129472 for ; Fri, 18 Nov 2016 00:14:45 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g23so21586388wme.1 for ; Fri, 18 Nov 2016 00:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=j6nBPrerRbteirDjwiE9EpoQq6y6KZ6zVCv4Y0Kda1E=; b=JwlJHuEc4nCqsbzCYH07+P3frA5Ym2+6bhA+p/A4UpeHbQRzBd14bD2HtJBJBuT3vM rNSqqw4kuCgv3jzZBuoRsSQnhn9mM6LcUWBxQRtNPQ946Hlj/lrIvMULv02zBI0FnOu4 S5iED23+d3qGfonhLF4koLpT3LYC4hbnqZgmKtuScZ0KvLq12wnxJOyh3Gk7cwpTTXGY /CIxYufOenGSxsnuh+/pJQ7Z4d8By9urpmFuxUv7QUdyXdAYeIyFrU+EnYppW5G0BSY0 F5MWyMfc07cnb/+1270ClWqPkI7x5Hlpc9LY+qQ23fj3Tzv/YRDgjxMbL3BBULzr60vj +Etg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=j6nBPrerRbteirDjwiE9EpoQq6y6KZ6zVCv4Y0Kda1E=; b=mtYUiZlNZ+QUfRwZqJkeDwyoOcWoi/flNP59hjHiqP4CdEkH3uLUhdFpivWMZ6yNhy YSkZwuThWv0/TsCVYWa08lvXyUgHbkYiKtXcF5mpjJHgfFzf61EMPJrhy2tAeTiZeDkh iIlK3cNQn2zS3inprKPgFAG8VvV9J+BTSgCGpW56WQGuVld0V27bQK1HCMz+gwoR5jjF 7ntwbeAuBQubmzm2FECc/ABqEzfkg/eq7knqJzyLw1Zauu3o0tFKYtHiYxYjOD867YZv jXvwDg5wKNP5o0yjTHCxZcwMDWXcdjXsVooIAKMvLY48HLcDJPpGVa9Xur51wcyEMblB QmVw== X-Gm-Message-State: ABUngvflqf+zOvWgvL075VZMQ8pR9SdyDQ5emk4LgeZrZ49F6lE/bxQv/CuTniIj9YPz00cY X-Received: by 10.25.67.2 with SMTP id q2mr1493064lfa.22.1479456883510; Fri, 18 Nov 2016 00:14:43 -0800 (PST) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id 18sm1900020ljj.7.2016.11.18.00.14.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 00:14:42 -0800 (PST) To: core@ietf.org References: <8694cf86-d694-adc4-3d95-b69ad01648b4@gmx.net> From: Ludwig Seitz Message-ID: Date: Fri, 18 Nov 2016 09:14:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8694cf86-d694-adc4-3d95-b69ad01648b4@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020903050802030307000304" Archived-At: Subject: Re: [core] Security aspects in CoAP over TCP 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 Nov 2016 08:14:47 -0000 This is a cryptographically signed message in MIME format. --------------ms020903050802030307000304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-11-18 08:17, Hannes Tschofenig wrote: > ~snip~ > >> But, again, the discussion here should not be about OSCOAP, it is abou= t >> allowing other security protocols for CoAP in the same way as RFC7252 = does. > > The discussion started with the question about what should be stated as= > mandatory-to-implement (MTI). The problem is that the discussion then > turned into OSCOAP vs. TLS. I argue that we should have TLS as MTI. > I think you are missing G=F6ran's point here. Can you please explain why do you think this draft should have a=20 different statement than the one that is in the CoAP RFC? If I understood RFC 7252 correctly (please feel free to correct me),=20 CoAP specifies a binding to DTLS and MTI algorithms iff you use DTLS. It = allows for other security protocols (such as e.g. IPSec, so this is not=20 limited to OSCOAP) by allowing to use NoSec mode at application layer. G=F6ran is only asking that we apply the same principle to the CoAP-TLS=20 specification. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelev=E4gen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order=20 to create a unified institute sector and become a stronger innovation=20 partner for businesses and society. At the end of the year we will=20 change our name to RISE. Read more at www.ri.se/en/about-rise --------------ms020903050802030307000304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjExMTgwODE0NDJaMC8GCSqGSIb3DQEJBDEiBCD+fiL4IwUy AbVRwySVBcta2df+I3iNB8yj9iZrMp/RZDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQB5DHOy99nbjitKbrYS7wqX 4WWZl2p7DXV7nQaBuvMA56tzmBmJ76LbrRr9vnMrVGfj279IEi+I8AmdD6Xc2crq6RULQEnd FXAcKFTH6+cP1VeJCNTo/+tsavSpdThoJjo3owgDvVWfuWaDhSzb6zdMzMKOGwjqVXDya+Bv FNaY1MsT4kePvL99M4wtc84PNhOgUnSsJ5wqe/WhZR93ovI+ax2Am4ldo6jjkylzP/vzZ3C0 RxrBEISCn1g38w6+G3quSsrmcfTic431HgXL6Aqjpx4tConWuQuuX+z+De3mTLG8eFb8opPL G9+em6Nm4rNbF4fD/B/SgOUN/f7odUA8AAAAAAAA --------------ms020903050802030307000304-- From nobody Fri Nov 18 04:17: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 2613D129663 for ; Fri, 18 Nov 2016 04:17:52 -0800 (PST) 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=unavailable 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 AkD-_F5HJ9Wy for ; Fri, 18 Nov 2016 04:17:50 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0092.outbound.protection.outlook.com [104.47.34.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0B2129653 for ; Fri, 18 Nov 2016 04:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TA3NQCABsOZPZYzjpymqrBMlXqBYPw86k9ZEBy5MUZg=; b=R7ejIrr3/hAsorEaVUaSEOzgUz1gO3cZgDCRw0cne9WwJ0zUhf790Zd3Wxf7v5tuq5LPinxtfmEnAAUHcsPbmiBbcNaUS5Ezjx25hIYL1rKG0FxkL6HT4RYDIMsxReCAIdE8PtPhNU/US0bB3la6wMRvFcWqQdSZ0LWY0VdMeAs= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Fri, 18 Nov 2016 12:07:58 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0734.007; Fri, 18 Nov 2016 12:07:58 +0000 From: Brian Raymor To: Brian Raymor , Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] Next steps for coap-tcp-tls Thread-Index: AdJBZy/pRagtkvg4Sdm9GOeDdbeLvQAA6ayAAABQOwAACYgeoA== Date: Fri, 18 Nov 2016 12:07:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [58.123.138.206] x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 7:YiHBSgHLWRa374pKjXGJ3DAmUkhUP0SBF8937ouorWJbm8aKx75fdrtXhJWMm0g+QIZaGakWB4F0BLqgZ9zQ5nQXFNUl3tNXogwV+DGIcfeAnbRdcMVywWykPgHFb0/TJd6ivK53txLXrNc1Fh/jAGVAe4QT/Hyuj3ri4yunO/P+KPVBLJ7UMSUsMZqdkRoeqIQQfMXjnoJsXlECHqG3rCEiRletH2ilFSvwyleAuYdo03NK8saHovzaNMUPKU1GL4hp79LfqP5N9TDNukjHG4d6TzZSbnDU1iLyccDX5MQysW+22Z5pzFAvomQgZNtNkynmmzw/yNnvGPXDSX6uQPRfcXf3NhaN87CL/mK5KEjW3xaCuf67s1yeZqsElN8W x-ms-office365-filtering-correlation-id: 72e581c5-a5af-4c95-f06c-08d40fab8991 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045074)(6040281)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6061324)(6046074)(6041223)(6047074)(6072148); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(13464003)(189002)(52024003)(105586002)(86612001)(2421001)(86362001)(3846002)(6116002)(50986999)(101416001)(106356001)(7696004)(54356999)(8676002)(102836003)(76576001)(2950100002)(561944003)(33656002)(81156014)(76176999)(122556002)(81166006)(6506003)(8936002)(77096005)(5001770100001)(99286002)(97736004)(2900100001)(1511001)(2906002)(5660300001)(189998001)(3660700001)(68736007)(66066001)(2561002)(230783001)(92566002)(3280700002)(5005710100001)(87936001)(10090500001)(10290500002)(8990500004)(7736002)(74316002)(7846002)(229853002)(9686002)(305945005)(107886002)(38730400001)(12290500005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2016 12:07:58.6318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Subject: Re: [core] Next steps for coap-tcp-tls 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 Nov 2016 12:17:52 -0000 Doh. I just realized that my dates are off by a week. I'll blame it on the = jet lag ;-)=20 Take two. Week of 11/21: Holiday week Week of 11/28: Security conference call with Hannes, Juan, and G=F6ran to i= terate on the pull request Week of 12/5: Present security pull request to the WG for review 12/9-12/12: Publish coap-tcp-tls-06 and start the second WGLC -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Friday, November 18, 2016 4:29 PM To: Hannes Tschofenig ; core@ietf.org WG Subject: Re: [core] Next steps for coap-tcp-tls Hi Hannes- In part, I asked Jaime for a second WGLC because of the limited participati= on in the first WGLC.=20 We've scheduled a second WGLC for WebPush. I felt that it really polished t= he draft for broader review which was noted in the IESG comments. Measure twice. Cut once. ...Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, November 18, 2016 4:10 PM To: Brian Raymor ; core@ietf.org WG Subject: Re: [core] Next steps for coap-tcp-tls Hi Brian, your proposal to start with RFC7252 as a starting point but I am wondering why there is a need for a second WGLC. Normally, we just take the feedback from the WGLC, incorporate it into the document and then send it to the IESG (if the WGLC comments are not dramatic). Ciao Hannes On 11/18/2016 08:06 AM, Brian Raymor wrote: > =20 >=20 > As editor, my aspiration is to publish coap-tcp-tls-06 for a second WGLC > between December 16-19th. I have editorial issues to address and a few > minor normative issues that I'll raise on the mailing list. The main > blocking point is https://github.com/core-wg/coap-tcp-tls/issues/11. We > need to find a way to quickly move forward and reach rough consensus. >=20 > =20 >=20 > Here is my plan that I've reviewed with Jaime and others: >=20 > =20 >=20 > Following the CoRE WG meeting on Wednesday, I've had several > conversations with people who needed to consult with their organizations > before sharing positions on this issue. Please share details about your > concrete positions and deployment plans/models (if possible) on the > mailing list as soon as possible. Remember that many people did not hear > the microphone discussions on Wednesday - so this is an opportunity to > educate the WG. (I appreciate that we're travelling and then there is a > holiday week for the US participants. Do the best you can.) >=20 > =20 >=20 > My perception was that some of the discussion on Wednesday was not > focused on CoAP+TCP and its scenarios. Please ensure that you're > addressing this specific case rather than constrained devices in general > or CoAP+UDP. Also, remember that we all share the same goals even if > we're proposing different solutions - to ensure that CoAP+TCP addresses > these guidelines (which are the best we have now): >=20 > =20 >=20 > Security Challenges For the Internet Of Things > (2011): >=20 > /It is essential that IoT protocol suites specify a *mandatory to > implement but optional to use security solution*. This will ensure > security is available in all implementations, but configurable to use > when not necessary (e.g., in closed environment)./ >=20 > =20 >=20 > I'll use your information and RFC7252 as a starting point for a pull > request. I plan to schedule a conference call with Hannes, Juan Perez, > and G=F6ran Selander (or Francesca Palombini) late in the week of Decembe= r > 5th based on availability. We'll iterate on the pull request and then > present to the broader working group for review during the week of > December 12th. >=20 > =20 >=20 > Thanks, >=20 > .Brian >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Nov 18 15:14: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 81B151294C6 for ; Fri, 18 Nov 2016 15:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfXfKtohgbLu for ; Fri, 18 Nov 2016 15:14:50 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 A080D12947E for ; Fri, 18 Nov 2016 15:14:50 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 58623E00780B3; Fri, 18 Nov 2016 23:14:45 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id uAINEnPf013964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2016 23:14:49 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id uAINEmOi014873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Nov 2016 23:14:48 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Fri, 18 Nov 2016 18:14:48 -0500 From: "Carey, Timothy (Nokia - US)" To: Brian Raymor , Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] Next steps for coap-tcp-tls Thread-Index: AQHSQZXSAF7y5nhxvkanLi/JORZw16DfXi0Q Date: Fri, 18 Nov 2016 23:14:47 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7DAC7F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Next steps for coap-tcp-tls 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 Nov 2016 23:14:52 -0000 Brian, Nokia's positions is that a "solution" must be secure. We believe we will see some solutions that use CoAP-TCP/TLS between the de= vice and the server.=20 OMA is thinking the same thing as LWM2M is considered to be added as a bind= ing in the next release. While we believe a "solution" must be secure that doesn't mean we have to m= andate implementation of TLS or have it be on by default. There are good reasons in a constrained world not to burden the UE with mul= tiple security protocols and there are other ways to secure the solution (e= .g., rely on the bearer, e2e security like OSCOAP). So our stance is that TLS should be recommended to be implemented and recom= mended to be turned on. BR, Tim -----Original Message----- From: Brian Raymor [mailto:Brian.Raymor@microsoft.com]=20 Sent: Friday, November 18, 2016 4:29 PM To: Hannes Tschofenig ; core@ietf.org WG Subject: Re: [core] Next steps for coap-tcp-tls Hi Hannes- In part, I asked Jaime for a second WGLC because of the limited participati= on in the first WGLC.=20 We've scheduled a second WGLC for WebPush. I felt that it really polished t= he draft for broader review which was noted in the IESG comments. Measure twice. Cut once. ...Brian -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Friday, November 18, 2016 4:10 PM To: Brian Raymor ; core@ietf.org WG Subject: Re: [core] Next steps for coap-tcp-tls Hi Brian, your proposal to start with RFC7252 as a starting point but I am wondering = why there is a need for a second WGLC. Normally, we just take the feedback = from the WGLC, incorporate it into the document and then send it to the IES= G (if the WGLC comments are not dramatic). Ciao Hannes On 11/18/2016 08:06 AM, Brian Raymor wrote: > =20 >=20 > As editor, my aspiration is to publish coap-tcp-tls-06 for a second=20 > WGLC between December 16-19th. I have editorial issues to address and=20 > a few minor normative issues that I'll raise on the mailing list. The=20 > main blocking point is=20 > https://github.com/core-wg/coap-tcp-tls/issues/11. We need to find a way = to quickly move forward and reach rough consensus. >=20 > =20 >=20 > Here is my plan that I've reviewed with Jaime and others: >=20 > =20 >=20 > Following the CoRE WG meeting on Wednesday, I've had several=20 > conversations with people who needed to consult with their=20 > organizations before sharing positions on this issue. Please share=20 > details about your concrete positions and deployment plans/models (if=20 > possible) on the mailing list as soon as possible. Remember that many=20 > people did not hear the microphone discussions on Wednesday - so this=20 > is an opportunity to educate the WG. (I appreciate that we're=20 > travelling and then there is a holiday week for the US participants.=20 > Do the best you can.) >=20 > =20 >=20 > My perception was that some of the discussion on Wednesday was not=20 > focused on CoAP+TCP and its scenarios. Please ensure that you're=20 > addressing this specific case rather than constrained devices in=20 > general or CoAP+UDP. Also, remember that we all share the same goals=20 > even if we're proposing different solutions - to ensure that CoAP+TCP=20 > addresses these guidelines (which are the best we have now): >=20 > =20 >=20 > Security Challenges For the Internet Of Things=20 > (2011): >=20 > /It is essential that IoT protocol suites specify a *mandatory to=20 > implement but optional to use security solution*. This will ensure=20 > security is available in all implementations, but configurable to use=20 > when not necessary (e.g., in closed environment)./ >=20 > =20 >=20 > I'll use your information and RFC7252 as a starting point for a pull=20 > request. I plan to schedule a conference call with Hannes, Juan Perez,=20 > and G=F6ran Selander (or Francesca Palombini) late in the week of=20 > December 5th based on availability. We'll iterate on the pull request=20 > and then present to the broader working group for review during the=20 > week of December 12th. >=20 > =20 >=20 > Thanks, >=20 > .Brian >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Sat Nov 19 13:56: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 8A8791294B4 for ; Sat, 19 Nov 2016 13:56:26 -0800 (PST) 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 r3wsAXkeSpOm for ; Sat, 19 Nov 2016 13:56:25 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 1040212711D for ; Sat, 19 Nov 2016 13:56:25 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id b126so87258409oia.2 for ; Sat, 19 Nov 2016 13:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=bxFvZ/6Fqy6zpvJvTRgXXpBOgr+1/8h1A8Aochrcl28=; b=L52cf7VC7XzpLoh2joClK2dCj5KqmzJxb/22Axy3kxdWpH53tD2qODRfimrc4IE4gk /z9w41N+16oH0R3TQfrBlHpyTk4+xlN7DkNWbiI4NI2OE0c4Tb9jlmtr9kJNIEERRAb1 GxI4U85B+uZSaERPolU5VEa+D8TsCPJDvoHq+l52sh9h85EZHgGWfK/dVFVsJz14UCFl DQrwNXaOUZcdGYiSbi2CEVPhE0nQxg6xBFNmC7zlXzgcodxWxEykaUhvflR803qeZ94f GY3N/2l6z52ynC2P++8Ps4TUTjWtBYDhhxpYnH4+FWfOmUftwwOuxnfTeEBRKnAMVGRn BkaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bxFvZ/6Fqy6zpvJvTRgXXpBOgr+1/8h1A8Aochrcl28=; b=WhVUkvKZbn+vvfPBa4r08bhByoZ4FtUQ2sc6DnL/WUF9Lmx2MpWoYctIt9VwgoQLQr fgYYtBxyGyZqPFbuK5eoKHi06NM0lGYSr2ARr+HcfEnnlWegen5VVrbwUtHoIfmO9YLj yhzbwVGyyva1ZbLLAbT+uMk/0jgzPdJwIoMnhyamSvL1XqV543Xf7IyOM/fZGRLJoV0C 2yuYFSMgI/DRfEqE2vwE0BmI+h6QaZVwpXtvoFjyHtb6181gKoxefNOmOeXtBoGzSRzp pw4e8B9Gkb0uaxAph9GcJMaWH/LnK3OK5/+eJwBWa3UgOzbmJIy5riuKfs+KoZOCUjrW lv2g== X-Gm-Message-State: AKaTC03MohdNH99Cb+KN8Lfz1uZrHqMS1AZXX59lMvMjgSx0pLfrS0q9r6eUFRgNGj/eHxi8w3Vdi1zpylcDZA== X-Received: by 10.202.48.145 with SMTP id w139mr4052162oiw.216.1479592584262; Sat, 19 Nov 2016 13:56:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.98.1 with HTTP; Sat, 19 Nov 2016 13:56:23 -0800 (PST) From: IoTPTS Chairs Date: Sat, 19 Nov 2016 13:56:23 -0800 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary=001a113cd49a65b8ef0541ae7e97 Archived-At: Subject: [core] Call For Papers - 3rd International Workshop on IoT Privacy, Trust, and Security (IoTPTS'17: April 2, 2017, Abu Dhabi, UAE) 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, 19 Nov 2016 21:56:26 -0000 --001a113cd49a65b8ef0541ae7e97 Content-Type: text/plain; charset=UTF-8 *CALL FOR PAPERS 3rd International Workshop on IoT Privacy, Trust, and Security (IoTPTS 2017) Held in conjunction with ASIACCS on April 2, 2017, in Abu Dhabi, UAE. Paper submission: Jan 20, 2017 Author Notification: Feb 15, 2017 The Internet of Things (IoT) is the next great technology frontier. At a basic level, IoT refers simply to networked devices, but the IoT vision is a complex ecosystem that ranges from cloud backend services and big-data analytics to home, public, industrial, and wearable sensor devices and appliances. Architectures for these systems are in the formative stages, and now is the time to ensure privacy, trust, and security are designed into these systems from the beginning. We encourage submissions on all aspects of IoT privacy, trust, and security. Topics of interest include (but are not limited) to the following areas: Privacy and IoT data Privacy attacks for IoT Trust management and device discoverability for IoT Usability of privacy and security systems in IoT User risk perceptions and modeling for IoT Policy Management and enforcement for IoT Authentication and access control for users for IoT Cryptography for IoT Attack detection and remediation for IoT Security architectures for IoT systems and applications =================================== For more information, see https://sites.google.com/site/iotpts2017/ --001a113cd49a65b8ef0541ae7e97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= *CALL =C2=A0FOR =C2=A0PAPERS

3rd International Wor= kshop on IoT Privacy, Trust, and Security (IoTPTS 2017)

Held in conjunction with ASIACCS on April 2, 2017, in Abu Dhabi, UAE.=

Paper submission: Jan 20, 2017
Author N= otification: Feb 15, 2017

The Internet of Things (= IoT) is the next great technology frontier. At a basic level, IoT refers si= mply to networked devices, but the IoT vision is a complex ecosystem that r= anges from cloud backend services and big-data analytics to home, public, i= ndustrial, and wearable sensor devices and appliances. Architectures for th= ese systems are in the formative stages, and now is the time to ensure priv= acy, trust, and security are designed into these systems from the beginning= .

We encourage submissions on all aspects of IoT p= rivacy, trust, and security.

Topics of interest in= clude (but are not limited) to the following areas:

Privacy and IoT data
Privacy attacks for IoT
Trust ma= nagement and device discoverability for IoT
Usability of privacy = and security systems in IoT
User risk perceptions and modeling fo= r IoT
Policy Management and enforcement for IoT
Authent= ication and access control for users for IoT
Cryptography for IoT=
Attack detection and remediation for IoT
Security arch= itectures for IoT systems and applications

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

--001a113cd49a65b8ef0541ae7e97-- From nobody Mon Nov 21 04:52:46 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 023AF129615 for ; Mon, 21 Nov 2016 04:52: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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui6DUVvnes8D for ; Mon, 21 Nov 2016 04:52:44 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BE112952D for ; Mon, 21 Nov 2016 04:52:44 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud3.xs4all.net with ESMTP id Acsi1u0094h15BW01csiD2; Mon, 21 Nov 2016 13:52:42 +0100 Received: from 2001:983:a264:1:8d0a:fa89:62f4:4b5e by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 21 Nov 2016 13:52:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 21 Nov 2016 13:52:42 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <1b3f3e0b91c6b9a24171f5888a40d6d8@xs4all.nl> X-Sender: stokcons@xs4all.nl (TS9rrXq4lvesD0MM+mFxVVn0xChCZm5N) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Comi payload discussion 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, 21 Nov 2016 12:52:46 -0000 Hi all, In Comi, objects are represented according to the CBOR (key, value) pair. When an object is accessed, the key is specified in the URI, and the value is transported in the payload. For DELETE, PUT, and POST, the request contains all information about the object. however, in the GET, the returned payload contains the value, and the key is unknown. This is very unpleasant for debugging, because it means that the request and return packets must be paired before debugging can take place. I therefore propose that the return of the GET payload contains both the key and the value of the object. the disadvantage is the addition of 2-5 bytes in the payload. Your reactions, please. thanks, peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Mon Nov 21 05: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 44A2312962A for ; Mon, 21 Nov 2016 05:46:22 -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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ICuSruIERH for ; Mon, 21 Nov 2016 05:46:20 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771D2129616 for ; Mon, 21 Nov 2016 05:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=31nEbKWvNX0ptVP6Amv9TYZsr2NGMjEp2SVUckoREIU=; b=H71ih3tbRriikLks53qYwwVjIhq64xL48zkCj3Lx8G0AZCmgBoIFiRHTnw1H3x0Os0+FtT429vSHNuLijBe91feJKAgrqjzZP8scwlzVGLj54obg07+SgbPnkYjq0OtvtPvv+YeiFP7eGU8VlGm4bx66gn3LiHXlXAHQ/l2T48M= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Mon, 21 Nov 2016 13:46:12 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0734.013; Mon, 21 Nov 2016 13:46:12 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] Comi payload discussion Thread-Index: AQHSQ/YshUqrRqXkFU+GiJAU7dp7CaDjb+gg Date: Mon, 21 Nov 2016 13:46:11 +0000 Message-ID: References: <1b3f3e0b91c6b9a24171f5888a40d6d8@xs4all.nl> In-Reply-To: <1b3f3e0b91c6b9a24171f5888a40d6d8@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:ou/mqAacVBWYm+kRMZaWEkVXRGI37x2GqUQzbQW1H4zkQTvZXfB4cv7/gh9tok4KA/IOvr2EaOuK0GcsX3wrUWjuwNvwvUcFY8ThspQhCXeDCXMdtBdXRRHg7pvdVaKKekCEBEoSxU2kH+uAS/iU/02dPvn+LHbHvoBFLl7gbFR30bl7rdcJYBt/rY9hRM8wHD8myPh3821KEFCtGVZEnCU5VuMlnAbP1guUXqTZuDtGNYqvklMqZywIoizabI6KRwPkTZwxifeM3fTw+yW+QTwCom9HdptZoMICOuXE+QLXavRs44jUczzIyeCsKmAa48Q4cTa5x9s02L4Zekm90HdDjqImeiiyH8hKKb4nYhg= x-ms-office365-filtering-correlation-id: c467943c-9af2-42fe-0ae1-08d41214c188 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324)(6072148); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(53754006)(377454003)(189002)(2900100001)(81156014)(5660300001)(2906002)(81166006)(101416001)(6116002)(8676002)(102836003)(3846002)(77096005)(92566002)(54356999)(76176999)(15974865002)(122556002)(2501003)(50986999)(86362001)(106356001)(2950100002)(87936001)(9686002)(66066001)(3660700001)(99286002)(68736007)(3280700002)(305945005)(74316002)(105586002)(7846002)(7736002)(33656002)(76576001)(107886002)(6506003)(189998001)(106116001)(97736004)(7696004)(38730400001)(8936002)(229853002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 21 Nov 2016 13:46:11.9374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Subject: Re: [core] Comi payload discussion 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 Nov 2016 13:46:22 -0000 Hi Peter The only way to debug a GET response is to known the GET request, its URI, = its CoAP options. Adding the data node identifier (SID) to the response payload is insufficie= nt to qualify the information returned and not typical for CoAP. See RFC 7252, section 2.2. Request/Response Model https://tools.ietf.org/html/rfc7252#section-2.2 GET /temperature 2.05 Content "22.5 C" Similarly in CoMI: GET /c/Bf4?k=3Deth0 2.05 Content "Ethernet adapter" Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Monday, November 21, 2016 7:53 AM To: Core Subject: [core] Comi payload discussion Hi all, In Comi, objects are represented according to the CBOR (key, value) pair. When an object is accessed, the key is specified in the URI, and the value = is transported in the payload. For DELETE, PUT, and POST, the request contains all information about the o= bject. however, in the GET, the returned payload contains the value, and the key i= s unknown. This is very unpleasant for debugging, because it means that the request an= d return packets must be paired before debugging can take place. I therefore propose that the return of the GET payload contains both the ke= y and the value of the object. the disadvantage is the addition of 2-5 bytes in the payload. Your reactions, please. thanks, peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Nov 22 00:29: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 4863B12969C for ; Tue, 22 Nov 2016 00:29:12 -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 s7qm8O0We_9N for ; Tue, 22 Nov 2016 00:29:10 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503D61296CC for ; Tue, 22 Nov 2016 00:29:10 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud3.xs4all.net with ESMTP id AwV81u0074QBLo201wV8Zt; Tue, 22 Nov 2016 09:29:08 +0100 Received: from 2001:983:a264:1:d39:7aed:8e68:7f8c by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 22 Nov 2016 09:29:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 22 Nov 2016 09:29:08 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <1b3f3e0b91c6b9a24171f5888a40d6d8@xs4all.nl> Message-ID: <1597407ea7d5152fc9de385d7a1b484a@xs4all.nl> X-Sender: stokcons@xs4all.nl (cBUbtsJDc1GHKypwLYCGDfBDmpInuSzN) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Comi payload discussion 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, 22 Nov 2016 08:29:12 -0000 Hi Michel, Indeed a very good observation, that you need more info than only the SID. I like to limit the discussion to CoMI. For example 2, the debugger knows it is a value of Bf4 and not the temperature. And the analysis tool can find the enveloping container or list. Peter Michel Veillette schreef op 2016-11-21 14:46: > Hi Peter > > The only way to debug a GET response is to known the GET request, its > URI, its CoAP options. > Adding the data node identifier (SID) to the response payload is > insufficient to qualify the information returned and not typical for > CoAP. > > See RFC 7252, section 2.2. Request/Response Model > https://tools.ietf.org/html/rfc7252#section-2.2 > GET /temperature > > 2.05 Content > "22.5 C" > > Similarly in CoMI: > GET /c/Bf4?k=eth0 > > 2.05 Content > "Ethernet adapter" > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: Monday, November 21, 2016 7:53 AM > To: Core > Subject: [core] Comi payload discussion > > Hi all, > > In Comi, objects are represented according to the CBOR (key, value) > pair. > When an object is accessed, the key is specified in the URI, and the > value is transported in the payload. > For DELETE, PUT, and POST, the request contains all information about > the object. > however, in the GET, the returned payload contains the value, and the > key is unknown. > This is very unpleasant for debugging, because it means that the > request and return packets must be paired before debugging can take > place. > > I therefore propose that the return of the GET payload contains both > the key and the value of the object. > the disadvantage is the addition of 2-5 bytes in the payload. > > Your reactions, please. > > thanks, > > peter > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Nov 22 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 E7C2E129EED for ; Tue, 22 Nov 2016 10:01:59 -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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmoiZCbC2OaW for ; Tue, 22 Nov 2016 10:01:58 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0E0129D8B for ; Tue, 22 Nov 2016 09:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CAY3xgUTarSHGwWmXwlSevshFxaDN3H2lo/tnyz+DgU=; b=ZsH3Pjxd34v32eaKwEeKzKapjkg/4T+rwuVSZNylxAreMWkq8P3uoNSsEpCcmrmrN5V79wAh97W8Z1AA/Qe9L6f0sChriBmhfxigcTnJ6zoD0BDclz6UqCARI3KCop41p3CnpP6hzfjNpG47Md0Neao7U5LJm3sGSu+KWfOiQLo= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 17:59:13 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 17:59:12 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] yang cbor comments Thread-Index: AQHSQLpL47EAr//15UCwVCri7zu5mqDdWvVAgACFSgCAB2rIMA== Date: Tue, 22 Nov 2016 17:59:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:dJitdfgV5FzeuqBqOBSNuZ6nYxEjGuyiLS0HVf2HlqFZxUGmri4da0P5if/NhWrkbKYkdmBcvqHZbuEJL0sOMjw/Gc04C3hiGAJucMTxRQy8D7hM7tPTJd5rXUjRZVlI6ey7gTwRQsyrTQ7Vn9vpBkPS7MRmUwCAyC46sDwG0NYSHCFB0zB1Bl/oL1zs8wwxWs7M/zW/0sZNgE4nUG9B8yREyAb8OmkxIaWX4PPnanNgXOrqpeikr7rdZpwUlMLvXe9ukSOgeFUAeOZdKygj0xat8fuQ1e1FSs7K6wdHMwEZN4c6drjJhWxm3OPDHGMA0zT2gIiGJgvtGrknueVV7P5ot1zKvzREHJi9w2CYl+A= x-ms-office365-filtering-correlation-id: 9a6d5a37-83d6-4a79-f465-08d413014465 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2307; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(150554046322364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6040307)(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(6061324)(6042181); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(106356001)(76576001)(2900100001)(7846002)(74316002)(229853002)(5640700001)(7736002)(305945005)(105586002)(1730700003)(33656002)(77096005)(66066001)(8676002)(106116001)(38730400001)(110136003)(7696004)(92566002)(2501003)(97736004)(189998001)(99286002)(6506003)(5660300001)(6916009)(68736007)(4326007)(3846002)(9686002)(2950100002)(81166006)(81156014)(8936002)(50986999)(54356999)(15395725005)(76176999)(3280700002)(2351001)(2906002)(101416001)(86362001)(122556002)(102836003)(6116002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 22 Nov 2016 17:59:12.7748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] yang cbor comments 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 Nov 2016 18:02:00 -0000 SGkgUGV0ZXINCg0KQW5zd2VycyBbTVZdIGlubGluZQ0KVXBkYXRlZCBkcmFmdCBpcyBhdmFpbGFi bGUgb24gR0lULg0KaHR0cDovL2NvcmUtd2cuZ2l0aHViLmlvL3lhbmctY2Jvci9kcmFmdC1pZXRm LWNvcmUteWFuZy1jYm9yLWxhdGVzdC50eHQNCg0KUmVnYXJkcywNCk1pY2hlbA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGV0ZXIgdmFuIGRlciBTdG9rIFttYWlsdG86c3Rv a2NvbnNAeHM0YWxsLm5sXSANClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNywgMjAxNiA3OjE1 IFBNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMu Y29tPg0KQ2M6IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBDb3JlIDxjb3JlQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtjb3JlXSB5YW5nIGNib3IgY29tbWVudHMNCg0KU2VlIGlubGluZQ0K PiANCj4gPT09PT4gUGFnZSA0OiBkZWx0YTsgbm90IG9ubHkgZGlmZmVyZW5jZSB3aXRoIHRoZSBw YXJlbnQgYnV0IGFsc28gDQo+IGRpZmZlcmVuY2Ugd2l0aCBwcmVkZWNlc3NvciBpbiBhIENCT1Ig YXJyYXkuDQo+IA0KPiBbSS1ELmNvcmUteWFuZy1jYm9yXSBvbmx5IG1ha2UgdXNlIG9mIHBhcmVu dCBkZWx0YSwgc2libGluZyBkZWx0YSBpcyANCj4gdXNlZCBieSB0aGUgcm9vdCBjb2xsZWN0aW9u IG9mIHNvbWUgQ29NSSBtZXRob2RzLg0KPiBTaG91bGQgd2UgaGF2ZSBhIGNvbW1vbiBkZWZpbml0 aW9uIG9mIGRlbHRhIGZvciBib3RoIGRvY3VtZW50cyBvciANCj4gc2hvdWxkIHdlIHRhaWxvciB0 aGUgZGVmaW5pdGlvbiBmb3IgZWFjaCBvbmU/DQo+IFdoaWNoIGFwcHJvYWNoIHdpbGwgYmUgdGhl IGxlc3MgY29uZnVzaW5nPw0KDQpJIGV4cGVjdCB0aGUgQ29NSSBkb2N1bWVudCB0byB1c2UgdGhl IGRlZmluaXRpb24gb2YgWUFORy1DQk9SIGRvYy4NCg0KW01WXSBEZWZpbml0aW9uIHVwZGF0ZWQg d2l0aCB0aGUgb25lIGRlZmluZWQgaW46DQpbTVZdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNvcmUtc2lkLTAwI3NlY3Rpb24tMiANCiBbTVZdIGRlbHRhIDogRGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZSBjdXJyZW50IFNJRCBhbmQgYSByZWZlcmVuY2UgU0lELiBBIHJlZmVy ZW5jZSBTSUQgaXMgZGVmaW5lZCBmb3IgZWFjaCBjb250ZXh0IGZvciB3aGljaCBkZWx0YXMgYXJl IHVzZWQuDQoNCj4gDQo+ID09PT0+IFBhZ2UgNSBpcyB0aGlzIOKAnCPigJ0gYSBwb3VuZCBzaWdu Pw0KPiANCj4gJyMnIGlzIHRoZSBjb21tZW50IGRlbGltaXRlciBjdXJyZW50bHkgdXNlZCBieSBb SS1ELmNvcmUteWFuZy1jYm9yXS4NCj4gSXMgdGhlcmUgYSBuZXcgc3RhbmRhcmRpemVkIHdheSB0 byBhZGQgY29tbWVudHMgdG8gQ0JPUiBkaWFnbm9zdGljIA0KPiBub3RhdGlvbiB3ZSBjYW4gdXNl Pw0KIiMiIGlzIE9LLCBpdCBpcyBjYWxsZWQgZGlmZmVyZW50bHk6IGUuZy4gc2hhcnAgYnV0IG5v dCBwb3VuZC4NCg0KW01WXSBDb21tZW50IGRlbGltaXRlcnMgaGF2ZSBiZWVuIHVwZGF0ZWQgdG8g YmUgYWxpZ25lZCB3aXRoIA0KW01WXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRsLTA5I2FwcGVuZGl4LUcuNQ0KW01WXSBBbnkg dGV4dCB3aXRoaW4gYW5kIGluY2x1ZGluZyBhIHBhaXIgb2Ygc2xhc2hlcyBpcyBjb25zaWRlcmVk IGEgY29tbWVudC4iDQpbTVZdIEV4YW1wbGVzIGNhbiBub3cgYmUgY29weS9wYXN0ZWQgdG8gaHR0 cDovL2Nib3IubWUvIHdpdGhvdXQgZXJyb3JzLg0KIA0KPiA9PT09PiBQYWdlIDYsIGxpbmUgMTUg dXNlZCBzb2xlbHkgZm9yIHVuaW9uPzsgdGhlcmUgYXJlIDQgdGFncyBkZWZpbmVkLg0KPiANCj4g Tm90IHN1cmUgd2hhdCBpcyB0aGUgaXNzdWUgaGVyZS4NCj4gVGhlIHNlbnRlbmNlIHN0YXJ0IGJ5 ICJDQk9SIHRhZ3MiIHBsdXJhbCB0byBhY2NvdW50IGZvciB0aGUgZmFjdCB3ZSANCj4gc3VwcG9y dCBtdWx0aXBsZSB0YWdzLg0KPiBIb3dldmVyLCBJJ20gYWRkaW5nIGFueXhtbCB3aGljaCBhbHNv IHJlcXVpcmUgdGhlIHVzZSBvZiB0YWdzLg0KPiAiRm9yIGluc3RhbmNlLCBDQk9SIHRhZ3MgYXJl IHVzZWQgc29sZWx5IGluIHRoZSBjYXNlIG9mIGFueXhtbCBkYXRhIA0KPiBub2RlcyBhbmQgdGhl IHVuaW9uIGRhdGF0eXBlIHRvIGRpc3Rpbmd1aXNoIC4uLiINCg0KSXQgaXMgdGhlIHdvcmQgInNv bGVseSI7IEkgd2FzIGFmcmFpZCBpdCByZW1haW5lZCBmcm9tIGVhcmxpZXIgdmVyc2lvbnMuDQo+ IA0KDQpbTVZdIEFscmVhZHkgZml4ZWQgaW4gZ2l0DQoNCj4gPT09PT4gRXhhbXBsZSBwYWdlIDg7 IHRoZSBsZWFmIGhvc3RuYW1lIGlzIG1pc3NpbmcgaW4gdGhlIGRpYWdub3N0aWMgDQo+IENCT1Ig YW5kIENCT1IgKHR3aWNlIGZvciBuYW1lcyBhbmQgU0lEcykgU2VjdGlvbiA0LjMsIHdoeSBpcyB0 aGUgDQo+IHNlYXJjaCBpZGVudGlmaWVyIG1pc3NpbmcgaW4gdGhlIGV4YW1wbGU/DQo+IA0KPiBS ZW1vdmluZyBob3N0bmFtZSBmb3JtIHRoZSBkZWZpbml0aW9uLg0KPiBUaGUgaWV0Zi1zeXN0ZW0s IGhvc3RuYW1lIGlzIGluIGEgY29tcGxldGVseSBkaWZmZXJlbnQgcGFydCBvZiB0aGUgDQo+IG1v ZHVsZS4NCj4gU2VlDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3lhbmctY2Jvci9ibG9i L21hc3Rlci9yZWdpc3RyeS9pZXRmLXN5c3RlbSUNCj4gNDAyMDE0LTA4LTA2LnRyZWUNCg0KQ2Fu IHRoaXMgYmUgYWRhcHRlZCwgSXQgaXMgY29uZnVzaW5nIHRvIGtub3cgd2hhdCBiZWxvbmdzIHRv IGV4YW1wbGUgYW5kIHdoYXQgbm90DQoNCj4gPT09PT4gUGFnZSAxMiBhbmQgMTMsIHdoYXQgaGFw cGVuZWQgdG8gdGhlIHNlcnZlciBpZGVudGlmaWVyIGluIHRoZSANCj4gZXhhbXBsZT8NCj4gDQo+ IE5vbmUgb2YgdGhlIFlBTkcgRGF0YSBOb2RlIEluc3RhbmNlcyBkZWZpbmVkIGluIHNlY3Rpb24g NCAobGVhZiwgDQo+IGNvbnRhaW5lciwgbGVhZi1saXN0LCBsaXN0LCBhbnlkYXRhLCBhbnl4bWwp IGlzIGVuY29kZWQgd2l0aCBpdHMgDQo+IGlkZW50aWZpZXIuDQo+IFN1Y2ggaWRlbnRpZmllcnMg YXJlIHBhcnQgb2YgdGhlIGluc3RhbmNlLWlkZW50aWZpZXIgY2FycnkgaW4gdGhlIA0KPiByZXF1 ZXN0IFVSSSBvciB3aXRoaW4gdGhlIHBheWxvYWQuDQoNCkFnYWluLCBJIGZpbmQgaXQgY29uZnVz aW5nOyBTb21lIHRleHQgaXMgbmVlZGVkIHRvIHBhcnNlIHRoZSBleGFtcGxlcy4gDQpTYXkgdGhh dCBvbmx5IHRoZSB2YWx1ZSBvZiB0aGUgcGFpciBpcyBzaG93bi4NCj4gDQoNCj4gPT09PT4gRXhh bXBsZXMgb2Ygc2VjdGlvbiA1LiBEbyB0aGUgZXhhbXBsZXMgbm90IG5lZWQgYW4gaWRlbnRpZmll ciANCj4gKENCT1Iga2V5KT8gV2Ugbm93IGFyZSBmYWNlZCB3aXRoIHZhbHVlcyB3aGljaCBkbyBu b3QgYmVsb25nIGFueXdoZXJlLg0KPiBBbHNvIHRoZSBTSUQgdmFsdWUgbmVlZHMgdG8gYmUgc3Bl Y2lmaWVkLiBGb3IgZXhhbXBsZSBzZWN0aW9uIDUuMSBjYW4gDQo+IGJlIHdyaXR0ZW4gYXMgZm9s bG93czoNCj4gVGhlIGxlYWYgbXR1IGlzIGFzc3VtZWQgdG8gaGF2ZSB2YWx1ZSAxMjgwIFRoZSBz aWQgb2YgbXR1IGlzIDEzNTAgVGhlIA0KPiBDQk9SIGRpYWdub3N0aWMgbm90YXRpb24gb2YgdGhl IHBhaXIgaXMgMTM1MDogMTI4MCwgd2hpY2ggcmVzdWx0cyBpbiANCj4gUGFnZSAxNSAvc2lnbmVk IGludGVnZXIvbmVnYXRpdmUgaW50ZWdlci8NCj4gDQo+IFNhbWUgYW5zd2VyIGFzIGFib3ZlLg0K PiBOb25lIG9mIHRoZSBZQU5HIERhdGEgTm9kZSBJbnN0YW5jZXMgZGVmaW5lZCBpbiBzZWN0aW9u IDQgKGxlYWYsIA0KPiBjb250YWluZXIsIGxlYWYtbGlzdCwgbGlzdCwgYW55ZGF0YSwgYW55eG1s KSBpcyBlbmNvZGVkIHdpdGggaXRzIA0KPiBpZGVudGlmaWVyLg0KPiBTdWNoIGlkZW50aWZpZXJz IGFyZSBwYXJ0IG9mIHRoZSBpbnN0YW5jZS1pZGVudGlmaWVyIGNhcnJ5IGluIHRoZSANCj4gcmVx dWVzdCBVUkkgb3Igd2l0aGluIHRoZSBwYXlsb2FkLg0KPiBUaGlzIGlzIHRoZSBqb2Igb2YgQ29N SQ0KPiANCj4gID09PT0+U2VjdGlvbiA1LjEwLjE7IGl0IGlzIHVuY2xlYXIgd2hlcmUgdGhlIHZh bHVlIDExODAgY29tZXMgZnJvbS4NCg0KSSBzZWVtIHRvIGV4cHJlc3MgbXlzZWxmIGJhZGx5Lg0K SXQgaXMgb25seSBuZWVkZWQgdG8gc2F5IHRoYXQgbXR1IGlzIGFzc3VtZWQgdG8gaGF2ZSB2YWx1 ZSAxMjgwICBhbmQgdGhhdCB0aGUgQ0JPUiBlbmNvZGluZyBvZiAxMjgwIGlzOg0KDQpBdCB0aGlz IG1vbWVudCB0aGUgc2NvcGUgb2YgdGhlIGV4YW1wbGUgQ0JPUiBjb2RlIGlzIHVuY2xlYXIuDQoN CltNVl0gaW4gc2VjdGlvbiA1LjEsIHRoZSBleGFtcGxlIGlzIGludHJvZHVjZWQgd2l0aCB0aGUg c2VudGVuY2U6DQpbTVZdICJUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhlIGVuY29kaW5n IG9mIGxlYWYgJ210dScgc2V0IHRvIDEyODAgYnl0ZXMuIg0KW01WXSBJcyBpdCB0aGUgcGFydCB0 aGF0IGlzIHVuY2xlYXI/DQpbTVZdIENhbiB5b3UgcHJvcG9zZSBhbiB1cGRhdGVkIHRleHQgdG8g Y2xhcmlmeSB0aGlzIGV4YW1wbGU/DQoNCj4gPT09PT4gU2VjdGlvbiA1LjEzIGlzIHZlcnkgdW5j bGVhci4gVGhlcmUgYXJlIG1hbnkgZXhhbXBsZXMgYnV0IGl0IGlzIA0KPiBub3QgY2xlYXIgd2hl cmUgYWxsIHRoZXNlIHZhbHVlcyBjb21lIGZyb207IHdoYXQgaXMgdGhlIFNJRCB2YWx1ZSwgDQo+ IHdoYXQgd2FzIHRoZSBsZWFmIGluc3RhbmNlIHZhbHVlLCBpcyBvbmUgbGFyZ2UgcHV6emxlLiBP bmUgZXhhbXBsZSANCj4gKGluc3RlYWQgb2YgMyksIGJ1dCB3aXRoIG1vcmUgZXhwbGFuYXRpb25z IHdvdWxkIGhlbHAuIEluIG15IG9waW5pb24gDQo+IHRoZSB0ZXh0IGluIGJlbG9uZ3MgaW4gdGhl IEZFVENIIGNvbnRlbnQgZm9ybWF0IGRvY3VtZW50IHRoYXQgc3RpbGwgDQo+IG5lZWRzIHRvIGJl IHdyaXR0ZW4uDQo+IA0KPiBUaGUgbXVsdGlwbGUgZXhhbXBsZXMgaGF2ZSBiZWVuIHJlcXVlc3Rl ZCBieSBkaWZmZXJlbnQgcGVvcGxlcyANCj4gaW5jbHVkaW5nIENhcnN0ZW4uDQo+IFRoZXNlIGV4 YW1wbGVzIHNob3cgY29tcGxldGVseSBkaWZmZXJlbnQgdXNlIGNhc2VzLCBzaW5nbGUgaW5zdGFu Y2UgDQo+IGRhdGEgbm9kZSwgbGlzdCBhbmQgbGlzdCBpbnN0YW5jZSBhbmQgYXJlIGFsbCB1c2Vm dWwuDQo+IEZvciB0aGUgcXVlc3Rpb24sICJ3aGF0IGlzIHRoZSBTSUQgdmFsdWUiLCB0aGlzIHdp bGwgYmUgcmVzb2x2ZWQgYnkgDQo+IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgcmVnaXN0cmFy cyBzaGFyaW5nIGEgY29tbW9uIGRhdGFiYXNlDQo+IChibG9ja2NoYWluKSBvZiAuc2lkIGZpbGVz Lg0KDQpwbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBhYm92ZS4NCk5vdCB0aGUgZXhhbXBsZXMgYXJl IHF1ZXN0aW9uZWQgYnV0IGFuIGV4cGxhbmF0aW9uIGlzIG5lZWRlZCB0aGF0IHNheXMgdGhhdCB0 aGUgQ0JPUiBjb2RlIGZvciB0aGUgdmFsdWUgaXMgc2hvd24gYW5kIG5vdCB0aGUgd2hvbGUgbGVh Zi4NCg0KW01WXSBUaGlzIHRvcGljIGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUteWFuZy1jYm9yLTAzI3NlY3Rpb24tMyAN CltNVl0NCltNVl0gICAiQmFzaWMgc2NoZW1hIG5vZGVzIHN1Y2ggYXMgbGVhZiwgbGVhZi1saXN0 LCBsaXN0LCBhbnlkYXRhIGFuZCBhbnl4bWwgY2FuIGJlIGVuY29kZWQgc3RhbmRhbG9uZS4NCltN Vl0gICAgSW4gdGhpcyBjYXNlLCBvbmx5IHRoZSB2YWx1ZSBvZiB0aGlzIHNjaGVtYSBub2RlIGlz IGVuY29kZWQgaW4gQ0JPUi4gSWRlbnRpZmljYXRpb24gb2YgdGhpcyB2YWx1ZSBuZWVkcw0KW01W XSAgICB0byBiZSBwcm92aWRlZCBieSBzb21lIGV4dGVybmFsIG1lYW5zIHdoZW4gcmVxdWlyZWQu DQpbTVZdICAgIEEgY29sbGVjdGlvbiBzdWNoIGFzIGNvbnRhaW5lciwgbGlzdCBpbnN0YW5jZSwg bm90aWZpY2F0aW9uLCBSUEMgaW5wdXQsIFJQQyBvdXRwdXQsIGFjdGlvbiBpbnB1dCBhbmQgYWN0 aW9uDQpbTVZdICAgIG91dHB1dCBpcyBzZXJpYWxpemVkIHVzaW5nIGEgQ0JPUiBtYXAgaW4gd2hp Y2ggZWFjaCBjaGlsZCBzY2hlbWEgbm9kZSBpcyBlbmNvZGVkIHVzaW5nIGEga2V5IGFuZCBhIHZh bHVlLiINCltNVl0NCltNVl0gQ2FuIHlvdSBwcm9wb3NlIGFuIHVwZGF0ZWQgdGV4dCB0byBjbGFy aWZ5IHRoaXMgdG9waWM/DQoNCj4gDQo+IC0tDQo+IFBldGVyIHZhbiBkZXIgU3Rvaw0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBt YWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Tue Nov 22 13:30: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 9171A129A2C for ; Tue, 22 Nov 2016 13:30:29 -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, HTML_MESSAGE=0.001, 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 j0ILeLOwSr_T for ; Tue, 22 Nov 2016 13:30:26 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1355129A0B for ; Tue, 22 Nov 2016 13:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qyah1Zhrld6g8FtgDgdmZ71i70v/cupyaN1ARuE3Qcs=; b=SXw18T5wJ4HQ9VeMMS+HeT0wdvEVTwp7JiCctiasGwJClZJClHqlhnViz6mtZVxmPZqekphec21dcDQLzrZRGCw7Ot9Rt/bPmlAT5SUSgBHGj+iLsQjNYpppqIXmyA3ygs0+6maJn+LQ1sIEwNxbWEMIycFigpMjhLDcAfYlGCk= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 21:30:19 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 21:30:19 +0000 From: Michel Veillette To: Carsten Bormann Thread-Topic: [core] yang cbor comments Thread-Index: AQHSQLpL47EAr//15UCwVCri7zu5mqDdWvVAgABM/gCAAADQgIAAByCAgAfZdlA= Date: Tue, 22 Nov 2016 21:30:19 +0000 Message-ID: References: <79A729D4-75E6-4DAC-BE05-CE7CF3F2C907@tzi.org> <4F62E1C7-C519-4A23-B037-8A8376D1F7FB@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: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:MnN2rZRMW66uieOWQq1a7Z7vgveQvrtviJzvtKeFUVco3LtMf3JLg4VmCWoaIOAbEWTcKholvFbuiZ9O95AgT7FlW2n/IfRXwAtx5D8TIRtPDmYwqmrc1OwWGedGQEKHrb76mfK29/tQjtusCLJ3MaK0HHASUPUzczPyNCDCRO/mj/36lvFidmK8s8i2ZE8PSs0+zC7rgd5Pa4oX/yqQ4pw4NTw0IxN8/wLukASPEpsuBtDnA79Eh/dUacuRdJJmy2pUSgod1d+lDbEZaDJoYC5UPmqI98VypC9q7icX06MUyssZOkti7EbIwYwDhT1INLsqoUCuboy9Qro6GnrEZ8UCDA4wXIe3qZG5Jwi2hB0= x-ms-office365-filtering-correlation-id: 33122a58-7435-4dc9-1f55-08d4131ec21c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6040307)(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(6061324)(6042181); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2308; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(92566002)(2900100001)(33656002)(5660300001)(189998001)(790700001)(76576001)(122556002)(3846002)(38730400001)(6116002)(2950100002)(102836003)(101416001)(6916009)(8676002)(7696004)(105586002)(229853002)(99286002)(81156014)(6506003)(106356001)(54356999)(106116001)(76176999)(50986999)(97736004)(77096005)(81166006)(3660700001)(3280700002)(74316002)(110136003)(8936002)(7846002)(7736002)(93886004)(68736007)(4326007)(66066001)(86362001)(2906002)(9686002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308A7C62619230033047D45FEB40BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 21:30:19.1210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Cc: Core Subject: Re: [core] yang cbor comments 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 Nov 2016 21:30:29 -0000 --_000_BN6PR06MB2308A7C62619230033047D45FEB40BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2Fyc3Rlbg0KDQoNCg0KVG8gY2xhcmlmeSB0aGVzZSBpdGVtcywgSSdtIHByb3Bvc2luZyB0 byBwcm9tb3RlIHNlY3Rpb24gMyAoWUFORyBTY2hlbWEgSXRlbSBpRGVudGlmaWVyKSBhcyBzZWN0 aW9uIDEgKEludHJvZHVjdGlvbikuIFRoZSBmb2xsb3dpbmcgaGlnaGxpZ2h0ZWQgdGV4dCBoYXZl IGJlZW4gYWRkZWQvdXBkYXRlZCB0byBhZGRyZXNzIHRoZXNlIGl0ZW1zLg0KDQoNCg0KUGxlYXNl IHJldmlldywgY29tbWVudCwgcHJvcG9zZSBhbHRlcm5hdGUgdGV4dC4NCg0KDQoNClJlZ2FyZHMs DQoNCk1pY2hlbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KMS4gSW50cm9kdWN0aW9uDQoNCg0KDQpTb21lIG9mIHRo ZSBpdGVtcyBkZWZpbmVkIGluIFlBTkcgW1JGQzc5NTBdIHJlcXVpcmUgdGhlIHVzZSBvZiBhIHVu aXF1ZSBpZGVudGlmaWVyLiAgSW4gYm90aCBORVRDT05GIGFuZCBSRVNUQ09ORiwgdGhlc2UgaWRl bnRpZmllcnMgYXJlIGltcGxlbWVudGVkIHVzaW5nIG5hbWVzLiAgVG8gYWxsb3cgdGhlIGltcGxl bWVudGF0aW9uIG9mIGRhdGEgbW9kZWxzIGRlZmluZWQgaW4gWUFORyBpbiBjb25zdHJhaW5lZCBk ZXZpY2VzIGFuZCBjb25zdHJhaW5lZCBuZXR3b3JrcywgYSBtb3JlIGNvbXBhY3QgbWV0aG9kIHRv IGlkZW50aWZ5IFlBTkcgaXRlbXMgaXMgcmVxdWlyZWQuIFRoaXMgY29tcGFjdCBpZGVudGlmaWVy LCBjYWxsZWQgU0lELCBpcyBlbmNvZGVkIHVzaW5nIGFuIHVuc2lnbmVkIGludGVnZXIuIFRoZSBm b2xsb3dpbmcgaXRlbXMgYXJlIGlkZW50aWZpZWQgdXNpbmcgU0lEczoNCg0KDQoNCm8gIGlkZW50 aXRpZXMNCg0KDQoNCm8gIGRhdGEgbm9kZXMNCg0KDQoNCm8gIFJQQ3MgYW5kIGFzc29jaWF0ZWQg aW5wdXQocykgYW5kIG91dHB1dChzKQ0KDQoNCg0KbyAgYWN0aW9ucyBhbmQgYXNzb2NpYXRlZCBp bnB1dChzKSBhbmQgb3V0cHV0KHMpDQoNCg0KDQpvICBub3RpZmljYXRpb25zIGFuZCBhc3NvY2lh dGVkIGluZm9ybWF0aW9uDQoNCg0KDQpvICBZQU5HIG1vZHVsZXMsIHN1Ym1vZHVsZXMgYW5kIGZl YXR1cmVzDQoNCg0KDQpUbyBtaW5pbWl6ZSBpdHMgc2l6ZSwgU0lEcyBhcmUgb2Z0ZW4gaW1wbGVt ZW50ZWQgdXNpbmcgYSBkZWx0YSBmcm9tIGEgcmVmZXJlbmNlIFNJRCBhbmQgdGhlIGN1cnJlbnQg U0lELiBDb252ZXJzaW9uIGZyb20gU0lEcyB0byBkZWx0YXMgYW5kIGJhY2sgdG8gU0lEcyBhcmUg c3RhdGVsZXNzIHByb2Nlc3NlcyBzb2xlbHkgYmFzZWQgb24gdGhlIGRhdGEgc2VyaWFsaXplZCBv ciBkZXNlcmlhbGl6ZWQuDQoNCg0KDQpUbyBndWFyYW50eSB0aGUgdW5pcXVlbmVzcyBvZiBlYWNo IGFzc2lnbmVkIFNJRCwgU0lEIHJhbmdlcyBNVVNUIGJlIHJlZ2lzdGVyZWQuIFNlY3Rpb24gNy4x IHByb3ZpZGUgbW9yZSBkZXRhaWxzIGFib3V0IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBvZiBT SUQgcmFuZ2UocykuDQoNCg0KDQpBc3NpZ25tZW50IG9mIFNJRHMgY2FuIGJlIGF1dG9tYXRlZCwg dGhlIHJlY29tbWVuZGVkIHByb2Nlc3MgdG8gYXNzaWduIFNJRHMgaXMgYXMgZm9sbG93czoNCg0K DQoNCm8gIEEgdG9vbCBleHRyYWN0cyB0aGUgZGlmZmVyZW50IGl0ZW1zIGRlZmluZWQgZm9yIGEg c3BlY2lmaWMgWUFORyBtb2R1bGUuDQoNCg0KDQpvICBUaGUgbGlzdCBvZiBpdGVtcyBpcyBvcmRl cmVkIGJ5IHR5cGUgYW5kIGxhYmVsLg0KDQoNCg0KbyAgU0lEcyBhcmUgYXNzaWduZWQgc2VxdWVu dGlhbGx5IGZvciB0aGUgZW50cnkgcG9pbnQgdXAgdG8gdGhlIHNpemUgb2YgdGhlIHJlZ2lzdGVy ZWQgU0lEIHJhbmdlLiAgVGhpcyBhcHByb2FjaCBpcyByZWNvbW1lbmRlZCB0byBtaW5pbWl6ZSB0 aGUgc2VyaWFsaXphdGlvbiBvdmVyaGVhZCwgZXNwZWNpYWxseSB3aGVuIGRlbHRhIGVuY29kaW5n IGlzIGltcGxlbWVudGVkLg0KDQoNCg0KbyAgSWYgdGhlIG51bWJlciBvZiBpdGVtcyBleGNlZWRz IHRoZSBTSUQgcmFuZ2UocykgYWxsb2NhdGVkIHRvIGEgWUFORyBtb2R1bGUsIGFuIGV4dHJhIHJh bmdlIGlzIGFkZGVkIGZvciBzdWJzZXF1ZW50IGFzc2lnbm1lbnRzLg0KDQoNCg0KU0lEcyBhcmUg YXNzaWduZWQgcGVybWFuZW50bHksIGl0ZW1zIGludHJvZHVjZWQgYnkgYSBuZXcgcmV2aXNpb24g b2YgYSBZQU5HIG1vZHVsZSBhcmUgYWRkZWQgdG8gdGhlIGxpc3Qgb2YgU0lEcyBhbHJlYWR5IGFz c2lnbmVkLiAgVGhpcyBwcm9jZXNzIGNhbiBhbHNvIGJlIGF1dG9tYXRlZCB1c2luZyB0aGUgc2Ft ZSBtZXRob2QgZGVzY3JpYmVkIGFib3ZlIGV4Y2VwdCB0aGF0IHRoZSBhc3NpZ25tZW50IHJlc3Rh cnQgZnJvbSB0aGUgaGlnaGVzdCBTSUQgYWxyZWFkeSBhc3NpZ25lZC4NCg0KDQoNClRvIGF2b2lk IGR1cGxpY2F0ZSBhc3NpZ25tZW50IG9mIFNJRHMsIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIFNJ RHMgYXNzaWduZWQgdG8gWUFORyBtb2R1bGUocykgaXMgcmVjb21tZW5kZWQuICBTZWN0aW9uIDcu MiBwcm92aWRlIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb2Yg WUFORyBtb2R1bGVzIGFuZCBhc3NvY2lhdGVkIFNJRHMuIEluIG9yZGVyIHRvIGltcGxlbWVudCB0 aGlzIHJlZ2lzdHJ5LCBzZWN0aW9uIDUgZGVmaW5lcyBhIHN0YW5kYXJkIGZpbGUgZm9ybWF0ICgu c2lkKSB1c2VkIHRvIHN0b3JlIGFuZCBwdWJsaXNoIFNJRHMgKC5zaWQpLiBUaGlzIFNJRCBmaWxl ICguc2lkKSBpcyB0aGUgb3V0cHV0IG9mIHRoZSBTSUQgYXNzaWdubWVudCBwcm9jZXNzIGFuZCBi b3RoIHRoZSBpbnB1dCBhbmQgb3V0cHV0IG9mIHRoZSB1cGRhdGUgcHJvY2Vzcy4NCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVu IEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIg MTcsIDIwMTYgNDoyMiBQTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVA dHJpbGxpYW50aW5jLmNvbT4NCkNjOiBDb3JlIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtjb3JlXSB5YW5nIGNib3IgY29tbWVudHMNCg0KDQoNCkluIGEgaGFsbHdheSBkaXNjdXNzaW9u IHllc3RlcmRheSwgd2UgZGlzY3Vzc2VkIHR3byBpbnZhcmlhbnRzIHRoYXQgSSB0aGluayB3ZSBh bGwgaGFkIGluIG91ciBtaW5kcyBidXQgcHJvYmFibHkgc2hvdWxkIGJlIG1hZGUgdmVyeSBleHBs aWNpdCBpbiB0aGUgZG9jdW1lbnQuDQoNCg0KDQoxKSBTSUQgZGVsdGEgcHJvY2Vzc2luZyB3aGVu IGdlbmVyYXRpbmcgb3IgY29uc3VtaW5nIFlBTkctQ0JPUiBpbnN0YW5jZXMgaXMgcHVyZSBhcml0 aG1ldGljLiAgVGhlcmUgaXMgbmV2ZXIgYSBuZWVkIHRvIGNvbnN1bHQgYSBZQU5HIG1vZHVsZSBv ciBvdGhlciB0YWJsZSB3aGVuIHBlcmZvcm1pbmcgdGhlIGRlbHRhIHByb2Nlc3NpbmcuDQoNCg0K DQoyKSBTSUQgZ2VuZXJhdGlvbiByZXN1bHRzIGluIGEgU0lEIGZpbGUgdGhhdCBpcyBwcmVzZXJ2 ZWQgZm9yIGEgdmVyc2lvbiBvZiBhIFlBTkcgbW9kdWxlLiAgVGhlIGdlbmVyYXRpb24gb2YgU0lE cyBmb3IgdGhlIG5leHQgdmVyc2lvbiB1c2VzIHRoaXMgU0lEIGZpbGUgYXMgYW4gaW5wdXQuICBT byBpdCBuZXZlciBjYW4gaGFwcGVuIHRoYXQgdGhlIFNJRCBmaWxlIGZvciB0aGUgbmV4dCB2ZXJz aW9uIGJlY29tZXMgaW5jb21wYXRpYmxlIHdpdGggdGhlIHByZXZpb3VzIHZlcnNpb246IEFsbCBT SURzIHRoYXQgd2VyZSBhc3NpZ25lZCBwcmV2aW91c2x5IHN0aWxsIGFyZSB2YWxpZCBpbiB0aGUg bmV4dCB2ZXJzaW9uIChvZiBjb3Vyc2UgdGhleSBtYXkgbm90IG1lYW4gdGhhdCBtdWNoIGFueW1v cmUgaWYgdGhlIHRoaW5nIGlkZW50aWZpZWQgYnkgdGhlIFNJRCBpcyBiZWluZyByZW1vdmVkKS4N Cg0KDQoNCk5vdywgdGhlIHJlbWFpbmluZyBxdWVzdGlvbiBtYXJrIEkgaGF2ZSBhYm91dCAyIGlz IHdoYXQgaGFwcGVucyB3aGVuIG9uZSBpbXBsZW1lbnRlciBzdGFydHMgZ2VuZXJhdGluZyBTSURz IGZvciB2ZXJzaW9uIDIgb2YgYSBtb2R1bGUsIHRoZW4gZm9yIHZlcnNpb24gNDsgYnV0IGFub3Ro ZXIgb25lIGFscmVhZHkgaGFzIFNJRHMgZm9yIHZlcnNpb24gMSBhbmQgdGhlbiB2ZXJzaW9uIDMu ICBUaGF0IHNob3VsZCBiZSBleHBsYWluZWQsIHRvby4NCg0KDQoNCkdyw7zDn2UsIENhcnN0ZW4N Cg0KDQo= --_000_BN6PR06MB2308A7C62619230033047D45FEB40BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+SGkgQ2Fy c3RlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+VG8gY2xhcmlmeSB0aGVzZSBpdGVtcywgSSdt IHByb3Bvc2luZyB0byBwcm9tb3RlIHNlY3Rpb24gMyAoWUFORyBTY2hlbWEgSXRlbSBpRGVudGlm aWVyKSBhcyBzZWN0aW9uIDEgKEludHJvZHVjdGlvbikuIFRoZSBmb2xsb3dpbmcgaGlnaGxpZ2h0 ZWQgdGV4dCBoYXZlIGJlZW4gYWRkZWQvdXBkYXRlZCB0byBhZGRyZXNzIHRoZXNlIGl0ZW1zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+UGxlYXNlIHJldmlldywgY29tbWVudCwgcHJvcG9zZSBh bHRlcm5hdGUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0Ei Pk1pY2hlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLUNBIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+MS4gSW50cm9kdWN0aW9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLUNBIj5Tb21lIG9mIHRoZSBpdGVtcyBkZWZpbmVkIGluIFlBTkcgW1JGQzc5 NTBdIHJlcXVpcmUgdGhlIHVzZSBvZiBhIHVuaXF1ZSBpZGVudGlmaWVyLiZuYnNwOyBJbiBib3Ro IE5FVENPTkYgYW5kIFJFU1RDT05GLCB0aGVzZSBpZGVudGlmaWVycyBhcmUgaW1wbGVtZW50ZWQg dXNpbmcgbmFtZXMuJm5ic3A7IFRvIGFsbG93IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBkYXRhIG1v ZGVscyBkZWZpbmVkDQogaW4gWUFORyBpbiBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBjb25zdHJh aW5lZCBuZXR3b3JrcywgYSBtb3JlIGNvbXBhY3QgbWV0aG9kIHRvIGlkZW50aWZ5IFlBTkcgaXRl bXMgaXMgcmVxdWlyZWQuIFRoaXMgY29tcGFjdCBpZGVudGlmaWVyLCBjYWxsZWQgU0lELCBpcyBl bmNvZGVkIHVzaW5nIGFuIHVuc2lnbmVkIGludGVnZXIuIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJl IGlkZW50aWZpZWQgdXNpbmcgU0lEczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPm8mbmJzcDsg aWRlbnRpdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+byZuYnNwOyBkYXRhIG5vZGVzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5vJm5ic3A7IFJQQ3MgYW5kIGFzc29jaWF0ZWQgaW5wdXQo cykgYW5kIG91dHB1dChzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+byZuYnNwOyBhY3Rpb25z IGFuZCBhc3NvY2lhdGVkIGlucHV0KHMpIGFuZCBvdXRwdXQocyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tQ0EiPm8mbmJzcDsgbm90aWZpY2F0aW9ucyBhbmQgYXNzb2NpYXRlZCBpbmZvcm1hdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+byZuYnNwOyBZQU5HIG1vZHVsZXMsIHN1Ym1vZHVsZXMg YW5kIGZlYXR1cmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5UbyBtaW5pbWl6ZSBpdHMgc2l6 ZSwgU0lEcyBhcmUgb2Z0ZW4gaW1wbGVtZW50ZWQgdXNpbmcgYSBkZWx0YSBmcm9tIGEgcmVmZXJl bmNlIFNJRCBhbmQgdGhlIGN1cnJlbnQgU0lELg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVs bG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5Db252ZXJzaW9uIGZyb20gU0lEcyB0byBkZWx0YXMg YW5kIGJhY2sgdG8gU0lEcyBhcmUgc3RhdGVsZXNzIHByb2Nlc3NlcyBzb2xlbHkgYmFzZWQgb24g dGhlIGRhdGEgc2VyaWFsaXplZCBvciBkZXNlcmlhbGl6ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1DQSI+VG8gZ3VhcmFudHkgdGhlIHVuaXF1ZW5lc3Mgb2YgZWFjaCBhc3NpZ25lZCBT SUQsIFNJRCByYW5nZXMgTVVTVCBiZSByZWdpc3RlcmVkLiBTZWN0aW9uIDcuMSBwcm92aWRlIG1v cmUgZGV0YWlscyBhYm91dCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb2YgU0lEIHJhbmdlKHMp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+QXNzaWdubWVudCBvZiBTSURzIGNhbiBiZSBhdXRv bWF0ZWQsIHRoZSByZWNvbW1lbmRlZCBwcm9jZXNzIHRvIGFzc2lnbiBTSURzIGlzIGFzIGZvbGxv d3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5vJm5ic3A7IEEgdG9vbCBleHRyYWN0cyB0aGUg ZGlmZmVyZW50IGl0ZW1zIGRlZmluZWQgZm9yIGEgc3BlY2lmaWMgWUFORyBtb2R1bGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLUNBIj5vJm5ic3A7IFRoZSBsaXN0IG9mIGl0ZW1zIGlzIG9yZGVyZWQg YnkgdHlwZSBhbmQgbGFiZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5vJm5ic3A7IFNJRHMg YXJlIGFzc2lnbmVkIHNlcXVlbnRpYWxseSBmb3IgdGhlIGVudHJ5IHBvaW50IHVwIHRvIHRoZSBz aXplIG9mIHRoZSByZWdpc3RlcmVkIFNJRCByYW5nZS4mbmJzcDsgVGhpcyBhcHByb2FjaCBpcyBy ZWNvbW1lbmRlZCB0byBtaW5pbWl6ZSB0aGUgc2VyaWFsaXphdGlvbiBvdmVyaGVhZCwgZXNwZWNp YWxseSB3aGVuIGRlbHRhIGVuY29kaW5nIGlzIGltcGxlbWVudGVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1DQSI+byZuYnNwOyBJZiB0aGUgbnVtYmVyIG9mIGl0ZW1zIGV4Y2VlZHMgdGhlIFNJRCBy YW5nZShzKSBhbGxvY2F0ZWQgdG8gYSBZQU5HIG1vZHVsZSwgYW4gZXh0cmEgcmFuZ2UgaXMgYWRk ZWQgZm9yIHN1YnNlcXVlbnQgYXNzaWdubWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPlNJRHMgYXJlIGFz c2lnbmVkIHBlcm1hbmVudGx5LCBpdGVtcyBpbnRyb2R1Y2VkIGJ5IGEgbmV3IHJldmlzaW9uIG9m IGEgWUFORyBtb2R1bGUgYXJlIGFkZGVkIHRvIHRoZSBsaXN0IG9mIFNJRHMgYWxyZWFkeSBhc3Np Z25lZC4mbmJzcDsgVGhpcyBwcm9jZXNzIGNhbiBhbHNvIGJlIGF1dG9tYXRlZA0KIHVzaW5nIHRo ZSBzYW1lIG1ldGhvZCBkZXNjcmliZWQgYWJvdmUgZXhjZXB0IHRoYXQgdGhlIGFzc2lnbm1lbnQg cmVzdGFydCBmcm9tIHRoZSBoaWdoZXN0IFNJRCBhbHJlYWR5IGFzc2lnbmVkLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRvIGF2b2lkIGR1cGxp Y2F0ZSBhc3NpZ25tZW50IG9mIFNJRHMsIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIFNJRHMgYXNz aWduZWQgdG8gWUFORyBtb2R1bGUocykgaXMgcmVjb21tZW5kZWQuJm5ic3A7IFNlY3Rpb24gNy4y IHByb3ZpZGUgbW9yZSBkZXRhaWxzIGFib3V0IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBvZiBZ QU5HIG1vZHVsZXMgYW5kIGFzc29jaWF0ZWQgU0lEcy4gSW4NCiBvcmRlciB0byBpbXBsZW1lbnQg dGhpcyByZWdpc3RyeSwgc2VjdGlvbiA1IGRlZmluZXMgYSBzdGFuZGFyZCBmaWxlIGZvcm1hdCAo LnNpZCkgdXNlZCB0byBzdG9yZSBhbmQgcHVibGlzaCBTSURzICguc2lkKS4NCjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+VGhpcyBTSUQgZmlsZSAo LnNpZCkgaXMgdGhlIG91dHB1dCBvZiB0aGUgU0lEIGFzc2lnbm1lbnQgcHJvY2VzcyBhbmQgYm90 aCB0aGUgaW5wdXQgYW5kIG91dHB1dCBvZiB0aGUgdXBkYXRlIHByb2Nlc3MuPC9zcGFuPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1DQSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNh Ym9AdHppLm9yZ10gPGJyPg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE3LCAyMDE2IDQ6MjIg UE08YnI+DQpUbzogTWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlh bnRpbmMuY29tJmd0Ozxicj4NCkNjOiBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NClN1 YmplY3Q6IFJlOiBbY29yZV0geWFuZyBjYm9yIGNvbW1lbnRzPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5JbiBhIGhhbGx3YXkg ZGlzY3Vzc2lvbiB5ZXN0ZXJkYXksIHdlIGRpc2N1c3NlZCB0d28gaW52YXJpYW50cyB0aGF0IEkg dGhpbmsgd2UgYWxsIGhhZCBpbiBvdXIgbWluZHMgYnV0IHByb2JhYmx5IHNob3VsZCBiZSBtYWRl IHZlcnkgZXhwbGljaXQgaW4gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+ MSkgU0lEIGRlbHRhIHByb2Nlc3Npbmcgd2hlbiBnZW5lcmF0aW5nIG9yIGNvbnN1bWluZyBZQU5H LUNCT1IgaW5zdGFuY2VzIGlzIHB1cmUgYXJpdGhtZXRpYy4mbmJzcDsgVGhlcmUgaXMgbmV2ZXIg YSBuZWVkIHRvIGNvbnN1bHQgYSBZQU5HIG1vZHVsZSBvciBvdGhlciB0YWJsZSB3aGVuIHBlcmZv cm1pbmcgdGhlIGRlbHRhIHByb2Nlc3NpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj4yKSBT SUQgZ2VuZXJhdGlvbiByZXN1bHRzIGluIGEgU0lEIGZpbGUgdGhhdCBpcyBwcmVzZXJ2ZWQgZm9y IGEgdmVyc2lvbiBvZiBhIFlBTkcgbW9kdWxlLiZuYnNwOyBUaGUgZ2VuZXJhdGlvbiBvZiBTSURz IGZvciB0aGUgbmV4dCB2ZXJzaW9uIHVzZXMgdGhpcyBTSUQgZmlsZSBhcyBhbiBpbnB1dC4mbmJz cDsgU28gaXQgbmV2ZXIgY2FuIGhhcHBlbiB0aGF0IHRoZSBTSUQgZmlsZSBmb3IgdGhlDQogbmV4 dCB2ZXJzaW9uIGJlY29tZXMgaW5jb21wYXRpYmxlIHdpdGggdGhlIHByZXZpb3VzIHZlcnNpb246 IEFsbCBTSURzIHRoYXQgd2VyZSBhc3NpZ25lZCBwcmV2aW91c2x5IHN0aWxsIGFyZSB2YWxpZCBp biB0aGUgbmV4dCB2ZXJzaW9uIChvZiBjb3Vyc2UgdGhleSBtYXkgbm90IG1lYW4gdGhhdCBtdWNo IGFueW1vcmUgaWYgdGhlIHRoaW5nIGlkZW50aWZpZWQgYnkgdGhlIFNJRCBpcyBiZWluZyByZW1v dmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk5vdywgdGhlIHJlbWFpbmluZyBxdWVzdGlv biBtYXJrIEkgaGF2ZSBhYm91dCAyIGlzIHdoYXQgaGFwcGVucyB3aGVuIG9uZSBpbXBsZW1lbnRl ciBzdGFydHMgZ2VuZXJhdGluZyBTSURzIGZvciB2ZXJzaW9uIDIgb2YgYSBtb2R1bGUsIHRoZW4g Zm9yIHZlcnNpb24gNDsgYnV0IGFub3RoZXIgb25lIGFscmVhZHkgaGFzIFNJRHMgZm9yIHZlcnNp b24gMSBhbmQgdGhlbiB2ZXJzaW9uDQogMy4mbmJzcDsgVGhhdCBzaG91bGQgYmUgZXhwbGFpbmVk LCB0b28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5HcsO8w59lLCBDYXJzdGVuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR06MB2308A7C62619230033047D45FEB40BN6PR06MB2308namp_-- From nobody Wed Nov 23 06:35: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 E33E3129E0A for ; Wed, 23 Nov 2016 06:35:13 -0800 (PST) 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 udqlgM31KvCo for ; Wed, 23 Nov 2016 06:35:12 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00B2127077 for ; Wed, 23 Nov 2016 06:35:11 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-ac-5835a91e3146 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 0D.48.31000.E19A5385; Wed, 23 Nov 2016 15:35:10 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 15:34:44 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "core@ietf.org" Thread-Topic: End-to-end integrity protection only Thread-Index: AQHSRZa7M0FmpnyXeUqbDiFDkK3+8A== Date: Wed, 23 Nov 2016 14:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <692F2CF9089BC14B84497694E1770C1B@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbE9RFdupWmEwbxlkhb73q5ntlg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRs+I8S8Ee6YpdZw8yNzA+kOpi5OSQEDCR uPR1LWsXIxeHkMA6RommRYvYIJwljBITNy5kBaliE3CReNDwiAnEFhHwkJjdtJIRxGYWsJK4 cqKfBcQWFtCV+PPkFSNEjZHEgXV32CFsPYmbz1vBalgEVCVmX5/FBmLzClhIbDy8H8xmFBCT +H5qDRPETHGJW0/mM0FcJyCxZM95ZghbVOLl439A93BwiALNXHM/DCKsJNG45AlYmFlAU2L9 Ln2IKdYSp1uOQk1UlJjS/ZAdYqugxMmZT1gmMIrOQrJsFkL3LCTds5B0z0LSvYCRdRWjaHFq cXFuupGRXmpRZnJxcX6eXl5qySZGYOwc3PLbagfjweeOhxgFOBiVeHgLYk0ihFgTy4orcw8x SnAwK4nwLlpmGiHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMH p1QDY+Zis5P2mbeWPUifKTyzUDq83tssMXFV8IOL/GJPV16x3v9j8ZrC+ie6MT0xLXoNp9r+ 2epebPbl/uOz1+6I5J3jhmnTrW4tYM+u8JV5xt+oO5v34k/dfA3BTbz9RgnfYjuffePZweU4 TXC/iklVVvSn+x+b8y6GCf4qWrH+6uwlaT5FNy/9UmIpzkg01GIuKk4EAN2lB5WZAgAA Archived-At: Subject: [core] End-to-end integrity protection only 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 Nov 2016 14:35:14 -0000 SGkgSmltLA0KDQpSZWZlcnJpbmcgdG8geW91ciBjb21tZW50IGluIHRoZSBDb1JFIGYyZiBvbiBp bnRlZ3JpdHkgcHJvdGVjdGlvbiBvbmx5IG9uDQphcHBsaWNhdGlvbiBsYXllciwgaS5lLiB0aGUg dXNlIG9mIGEgTUFDIGFsZ29yaXRobSBpbnN0ZWFkIG9mIGFuIEFFQUQgYXMNCnRyYWZmaWMgcHJv dGVjdGlvbiBpbiBPU0NPQVAuDQoNCklmIEkgdW5kZXJzdGFuZCByaWdodCwgdGhlIGlkZWEgaXMg dGhhdCBhbiBpbnRlcm1lZGlhdGUgbm9kZSBzaG91bGQgYmUNCmFibGUgdG8gcmVhZCBidXQgbm90 IGNoYW5nZSBwYXlsb2FkIHdoaWNoIGlzIGludGVncml0eSBwcm90ZWN0ZWQgYmV0d2Vlbg0KZW5k cG9pbnRzLg0KDQpGaXJzdCBvZiBhbGwsIGFzIHdhcyBzaW1pbGFybHkgZGlzY3Vzc2VkIGluIENP U0UsIGluIG9yZGVyIGZvciB0aGUNCmludGVybWVkaWFyeSB0byBkZXBlbmQgdXBvbiB0aGUgcGF5 bG9hZCBpdCB3b3VsZCBuZWVkIHRvIHZlcmlmeSBpdHMNCmludGVncml0eSAoYSBNQUMpLCBhbmQg aWYgaXQgaGFzIHRoZSBrZXkgdG8gZG8gc28sIHRoYXQga2V5IGNvdWxkIHdpdGgNCm5lZ2xpZ2li bGUgcGVyZm9ybWFuY2UgcGVuYWx0eSBiZSB1c2VkIHRvIGVuY3J5cHQgdGhlIHBheWxvYWQuIFNv IGlmIHdlDQphcmUgc3BlYWtpbmcgYXBwbGljYXRpb24gbGF5ZXIgcHJvdGVjdGlvbiBvZiBtZXNz YWdlIGJldHdlZW4gZW5kcG9pbnQgYW5kDQpwcm94eSwgdGhlbiBJIGRvbuKAmXQgc2VlIHRoZSBu ZWVkIGZvciBhIE1BQy4NCg0KQW5vdGhlciB1c2UgY2FzZSBwcmV2aW91c2x5IGRpc2N1c3NlZCBp cyBob3AtYnktaG9wIGVuZHBvaW50LXByb3h5DQpjb21tdW5pY2F0aW9uIHByb3RlY3RlZCB3aXRo IChEKVRMUyBhbmQgZW5kcG9pbnQtZW5kcG9pbnQgY29tbXVuaWNhdGlvbg0KcHJvdGVjdGVkIGJ5 IE9TQ09BUC4gSW4gdGhpcyBjYXNlIHRoZSBwcm94eSB3b3VsZCB2ZXJpZnkgdGhlIERUTFMgcmVj b3JkDQpsYXllciBtZXNzYWdlLiBCdXQgaW4gb3JkZXIgdG8gcmVhZCBvdXQgdGhlIGFwcGxpY2F0 aW9uIGxheWVyIHBheWxvYWQsIHRoZQ0KcHJveHkgd291bGQgbmVlZCB0byBwYXJzZSB0aGUgT1ND T0FQIG1lc3NhZ2UsIHdpdGhvdXQgYmVpbmcgYWJsZSB0byB2ZXJpZnkNCnRoZSBDT1NFIG9iamVj dCwgbmVpdGhlciB0aGUgcGF5bG9hZCBub3IgdGhlIG9wdGlvbnMgb3IgaGVhZGVyLCBzaW5jZSBi eQ0KYXNzdW1wdGlvbiBvbmx5IHRoZSBlbmRwb2ludHMgc2hhcmUgdGhhdCBrZXkuIEJ1dCB0aGUg cG9pbnQgd2l0aCB1c2luZw0KT1NDT0FQIGlzIGV4YWN0bHkgdGhhdCBpdCBwcm90ZWN0cyBub3Qg b25seSBwYXlsb2FkIGJ1dCBlc3NlbnRpYWxseSBhbGwNCm9wdGlvbnMgYW5kIGhlYWRlcnMgdGhh dCBhcmUgbm90IHBhcnQgb2YgQ29BUCBtZXNzYWdlIGxheWVyLCB0aGF0IGl0IGlzDQpwb3NzaWJs ZSB0byB2ZXJpZnkgdGhhdCByZXF1ZXN0IGFuZCByZXNwb25zZSBiZWxvbmcgdG9nZXRoZXIgZXRj Li4gTm90aGluZw0Kb2YgdGhpcyB3b3VsZCBhdmFpbGFibGUgdG8gdGhlIHByb3h5Lg0KDQpBZGRp dGlvbmFsbHksIHRoZSB1c2Ugb2YgZHVwbGljYXRlIENvQVAgb3B0aW9ucyBmb3IgcHJveHkgYW5k IGVuZHBvaW50DQpyZXNwZWN0aXZlbHksIGFzIGN1cnJlbnRseSBzcGVjaWZpZWQgd2lsbCBub3Qg d29yayB3aXRoIGludGVncml0eQ0KcHJvdGVjdGlvbiBvbmx5LCBzaW5jZSBvbmx5IG9uZSBzZXQg b2Ygb3B0aW9ucyBhcmUgYXZhaWxhYmxlLiBTbywgZS5nLiB0aGUNCnVzZSBvZiBCbG9ja3dpc2Ug YXMgaXMgY3VycmVudGx5IHNwZWNpZmllZCBmb3IgdXNlIGJvdGggZW5kLXRvLWVuZCBhbmQNCmhv cC1ieS1ob3Agd291bGQgbm90IHdvcmsuDQoNCg0KV2hpbGUgRFRMUyBhbmQgT1NDT0FQIGNhbiBi ZSBjb21iaW5lZCBmb3IgYWRkaXRpb25hbCBwcm90ZWN0aW9uIG9mIHRoZSBmZXcNCmhlYWRlciBm aWVsZHMgd2hpY2ggYXJlIG5vdCBhbHJlYWR5IGVuY3J5cHRlZCwgSSB0aGluayB0aGF0IHRoZSB1 c2UgY2FzZQ0KZGlzY3Vzc2VkIGhlcmUgd2hlcmUgc2VjdXJpdHkgb24gZGlmZmVyZW50IGxheWVy cyBpcyB1c2VkIGZvciBwcm90ZWN0aW5nDQpvbmUgYW5kIHRoZSBzYW1lIHBheWxvYWQgc2hvdWxk IGJlIGFkZHJlc3NlZCB3aXRoIE9TQ09OIG9yIGV2ZW4gQ09TRQ0KZGlyZWN0bHkgb3ZlciBEVExT LCByYXRoZXIgdGhhbiBPU0NPQVAgb3ZlciBEVExTLiBTbywgdXNpbmcgdGhlIE9TQ09ODQpmb3Jt YXQgb3Igb3RoZXIgc2ltcGxlIENPU0Ugd3JhcHBpbmcgb2YgcGF5bG9hZCBhbmQgcG90ZW50aWFs bHkgbWV0YWRhdGEsDQp0aGlzIGNhbiBiZSBtb3JlIGVhc2lseSBwYXJzZWQgYnkgYW4gaW50ZXJt ZWRpYXRlIG5vZGUgZm9yIHRoaXMgdXNlIGNhc2UuDQpBbHRlcm5hdGl2ZWx5IHBheWxvYWQgcHJv dGVjdGlvbiBob3AtYnktaG9wIGFuZCBlbmQtdG8tZW5kIGNvdWxkIGJlDQplbnRpcmVseSBzb2x2 ZWQgb24gYXBwbGljYXRpb24gbGF5ZXIuIFRoaXMgd291bGQgYWN0dWFsbHkgYmUgYSB1c2UgY2Fz ZQ0KZm9yIGEgY291bnRlci1NQUMuDQoNCkRvZXMgaXQgbWFrZSBzZW5zZT8NCg0KDQpHw7ZyYW4N Cg0K From nobody Wed Nov 23 12:21: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 DD1A41296D8 for ; Wed, 23 Nov 2016 12:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 fBPr26s8wkOR for ; Wed, 23 Nov 2016 12:21:20 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D0D12945A for ; Wed, 23 Nov 2016 12:21:19 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 23 Nov 2016 12:38:47 -0800 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: In-Reply-To: Date: Wed, 23 Nov 2016 12:21:05 -0800 Message-ID: <015001d245c7$1ff36920$5fda3b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEVIDyrcX/bf+sOeRR0agcNqguEHaJhR7ZQ Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] End-to-end integrity protection only 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 Nov 2016 20:21:22 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Wednesday, November 23, 2016 6:35 AM > To: Jim Schaad ; core@ietf.org > Cc: Francesca Palombini > Subject: End-to-end integrity protection only >=20 > Hi Jim, >=20 > Referring to your comment in the CoRE f2f on integrity protection only = on > application layer, i.e. the use of a MAC algorithm instead of an AEAD = as traffic > protection in OSCOAP. I would not limit it to MAC, a signature would also be equally effective = in terms of dealing with this issue. >=20 > If I understand right, the idea is that an intermediate node should be = able to read > but not change payload which is integrity protected between endpoints. That was what was presented at the Berlin F2F. >=20 > First of all, as was similarly discussed in COSE, in order for the = intermediary to > depend upon the payload it would need to verify its integrity (a MAC), = and if it > has the key to do so, that key could with negligible performance = penalty be used > to encrypt the payload. So if we are speaking application layer = protection of > message between endpoint and proxy, then I don=E2=80=99t see the need = for a MAC. The use case presented is that the intermediary can read, but not verify = the integrity, of the payload. That is, it wants to be able to monitor = the content being sent back but does not care if it occasionally gets a = bad answer. Note the use case is not mine. >=20 > Another use case previously discussed is hop-by-hop endpoint-proxy > communication protected with (D)TLS and endpoint-endpoint = communication > protected by OSCOAP. In this case the proxy would verify the DTLS = record layer > message. But in order to read out the application layer payload, the = proxy would > need to parse the OSCOAP message, without being able to verify the = COSE > object, neither the payload nor the options or header, since by = assumption only > the endpoints share that key. But the point with using OSCOAP is = exactly that it > protects not only payload but essentially all options and headers that = are not > part of CoAP message layer, that it is possible to verify that request = and > response belong together etc.. Nothing of this would available to the = proxy. >=20 > Additionally, the use of duplicate CoAP options for proxy and endpoint > respectively, as currently specified will not work with integrity = protection only, > since only one set of options are available. So, e.g. the use of = Blockwise as is > currently specified for use both end-to-end and hop-by-hop would not = work. I don't follow this. If it was true, then it would not work for = encryption either. Duplicating the options inside of the payload should = be just fine for either case. If it is integrity only protected, then = the ones inside the payload are ignored by the proxy just as is done = with encryption. Additionally, one could place some of the attributes = in the external application data and protect them in that manner even if = one did not duplicate them. >=20 >=20 > While DTLS and OSCOAP can be combined for additional protection of the = few > header fields which are not already encrypted, I think that the use = case discussed > here where security on different layers is used for protecting one and = the same > payload should be addressed with OSCON or even COSE directly over = DTLS, > rather than OSCOAP over DTLS. So, using the OSCON format or other = simple > COSE wrapping of payload and potentially metadata, this can be more = easily > parsed by an intermediate node for this use case. Using just OSCON does not protect headers which I think is going to be = of importance. One will want to protect the Uri-Port and Uri-Path = options for a PUT. =20 Jim > Alternatively payload protection hop-by-hop and end-to-end could be = entirely > solved on application layer. This would actually be a use case for a = counter- > MAC. >=20 > Does it make sense? >=20 >=20 > G=C3=B6ran From nobody Thu Nov 24 00:12: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 C98591296B5 for ; Thu, 24 Nov 2016 00:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 QO5fJuWUZZlo for ; Thu, 24 Nov 2016 00:12:19 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 778BD1294EB for ; Thu, 24 Nov 2016 00:12:18 -0800 (PST) Received: from WeiGengyuPC (unknown [221.219.56.78]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 1416E19F404; Thu, 24 Nov 2016 16:12:15 +0800 (HKT) Message-ID: <44FAF50836AF40D5BB631F8778957841@WeiGengyuPC> From: "weigengyu" To: "Carsten Bormann" References: <0877a32a-3363-c86b-6cbb-a5c7db798c2c@gmx.net> In-Reply-To: Date: Thu, 24 Nov 2016 16:12:13 +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] DTLS over CoAP 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, 24 Nov 2016 08:12:21 -0000 Hi， >> Indeed — that was the original motivation — getting rid of DTLS >> retransmissions by using the much better behaved CoAP retransmissions >> instead. >> Only then did we notice that this makes a nice end-to-end key agreement >> protocol if there is a cipher suite that matches your security >> requirements. When considering DTLS over CoAP, another question is why not to have TLS over CoAP instead. CoAP is a reliable protocol and TLS is designed to run over a reliable protocol which is TCP as default. So, having TLS over CoAP seems to be rational. I wonder that TLS may needs modifing less than DTLS if comparing TLS over CoAP than DTLS over CoAP. >>Göran: I mentioned this as a reaction to Hannes’ idea that we should use >>TLS at the application layer. We still need OSCOAP to actually replace >>the record layer (and provide semantics appropriate to end-to-end >>security). And no, I still don’t want to be forced to add transport >>layer security when application layer security is what my security >>objectives actually require. The OSCOAP may be required if TLS over CoAP and CoAP connection is not end-to-end. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Wednesday, November 16, 2016 4:26 PM To: weigengyu Cc: Göran Selander ; Hannes Tschofenig ; core@ietf.org Subject: Re: [core] DTLS over CoAP On 16 Nov 2016, at 16:21, weigengyu wrote: > > It needs to point out that DTLS would work better on some reliable > datagram transport facilities. > So, "DTLS over CoAP" is much like that. > But, we also think that DTLS needs optimizing its handshake efficiencies, > retransmission mechanism, and ets. Göran: I mentioned this as a reaction to Hannes’ idea that we should use TLS at the application layer. We still need OSCOAP to actually replace the record layer (and provide semantics appropriate to end-to-end security). And no, I still don’t want to be forced to add transport layer security when application layer security is what my security objectives actually require. Grüße, Carsten From nobody Thu Nov 24 01:36:01 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 942B2129F13 for ; Thu, 24 Nov 2016 01:35:59 -0800 (PST) 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 e0FhnQOFebQh for ; Thu, 24 Nov 2016 01:35:57 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C012129F11 for ; Thu, 24 Nov 2016 01:35:57 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-41-5836b47b8c23 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 71.0D.32482.B74B6385; Thu, 24 Nov 2016 10:35:55 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Thu, 24 Nov 2016 10:35:55 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "core@ietf.org" Thread-Topic: End-to-end integrity protection only Thread-Index: AQHSRZa7M0FmpnyXeUqbDiFDkK3+8KDm8kqAgADu14A= Date: Thu, 24 Nov 2016 09:35:54 +0000 Message-ID: References: <015001d245c7$1ff36920$5fda3b60$@augustcellars.com> In-Reply-To: <015001d245c7$1ff36920$5fda3b60$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <815E667CA899034BB47429F1109CC650@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7rm71FrMIg3sT9C32vV3PbLF6+nc2 ByaPjXOms3ksWfKTKYApissmJTUnsyy1SN8ugSvjdNtCtoIV9hXn/55mbWC8YdvFyMkhIWAi sar5OHsXIxeHkMA6RomV169DOUsYJX4vnc4CUsUm4CLxoOERE4gtIuAhMbtpJSOIzSxgJXHl RD9YjbCAocSRnfdZIWqMJA6su8MOYVtJPLg7F6yXRUBV4tOCC2C9vAIWEouObgXrFRLIk7g/ /SxYPaeAg8TiK1PYQGxGATGJ76fWMEHsEpe49WQ+E8TVAhJL9pxnhrBFJV4+/ge0l4NDVEBP Ys39MIiwksSi25+ZQMLMApoS63fpQ0yxlvh4eio7hK0oMaX7ITvENYISJ2c+YZnAKD4LybJZ CN2zkHTPQtI9C0n3AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBsXZwy2/VHYyX3zge YhTgYFTi4f2wzjRCiDWxrLgy9xCjBAezkgjvgU1mEUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwZkY8OpAWuDrjX/zsV3uvsry93OLxbmXY2YrveRZO t5rb3CbxHW7ZXbWCWVP7FGPulXIDN08vAc1l34w5rbx8bQ9Wx0xw2n0qjOnSQfXE+3yczzTW FOmdMnx5muflO4fiWQoHapuXevu8YgivOTZX0WpRMMsWJ5cnl/Zq+lws9vr93/TnimPhSizF GYmGWsxFxYkA/wiT7LECAAA= Archived-At: Subject: Re: [core] End-to-end integrity protection only 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, 24 Nov 2016 09:36:00 -0000 DQoNCk9uIDIwMTYtMTEtMjMgMjE6MjEsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDIzLCAyMDE2IDY6MzUgQU0NCj4+IFRvOiBK aW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgY29yZUBpZXRmLm9yZw0KPj4gQ2M6 IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPg0K Pj4gU3ViamVjdDogRW5kLXRvLWVuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBvbmx5DQo+PiANCj4+ IEhpIEppbSwNCj4+IA0KPj4gUmVmZXJyaW5nIHRvIHlvdXIgY29tbWVudCBpbiB0aGUgQ29SRSBm MmYgb24gaW50ZWdyaXR5IHByb3RlY3Rpb24gb25seQ0KPj5vbg0KPj4gYXBwbGljYXRpb24gbGF5 ZXIsIGkuZS4gdGhlIHVzZSBvZiBhIE1BQyBhbGdvcml0aG0gaW5zdGVhZCBvZiBhbiBBRUFEDQo+ PmFzIHRyYWZmaWMNCj4+IHByb3RlY3Rpb24gaW4gT1NDT0FQLg0KPg0KPkkgd291bGQgbm90IGxp bWl0IGl0IHRvIE1BQywgYSBzaWduYXR1cmUgd291bGQgYWxzbyBiZSBlcXVhbGx5IGVmZmVjdGl2 ZQ0KPmluIHRlcm1zIG9mIGRlYWxpbmcgd2l0aCB0aGlzIGlzc3VlLg0KDQpBIHNpZ25hdHVyZSBt YWtlcyBtdWNoIG1vcmUgc2Vuc2UgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyB0aGF0IGFueQ0KaW50 ZXJtZWRpYXJ5IGNvdWxkIGFjdHVhbGx5IHZlcmlmeSB0aGUgbWVzc2FnZS4gSW4gdGhpcyBjYXNl IHRoZSBzZWN1cmUNCmdyb3VwIGNvbW11bmljYXRpb24gZm9yIENvQVAgWzFdIGNhbiBiZSBhcHBs aWVkIGRpcmVjdGx5IHdpdGggb25lDQppbnRlcm1lZGlhcnkgYXMg4oCcbGlzdGVuZXLigJ0uDQoN Cj4NCj4+IA0KPj4gSWYgSSB1bmRlcnN0YW5kIHJpZ2h0LCB0aGUgaWRlYSBpcyB0aGF0IGFuIGlu dGVybWVkaWF0ZSBub2RlIHNob3VsZCBiZQ0KPj5hYmxlIHRvIHJlYWQNCj4+IGJ1dCBub3QgY2hh bmdlIHBheWxvYWQgd2hpY2ggaXMgaW50ZWdyaXR5IHByb3RlY3RlZCBiZXR3ZWVuIGVuZHBvaW50 cy4NCj4NCj5UaGF0IHdhcyB3aGF0IHdhcyBwcmVzZW50ZWQgYXQgdGhlIEJlcmxpbiBGMkYuDQoN CkkgZGlkbuKAmXQgZmluZCBpdCBpbiB0aGUgbWludXRlcywgd2FzIHRoaXMgYSBzbWFydCBtZXRl ciBzY2VuYXJpbz8gSSByZWNhbGwNCmEgcHJldmlvdXMgZGlzY3Vzc2lvbiB3aGVyZSB0aGUgaW50 ZXJtZWRpYXJ5IHdhcyB0aGUgYWN0dWFsIHNtYXJ0IG1ldGVyDQphbmQgdGhlIHB1cnBvc2Ugb2Yg cmVhZGluZyBvdXQgd2FzIHRvIGJlIGFibGUgdG8gcmVhZCBvdXQgdGhlIGNvbnN1bXB0aW9uDQps b2NhbGx5Lg0KDQo+DQo+PiANCj4+IEZpcnN0IG9mIGFsbCwgYXMgd2FzIHNpbWlsYXJseSBkaXNj dXNzZWQgaW4gQ09TRSwgaW4gb3JkZXIgZm9yIHRoZQ0KPj5pbnRlcm1lZGlhcnkgdG8NCj4+IGRl cGVuZCB1cG9uIHRoZSBwYXlsb2FkIGl0IHdvdWxkIG5lZWQgdG8gdmVyaWZ5IGl0cyBpbnRlZ3Jp dHkgKGEgTUFDKSwNCj4+YW5kIGlmIGl0DQo+PiBoYXMgdGhlIGtleSB0byBkbyBzbywgdGhhdCBr ZXkgY291bGQgd2l0aCBuZWdsaWdpYmxlIHBlcmZvcm1hbmNlDQo+PnBlbmFsdHkgYmUgdXNlZA0K Pj4gdG8gZW5jcnlwdCB0aGUgcGF5bG9hZC4gU28gaWYgd2UgYXJlIHNwZWFraW5nIGFwcGxpY2F0 aW9uIGxheWVyDQo+PnByb3RlY3Rpb24gb2YNCj4+IG1lc3NhZ2UgYmV0d2VlbiBlbmRwb2ludCBh bmQgcHJveHksIHRoZW4gSSBkb27igJl0IHNlZSB0aGUgbmVlZCBmb3IgYSBNQUMuDQo+DQo+VGhl IHVzZSBjYXNlIHByZXNlbnRlZCBpcyB0aGF0IHRoZSBpbnRlcm1lZGlhcnkgY2FuIHJlYWQsIGJ1 dCBub3QgdmVyaWZ5DQo+dGhlIGludGVncml0eSwgb2YgdGhlIHBheWxvYWQuICBUaGF0IGlzLCBp dCB3YW50cyB0byBiZSBhYmxlIHRvIG1vbml0b3INCj50aGUgY29udGVudCBiZWluZyBzZW50IGJh Y2sgYnV0IGRvZXMgbm90IGNhcmUgaWYgaXQgb2NjYXNpb25hbGx5IGdldHMgYQ0KPmJhZCBhbnN3 ZXIuICBOb3RlIHRoZSB1c2UgY2FzZSBpcyBub3QgbWluZS4NCg0KT0suIElNSE8sIHRoZSBwYXJ0 IOKAnG5vdCBjYXJlIGlmIGl0IG9jY2FzaW9uYWxseSBnZXRzIGEgYmFkIGFuc3dlcuKAnSBpcyBu b3QNCnBlcmZlY3RseSBtYXRjaGluZyB0aGUgc21hcnQgbWV0ZXIgc2NlbmFyaW8uIEl0IHdvdWxk IGJlIGdvb2QgaWYgdGhlIG93bmVyDQpvZiB0aGlzIHVzZSBjYXNlIGNvdWxkIHByb3ZpZGUgbW9y ZSBkZXRhaWxzLg0KDQo+DQo+PiANCj4+IEFub3RoZXIgdXNlIGNhc2UgcHJldmlvdXNseSBkaXNj dXNzZWQgaXMgaG9wLWJ5LWhvcCBlbmRwb2ludC1wcm94eQ0KPj4gY29tbXVuaWNhdGlvbiBwcm90 ZWN0ZWQgd2l0aCAoRClUTFMgYW5kIGVuZHBvaW50LWVuZHBvaW50IGNvbW11bmljYXRpb24NCj4+ IHByb3RlY3RlZCBieSBPU0NPQVAuIEluIHRoaXMgY2FzZSB0aGUgcHJveHkgd291bGQgdmVyaWZ5 IHRoZSBEVExTDQo+PnJlY29yZCBsYXllcg0KPj4gbWVzc2FnZS4gQnV0IGluIG9yZGVyIHRvIHJl YWQgb3V0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBwYXlsb2FkLCB0aGUNCj4+cHJveHkgd291bGQN Cj4+IG5lZWQgdG8gcGFyc2UgdGhlIE9TQ09BUCBtZXNzYWdlLCB3aXRob3V0IGJlaW5nIGFibGUg dG8gdmVyaWZ5IHRoZSBDT1NFDQo+PiBvYmplY3QsIG5laXRoZXIgdGhlIHBheWxvYWQgbm9yIHRo ZSBvcHRpb25zIG9yIGhlYWRlciwgc2luY2UgYnkNCj4+YXNzdW1wdGlvbiBvbmx5DQo+PiB0aGUg ZW5kcG9pbnRzIHNoYXJlIHRoYXQga2V5LiBCdXQgdGhlIHBvaW50IHdpdGggdXNpbmcgT1NDT0FQ IGlzDQo+PmV4YWN0bHkgdGhhdCBpdA0KPj4gcHJvdGVjdHMgbm90IG9ubHkgcGF5bG9hZCBidXQg ZXNzZW50aWFsbHkgYWxsIG9wdGlvbnMgYW5kIGhlYWRlcnMgdGhhdA0KPj5hcmUgbm90DQo+PiBw YXJ0IG9mIENvQVAgbWVzc2FnZSBsYXllciwgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byB2ZXJpZnkg dGhhdCByZXF1ZXN0DQo+PmFuZA0KPj4gcmVzcG9uc2UgYmVsb25nIHRvZ2V0aGVyIGV0Yy4uIE5v dGhpbmcgb2YgdGhpcyB3b3VsZCBhdmFpbGFibGUgdG8gdGhlDQo+PnByb3h5Lg0KPj4gDQo+PiBB ZGRpdGlvbmFsbHksIHRoZSB1c2Ugb2YgZHVwbGljYXRlIENvQVAgb3B0aW9ucyBmb3IgcHJveHkg YW5kIGVuZHBvaW50DQo+PiByZXNwZWN0aXZlbHksIGFzIGN1cnJlbnRseSBzcGVjaWZpZWQgd2ls bCBub3Qgd29yayB3aXRoIGludGVncml0eQ0KPj5wcm90ZWN0aW9uIG9ubHksDQo+PiBzaW5jZSBv bmx5IG9uZSBzZXQgb2Ygb3B0aW9ucyBhcmUgYXZhaWxhYmxlLiBTbywgZS5nLiB0aGUgdXNlIG9m DQo+PkJsb2Nrd2lzZSBhcyBpcw0KPj4gY3VycmVudGx5IHNwZWNpZmllZCBmb3IgdXNlIGJvdGgg ZW5kLXRvLWVuZCBhbmQgaG9wLWJ5LWhvcCB3b3VsZCBub3QNCj4+d29yay4NCj4NCj5JIGRvbid0 IGZvbGxvdyB0aGlzLiAgSWYgaXQgd2FzIHRydWUsIHRoZW4gaXQgd291bGQgbm90IHdvcmsgZm9y DQo+ZW5jcnlwdGlvbiBlaXRoZXIuICBEdXBsaWNhdGluZyB0aGUgb3B0aW9ucyBpbnNpZGUgb2Yg dGhlIHBheWxvYWQgc2hvdWxkDQo+YmUganVzdCBmaW5lIGZvciBlaXRoZXIgY2FzZS4gIElmIGl0 IGlzIGludGVncml0eSBvbmx5IHByb3RlY3RlZCwgdGhlbg0KPnRoZSBvbmVzIGluc2lkZSB0aGUg cGF5bG9hZCBhcmUgaWdub3JlZCBieSB0aGUgcHJveHkganVzdCBhcyBpcyBkb25lIHdpdGgNCj5l bmNyeXB0aW9uLiAgQWRkaXRpb25hbGx5LCBvbmUgY291bGQgcGxhY2Ugc29tZSBvZiB0aGUgYXR0 cmlidXRlcyBpbiB0aGUNCj5leHRlcm5hbCBhcHBsaWNhdGlvbiBkYXRhIGFuZCBwcm90ZWN0IHRo ZW0gaW4gdGhhdCBtYW5uZXIgZXZlbiBpZiBvbmUgZGlkDQo+bm90IGR1cGxpY2F0ZSB0aGVtLg0K DQpJIHRoaW5rIHlvdSBhcmUgcmlnaHQgYWJvdXQgdGhpcyBwb2ludC4gVGhlIGR1cGxpY2F0ZSBv cHRpb25zIGNvdWxkIHdvcmsNCmVxdWFsbHkgd2VsbCB3aXRoIHRoZSBwYXlsb2FkIG9mIENPU0Vf TWFjMCBhbmFsb2dvdXMgdG8gdGhlIHBsYWludGV4dCBvZg0KQ09TRV9FbmNyeXB0MCwgdGhlIHNh bWUgZXh0ZXJuYWxfQUFELCBldGMuLiBJIHdhcyB0aGlua2luZyBvZiBhIHByZXZpb3VzDQp2ZXJz aW9uIG9mIHRoZSBkcmFmdCBzdXBwb3J0aW5nIE1BQ3Mgd2hlcmUgdGhlIHBheWxvYWQgb2YgdGhl IE1BQyBvYmplY3QNCndhcyBkZXRhY2hlZCwgaW4gd2hpY2ggY2FzZSBubyBvdGhlciBDb0FQIG9w dGlvbnMgYW5kIHBheWxvYWQgY291bGQgYmUNCnNlbnQgdGhhbiB0aGUgb3B0aW9ucyBhbmQgcGF5 bG9hZCBvZiB0aGUgdW5wcm90ZWN0ZWQgQ29BUCBtZXNzYWdlLg0KDQpCdXQgSeKAmW0gbm90IHll dCBjb252aW5jZWQgdGhhdCB3ZSBuZWVkIHRvIHN1cHBvcnQgTUFDLW9ubHkuDQoNCj4NCj4+IA0K Pj4gDQo+PiBXaGlsZSBEVExTIGFuZCBPU0NPQVAgY2FuIGJlIGNvbWJpbmVkIGZvciBhZGRpdGlv bmFsIHByb3RlY3Rpb24gb2YgdGhlDQo+PmZldw0KPj4gaGVhZGVyIGZpZWxkcyB3aGljaCBhcmUg bm90IGFscmVhZHkgZW5jcnlwdGVkLCBJIHRoaW5rIHRoYXQgdGhlIHVzZQ0KPj5jYXNlIGRpc2N1 c3NlZA0KPj4gaGVyZSB3aGVyZSBzZWN1cml0eSBvbiBkaWZmZXJlbnQgbGF5ZXJzIGlzIHVzZWQg Zm9yIHByb3RlY3Rpbmcgb25lIGFuZA0KPj50aGUgc2FtZQ0KPj4gcGF5bG9hZCBzaG91bGQgYmUg YWRkcmVzc2VkIHdpdGggT1NDT04gb3IgZXZlbiBDT1NFIGRpcmVjdGx5IG92ZXIgRFRMUywNCj4+ IHJhdGhlciB0aGFuIE9TQ09BUCBvdmVyIERUTFMuIFNvLCB1c2luZyB0aGUgT1NDT04gZm9ybWF0 IG9yIG90aGVyIHNpbXBsZQ0KPj4gQ09TRSB3cmFwcGluZyBvZiBwYXlsb2FkIGFuZCBwb3RlbnRp YWxseSBtZXRhZGF0YSwgdGhpcyBjYW4gYmUgbW9yZQ0KPj5lYXNpbHkNCj4+IHBhcnNlZCBieSBh biBpbnRlcm1lZGlhdGUgbm9kZSBmb3IgdGhpcyB1c2UgY2FzZS4NCj4NCj5Vc2luZyBqdXN0IE9T Q09OIGRvZXMgbm90IHByb3RlY3QgaGVhZGVycyB3aGljaCBJIHRoaW5rIGlzIGdvaW5nIHRvIGJl IG9mDQo+aW1wb3J0YW5jZS4gIE9uZSB3aWxsIHdhbnQgdG8gcHJvdGVjdCB0aGUgVXJpLVBvcnQg YW5kIFVyaS1QYXRoIG9wdGlvbnMNCj5mb3IgYSBQVVQuICANCg0KVGhhdCBpcyB3aGF0IEkgaW50 ZW5kZWQgd2l0aCDigJx3cmFwcGluZyAuLiBwb3RlbnRpYWxseSBtZXRhZGF0YeKAnS4gQnV0DQpp cnJlc3BlY3RpdmUgb2YgQ09TRSwgT1NDT04gb3IgT1NDT0FQLCB3aXRoIHN5bW1ldHJpYyBrZXlz IG9ubHksIGl0DQpiZWNvbWVzIGEgbWF0dGVyIG9mIHRoZSBpbnRlcm1lZGlhcnkgcGFyc2luZyBh IENPU0UgbWVzc2FnZSB3aXRob3V0DQp2ZXJpZnlpbmcgaXQgKHVubGVzcyB0aGVyZSBpcyBhIGNv dW50ZXItTUFDKSBhbmQgSSBxdWVzdGlvbiB0aGUgc2Vuc2UgaW4NCnRoYXQuDQoNClRvIHN1bW1h cmlzZTogDQoNCi0gQ3VycmVudCBkcmFmdHMgc3VwcG9ydCB0aGUgY2FzZSBvZiBtdWx0aXBsZSBw YXJ0aWVzIHJlYWRpbmcgYW5kDQp2ZXJpZnlpbmcgc291cmNlIGFuZCBpbnRlZ3JpdHkgb2YgZW5k LXRvLWVuZCBwcm90ZWN0ZWQgQ29BUCBtZXNzYWdlcw0Kd2l0aG91dCBiZWluZyBhYmxlIHRvIHVu c2VlbiBtb2RpZnkgdGhlIGRhdGEgaW4gdHJhbnNpdC4NCg0KLSBNb3JlIGlucHV0IG1vdGl2YXRp bmcgdGhlIHBhcnNpbmcgb2YgQ09TRSBvYmplY3RzIHdpdGhvdXQgdmVyaWZpY2F0aW9uDQppcyB3 ZWxjb21lLg0KDQpHw7ZyYW4NCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC10aWxvY2EtY29yZS1tdWx0aWNhc3Qtb3Njb2FwDQoNCg0KDQo+DQo+SmltDQoNCg== From nobody Thu Nov 24 05:37: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 BC41C129611 for ; Thu, 24 Nov 2016 05:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 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, RP_MATCHES_RCVD=-1.497, 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 vq2FVhY3shDK for ; Thu, 24 Nov 2016 05:37:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 DF33E1299A0 for ; Thu, 24 Nov 2016 05:37:24 -0800 (PST) Received: from [172.16.254.118] ([80.92.114.246]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbOrg-1cQKdI2lZU-00Ini5; Thu, 24 Nov 2016 14:37:04 +0100 To: weigengyu , Carsten Bormann References: <0877a32a-3363-c86b-6cbb-a5c7db798c2c@gmx.net> <44FAF50836AF40D5BB631F8778957841@WeiGengyuPC> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 24 Nov 2016 14:36:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <44FAF50836AF40D5BB631F8778957841@WeiGengyuPC> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LgIhlbRJ8oPGpHkfdj1q81cmuR57oFHUu" X-Provags-ID: V03:K0:LyZtsHIHPtwhfo6VitFOCoWfJL+44SKNNrRaoZfUNTWvqvTARBk CNmyQqFvYfMdOL3xTTbOxs1Hz4BPnf2zz7hWz1lpdnAxaPnajmX9GJQKbNcm4qqDArLd8an EtLovz79WwkLRrENegDnEmpiABfrnbPiIrCogbLwS/h4yLWw1iSrPQi+hdR9Cz3UaDpFcDV ZyOsQyGuC4go/N8i4wsxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:QN8+UzV2Wa0=:O4WbzlK7Kw3868IFCEaZpb jgna8CAkpOP0MhN9qvGdDikyXVcqXlGdBs1tCgtX6nV433rolLEPwOUhtXOt5YrdllU6a6jjI FFQDkwwj0pASmmxLvnCi6WlrVoBWRr5ATejYLjzEDAy2H8O6BXf2iTaHVVAGIZflKnEhu/GMl 9CC3h9juHKSOGVHxcB5mP73iiebbtdoFCZBV47zFNtMaCvRPDEAVl1t4kkTh68wsRQzqs8Dfh pCih6KNdZp9GFLKXN6sL4yWLMDhSsKKkKjmzmPW2DMauV8Z24HAOenkS69SlWidk/eGdtm6OF Ew2oZPJMtGOqEuSmaR6L4e3ZNxjeVQbUXqFKL8bzGMKsWhDSfy5R7jYMDlx16FvG2AsTIuRc7 vLmOM0twMzHU9nnK9j2NwcOCpB8mJDfqBOgXCmN44b88KyeLUHSmraiJW9B5XgY87SO78T9uk tTMbe0HQgYtM+DMuu5ZfsVKi1oSoXkkZ9aWgL/NWKD3WOBZtzFucSRHNJehGlEDrKfPWI/ExH GJoAHi1rr6zbVHMSHyEGtB6Xu8HVF+QT8AIytHewV3Ca9a7v1cnEm+94WRxzob5G6z263SWkj 4qEIbJGJUNj7Npl4+IxgWIODDAtb5OnMhOJdtPzlon6Fo3ksKrPkh6M4RFlmk8tT+3bhnL1Hd jV+LGhCqFx1KI6IFCavJMo/Y45QKmXIZ+2gSFyoj6OJvMQvbNFi/Sewzg5NFKkRfIpH84bAqp BBlOLySjyhRI06IQF4QXWmJdaRYhLhF7TZtnSQpCi3qrKVmvnhjP2QqKPMs= Archived-At: Cc: core@ietf.org Subject: Re: [core] DTLS over CoAP 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, 24 Nov 2016 13:37:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LgIhlbRJ8oPGpHkfdj1q81cmuR57oFHUu Content-Type: multipart/mixed; boundary="FMsjliME251tAVeRDlJDaTnLUWtjHcrUs"; protected-headers="v1" From: Hannes Tschofenig To: weigengyu , Carsten Bormann Cc: =?UTF-8?Q?G=c3=b6ran_Selander?= , core@ietf.org Message-ID: Subject: Re: [core] DTLS over CoAP References: <0877a32a-3363-c86b-6cbb-a5c7db798c2c@gmx.net> <44FAF50836AF40D5BB631F8778957841@WeiGengyuPC> In-Reply-To: <44FAF50836AF40D5BB631F8778957841@WeiGengyuPC> --FMsjliME251tAVeRDlJDaTnLUWtjHcrUs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You are correct in your observation that TLS may due the job when the underlying application protocol already provides reliable transmission. On 11/24/2016 09:12 AM, weigengyu wrote: > CoAP is a reliable protocol and TLS is designed to run over a reliable > protocol which is TCP as default. > So, having TLS over CoAP seems to be rational. >=20 > I wonder that TLS may needs modifing less than DTLS if comparing TLS > over CoAP than DTLS over CoAP. --FMsjliME251tAVeRDlJDaTnLUWtjHcrUs-- --LgIhlbRJ8oPGpHkfdj1q81cmuR57oFHUu 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYNuz6AAoJEGhJURNOOiAtEK0H/it4Hvaor604MjdphLMl6m4U LWO5qE4T5CxugXJ3XtqGLOKv+goDohqbJERm9xuc8s7W6QoQxEBu3yw22VswC6US Rh+La1svO98ac6/ofCLFNFwCplrDiTNyte6NJHcn1PXF5rOwYLdhX5pIyCFvhCwq IgGYgsRK632RGGNFB092BuV6Z7AvpRnpx7UzvpwkTuIAoGW9g07ldlRIsgOTmXuK li3JMTdb8YjDgGHMx08HAQ9A7WqntESIbKQeJvRP8lYsAMBxZiV4vJfPF21iC6Df mkT/WyL3vuUGdXB6iJ2TgPet2Q4MZQ98Acnze5Q27BBOPzX0E0BE2h+gD56Jy6I= =eQdh -----END PGP SIGNATURE----- --LgIhlbRJ8oPGpHkfdj1q81cmuR57oFHUu-- From nobody Mon Nov 28 09:34: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 084D5129F69; Mon, 28 Nov 2016 09:34:06 -0800 (PST) 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.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148035444603.5386.435381283293769937.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 09:34:06 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-17.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, 28 Nov 2016 17:34:06 -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-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-17.txt Pages : 43 Date : 2016-11-28 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-17 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 Nov 28 09:40: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 66E25129F76; Mon, 28 Nov 2016 09:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SADLTMiwysU; Mon, 28 Nov 2016 09:40:08 -0800 (PST) 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 0E49B129EAB; Mon, 28 Nov 2016 09:40:07 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C71D6EF7AD567; Mon, 28 Nov 2016 17:40:01 +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 uASHe3Fv022296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Nov 2016 17:40:04 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uASHe2dU030625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Nov 2016 17:40:02 GMT Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.191]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 28 Nov 2016 18:40:02 +0100 From: "Fossati, Thomas (Nokia - GB)" To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-17.txt Thread-Index: AQHSSZ5yQWheox8CbkSzeCNa0RoAnw== Date: Mon, 28 Nov 2016 17:40:02 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_D4621B4176DBBthomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , The IESG Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-17.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 Nov 2016 17:40:10 -0000 --_000_D4621B4176DBBthomasfossatialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, We have just uploaded http-mapping-17. This version should close all open DISCUSS, i.e.: Stephens' [1] and Ben's [= 2]. In particular, the conversation around the latter point ended in Seoul with= the decision of the working group to move the document from Informational = to PS [3]. Hopefully Stephen and Ben are satisfied with the outcome of this pretty lon= g but important discussion and we can move forward =97 IIUC, re-issuing IET= F LC on the document? Cheers, Thomas (on behalf of the draft editors). [1] https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/#s= tephen-farrell [2] https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/#b= en-campbell [3] http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-core --_000_D4621B4176DBBthomasfossatialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B4E542D3525FB41ACBF60BB992CF679@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hi all,

We have just uploaded http-mapping-17.

This version should close all open DISCUSS, i.e.: Stephens' [1] and Be= n's [2].

In particular, the conversation around the latter point ended in Seoul= with the decision of the working group to move the document from Informati= onal to PS [3].

Hopefully Stephen and Ben are satisfied with the outcome of this prett= y long but important discussion and we can move forward =97 IIUC, re-issuin= g IETF LC on the document?

Cheers, Thomas (on behalf of the draft editors).

--_000_D4621B4176DBBthomasfossatialcatellucentcom_-- From nobody Mon Nov 28 11:08:47 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 D58C1129F8F; Mon, 28 Nov 2016 11:08:39 -0800 (PST) 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.38.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148036011985.5514.3457646909214230918.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 11:08:39 -0800 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Last Call: (Guidelines for HTTP-to-CoAP Mapping Implementations) to Informational RFC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@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: Mon, 28 Nov 2016 19:08:40 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a Second IETF LC for the document. The document was initially targeted at Informational, but is now targeting to become Proposed Standard. Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 29 09:38:14 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 A0D2B129C36; Tue, 29 Nov 2016 09:38:11 -0800 (PST) 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.38.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148044109165.11686.836486035375310202.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 09:38:11 -0800 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Last Call: (Guidelines for HTTP-to-CoAP Mapping Implementations) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@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: Tue, 29 Nov 2016 17:38:12 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Guidelines for HTTP-to-CoAP Mapping Implementations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a Second IETF LC for the document. The document was initially targeted at Informational, but is now targeting to become Proposed Standard. Abstract This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 29 22:09: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 D18C0126CD8; Tue, 29 Nov 2016 22:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 h0zDH8mhqp-U; Tue, 29 Nov 2016 22:09:07 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8184C129488; Tue, 29 Nov 2016 22:08:59 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 29 Nov 2016 22:28:40 -0800 From: Jim Schaad To: Date: Tue, 29 Nov 2016 22:08:52 -0800 Message-ID: <083101d24ad0$3b071aa0$b1154fe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJKtW70xWwK1XHBRtGhNREf/zkBMg== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: core@ietf.org Subject: [core] Comments on draft-ietf-core-object-security-06 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 Nov 2016 06:09:11 -0000 Since I never seem to get that far in the document I decided to jump straight to appendix C and look at what you have for OSCON. As I have stated many times the past, I believe that this should be part of the core document and not an appendix, but I don't ever remember reading it. Appendix C - I am having a hard time with the first paragraph here. I do not believe that you have correctly characterized the problem. The reason that you cannot use OSCOAP for this has more to do with how you decided which records in the header to authenticate rather than the fact that this is going to be distributed to multiple recipients. Appendix C - Talking about the "unprotected" and the "protected" CoAP message is very confusing especially since COSE has protected and unprotected objects as well. It would be better to use a different terminology such as "the original message" and "the resulting message". Appendix C - I do not understand what this sentence means. " OSCON shall not be used in cases which require a secure binding between request and response." Is it intended to say that the use of a transaction identifier in the COSE wrappers for the request and response is not permitted? There are a lot of ways to do this that do not rely on CoAP. Appendix C - It is not clear if the Content-Format should be set if there was no Content-Format in the original message. Appendix C.1 - I do not understand what this section is trying to accomplish. It appears to be doing three different things, some of which should be in Appendix C, some of which should be standalone and some of which looks like it should be Appendix C.5 - There should be a discussion related this this about the different security properties that are to be found for Encrypt+Sign(M) vs Sign(Encrypt(M)). Appendix B - These are really example message flows rather than examples of OSCOP messages. This should be made clearer in the section title Appendix B.1 - How does one securely bind the request and the response? I am not seeing anything from this example that will do so. From nobody Wed Nov 30 00:30: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 814941295F7 for ; Wed, 30 Nov 2016 00:30:42 -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 Qjn3yovMScuZ for ; Wed, 30 Nov 2016 00:28:52 -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 0D36D129406 for ; Wed, 30 Nov 2016 00:28:51 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud2.xs4all.net with ESMTP id E8Up1u00G4QBLo2018Updf; Wed, 30 Nov 2016 09:28:50 +0100 Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 30 Nov 2016 09:28:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 30 Nov 2016 09:28:49 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <0c85346845306da9e01117bedd9e5747@xs4all.nl> X-Sender: stokcons@xs4all.nl (rYFxHj1FY9ezSaFBb/vrduo7KBZNZgxL) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] yang cbor comments 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 Nov 2016 08:30:42 -0000 Hi Michel, Apologies for the late reaction, but I was occupied by other things, and almost forgot. Let me give one example from section 5.9 The text says: The following example shows the encoding of leaf 'interface-state- ref' set to the value "eth1". However it is NOT the encoding of the leaf, but the encoding of the value of the leaf. (that's where my confusion comes from, sorry to seem to be nit-picking) My proposal: The following example shows the encoding of the value "eth1" assigned to the leaf 'interface-state-ref'. I hope I made my point clearer. You may start the sections 5, before section 5.1, with the following text: In the folowing examples values of the discussed type are assigned to an example leaf of the discussed type. Consectively, the CBOR encoding of the value is shown. (Or similar but much better text.) > >> ====> Examples of section 5. Do the examples not need an identifier >> (CBOR key)? We now are faced with values which do not belong anywhere. >> Also the SID value needs to be specified. For example section 5.1 can >> be written as follows: >> The leaf mtu is assumed to have value 1280 The sid of mtu is 1350 The >> CBOR diagnostic notation of the pair is 1350: 1280, which results in >> Page 15 /signed integer/negative integer/ >> >> Same answer as above. >> None of the YANG Data Node Instances defined in section 4 (leaf, >> container, leaf-list, list, anydata, anyxml) is encoded with its >> identifier. >> Such identifiers are part of the instance-identifier carry in the >> request URI or within the payload. >> This is the job of CoMI >> >> ====>Section 5.10.1; it is unclear where the value 1180 comes from. > > I seem to express myself badly. > It is only needed to say that mtu is assumed to have value 1280 and > that the CBOR encoding of 1280 is: > > At this moment the scope of the example CBOR code is unclear. > > [MV] in section 5.1, the example is introduced with the sentence: > [MV] "The following example shows the encoding of leaf 'mtu' set to > 1280 bytes." > [MV] Is it the part that is unclear? > [MV] Can you propose an updated text to clarify this example? > >> ====> Section 5.13 is very unclear. There are many examples but it is >> not clear where all these values come from; what is the SID value, >> what was the leaf instance value, is one large puzzle. One example >> (instead of 3), but with more explanations would help. In my opinion >> the text in belongs in the FETCH content format document that still >> needs to be written. >> >> The multiple examples have been requested by different peoples >> including Carsten. >> These examples show completely different use cases, single instance >> data node, list and list instance and are all useful. >> For the question, "what is the SID value", this will be resolved by >> the implementation of the registrars sharing a common database >> (blockchain) of .sid files. > > please see my responses above. > Not the examples are questioned but an explanation is needed that says > that the CBOR code for the value is shown and not the whole leaf. > > [MV] This topic is discussed in section > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-03#section-3 > [MV] > [MV] "Basic schema nodes such as leaf, leaf-list, list, anydata and > anyxml can be encoded standalone. > [MV] In this case, only the value of this schema node is encoded in > CBOR. Identification of this value needs > [MV] to be provided by some external means when required. > [MV] A collection such as container, list instance, notification, > RPC input, RPC output, action input and action > [MV] output is serialized using a CBOR map in which each child > schema node is encoded using a key and a value." > [MV] > [MV] Can you propose an updated text to clarify this topic? > From nobody Wed Nov 30 06:48: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 912501295DE for ; Wed, 30 Nov 2016 06:47:59 -0800 (PST) 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 8JBNsb-VCq2K for ; Wed, 30 Nov 2016 06:47:57 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688981298C3 for ; Wed, 30 Nov 2016 06:47:09 -0800 (PST) X-AuditID: c1b4fb3a-97bff70000007918-83-583ee66b5676 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id D3.01.31000.B66EE385; Wed, 30 Nov 2016 15:47:07 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 15:47:07 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" Thread-Topic: OSCOAP update Thread-Index: AQHSSxif7sKIdzvIZ0GoNx6934CUxA== Date: Wed, 30 Nov 2016 14:47:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <4E185968FACCED439047C5612747E082@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7pW72M7sIg/tXTS32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO33PzEWtHFW3N/1nrWB8QVHFyMnh4SAiUTLqUesILaQwDpG iQOr1LsYuYDsJYwSjycsYgZJsAm4SDxoeMQEYosIKEtsPvOaEcQWFhCTaN5+ByouLdE0eTML hK0nMWvZPbA4i4CqxIK5G8Dm8ApYSBxaPgWslxGo9/upNWA1zALiEreezGeCOEhAYsme88wQ tqjEy8f/gI7j4BAFmrnmfhhEWEli7eHtLCBhZgFNifW79CGmWEtMurGbGcJWlJjS/ZAdYqug xMmZT1gmMIrMQrJsFkL3LCTds5B0z0LSvYCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG YDQc3PLbagfjweeOhxgFOBiVeHg/TLeNEGJNLCuuzD3EKMHBrCTCu+WBXYQQb0piZVVqUX58 UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjJoqxa+VD89y3JO+9XV1//GS zxPjVjzXU5n+c5Yjj6ymCcsWfc8tigznhWO2/OnwXHB4Ztq75ZGxDS5HLSdG+PArcN6XMvju V6imkF8y8/vBi3JJ9/rLml0efHi6i/m54gXhdGnfc2as8mI6TizSf331XlmHhZ4/t/l04CpL tZXccw4/5Q1KU2Ipzkg01GIuKk4EANBxCc+CAgAA Archived-At: Subject: [core] OSCOAP 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: Wed, 30 Nov 2016 14:47:59 -0000 DQpEZWFyIGFsbCwNCg0KSW4gdGhlIHJlY2VudCBmMmYgbWVldGluZyB3ZSBkZWNpZGUgdG8gbGFi ZWwNCmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDAgYW4g4oCcaW1wbGVtZW50YXRp b24gZHJhZnTigJ0gdG8gYmUgdXNlZA0KZm9yIGludGVyb3AgdGVzdGluZyBpbiB0aGUgYmVnaW5u aW5nIG9mIG5leHQgeWVhci4gV2UgaGF2ZSByZWNlbnRseSBtYWRlDQphbiB1cGRhdGUgb24gdGhl IEdpdGh1YiAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvb3Njb2FwKSB3aGljaCBjb250YWlu cw0KbWFueSBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbnMgYW5kIGEgZmV3IGNoYW5nZXMgdG8gdGhl IGFjdHVhbA0Kc3BlY2lmaWNhdGlvbi4gT25lIGNoYW5nZSBpcyB0aGUgaGFybW9uaXNhdGlvbiB0 byBUTFMgb2YgdGhlIHJlcGxheQ0KcHJvdGVjdGlvbiBtZWNoYW5pc20uIEFub3RoZXIgY2hhbmdl IGlzIHRoZSBpbnRyb2R1Y3Rpb24gb2YgZnVydGhlciBDQk9SDQpzdHJ1Y3R1cmVzIHRvIGF2b2lk IGJsZWVkaW5nIGJldHdlZW4gbWVzc2FnZSBmaWVsZHMuIFRoZSBhY3R1YWwgY2hhbmdlcyBpbg0K dGVybXMgb2YgaW1wbGVtZW50YXRpb24gYXJlIG1pbm9yIGNvbXBhcmVkIHRvIC0wMC4NCg0KV2Ug cGxhbiB0byByZWxlYXNlIGEgdmVyc2lvbiAtMDEgdGhpcyB3ZWVrIChhbHNvIGNvbnNpZGVyaW5n IHRoZSByZWNlbnQNCmNvbW1lbnRzIGZyb20gSmltKSBhbmQgd291bGQgcHJvcG9zZSB1cyB0byB1 c2UgLTAxIGFzIHRoZSBpbXBsZW1lbnRhdGlvbg0KdmVyc2lvbiBpbnN0ZWFkIG9mIC0wMC4NCg0K QW55b25lIHZpZXdzIG9uIHRoaXM/DQoNClJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQo= From nobody Wed Nov 30 07:16: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 2AEA8129446 for ; Wed, 30 Nov 2016 07:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAYA5XLDBG6O for ; Wed, 30 Nov 2016 07:16:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B35C1293F5 for ; Wed, 30 Nov 2016 07:16:34 -0800 (PST) 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 uAUFGU0D029775; Wed, 30 Nov 2016 16:16:30 +0100 (CET) Received: from eduroam-pool6-0447.wlan.uni-bremen.de (eduroam-pool6-0447.wlan.uni-bremen.de [134.102.25.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tTPC23yZkz8L9t; Wed, 30 Nov 2016 16:16:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: Date: Wed, 30 Nov 2016 16:16:29 +0100 X-Mao-Original-Outgoing-Id: 502211789.231691-0cce714d69118504d05c8c2954ddd3e4 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] OSCOAP 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: Wed, 30 Nov 2016 15:16:37 -0000 On 30 Nov 2016, at 15:47, G=C3=B6ran Selander = wrote: >=20 > We plan to release a version -01 this week (also considering the = recent > comments from Jim) and would propose us to use -01 as the = implementation > version instead of -00. Sounds good to me. Maybe we should even get in a few reviews of -01 = before we label. I think the best way to get these is for the chairs to issue a formal = last call on -01 once its there (not a WGLC, but a last call before = labeling). This should be doable in a week, I think. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 30 09:04: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 42D611295B0; Wed, 30 Nov 2016 09:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=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 QGsXxq6PDRnY; Wed, 30 Nov 2016 09:03:54 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003C4129456; Wed, 30 Nov 2016 09:03:52 -0800 (PST) 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 uAUH3k3d001975; Wed, 30 Nov 2016 18:03:47 +0100 (CET) Received: from [192.168.217.113] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tTRZp4k1Fz8LCs; Wed, 30 Nov 2016 18:03:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <8C4F164D-DB72-4927-9BB7-81EB6B69980B@tzi.org> Date: Wed, 30 Nov 2016 18:03:46 +0100 X-Mao-Original-Outgoing-Id: 502218225.961512-7f2d7495a74c5b5dd90cf3eea905e436 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147612868715.31457.7459381389963542114.idtracker@ietfa.amsl.com> <57FCDC80.3000004@tzi.org> <2DCF36F2-0821-4B02-A97F-2B8D238B3C67@cooperw.in> <8C4F164D-DB72-4927-9BB7-81EB6B69980B@tzi.org> To: Alissa Cooper X-Mailer: Apple Mail (2.3251) Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, IESG , core@ietf.org Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-etch-03: (with DISCUSS and 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: Wed, 30 Nov 2016 17:03:59 -0000 On 14 Nov 2016, at 02:29, Carsten Bormann wrote: >=20 > I think that together with the other editorial improvements that = should be enough to address the concern and clear the DISCUSS. Hi Alissa, just checking whether this fell on the floor in the run up to IETF97. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 30 12:51:02 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 737F7129A8B; Wed, 30 Nov 2016 12:51:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148053906144.9726.4431534233095634676.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 12:51:01 -0800 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Alissa Cooper's No Objection on draft-ietf-core-etch-04: (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: Wed, 30 Nov 2016 20:51:01 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-core-etch-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-etch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. OLD COMMENT: = Section 2 = "(However, while processing a search request, a server can be expected to allocate computing and memory resources or even create additional server resources through which the response to the search can be retrieved.)" s/search/fetch/ would be clearer I think = Section 3 = "If the Request-URI does not point to an existing resource, the server MAY create a new resource with that URI, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc." I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions? = Section 5 = It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning. From nobody Wed Nov 30 14:00: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 4A0DB129B74 for ; Wed, 30 Nov 2016 14:00:07 -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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK-_8-zd6q43 for ; Wed, 30 Nov 2016 14:00:02 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0091.outbound.protection.outlook.com [104.47.42.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136EB129B75 for ; Wed, 30 Nov 2016 13:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8t0PiBMv5+pBTSvezk7o3UM/BnBfwe/FRN0mKRHSt6o=; b=bqjUkavhsph1m+ntM0nc2BAWKsnbbUduNuFd+HVQEIBz65lU2OyxdkO+NprZbwk8ayuyBQPe1JcO0CFaKYg88GnTDvrWDz4IVqdEOB90RZ31XDT6S7pdpugf8C8K13Kre9yB47WikHZRNEbS6WWW8P95N3W2Owg2rGg6FGuB8ZQ= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Wed, 30 Nov 2016 21:59:46 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0747.013; Wed, 30 Nov 2016 21:59:45 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] yang cbor comments Thread-Index: AQHSQLpL47EAr//15UCwVCri7zu5mqDdWvVAgACFSgCAB2rIMIAL+xCAgADSL4A= Date: Wed, 30 Nov 2016 21:59:45 +0000 Message-ID: References: <0c85346845306da9e01117bedd9e5747@xs4all.nl> In-Reply-To: <0c85346845306da9e01117bedd9e5747@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 18a5d616-201d-4048-9b65-08d4196c3258 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2307; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:3zVgRhho53P1ixtyDXhqhpm14FDOBQcUFSj5VXoJhc9t+vUKdl6i9bzaShQyiUmOPfPP0dEojfikSFTzAQxnJ1h3vNvRqxv7S5wzdS5T/7S6de3aOM1M8MV4gsW0MBnGdYLcqMEDdZNuS/rQVOQMig8mjCgRgnP16obF69PeIF2loai3X8wP00vj7rkaq55Yabmh20HN6jBX8BBG1EzBzHNgKFdTrw+AVXVY8aKDsr6tUCW0enaZiDUVl996V5XG8YX8Poeqgu4p4oM2BouAu1T4P+W8IoAn1cDP/RkTQbLOgedLXpH5nRy3C1LF9uhsj6wR0D78NvdEg6Rpfd6MukLfCkFBG6OCnNxgSru1tbO4l/i3rON0fi7RCed8JmFKJ/dQfLz0rDRLChqKfWCb6Xt60Xvl2e9hJTj1Btb21VjrXsFKhsZdzT6IvoPXavOkg60KtRiVUzFEnpwPaCEWXA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 0142F22657 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(13464003)(5660300001)(2906002)(93886004)(3280700002)(81156014)(561944003)(2501003)(105586002)(3660700001)(8936002)(92566002)(99286002)(33656002)(9686002)(5640700001)(68736007)(8676002)(81166006)(7846002)(1730700003)(7736002)(76576001)(74316002)(305945005)(106116001)(54356999)(229853002)(50986999)(122556002)(6916009)(86362001)(2950100002)(2351001)(106356001)(38730400001)(110136003)(7696004)(4326007)(3846002)(6116002)(66066001)(102836003)(2900100001)(39450400002)(101416001)(39410400001)(76176999)(77096006)(189998001)(6506003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 30 Nov 2016 21:59:45.5230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Cc: Core Subject: Re: [core] yang cbor comments 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 Nov 2016 22:00:07 -0000 Hi Peter =3D=3D=3D About " My proposal: The following example shows the encoding of = the value "eth1" assigned to the leaf 'interface-state-ref'." All examples have been fixed with the following scheme: The following example shows the encoding of an 'interface-state-ref' lea= f instance set to "eth1". See diff at https://github.com/core-wg/yang-cbor/commit/6f514542d5d09ec5c992e095dd60= 9c68303cdb89#diff-083fd5e71ffd63b12d8cd2854c3ad1bf Your proposed solution works fine for this specific example but was hard to= apply to all examples. I'm also not sure about the use of "assigned" which seem to imply a previou= s PUT or POST. I'm open the revisit this wording if needed. =3D=3D=3D About the into of section 5, I proposing the following text based= on the intro present in https://tools.ietf.org/html/rfc7951#section-6=20 The CBOR encoding of an instance of a leaf or leaf-list data node depends o= n the built-in type of that data node. The following sub-section defined th= e CBOR encoding of each built-in type supported by YANG as listed in [RFC79= 50] section 4.2.4. Each subsection shows an example value assigned to a dat= a node instance of the discussed built-in type. The update draft is available at http://core-wg.github.io/yang-cbor/draft-i= etf-core-yang-cbor-latest.txt Regards, Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Wednesday, November 30, 2016 3:29 AM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] yang cbor comments Hi Michel, Apologies for the late reaction, but I was occupied by other things, and al= most forgot. Let me give one example from section 5.9 The text says: The following example shows the encoding of leaf 'interface-state- ref' set to the value "eth1". However it is NOT the encoding of the leaf, but the encoding of the value o= f the leaf. (that's where my confusion comes from, sorry to seem to be nit-= picking) My proposal: The following example shows the encoding of the value "eth1" assigned to th= e leaf 'interface-state-ref'. I hope I made my point clearer. You may start the sections 5, before section 5.1, with the following text: In the folowing examples values of the discussed type are assigned to an ex= ample leaf of the discussed type. Consectively, the CBOR encoding of the value is shown. (Or similar but much better text.) >=20 >> =3D=3D=3D=3D> Examples of section 5. Do the examples not need an identif= ier=20 >> (CBOR key)? We now are faced with values which do not belong anywhere. >> Also the SID value needs to be specified. For example section 5.1 can=20 >> be written as follows: >> The leaf mtu is assumed to have value 1280 The sid of mtu is 1350 The=20 >> CBOR diagnostic notation of the pair is 1350: 1280, which results in=20 >> Page 15 /signed integer/negative integer/ >>=20 >> Same answer as above. >> None of the YANG Data Node Instances defined in section 4 (leaf,=20 >> container, leaf-list, list, anydata, anyxml) is encoded with its=20 >> identifier. >> Such identifiers are part of the instance-identifier carry in the=20 >> request URI or within the payload. >> This is the job of CoMI >>=20 >> =3D=3D=3D=3D>Section 5.10.1; it is unclear where the value 1180 comes f= rom. >=20 > I seem to express myself badly. > It is only needed to say that mtu is assumed to have value 1280 and=20 > that the CBOR encoding of 1280 is: >=20 > At this moment the scope of the example CBOR code is unclear. >=20 > [MV] in section 5.1, the example is introduced with the sentence: > [MV] "The following example shows the encoding of leaf 'mtu' set to > 1280 bytes." > [MV] Is it the part that is unclear? > [MV] Can you propose an updated text to clarify this example? >=20 >> =3D=3D=3D=3D> Section 5.13 is very unclear. There are many examples but = it is=20 >> not clear where all these values come from; what is the SID value,=20 >> what was the leaf instance value, is one large puzzle. One example=20 >> (instead of 3), but with more explanations would help. In my opinion=20 >> the text in belongs in the FETCH content format document that still=20 >> needs to be written. >>=20 >> The multiple examples have been requested by different peoples=20 >> including Carsten. >> These examples show completely different use cases, single instance=20 >> data node, list and list instance and are all useful. >> For the question, "what is the SID value", this will be resolved by=20 >> the implementation of the registrars sharing a common database >> (blockchain) of .sid files. >=20 > please see my responses above. > Not the examples are questioned but an explanation is needed that says=20 > that the CBOR code for the value is shown and not the whole leaf. >=20 > [MV] This topic is discussed in section > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-03#section-3 > [MV] > [MV] "Basic schema nodes such as leaf, leaf-list, list, anydata and > anyxml can be encoded standalone. > [MV] In this case, only the value of this schema node is encoded in > CBOR. Identification of this value needs > [MV] to be provided by some external means when required. > [MV] A collection such as container, list instance, notification, > RPC input, RPC output, action input and action > [MV] output is serialized using a CBOR map in which each child > schema node is encoded using a key and a value." > [MV] > [MV] Can you propose an updated text to clarify this topic? >=20 From nobody Wed Nov 30 22: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 73F18128874 for ; Wed, 30 Nov 2016 22:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 28GpdY0bLDxg for ; Wed, 30 Nov 2016 22:52:42 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2FF129BEC for ; Wed, 30 Nov 2016 22:52:40 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 30 Nov 2016 23:11:59 -0800 From: Jim Schaad To: Date: Wed, 30 Nov 2016 22:52:12 -0800 Message-ID: <018401d24b9f$72d6f8e0$5884eaa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJLnlAU1xxThzc1SwG4iFkQ1mka5A== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Caching of responses 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, 01 Dec 2016 06:52:46 -0000 In the process of talking about the OSCOAP drafts with people at the Seoul IETF, I finally managed to get my understanding of the caching problem that I see into a formulation that can be understood by other people. When you look at caching, there are two different types that can be thought about: 1. I am caching a value that can be used by anybody who asks for the same answer. This is the classical type of caching that occurs on the internet today and is how things such as DNS work. 2. I am caching a value that can only be used by a specific person, but I am doing so in order to deal with the fact that the network is unreliable and by doing so I can a) decrease the response time in the even the packet is lost between me and the asker and b) can generally increase the reliability of the network between me and the responder. Generally, this type of caching would require a combination of asker address/port and information from the request. CoAP currently supports the first and not the second. When security is added to messages, I believe that the second type of caching may become important as well since the first set of caching would hopefully approach zero as we add more and more security to messages. Am I way out in left field or does this make sense? Jim From nobody Wed Nov 30 23:48: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 87943129C11; Wed, 30 Nov 2016 23:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efgcL7Tr2xMl; Wed, 30 Nov 2016 23:47:54 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEC51295AC; Wed, 30 Nov 2016 23:47:51 -0800 (PST) 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 uB17ljOl005961; Thu, 1 Dec 2016 08:47:45 +0100 (CET) Received: from [172.20.10.2] (ip-109-47-2-226.web.vodafone.de [109.47.2.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tTqBk0hMpz8LPt; Thu, 1 Dec 2016 08:47:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <148053906144.9726.4431534233095634676.idtracker@ietfa.amsl.com> Date: Thu, 1 Dec 2016 08:47:40 +0100 X-Mao-Original-Outgoing-Id: 502271260.371683-3ebb6472c998039b9c0f502f24fc394a Content-Transfer-Encoding: quoted-printable Message-Id: <0E4DD69D-E4EF-4FFC-B15F-A2368B3EA226@tzi.org> References: <148053906144.9726.4431534233095634676.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3251) Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Alissa Cooper's No Objection on draft-ietf-core-etch-04: (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: Thu, 01 Dec 2016 07:47:55 -0000 > On 30 Nov 2016, at 21:51, Alissa Cooper wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-core-etch-04: No Objection Thank you for clearing the DISCUSS. Your remaining COMMENTs also have been addressed in -04: > =3D Section 2 =3D >=20 > "(However, while processing a search request, a server can be expected > to allocate computing and memory resources or even create additional > server resources through which the response to the search can be > retrieved.)" >=20 > s/search/fetch/ would be clearer I think Done in -04. > =3D Section 3 =3D >=20 > "If the Request-URI does not point to an existing > resource, the server MAY create a new resource with that URI, > depending on the patch document type (whether it can logically = modify > a null resource) and permissions, etc." >=20 > I know this is the same text as in RFC 5789, but it's vague. What else > might create the basis for the server's decision besides the document > type and permissions? I don=E2=80=99t think the considerations going into the server=E2=80=99s = decision can be enumerated completely, but -04 changes =E2=80=9Cetc.=E2=80= =9D into: [=E2=80=A6], as well as other conditions such as the degree of control the server gives clients in creating new entries in its URI space (see also Section 3.4). =20 > =3D Section 5 =3D >=20 > It seems that FETCH does introduce a new security consideration, in = that > any observer of FETCH requests can potentially glean information about > the specific portions of a resource of interest to the requester. This > might factor into decisions about whether to use DTLS to secure a > particular request so may be worth mentioning. This is indeed an important security consideration to be aware of. -04 now says: [=E2=80=A6] The payload of a FETCH request may reveal more detailed information about the specific portions of a resource of interest to the requester than a GET request for the entire resource would; this may mean that confidentiality protection of the request by DTLS or other means is needed for FETCH where it wouldn't be needed for GET. Thank you again for comments that really helped us improve the document. Gr=C3=BC=C3=9Fe, Carsten