From nobody Mon Feb 2 11:45:55 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007671A89B9 for ; Mon, 2 Feb 2015 11:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTXwyrCoesuP for ; Mon, 2 Feb 2015 11:45:42 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0679B1A893F for ; Mon, 2 Feb 2015 11:45:42 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id s18so44675960lam.3 for ; Mon, 02 Feb 2015 11:45:40 -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:cc:content-type; bh=WnkGOuMWdFpqXbaRNg0+vSEnBZ1CG4t3Y758rqI6Pz0=; b=GZ9RhRrGKaBRXLxgQrJJPii4IKHcNChBT9++Ln5OaFqeOuRERxnEfYHSl51EvqD0wc e6ySbLaMkOM0ReUL4U/D3/ELz4+P1ZmdYnfOTB2Dd2JDXWYSALRRy4eCz6JayRJ4If3e 7yQ8+LeacV8Pk4A+G8owRiACp3p88eJvw/6VumtFPKqlXoX5yO//jH/FpOE0YHkNl0dh pmeqe9WpCRXd67WcQ2dkHD9JqGGJO2j/g7Ru2RMvy1uTqV6JhRoH0SocJsY4fBYHbBrX Wbb5ta+Xc2Y2J4PF9WxtJfiAH+1M0A/tSWnG977ixp4pqrLi8x/ZG4CC3VemLdY5ssxO jN8A== X-Received: by 10.112.125.41 with SMTP id mn9mr21051989lbb.80.1422906340505; Mon, 02 Feb 2015 11:45:40 -0800 (PST) MIME-Version: 1.0 From: Julien Vermillard Date: Mon, 02 Feb 2015 19:45:39 +0000 Message-ID: To: "core@ietf.org" Content-Type: multipart/alternative; boundary=089e0112c200f97d5e050e2032a2 Archived-At: Subject: [core] SenML and delta encoding for samples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:45:49 -0000 --089e0112c200f97d5e050e2032a2 Content-Type: text/plain; charset=UTF-8 Hi, I'm taking a look at SenML with a CBOR encoding for replacing a proprietary representation for telemetry values. For now it's fitting my needs but I'm just surprised about the lack of delta encoding for values (it's present for timestamp only). Here my use case: We send large number of samples of vehicle sensors: time, latitude, longitude, altitude, accelerometer (x, y, z) and some extra sensors. Everything is sampled at 10 Hz, so the difference between each sample can be minimal. Smaller the delta value is, smaller the json or cbor encoding would be. The file can be really large (megabytes), so delta encoding save a lot of space (30% for a protocol buffer based encoding). A crude example, of delta encoding support for samples could look likes: {"e":[ { "n": "sensorA", "dv":20 }, { "n": "sensorB", "t": -5, "dv": 0.2 }, { "n": "sensorB", "t": -4, "dv": 0.30 }, { "n": "sensorA", "t": -3, "dv": -10.14 }, { "n": "sensorB", "t": -2, "dv": 0.5 }, { "n": "sensorA", "t": -1, "dv": 20.6 }, { "n": "sensorB", "t": 0, "dv": 0.7 }], "bn": "urn:dev:mac:0024befffe804f/", "bt": 1276020076, "ver": 1, "bv" : { "sensorA" : 1000, "sensorB": 250} } vs {"e":[ { "n": "sensorA", "dv":1020 }, { "n": "sensorB", "t": -5, "dv": 250.2 }, { "n": "sensorB", "t": -4, "dv": 250.30 }, { "n": "sensorA", "t": -3, "dv": 990.14 }, { "n": "sensorB", "t": -2, "dv": 250.5 }, { "n": "sensorA", "t": -1, "dv": 1020.6 }, { "n": "sensorB", "t": 0, "dv": 250.7 }], "bn": "urn:dev:mac:0024befffe804f/", "bt": 1276020076, "ver": 1 } I can provide an example based on real world samples if it helps. By the way putting "e" at the end of the document would help streaming and reduce memory consumption, I wonder why all the samples are this way in the RFC, it could be misleading. Julien --089e0112c200f97d5e050e2032a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,
I'm taking a look at SenML with a CBOR encoding for replacing a= proprietary representation for telemetry values.

= For now it's fitting my needs but I'm just surprised about the lack= of delta encoding for values (it's present for timestamp only).
<= div>
Here my use case:

We send large= number of samples of vehicle sensors:
time, latitude, longitude,= altitude, accelerometer (x, y, z) and some extra sensors. Everything is sa= mpled at 10 Hz, so the difference between each sample can be minimal. Small= er the delta value is, smaller the json or cbor encoding would be.

The file can be really large (megabytes), so delta encodin= g save a lot of space (30% for a protocol buffer based encoding).

A crude example, of delta encoding support for samples coul= d look likes:

{"e":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "sensorA", "dv= ":20 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "s= ensorB", "t": -5, "dv": 0.2 },
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 { "n": "sensorB", "t": -= 4, "dv": 0.30 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n&= quot;: "sensorA", "t": -3, "dv": -10.14 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "sensorB", &= quot;t": -2, "dv": 0.5 },
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 { "n": "sensorA", "t": -1, "dv"= : 20.6 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "sens= orB", "t": 0, =C2=A0 "dv": 0.7 }],
=C2= =A0 =C2=A0 "bn": "urn:dev:mac:0024befffe804f/",
=C2=A0 =C2=A0 "bt": 1276020076,
=C2=A0 =C2=A0 "= ver": 1,
=C2=A0 =C2=A0 "bv" : { "sensorA"= ; : 1000,=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "sensorB": 250} }

vs=C2=A0<= /div>

{"e":[
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 { "n": "sensorA", "dv":1020 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "sensorB", &q= uot;t": -5, "dv": 250.2 },
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 { "n": "sensorB", "t": -4, "dv&qu= ot;: 250.30 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "= ;sensorA", "t": -3, "dv": 990.14 },
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 { "n": "sensorB", "t"= ;: -2, "dv": 250.5 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { &qu= ot;n": "sensorA", "t": -1, "dv": 1020.6 = },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "sensorB&quo= t;, "t": 0, =C2=A0 "dv": 250.7 }],
=C2=A0 =C2= =A0 "bn": "urn:dev:mac:0024befffe804f/",
=C2= =A0 =C2=A0 "bt": 1276020076,
=C2=A0 =C2=A0 "ver&qu= ot;: 1
}

I can provide an example = based on real world samples if it helps.

By the wa= y putting "e" at the end of the document would help streaming and= reduce memory consumption, I wonder why all the samples are this way in th= e RFC, it could be misleading.

Julien
--089e0112c200f97d5e050e2032a2-- From nobody Tue Feb 3 00:27:23 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C3F1A6F39 for ; Tue, 3 Feb 2015 00:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 28B8LGa3Cn9M for ; Tue, 3 Feb 2015 00:27:19 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8DF1A1B4A for ; Tue, 3 Feb 2015 00:27:19 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id nkTH1p00D4Hiz6i01kTHws; Tue, 03 Feb 2015 09:27:17 +0100 Received: from AMontpellier-654-1-194-252.w90-0.abo.wanadoo.fr ([90.0.97.252]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 03 Feb 2015 09:27:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 03 Feb 2015 09:27:17 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (tzhc0Rn0xIJD6HZ7o9hjwJiqTAD64I4n) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 08:27:21 -0000 We have submitted a new version of the comi draft. The latest Changes from version 05 to version 06 have been: o Hash values in payload as hexadecimal and in URL in base64 numbers o Streamlined CoMI architecture text o Added select query parameter text o Data editing optional o Text on Notify added o Text on rehashing improved with example Greetings, peter A new version of I-D, draft-vanderstok-core-comi-06.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-comi Revision: 06 Title: CoAP Management Interface Document date: 2015-02-03 Group: Individual Submission Pages: 46 URL: http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-06.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: http://tools.ietf.org/html/draft-vanderstok-core-comi-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-06 Abstract: This document describes a network management interface for constrained devices, called CoMI. CoMI is an adaptation of the RESTCONF protocol for use in constrained devices and networks. It is designed to reduce the message sizes, server code size, and application development complexity. The Constrained Application Protocol (CoAP) is used to access management data resources specified in YANG, or SMIv2 converted to YANG. The payload of the CoMI message is encoded in Concise Binary Object Representation (CBOR). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Feb 4 02:04:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC54D1A1A92 for ; Wed, 4 Feb 2015 02:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPtg3CO7o30x for ; Wed, 4 Feb 2015 02:04:06 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 38C7F1A007B for ; Wed, 4 Feb 2015 02:04:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFADft0VSsEhcE/2dsb2JhbABag1hZgwHAA4V5AhyBOQEBAQEBfYQMAQEBBCNLCxAJAgQDBgEDAwECKAMCAgJECQgGCwgbqm6bewEBb5ZbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4UnYolUChEHBoJiLoETBYocjy2LDoY6hBhngkIBAQE X-IPAS-Result: AjAFADft0VSsEhcE/2dsb2JhbABag1hZgwHAA4V5AhyBOQEBAQEBfYQMAQEBBCNLCxAJAgQDBgEDAwECKAMCAgJECQgGCwgbqm6bewEBb5ZbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4UnYolUChEHBoJiLoETBYocjy2LDoY6hBhngkIBAQE X-IronPort-AV: E=Sophos;i="5.09,517,1418063400"; d="scan'208";a="641585232" In-Reply-To: <54C89A75.3010607@tzi.org> References: <031DD135F9160444ABBE3B0C36CED61839AA4DC9@AMSPRD9003MB066.MGDPHG.emi.philips.com> <54C89A75.3010607@tzi.org> To: Carsten Bormann , "Dijk, Esko" MIME-Version: 1.0 X-KeepSent: 3691B43A:9DBED3FD-65257DE2:003645AC; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 4 Feb 2015 15:33:55 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0.1FP2HF609 | December 16, 2014) at 02/04/2015 15:33:56, Serialize complete at 02/04/2015 15:33:56, Serialize by Router on InKolM02/TCS(Release 9.0.1FP2HF609 | December 16, 2014) at 02/04/2015 15:33:56 Content-Type: multipart/alternative; boundary="=_alternative 003743F365257DE2_=" Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP No-Response: use with NON only? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:04:09 -0000 This is a multipart message in MIME format. --=_alternative 003743F365257DE2_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXNrbywgQ2Fyc3RlbiwNClNvcnJ5IHRvIHJlc3BvbmQgbGF0ZSBvbiB0aGlzLiANCkluZGVl ZCwgcmVxdWVzdC9yZXNwb25zZSBsYXllciBhbmQgbWVzc2FnaW5nIGxheWVyIGZ1bmN0aW9uYWxp dGllcyBzaG91bGQgDQpiZSBzZXBhcmF0ZWQuIFdlIHNoYWxsIHJlbW92ZSB0aGUgY29uc3RyYWlu dCByZWdhcmRpbmcgZGVwZW5kZW5jeSBvbiANCk5PTi9DT04uIEJ1dCBhcyBhIG5vdGUgd2Ugc2hh bGwga2VlcCB0aGUgZGlzY3Vzc2lvbnMgdGhhdCB3ZSBoYWQgaW4gdGhlIA0KbWFpbGluZyBsaXN0 IHJlZ2FyZGluZyB3aHkgdXNpbmcgdGhpcyBvcHRpb24gd2l0aCBOT04gbWF5IGJlIGFuIG9idmlv dXMgDQpzYW5lIGFwcHJvYWNoLiANCkhvcGUsIHRoYXQgc2hvdWxkIGJlIGZpbmUuDQoNClJlZ2Fy ZHMNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlz dCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZp Y2VzDQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRlOiBodHRw Oi8vd3d3LnRjcy5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpFeHBlcmllbmNlIGNlcnRhaW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAgICAgICAg ICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBDb25z dWx0aW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KRnJvbTogICBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NClRvOiAgICAgIkRpamss IEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5jb20+LCBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgDQo8 YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+LCAiY29yZUBpZXRmLm9yZyIgPGNvcmVAaWV0 Zi5vcmc+DQpEYXRlOiAgIDAxLzI4LzIwMTUgMDE6NDQgUE0NClN1YmplY3Q6ICAgICAgICBSZTog W2NvcmVdIENvQVAgTm8tUmVzcG9uc2U6IHVzZSB3aXRoIE5PTiBvbmx5Pw0KDQoNCg0KPiDigJxw cmltYXJpbHkgaW50ZW5kZWQgdG8gYmUgdXNlZCB3aXRoIG5vbi1jb25maXJtYWJsZSB1cGRhdGUg cmVxdWVzdHMNCj4gKGUuZy4sIFBVVCkgYW5kIHNob3VsZCBoYXZlIG5vIGVmZmVjdCBpZiB1c2Vk IHdpdGggYSBDT04gIHJlcXVlc3Qu4oCdDQoNCkhtbSwgSSdtIG5vdCBzdXJlIHdlIHNob3VsZCBt YWtlIG9wdGlvbiBzZW1hbnRpY3MgZGVwZW5kIG9uIGEgZGV0YWlsDQooQ09OIHZzLiBOT04pIGF0 IHRoZSBtZXNzYWdlIGxheWVyLg0KDQoiVGhpcyBhcHBlYXJzIHRvIGJlIG1vcmUgdXNlZnVsIHdp dGggTk9OIiBpcyBzYWdlIGFkdmljZSwgYnV0IHRoZQ0KcmVxdWVzdC9yZXNwb25zZSBsYXllciBz aG91bGRuJ3QgaGF2ZSB0byByZWFjdCBkaWZmZXJlbnRseSBiYXNlZCBvbg0KbWVzc2FnZSBsYXll ciBwcm9jZWVkaW5ncy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCg0KPT09PT0tLS0tLT09PT09 LS0tLS09PT09PQpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1h aWwKbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gCmNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIApub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgCnJldmlldywgZGlzdHJpYnV0 aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZSAKaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZS1tYWlsIG1lc3NhZ2UgCmFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwgCnBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBh bmQgCmltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgCmFuZCBh bnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdQoKCg== --=_alternative 003743F365257DE2_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVza28sIENhcnN0ZW4sPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Tb3JyeSB0byByZXNwb25kIGxhdGUg b24gdGhpcy4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbmRl ZWQsIHJlcXVlc3QvcmVzcG9uc2UgbGF5ZXIgYW5kIG1lc3NhZ2luZw0KbGF5ZXIgZnVuY3Rpb25h bGl0aWVzIHNob3VsZCBiZSBzZXBhcmF0ZWQuIFdlIHNoYWxsIHJlbW92ZSB0aGUgY29uc3RyYWlu dA0KcmVnYXJkaW5nIGRlcGVuZGVuY3kgb24gTk9OL0NPTi4gQnV0IGFzIGEgbm90ZSB3ZSBzaGFs bCBrZWVwIHRoZSBkaXNjdXNzaW9ucw0KdGhhdCB3ZSBoYWQgaW4gdGhlIG1haWxpbmcgbGlzdCBy ZWdhcmRpbmcgd2h5IHVzaW5nIHRoaXMgb3B0aW9uIHdpdGggTk9ODQptYXkgYmUgYW4gb2J2aW91 cyBzYW5lIGFwcHJvYWNoLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkhvcGUsIHRoYXQgc2hvdWxkIGJlIGZpbmUuPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCkFi aGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50 aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5 IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4N CldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48L2E+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25z dWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYg ZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Q2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJv QHR6aS5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9 InNhbnMtc2VyaWYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtEaWprLCBFc2tvJnF1b3Q7DQombHQ7ZXNr by5kaWprQHBoaWxpcHMuY29tJmd0OywgQWJoaWphbiBCaGF0dGFjaGFyeXlhICZsdDthYmhpamFu LmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSZndDssDQomcXVvdDtjb3JlQGlldGYub3JnJnF1b3Q7ICZs dDtjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9m b250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wMS8yOC8yMDE1IDAxOjQ0IFBNPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlN1 YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJlOiBbY29yZV0gQ29BUA0KTm8tUmVzcG9uc2U6IHVzZSB3aXRoIE5P TiBvbmx5PzwvZm9udD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyDigJxwcmltYXJpbHkgaW50ZW5kZWQgdG8gYmUgdXNlZCB3aXRoIG5v bi1jb25maXJtYWJsZQ0KdXBkYXRlIHJlcXVlc3RzPGJyPg0KJmd0OyAoZS5nLiwgUFVUKSBhbmQg c2hvdWxkIGhhdmUgbm8gZWZmZWN0IGlmIHVzZWQgd2l0aCBhIENPTiAmbmJzcDtyZXF1ZXN0LuKA nTxicj4NCjxicj4NCkhtbSwgSSdtIG5vdCBzdXJlIHdlIHNob3VsZCBtYWtlIG9wdGlvbiBzZW1h bnRpY3MgZGVwZW5kIG9uIGEgZGV0YWlsPGJyPg0KKENPTiB2cy4gTk9OKSBhdCB0aGUgbWVzc2Fn ZSBsYXllci48YnI+DQo8YnI+DQomcXVvdDtUaGlzIGFwcGVhcnMgdG8gYmUgbW9yZSB1c2VmdWwg d2l0aCBOT04mcXVvdDsgaXMgc2FnZSBhZHZpY2UsIGJ1dA0KdGhlPGJyPg0KcmVxdWVzdC9yZXNw b25zZSBsYXllciBzaG91bGRuJ3QgaGF2ZSB0byByZWFjdCBkaWZmZXJlbnRseSBiYXNlZCBvbjxi cj4NCm1lc3NhZ2UgbGF5ZXIgcHJvY2VlZGluZ3MuPGJyPg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3Rl bjxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg08cD49PT09PS0tLS0tPT09PT0tLS0tLT09 PT09PGJyPgpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8 YnI+Cm1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDxicj4KY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgPGJyPgpub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgPGJyPgpyZXZp ZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPgppbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8YnI+CmFuZC9vciBhdHRhY2ht ZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgPGJyPgp5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxicj4KcGxlYXNlIG5vdGlmeSB1cyBi eSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8YnI+CmltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPGJyPgphbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFu ayB5b3U8L3A+Cgo8cD48L3A+ --=_alternative 003743F365257DE2_=-- From nobody Wed Feb 4 10:49:08 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4601A1B59 for ; Wed, 4 Feb 2015 10:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-tIw4nOXgjg for ; Wed, 4 Feb 2015 10:49:02 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0D21A0155 for ; Wed, 4 Feb 2015 10:49:01 -0800 (PST) Received: from DB3PR04MB155.eurprd04.prod.outlook.com (10.242.129.146) by DB3PR04MB027.eurprd04.prod.outlook.com (10.242.136.150) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 4 Feb 2015 18:48:38 +0000 Received: from DBXPR04CA0052.eurprd04.prod.outlook.com (10.141.8.180) by DB3PR04MB155.eurprd04.prod.outlook.com (10.242.129.146) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 4 Feb 2015 18:48:37 +0000 Received: from DB3FFO11FD011.protection.gbl (2a01:111:f400:7e04::131) by DBXPR04CA0052.outlook.office365.com (2a01:111:e400:9414::52) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Wed, 4 Feb 2015 18:48:37 +0000 Received: from mail.philips.com (206.191.242.68) by DB3FFO11FD011.mail.protection.outlook.com (10.47.216.167) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Wed, 4 Feb 2015 18:48:36 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.80]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0476.000; Wed, 4 Feb 2015 18:48:35 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya , Carsten Bormann Thread-Topic: [core] CoAP No-Response: use with NON only? Thread-Index: AdA6UznR9QlycZdtT8mVXERMSK4nswAfz+yAAWPaQIAAENGN8A== Date: Wed, 4 Feb 2015 18:48:35 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61839ABCFEF@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61839AA4DC9@AMSPRD9003MB066.MGDPHG.emi.philips.com> <54C89A75.3010607@tzi.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.223.203.154] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61839ABCFEFAMSPRD9003MB066_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; tcs.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(428002)(85714005)(377454003)(479174004)(54356999)(50986999)(6806004)(101416001)(16236675004)(84326002)(33656002)(19580405001)(19580395003)(76176999)(77156002)(19625305001)(19625215002)(46102003)(19300405004)(86362001)(62966003)(15975445007)(102836002)(2920100001)(2900100001)(2950100001)(19617315012)(104016003)(92566002)(105586002)(106466001)(512874002)(16601075003)(2656002)(87936001)(66066001)(55846006)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR04MB155; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB155; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR04MB155; X-Forefront-PRVS: 04772EA191 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB155; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2015 18:48:36.3532 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[206.191.242.68] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB155 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB027; X-OriginatorOrg: philips.com Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP No-Response: use with NON only? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 18:49:05 -0000 --_000_031DD135F9160444ABBE3B0C36CED61839ABCFEFAMSPRD9003MB066_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBzb3VuZHMgdG8gbWUgbGlrZSB0aGUgYmVzdCBhcHByb2FjaCEgQWdyZWVkLA0KDQpFc2tv DQoNCkZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hh cnl5YUB0Y3MuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNCwgMjAxNSAxMTowNA0K VG86IENhcnN0ZW4gQm9ybWFubjsgRGlqaywgRXNrbw0KQ2M6IGNvcmVAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbY29yZV0gQ29BUCBOby1SZXNwb25zZTogdXNlIHdpdGggTk9OIG9ubHk/DQoNCkhp IEVza28sIENhcnN0ZW4sDQpTb3JyeSB0byByZXNwb25kIGxhdGUgb24gdGhpcy4NCkluZGVlZCwg cmVxdWVzdC9yZXNwb25zZSBsYXllciBhbmQgbWVzc2FnaW5nIGxheWVyIGZ1bmN0aW9uYWxpdGll cyBzaG91bGQgYmUgc2VwYXJhdGVkLiBXZSBzaGFsbCByZW1vdmUgdGhlIGNvbnN0cmFpbnQgcmVn YXJkaW5nIGRlcGVuZGVuY3kgb24gTk9OL0NPTi4gQnV0IGFzIGEgbm90ZSB3ZSBzaGFsbCBrZWVw IHRoZSBkaXNjdXNzaW9ucyB0aGF0IHdlIGhhZCBpbiB0aGUgbWFpbGluZyBsaXN0IHJlZ2FyZGlu ZyB3aHkgdXNpbmcgdGhpcyBvcHRpb24gd2l0aCBOT04gbWF5IGJlIGFuIG9idmlvdXMgc2FuZSBh cHByb2FjaC4NCkhvcGUsIHRoYXQgc2hvdWxkIGJlIGZpbmUuDQoNClJlZ2FyZHMNCkFiaGlqYW4g QmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3ZhdGlv biBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQpNYWlsdG86 IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5 eWFAdGNzLmNvbT4NCldlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbTxodHRwOi8vd3d3LnRjcy5j b20vPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4cGVy aWVuY2UgY2VydGFpbnR5LiAgICAgICAgSVQgU2VydmljZXMNCiAgICAgICAgICAgICAgICAgICAg ICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRpbmcN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpGcm9t OiAgICAgICAgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9y Zz4+DQpUbzogICAgICAgICJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPG1haWx0 bzplc2tvLmRpamtAcGhpbGlwcy5jb20+PiwgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxhYmhpamFu LmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5j b20+PiwgImNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IiA8Y29yZUBpZXRmLm9y ZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+DQpEYXRlOiAgICAgICAgMDEvMjgvMjAxNSAwMTo0NCBQ TQ0KU3ViamVjdDogICAgICAgIFJlOiBbY29yZV0gQ29BUCBOby1SZXNwb25zZTogdXNlIHdpdGgg Tk9OIG9ubHk/DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KPiDigJxw cmltYXJpbHkgaW50ZW5kZWQgdG8gYmUgdXNlZCB3aXRoIG5vbi1jb25maXJtYWJsZSB1cGRhdGUg cmVxdWVzdHMNCj4gKGUuZy4sIFBVVCkgYW5kIHNob3VsZCBoYXZlIG5vIGVmZmVjdCBpZiB1c2Vk IHdpdGggYSBDT04gIHJlcXVlc3Qu4oCdDQoNCkhtbSwgSSdtIG5vdCBzdXJlIHdlIHNob3VsZCBt YWtlIG9wdGlvbiBzZW1hbnRpY3MgZGVwZW5kIG9uIGEgZGV0YWlsDQooQ09OIHZzLiBOT04pIGF0 IHRoZSBtZXNzYWdlIGxheWVyLg0KDQoiVGhpcyBhcHBlYXJzIHRvIGJlIG1vcmUgdXNlZnVsIHdp dGggTk9OIiBpcyBzYWdlIGFkdmljZSwgYnV0IHRoZQ0KcmVxdWVzdC9yZXNwb25zZSBsYXllciBz aG91bGRuJ3QgaGF2ZSB0byByZWFjdCBkaWZmZXJlbnRseSBiYXNlZCBvbg0KbWVzc2FnZSBsYXll ciBwcm9jZWVkaW5ncy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCj09PT09LS0tLS09PT09PS0t LS0tPT09PT0NCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFp bA0KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4NCmNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlDQpub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwNCnJldmlldywgZGlzdHJpYnV0 aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZS1tYWlsIG1lc3NhZ2UNCmFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYNCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwNCnBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBh bmQNCmltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UNCmFuZCBh bnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNv bmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRo ZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24g b2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3Qg dGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhl IG9yaWdpbmFsIG1lc3NhZ2UuDQo= --_000_031DD135F9160444ABBE3B0C36CED61839ABCFEFAMSPRD9003MB066_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlRoYXQgc291bmRzIHRvIG1lIGxpa2UgdGhlIGJlc3QgYXBwcm9hY2gh IEFncmVlZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXNrbzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgRmVicnVhcnkgMDQsIDIwMTUgMTE6MDQ8YnI+DQo8Yj5Ubzo8L2I+IENhcnN0ZW4gQm9ybWFu bjsgRGlqaywgRXNrbzxicj4NCjxiPkNjOjwvYj4gY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2NvcmVdIENvQVAgTm8tUmVzcG9uc2U6IHVzZSB3aXRoIE5PTiBvbmx5Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SGkgRXNrbywgQ2Fyc3Rlbiw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Tb3JyeSB0byByZXNwb25kIGxhdGUgb24gdGhpcy4NCjwvc3Bhbj48YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JbmRlZWQsIHJlcXVlc3QvcmVzcG9uc2UgbGF5ZXIgYW5kIG1lc3Nh Z2luZyBsYXllciBmdW5jdGlvbmFsaXRpZXMgc2hvdWxkIGJlIHNlcGFyYXRlZC4gV2Ugc2hhbGwg cmVtb3ZlIHRoZSBjb25zdHJhaW50IHJlZ2FyZGluZyBkZXBlbmRlbmN5IG9uIE5PTi9DT04uIEJ1 dCBhcyBhIG5vdGUgd2Ugc2hhbGwga2VlcCB0aGUgZGlzY3Vzc2lvbnMNCiB0aGF0IHdlIGhhZCBp biB0aGUgbWFpbGluZyBsaXN0IHJlZ2FyZGluZyB3aHkgdXNpbmcgdGhpcyBvcHRpb24gd2l0aCBO T04gbWF5IGJlIGFuIG9idmlvdXMgc2FuZSBhcHByb2FjaC4NCjwvc3Bhbj48YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ib3BlLCB0aGF0IHNob3VsZCBiZSBmaW5lLjxicj4NCjxicj4N ClJlZ2FyZHM8YnI+DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpBc3NvY2lhdGUgQ29uc3Vs dGFudDxicj4NClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0K VGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCk1haWx0bzogPGEgaHJlZj0ibWFpbHRvOmFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv bTwvYT48YnI+DQpXZWJzaXRlOiA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy50Y3MuY29tLyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL3d3dy50Y3MuY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkV4cGVyaWVuY2UgY2VydGFpbnR5LiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2aWNlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7QnVzaW5lc3MgU29sdXRpb25zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25z dWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+IDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNUY1RjVGIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYXJzdGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0 bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9yZzwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtEaWprLCBFc2tv JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tIj5lc2tvLmRp amtAcGhpbGlwcy5jb208L2E+Jmd0OywgQWJoaWphbiBCaGF0dGFjaGFyeXlhDQogJmx0OzxhIGhy ZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSI+YWJoaWphbi5iaGF0dGFj aGFyeXlhQHRjcy5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5v cmciPmNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRm Lm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjAxLzI4LzIwMTUgMDE6NDQgUE08L3Nw YW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVj dDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UmU6IFtjb3JlXSBDb0FQIE5vLVJlc3BvbnNlOiB1c2Ugd2l0aCBOT04gb25seT88L3Nw YW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIg bm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IOKAnHBy aW1hcmlseSBpbnRlbmRlZCB0byBiZSB1c2VkIHdpdGggbm9uLWNvbmZpcm1hYmxlIHVwZGF0ZSBy ZXF1ZXN0czwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyAoZS5nLiwgUFVUKSBh bmQgc2hvdWxkIGhhdmUgbm8gZWZmZWN0IGlmIHVzZWQgd2l0aCBhIENPTiAmbmJzcDtyZXF1ZXN0 LuKAnTwvdHQ+PGJyPg0KPGJyPg0KPHR0PkhtbSwgSSdtIG5vdCBzdXJlIHdlIHNob3VsZCBtYWtl IG9wdGlvbiBzZW1hbnRpY3MgZGVwZW5kIG9uIGEgZGV0YWlsPC90dD48YnI+DQo8dHQ+KENPTiB2 cy4gTk9OKSBhdCB0aGUgbWVzc2FnZSBsYXllci48L3R0Pjxicj4NCjxicj4NCjx0dD4mcXVvdDtU aGlzIGFwcGVhcnMgdG8gYmUgbW9yZSB1c2VmdWwgd2l0aCBOT04mcXVvdDsgaXMgc2FnZSBhZHZp Y2UsIGJ1dCB0aGU8L3R0Pjxicj4NCjx0dD5yZXF1ZXN0L3Jlc3BvbnNlIGxheWVyIHNob3VsZG4n dCBoYXZlIHRvIHJlYWN0IGRpZmZlcmVudGx5IGJhc2VkIG9uPC90dD48YnI+DQo8dHQ+bWVzc2Fn ZSBsYXllciBwcm9jZWVkaW5ncy48L3R0Pjxicj4NCjxicj4NCjx0dD5HcsO8w59lLCBDYXJzdGVu PC90dD48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD49PT09PS0tLS0tPT09 PT0tLS0tLT09PT09PGJyPg0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgZS1tYWlsPGJyPg0KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRh aW4gPGJyPg0KY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBh cmUgPGJyPg0Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1 c2UsIDxicj4NCnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRo ZSA8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8YnI+ DQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDxi cj4NCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgPGJyPg0K cGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8YnI+DQpp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDxicj4NCmFuZCBh bnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YnI+DQo8 aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxl Z2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkDQogdGhhdCBhbnkgdXNlLCBm b3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdl IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSBy ZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3Nh Z2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_031DD135F9160444ABBE3B0C36CED61839ABCFEFAMSPRD9003MB066_-- From nobody Thu Feb 5 05:23:23 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240E91A879A; Thu, 5 Feb 2015 05:23:07 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EomWfvpMzlN3; Thu, 5 Feb 2015 05:22:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399381A87AA; Thu, 5 Feb 2015 05:22:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t15DMijx020257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 13:22:45 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t15DMhjJ014187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 14:22:44 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 5 Feb 2015 14:22:43 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Thu, 5 Feb 2015 14:22:43 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available Thread-Index: AdA9Z1V9LrIizW9/SFC3DbYz1F9geAD3GWuA Date: Thu, 5 Feb 2015 13:22:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 39423 X-purgate-ID: 151667::1423142565-000067C4-BF5EA218/0/0 Archived-At: Cc: "i2rs@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "ops-ads@tools.ietf.org" , "app-ads@tools.ietf.org" , "core@ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: [core] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:23:07 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we hereby issue a WG Last Call for 3 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Please review and send your comments to the NETCONF WG mailing list by Febr= uary 26, 2015 EOB PT. The related draft-ietf-netconf-yang-library will follow with LC as soon as = the remaining two issues are solved (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). RESTCONF documents are planned to publish as standard track documents. As RESTCONF is a major protocol we expect a detailed and thorough review wi= thin NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs wil= l be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to rev= iew. Please state explicitly that you have read/reviewed and whether you support= the publication. Please indicate also if you plan to implement or have already implementatio= n experience with RESTCONF. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Saturday, January 31, 2015 4:05 PM To: netconf@ietf.org Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available All, 1 YANG patch and 9 Restconf issues have been solved and provided in the dra= fts below. These issues have been set to the status Review (https://github.com/netconf= -wg/restconf/issues). Please check and comment on the drafts below before we go to WGLC soon: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear NETCONF WG,

=

= we hereby issue a WG Last Call for 3 weeks for the drafts below:

=  

https://tools.ietf.org/html/draft-ietf-netconf-restconf-04

https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-= 03

=  

= Please review and send your comments to the NETC= ONF WG mailing list by February 26, 2015 EOB PT.

= The related draft-ietf-netconf-yang-library will follow with LC as soon as the remaining two issues are solved <= /span>

= (see http://tools.ietf.org/html/draft-ietf-netco= nf-yang-library).

=

= RESTCONF documents are planned to publish as standard track documents.

= As RESTCONF is a major protocol we expect a deta= iled and thorough review within NETCONF WG but also by the related WGs before p= ublishing.

= Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs will be informed as well as Core, I2rs, 6lo, and= 6tisch WGs are invited to review.

=

= Please state explicitly that you have read/revie= wed and whether you support the publication.

= Please indicate also if you plan to implement or have already implementation experience with RESTCONF.=

=  

= Thank you,

= Mehmet and Mahesh

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Saturday, January 31, = 2015 4:05 PM
To: netconf@ietf.org
Subject: [Netconf] Restconf-= 04 and YANG-Patch-03 drafts available

 

All,

 

1 YANG patch and 9 Restconf = issues have been solved and provided in the drafts below.

These issues have been set t= o the status Review (https://github.com/netconf-wg/restconf/issues).

 

Please check and comment on = the drafts below before we go to WGLC soon:

=  

= Regards,
Mehmet

=  

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_-- From nobody Thu Feb 5 14:31:53 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872FB1A6FEE for ; Thu, 5 Feb 2015 14:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 zKpBMyuxh6jC for ; Thu, 5 Feb 2015 14:31:40 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::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 0B5EC1A6F0E for ; Thu, 5 Feb 2015 14:31:39 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id w7so8909703qcr.10 for ; Thu, 05 Feb 2015 14:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XTvXya0NLLhL2fKZAAmpfT1g9PU5B1jlN+wVifsSOlA=; b=Ddyk48UuojqOaPDOo+4eJroHN+sAEPmyufmwLlrUG7ngBX4mKbOz8KwmXPj5k3yV/G Ir+zwSn3vht547X6qLVNDBnWQ6sYUJG7FtiucB3DAb/LyStZfPpnzvfAbmpfAmKJuQn8 XgORqhLkbP1MCIvGFX5kVL50vU9frTSCTgY8WQFSO90IKT/MLwnOxbSwTUe8NOqtNdi1 R8M3eGAFqNNhCvbaP8zP6CgmPdAoc7dn6ftPOr/Br+Ks2MWGxSD94R/p9N/N3+qVPEe9 r4xph0EKcdZqXYlj/6sG6yeBJxVBLB5IP8mFWh5diaU3QLo1nabxkTK8XqqysFLFoN1r YKFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=XTvXya0NLLhL2fKZAAmpfT1g9PU5B1jlN+wVifsSOlA=; b=GcIKFRH/4Duw1JzbLk8UM3LxZiwEdHvwP0gQ2yARC1wCZOb3k5Kf0lE8T2J1qY1sqR Q9ZAzppHRjm1o1fzLaXIrB9JBTigi4XWmvl29emTjP9taHI5N12FqmWHuDW6HPC2LcCj 8bvG6cSXhrnE7Ifmpexq29nJ8ubkkP1XLViWuY7/huTgmqwren3XAAq0w8ujPK+2F4hE BUKKonN2snIKviVa/t1qsLTE82USV3/4wAtq83cSMMp/G4W02OHyXVJwocEYWqxb4tzi BKJma2DvpDtaInM/A3BozHRMo3MkIRhL8PG2IL1xKvcMDDuCABm4JxHB1fvp4BBzNS0t deEg== X-Gm-Message-State: ALoCoQkMVfrJO3fd5qg95IdsJkowzpGeHHo4SBoIiatwmBezxssALy0CMzwdpAEEAAVamefYl/ws MIME-Version: 1.0 X-Received: by 10.229.18.9 with SMTP id u9mr987749qca.19.1423175499036; Thu, 05 Feb 2015 14:31:39 -0800 (PST) Received: by 10.96.68.74 with HTTP; Thu, 5 Feb 2015 14:31:38 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2015 09:31:38 +1100 Message-ID: From: Andrew Mcgregor To: Core , "core-chairs@tools.ietf.org" , Barry Leiba , Zach Shelby Content-Type: multipart/alternative; boundary=001a1133d79812ee62050e5edecf Archived-At: Subject: Re: [core] WGLC for draft-ietf-core-block-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 22:31:42 -0000 --001a1133d79812ee62050e5edecf Content-Type: text/plain; charset=UTF-8 Since there have been no objections, I believe we are good to proceed with this draft. On 5 January 2015 at 09:53, Andrew Mcgregor wrote: > Some text was unintentionally omitted from draft-ietf-core-block-15, this > last call is to confirm the inclusion of that text. Last call will close > Monday 19 Jan 2015. > > Diff is at http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-16 > > Current draft is at http://tools.ietf.org/html/draft-ietf-core-block-16 > > Thanks, > Andrew > > -- > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a1133d79812ee62050e5edecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since there have been no objections, I believe we are good= to proceed with this draft.

On 5 January 2015 at 09:53, Andrew Mcgregor <andrewmc= gr@google.com> wrote:
Some text was unintentionally omitted from draft-ietf-core-bloc= k-15, this last call is to confirm the inclusion of that text.=C2=A0 Last c= all will close Monday 19 Jan 2015.



Thanks,
Andrew

--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221



--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewm= cgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a1133d79812ee62050e5edecf-- From nobody Fri Feb 6 06:38:04 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71C1A1AD0 for ; Fri, 6 Feb 2015 06:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 f0emGjhXImpf for ; Fri, 6 Feb 2015 06:38:01 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8428D1A1B62 for ; Fri, 6 Feb 2015 06:37:23 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id c9so12025651qcz.6 for ; Fri, 06 Feb 2015 06:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+/5DJO8o3Ge+glDA9F0lq5zfuLba7hkVthj9pQmaZV4=; b=cN5nRvzCBLqYLeOUpcP+IdrqeNbgIEVpCsvhtPlAQPqytyHR5gbo51NUNlGcIoIhyl QkvKa5yBCG6jr+CMHTqZ1LJYr45VpFyyxBmRZ3kapPFb+3WNPtP1IiNIZfBZI4I2erKd 6iQ8XyoMg+95NNweZ0NM0VpUzqhCimOb1xrlHRa+vcc4nGF7jNH4V3aog8L8BXmyM+cf 1ay5EiKri5ECUhr6hTQ4z1qwCgYoDrwnQUWpQotgNLqg0Ab1JYd7AlpK4eGe9X/+KZAT TKXRy7P8MfleZFTeidx03NmCtg42/dM4S6k4ET24hzaWrWgpbuA9dKBBeknaLDmIOuge 9iPg== MIME-Version: 1.0 X-Received: by 10.140.19.78 with SMTP id 72mr8550425qgg.37.1423233442445; Fri, 06 Feb 2015 06:37:22 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.163 with HTTP; Fri, 6 Feb 2015 06:37:22 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2015 09:37:22 -0500 X-Google-Sender-Auth: 3P0Nv5S2vlhQ43WZ4rqjNnrOxzQ Message-ID: From: Barry Leiba To: Klaus Hartke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] What's the status of the "observe" doc after IESG Evaluation? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:38:02 -0000 Ping... Status, here? What about the comments I note below? Barry On Fri, Jan 2, 2015 at 11:53 AM, Barry Leiba wrote: >>>> Are there still updates pending? >>> >>> I have uploaded revision -16 which closes the last remaining issues. >> >> Excellent; thanks. Document shepherd, can I get confirmation that you >> think this version is ready to go? > > Even before I hear from the shepherd, I wonder about quite a few of > the IESG comments. For example: > > Adrian's comment asking for clarification in Section 3.1. > > Adrian's comment about the "MAY" in Section 3.3.1 (looks like it > shouldn't be a 2119 "MAY"). > > Adrian's comment about Section 3.5 (clarify "eventually", perhaps with > "after repeated failures to confirm", or some such). > > Kathleen's comment asking that you mention 7252 Section 9 as well as > 7252 Section 11 in the Security Considerations. > > Martin's comment asking for a forward reference to Section 4.5.1 in Section 1.4. > > Pete's and Richard's various comments. > > And so on..... > > Have you gone through these comments, addressed them, and evaluated > which ones should result in some minor document changes and which > shouldn't (and why)? > > Barry From nobody Fri Feb 6 07:46:57 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC521A1BAF for ; Fri, 6 Feb 2015 07:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 uSf7MoUD5dYy for ; Fri, 6 Feb 2015 07:46:44 -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 BC6601A1BAD for ; Fri, 6 Feb 2015 07:46:43 -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 t16FkdMS027094; Fri, 6 Feb 2015 16:46:40 +0100 (CET) Received: from alma.local (p5DCCC7CE.dip0.t-ipconnect.de [93.204.199.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kf1Fp2cCpz2Ppr; Fri, 6 Feb 2015 16:46:38 +0100 (CET) Message-ID: <54D4E1DD.4050406@tzi.org> Date: Fri, 06 Feb 2015 16:46:37 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba , Klaus Hartke References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] What's the status of the "observe" doc after IESG Evaluation? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:46:45 -0000 On 2015-02-06 15:37, Barry Leiba wrote: > Ping... > Status, here? What about the comments I note below? The shepherd (yours truly) is still up with matching up the detailed comment response. Real soon now... Grüße, Carsten From nobody Fri Feb 6 09:51:33 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581971A86E1 for ; Fri, 6 Feb 2015 09:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlzJ4ZbP6Z-6 for ; Fri, 6 Feb 2015 09:51:30 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 A70121A8547 for ; Fri, 6 Feb 2015 09:51:29 -0800 (PST) Received: by labpv20 with SMTP id pv20so2687941lab.7 for ; Fri, 06 Feb 2015 09:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=6RygrD9sNLMbFgJOuonIka/jlbKOcnoPtp+RHnOokNI=; b=PxOcN/O5meI3W4PVMK61YHKJGmkXK9CCP++xn24UPWlYb/Iufhi9+N9D4xL1OvIGYw 9z/vkC2DNQAth0KpioLZUDDJZwo/uhjTnY4+tzjpVVjtOypZfbt0aMblEL+F4losWfwR f6+7bddBxL86uE/wZhl4covDB3plx9U4aR9ss7ZmYcUPHY76fDU+Vw6+LC/f0DHZ5u/2 XfaOYPs3vcE9JA9j1HlkqQtNAbzVoSft+nCA4ovdaA/dtvKeATnkzvzSQx/jJ2Ek3OFz vx4pecDftxRs7q/0TvsTQohkXyxw9Uh1bbhqmuubjjhnxIkF+vONsXq7mKgH6+P2FUU4 lfyw== X-Received: by 10.112.255.104 with SMTP id ap8mr4083413lbd.105.1423245088181; Fri, 06 Feb 2015 09:51:28 -0800 (PST) MIME-Version: 1.0 References: <54D4E1DD.4050406@tzi.org> From: =?UTF-8?B?U3RlZsOhbiBBdGxpIErDs25zc29u?= Date: Fri, 06 Feb 2015 17:51:27 +0000 Message-ID: To: Carsten Bormann , Barry Leiba , Klaus Hartke Content-Type: multipart/alternative; boundary=001a11348de0e8d3fc050e6f1174 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] What's the status of the "observe" doc after IESG Evaluation? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:51:32 -0000 --001a11348de0e8d3fc050e6f1174 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Everything seems ok .let's get it done On Fri, 6 Feb 2015 15:46 Carsten Bormann wrote: > On 2015-02-06 15:37, Barry Leiba wrote: > > Ping... > > Status, here? What about the comments I note below? > > The shepherd (yours truly) is still up with matching up the detailed > comment response. Real soon now... > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11348de0e8d3fc050e6f1174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Everything seems ok .let's get it done


On Fri, 6 Feb 2015 15:46=C2=A0Carsten Borman= n <cabo@tzi.org> wrote:
On 2015-02-06 15:37, Barry Leiba wrote:
> Ping...
> Status, here?=C2=A0 What about the comments I note below?

The shepherd (yours truly) is still up with matching up the detailed
comment response.=C2=A0 Real soon now...

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


_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--001a11348de0e8d3fc050e6f1174-- From nobody Fri Feb 6 11:37:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7961A7002 for ; Fri, 6 Feb 2015 11:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 VqqBC0Yzy3Kc for ; Fri, 6 Feb 2015 11:37:08 -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 0B5CB1A1A40 for ; Fri, 6 Feb 2015 11:37:07 -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 t16Jb30x016225; Fri, 6 Feb 2015 20:37:03 +0100 (CET) Received: from alma.local (p5DCCC7CE.dip0.t-ipconnect.de [93.204.199.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kf6Mg11tZz2P4k; Fri, 6 Feb 2015 20:37:03 +0100 (CET) Message-ID: <54D517DE.2050209@tzi.org> Date: Fri, 06 Feb 2015 20:37:02 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?U3RlZsOhbiBBdGxpIErDs25zc29u?= , Barry Leiba , Klaus Hartke References: <54D4E1DD.4050406@tzi.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] What's the status of the "observe" doc after IESG Evaluation? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 19:37:09 -0000 On 2015-02-06 18:51, Stefán Atli Jónsson wrote: > Everything seems ok .let's get it done Absolutely. This is about crossing a few more t's and dotting the i's, not about technical changes. Grüße, Carsten From nobody Fri Feb 6 18:42:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75AB1A1A38 for ; Fri, 6 Feb 2015 18:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDOJEk-yM1iS for ; Fri, 6 Feb 2015 18:41:58 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFBF1A00EC for ; Fri, 6 Feb 2015 18:41:55 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 7 Feb 2015 03:41:47 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0195.001; Sat, 7 Feb 2015 03:41:53 +0100 From: "Kovatsch Matthias" To: core WG Thread-Topic: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt Thread-Index: AQHQNXj8ZomUxxc+k0yxm9VzJ4k0Cpzkf/eA Date: Sat, 7 Feb 2015 02:41:52 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B53543FDEF@MBX110.d.ethz.ch> References: In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.171.155] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B53543FDEFMBX110dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 02:42:05 -0000 --_000_55877B3AFB359744BA0F2140E36F52B53543FDEFMBX110dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Abhijan, dear group Here is my review of the No-Response draft. In general, I can see a benefit= in the new option, but the draft still needs work: First, the benefits and use cases of No-Response need to be stated earlier = and clearer. For this, Section 1.1 should be moved to Section 2 and become = a part of the option definition. Both Section 3 and 5 provide examples for = the usage, but fail to clearly state the necessity of this new option. The = main point here should be why Observe does not work for the intended use ca= ses. The argument I can see here is a data collection endpoint that is unab= le to know all its data sources or has more sources than he can handle with= its available (computing) resources. Here the classic model of POSTing cli= ents is better suited than observing resources, where the collection servic= e (CoAP client) must manage observe relationships to all origin servers. The text on No-Response and Observe "combined together" (4.4 / 5.2) is very= confusing. There is in fact no combination. REST is a layered architecture= and one layer does not care how the next layer gets its data. Hence, it sh= ould be out of scope for the draft how a server receiving POST requests can= provide the data to another clients (using Observe on changing resources i= s pretty straight forward). The concept of transient resources and POST updating though resource creati= on (5.1.2.2) is quite weird and should also be out of scope. Using POST whi= le encoding the data in the Uri-Query is a bad practice. It is also not cle= ar to me, which resource is observed by the clients of the next layer. CoAP= -MQ has a cleaner approach here and is probably the better place to describ= e this concept (if my assumption is correct that the transient resources in= the No-Response draft should achieve the same thing). The described suppression of response for multicast in Section 3.2 is alrea= dy discussed in RFC 7390 (group-comm). I would rather like to see a clear d= efinition how the No-Response option can make the suppression for group com= munication explicit. Disabling the suppression by setting the bits in the o= ption bitmap for the code classes to receive could help debugging applicati= ons and networks. Since the option is elective, servers do not need to comp= ly when this would cause too much energy drain. I think it is a bad idea to mingle the concept of the infamous Patience opt= ion into the draft (4.2). I am also very confused by the reference to the L= eisure for unicast. Discussing congestion (4.3) must be more prominent in the draft. The requir= ement to "strategically interweave requests without No-Response" needs to b= e a MUST. The exact rule should be discussed by the working group (maybe in= particular the CoCoA authors). The messaging and request-response sub-layers should be kept separated. Hen= ce, the behavior must be the same for NON and CON messages. Still there nee= ds to be a discussion with message type makes sense in the targeted use cas= es. Also think about the TCP binding of CoAP there. As a general remark, the draft needs to become normative by replacing the m= any SHOULDs and soft wording with clear specifications. Editorial comments: I saw heavy use of the word "typical," even when it did not quite fit. Calling a CoAP endpoint "sensor-gateway" (3.1) can be very confusing. Best regards Matthias From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] Sent: Wednesday, 21 January 2015 13:52 To: Kovatsch Matthias Cc: cabo@tzi.org Subject: Fw: [core] Fw: New Version Notification for draft-tcs-coap-no-resp= onse-option-08.txt Importance: High Hi Matthias, Wish, things are fine at your end. Hope you remember the discussion I had w= ith you during last IETF meeting in Honolulu. I requested you for reviewing= my draft. If you have noticed, I have submitted a new version of the draft= (ver 8) (please refer to the mail below). Requesting your review comments on the same please. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 06:14 PM ---= -- From: Abhijan Bhattacharyya > To: core@ietf.org Date: 01/21/2015 06:05 PM Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-r= esponse-option-08.txt Sent by: "core" = > ________________________________ Hi all, A modified version of the No-Response draft has been submitted. This draft = has so far addressed all the technical comments received during the past me= etings and mailing list discussions. We would urge the CoRE members to do a= review of the draft and share their comments. Also, would request people t= o implement this option. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM ---= -- From: internet-drafts@ietf.org To: Soma Bandyopadhyay >, "Abhijan Bhattacharyya" >, "Arpan Pal" >, Arpan Pal >, "Soma Bandyopadhyay" >, Abhijan Bhattacharyya > Date: 01/21/2015 05:57 PM Subject: New Version Notification for draft-tcs-coap-no-response-opt= ion-08.txt ________________________________ A new version of I-D, draft-tcs-coap-no-response-option-08.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 08 Title: CoAP option for no server-response Document date: 2015-01-21 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-tcs-coap-no-respo= nse-option-08.txt Status: https://datatracker.ietf.org/doc/draft-tcs-coap-no-response= -option/ Htmlized: http://tools.ietf.org/html/draft-tcs-coap-no-response-optio= n-08 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-respon= se-option-08 Abstract: There can be typical M2M scenarios where responses from server against request from client might be considered redundant. This kind of open-loop exchange (with no reverse path from the server to the client) may be typically desired to minimize resource consumption in constrained systems while simultaneously updating a bulk of resources or updating a resource with a very high frequency. CoAP already provides a non-confirmable (NON) mode of exchange where the server end-point does not respond with ACK. However, the server end- point responds back with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option for CoAP called 'No-Response'. The option explicitly tells the server to suppress responses about the state of the resource against the request from the client. This option also provides granular control by allowing suppression of a typical class or a combination of classes of responses. This option may be effective for both unicast and multicast requests. This draft discusses few exemplary applications which might benefit from this option. 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 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you_____________________________________________= __ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_55877B3AFB359744BA0F2140E36F52B53543FDEFMBX110dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Abhijan,

dear group

 

Here is my review of the No-Response = draft. In general, I can see a benefit in the new option, but the draft sti= ll needs work:

 

First, the benefits and use cases of = No-Response need to be stated earlier and clearer. For this, Section 1.1 sh= ould be moved to Section 2 and become a part of the option definition. Both Section 3 and 5 provide examples for the usage= , but fail to clearly state the necessity of this new option. The main poin= t here should be why Observe does not work for the intended use cases. The = argument I can see here is a data collection endpoint that is unable to know all its data sources or has mor= e sources than he can handle with its available (computing) resources. Here= the classic model of POSTing clients is better suited than observing resou= rces, where the collection service (CoAP client) must manage observe relationships to all origin servers.

 

The text on No-Response and Observe &= #8220;combined together” (4.4 / 5.2) is very confusing. There is in f= act no combination. REST is a layered architecture and one layer does not care how the next layer gets its data. Hence, it should be = out of scope for the draft how a server receiving POST requests can provide= the data to another clients (using Observe on changing resources is pretty= straight forward).

 

The concept of transient resources an= d POST updating though resource creation (5.1.2.2) is quite weird and shoul= d also be out of scope. Using POST while encoding the data in the Uri-Query is a bad practice. It is also not clear to me, w= hich resource is observed by the clients of the next layer. CoAP-MQ has a c= leaner approach here and is probably the better place to describe this conc= ept (if my assumption is correct that the transient resources in the No-Response draft should achieve the s= ame thing).

 

The described suppression of response= for multicast in Section 3.2 is already discussed in RFC 7390 (group-comm)= . I would rather like to see a clear definition how the No-Response option can make the suppression for group communicatio= n explicit. Disabling the suppression by setting the bits in the option bit= map for the code classes to receive could help debugging applications and n= etworks. Since the option is elective, servers do not need to comply when this would cause too much energy drain.=

 

I think it is a bad idea to mingle th= e concept of the infamous Patience option into the draft (4.2). I am also v= ery confused by the reference to the Leisure for unicast.

 

Discussing congestion (4.3) must be m= ore prominent in the draft. The requirement to “strategically interwe= ave requests without No-Response” needs to be a MUST. The exact rule should be discussed by the working group (maybe in particul= ar the CoCoA authors).

 

The messaging and request-response su= b-layers should be kept separated. Hence, the behavior must be the same for= NON and CON messages. Still there needs to be a discussion with message type makes sense in the targeted use cases. Also= think about the TCP binding of CoAP there.

 

As a general remark, the draft needs = to become normative by replacing the many SHOULDs and soft wording with cle= ar specifications.

 

Editorial comments:=

I saw heavy use of the word “ty= pical,” even when it did not quite fit.

Calling a CoAP endpoint “sensor= -gateway” (3.1) can be very confusing.

 

 

Best regards

Matthias

 

 

From: Abhijan Bhattacharyya [mailto:= abhijan.bhattacharyya@tcs.com]
Sent: Wednesday, 21 January 2015 13:52
To: Kovatsch Matthias
Cc: cabo@tzi.org
Subject: Fw: [core] Fw: New Version Notification for draft-tcs-coap-= no-response-option-08.txt
Importance: High

 

Hi Matthias,
W= ish, things are fine at your end. Hope you remember the discussion I had wi= th you during last IETF meeting in Honolulu. I requested you for reviewing = my draft. If you have noticed, I have submitted a new version of the draft (ver 8) (please refer to the mail below).
R= equesting your review comments on the same please.
<= br>
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com=
____________________________________________
Experience certainty.        IT Services
                     = ;  Business Solutions
                     = ;  Consulting
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 0= 6:14 PM -----

From:        Abhijan Bhattacharyya <= ;abhijan.bhattacharyya@tcs= .com>
To:        core@ietf.org
Date:        01/21/2015 06:05 PM
Subject:        [core] Fw: New Version= Notification for draft-tcs-coap-no-response-option-08.txt
Sent by:        "core" <<= a href=3D"mailto:core-bounces@ietf.org">core-bounces@ietf.org>




H= i all,
A modified version of the No-Response draft has been submitted. This draft = has so far addressed all the technical comments received during the past me= etings and mailing list discussions. We would urge the CoRE members to do a= review of the draft and share their comments. Also, would request people to implement this option.
<= br> Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com=
____________________________________________
Experience certainty.        IT Services
                     = ; Business Solutions
                     = ; Consulting
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM ---= --

From:        internet-drafts@ietf.org
To:        Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, "Abh= ijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal" <arpan.pal@t= cs.com>, Arpan Pal <arpan.pa= l@tcs.com>, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, Abhijan Bhatta= charyya <abhijan.bhattacharyya= @tcs.com>
Date:        01/21/2015 05:57 PM
Subject:        New Version Notification for draft= -tcs-coap-no-response-option-08.txt





A new version of I-D, draft-tcs-coap-no-response-option-08.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to = the
IETF repository.

Name:                   &n= bsp;              draft-tcs-coap-no-resp= onse-option
Revision:                 08
Title:                   &= nbsp;              CoAP option for no se= rver-response
Document date:                 = 2015-01-21
Group:                   &= nbsp;              Individual Submission=
Pages:                   &= nbsp;              17
URL:            http://www.ietf.org/internet-drafts/d= raft-tcs-coap-no-response-option-08.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-respo= nse-option/
Htmlized:       http://tools.ietf.org/html/draft-tcs-coap-no-response-option-08
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-co= ap-no-response-option-08

Abstract:
 There can be typical M2M scenarios where responses from server
 against request from client might be considered redundant. This k= ind
 of open-loop exchange (with no reverse path from the server to th= e
 client) may be typically desired to minimize resource consumption= in
 constrained systems while simultaneously updating a bulk of<= br>  resources or updating a resource with a very high frequency. CoAP=
 already provides a non-confirmable (NON) mode of exchange where t= he
 server end-point does not respond with ACK. However, the server e= nd-
 point responds back with a status code indicating "the resul= t of the
 attempt to understand and satisfy the request".

 This draft introduces a header option for CoAP called 'No-Respons= e'.
 The option explicitly tells the server to suppress responses abou= t
 the state of the resource against the request from the client. Th= is
 option also provides granular control by allowing suppression of = a
 typical class or a combination of classes of responses. This opti= on
 may be effective for both unicast and multicast requests. This dr= aft
 discusses few exemplary applications which might benefit from thi= s
 option.

                    &= nbsp;                    =                     &nbs= p;                


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

The IETF Secretariat

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

--_000_55877B3AFB359744BA0F2140E36F52B53543FDEFMBX110dethzch_-- From nobody Sun Feb 8 17:43:15 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F7A1A700D for ; Sun, 8 Feb 2015 17:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JerUkx3BQmHT for ; Sun, 8 Feb 2015 17:41:29 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3661A6FEE for ; Sun, 8 Feb 2015 17:41:27 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 9 Feb 2015 02:41:24 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 02:41:25 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: Multiple Resource Observation Attributes in draft-ietf-core-interfaces Thread-Index: AdBECCeKzp3Xd2CWTdCFW50qPmdO7Q== Date: Mon, 9 Feb 2015 01:41:23 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B535440A30@MBX110.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.171.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] Multiple Resource Observation Attributes in draft-ietf-core-interfaces X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:41:32 -0000 Hi all draft-ietf-core-interfaces-02 does not define how to handle the lt and gt a= ttributes. There is currently a similar problem for OMA LWM2M. There are ba= sically two problems: Conjunction: Since they are defined in a query, I would expect AND. This on= ly allows for notifications within an interval, though. Hence, it should be= AND for (gt < lt) and OR for (lt < gt). Triggering: There should also be text on when exactly notifications are tri= ggered. In addition to values above/below the specified thresholds, there s= hould also be one notification after crossing the threshold. Otherwise the = application cannot decide if the value is still in the "alarm range" and ha= s not changed more than step or if the value is back to normal. Ciao Matthias PS: Thanks to Michael Koster, who provided this input! :) From nobody Sun Feb 8 19:32:45 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15DA1A8030 for ; Sun, 8 Feb 2015 19:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys5VvEx02AJ6 for ; Sun, 8 Feb 2015 19:32:42 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDBC1A1BAC for ; Sun, 8 Feb 2015 19:32:41 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id fb1so15799465pad.8 for ; Sun, 08 Feb 2015 19:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H5J7pgtdnZ2DfEX5tWKuBaPJMZ0X4lk7HWfxF7LUcSc=; b=kb5MvV5fBuQg1tpHe058Em5S+gLMYZGiTe8Zyzbhecewmy1OA3gqHY0lak2AtekslD pgPINaEv2SX3tSSsYPQOWry6HbNKnWnSOCv2JZt0efgV7eWc6DgTJPc1s4OGK+/HY+KR TFc4GMMo+030yf+AVdys0Wc4yJjmJMFD52fJl2ID7k/6C/DTye42tz99ezt768gMBa5o tQKurOW2SAKF2yd7Vj4hz5HDFYyFESLYdoW2Kkn0qldTC/drsao1SW/Mp2k60SMwNUhg kITcBIYAyhy2kxSFsOiXbhFjRZAGOsyfoRbYeIGKj1VT97t0xbowij46yTtqCS5oquIg ms7A== X-Received: by 10.70.125.232 with SMTP id mt8mr24897566pdb.152.1423452761246; Sun, 08 Feb 2015 19:32:41 -0800 (PST) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id kg2sm14650556pbc.72.2015.02.08.19.32.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Feb 2015 19:32:40 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Koster In-Reply-To: <55877B3AFB359744BA0F2140E36F52B535440A30@MBX110.d.ethz.ch> Date: Sun, 8 Feb 2015 19:32:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B535440A30@MBX110.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1878.2) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Multiple Resource Observation Attributes in draft-ietf-core-interfaces X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 03:32:44 -0000 Hi all, Thanks Matthias for bringing this up. I have been interpreting the =91&=92 character as simply a separator, = not implying a logical =91and=92 operation.=20 As for the triggering, I believe there should be a notification each = time either lt or gt is crossed, either direction. I interpret lt and gt = as defining 3 bands, the normal band, high alarm, and low alarm, with = notification any time the measurement crosses from one band into = another. This way the client application can track the signal state. = Additionally there might be more frequent notifications while the = measurement is in an alarm condition. Cheers, Michael On Feb 8, 2015, at 5:41 PM, Kovatsch Matthias = wrote: > Hi all >=20 > draft-ietf-core-interfaces-02 does not define how to handle the lt and = gt attributes. There is currently a similar problem for OMA LWM2M. There = are basically two problems: >=20 > Conjunction: Since they are defined in a query, I would expect AND. = This only allows for notifications within an interval, though. Hence, it = should be AND for (gt < lt) and OR for (lt < gt). >=20 > Triggering: There should also be text on when exactly notifications = are triggered. In addition to values above/below the specified = thresholds, there should also be one notification after crossing the = threshold. Otherwise the application cannot decide if the value is still = in the "alarm range" and has not changed more than step or if the value = is back to normal. >=20 > Ciao > Matthias >=20 > PS: Thanks to Michael Koster, who provided this input! :) >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Feb 11 09:08:15 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E41A89B4 for ; Wed, 11 Feb 2015 09:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUW2V5-g9h41 for ; Wed, 11 Feb 2015 09:08:10 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 094EB1A89A0 for ; Wed, 11 Feb 2015 09:08:09 -0800 (PST) Received: by labgd6 with SMTP id gd6so4726972lab.7 for ; Wed, 11 Feb 2015 09:08:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=w1aauZm29PwquQfh3a45quW9LYQYcDH8ERhTGS91Pjs=; b=aXHispQBQM5HhR8qRYAohLNhO9VPsaHGO6+feo1iY02UdlrjODy3WgBkctmKA5bv5X s3OXutdmheyfxnpGLjD6R2RZH4S1ysD4+9Gii/ibQb8kG6+tYrvY8sX7dZsstvK8MuGF e/I01B8HeErvYdqWXhg4E5Ao7jT798yXWjJjFkeTNBznqnJCWW+mglRE12FOvcjugJLM AbR93mcWBpQ09LPH+CxR/TWb7fYwHDPMlKUU6CXfhxJkHS3bnE/k5CpxNunk0E+6VwHt eO0mfYMxF+0bmKL/oysk+1qv7UVTSgQmEQNpxrI0ydxZPwxC/eAao5g+IVFokCGFaI+h 4uOA== X-Gm-Message-State: ALoCoQmHBugTCVzjL+RjVRg4lL4rP87FPsjUlaGPOqhzg1+hRwfSs/0b9Z2fQ3gRmhtoa88KDj13 MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr28494755lbb.37.1423674487943; Wed, 11 Feb 2015 09:08:07 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 09:08:07 -0800 (PST) Date: Wed, 11 Feb 2015 09:08:07 -0800 Message-ID: From: Andy Bierman To: Core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:08:12 -0000 Hi, One significant issue not addressed in the CoMI draft is the encoding of the 'enumeration' and 'bits' data types. Currently, the identifier names are encoded as a string. If the 'value' or 'position' numeric values were used instead, the binary encoding would be about 10X smaller for enums and 10X - 100X smaller for bits. Since CoMI will use its own YANG-to-CBOR mapping, this change would not impact the YANG RFC. Andy From nobody Wed Feb 11 09:14:02 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625011A89EB for ; Wed, 11 Feb 2015 09:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 FjARUe4MkErO for ; Wed, 11 Feb 2015 09:13:55 -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 BA9361A1A31 for ; Wed, 11 Feb 2015 09:13:54 -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 t1BHDpNN015488; Wed, 11 Feb 2015 18:13:52 +0100 (CET) Received: from alma.local (p5DCCC7CE.dip0.t-ipconnect.de [93.204.199.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kj6y76C8lz2P0V; Wed, 11 Feb 2015 18:13:51 +0100 (CET) Message-ID: <54DB8DCF.5070108@tzi.org> Date: Wed, 11 Feb 2015 18:13:51 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andy Bierman , Core References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:13:56 -0000 Hi Andy, > One significant issue not addressed in the CoMI draft is > the encoding of the 'enumeration' and 'bits' data types. > Currently, the identifier names are encoded as a string. What is the extension model here? I.e., how can we expect the set of enumeration values, or the set of bits, to evolve over time? Is the addition linear, or do we have to cope with cacti? Grüße, Carsten From nobody Wed Feb 11 09:16:36 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA82B1A1A66 for ; Wed, 11 Feb 2015 09:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJWQnA7w4Qp6 for ; Wed, 11 Feb 2015 09:16:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAF51A1A5E for ; Wed, 11 Feb 2015 09:16:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C0C1818AA; Wed, 11 Feb 2015 18:16:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id imTtVhHGUNGv; Wed, 11 Feb 2015 18:16:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Feb 2015 18:16:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23BFB20037; Wed, 11 Feb 2015 18:16:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WPW8vlvunrI6; Wed, 11 Feb 2015 18:08:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11E9220036; Wed, 11 Feb 2015 18:16:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2F16D31FAAB6; Wed, 11 Feb 2015 18:16:23 +0100 (CET) Date: Wed, 11 Feb 2015 18:16:23 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150211171623.GB89749@elstar.local> Mail-Followup-To: Andy Bierman , Core References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Core Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:16:33 -0000 On Wed, Feb 11, 2015 at 09:08:07AM -0800, Andy Bierman wrote: > Hi, > > One significant issue not addressed in the CoMI draft is > the encoding of the 'enumeration' and 'bits' data types. > Currently, the identifier names are encoded as a string. > > If the 'value' or 'position' numeric values were used instead, > the binary encoding would be about 10X smaller for enums > and 10X - 100X smaller for bits. > > Since CoMI will use its own YANG-to-CBOR mapping, > this change would not impact the YANG RFC. > Not sure everybody understands but in YANG 1.0, there is a defined numeric value for enums and bits. There is a proposal to change that in YANG 1.1 but the final call on this has not been made. The outcome of this decision may impact the CBOR encoding decision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 11 09:26:05 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720091A1A5A for ; Wed, 11 Feb 2015 09:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWQc6P3GC2Bz for ; Wed, 11 Feb 2015 09:25:51 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 E8F721A1A13 for ; Wed, 11 Feb 2015 09:25:30 -0800 (PST) Received: by labgm9 with SMTP id gm9so4838102lab.2 for ; Wed, 11 Feb 2015 09:25:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Hm/hCfaXnofZMAjCpIyJdASpPy6lxVXAaFpTyVZKUKg=; b=fbH5lI7K85BGNxNSjUIrgf/Ht5B9gdDwIfPLF56OzLTLXjoOkg/bfeXdLHVbVJqz6C CxoaLKo7jxnYnnsmdVAiBtwjTo/KC1a6swnPRlhO7orJ1fxoAFkzchEiPDkskhkuWd4c J9fcsh2VI8c1WPoxa1s/8gkjZiXm5fN5esfNrDecz8H08tJICkpaurwodrgs3RosZWU2 KbvBwYpyhBKvQbGKSWvJxhJsLjzGmJVQVb3uCONuqYzvA0a4SCqeuRPnrwYgqt+XeuOr rGU5ttSWqdoOUW1Dc4+9CV0KcG7E8DywSRvELD7iSHIWsnWzUMgOQbwkNerCsRWiCtAF 1BWg== X-Gm-Message-State: ALoCoQnBUX7+Ftf+RXtRMp5OVn9+Fop+U6k2/Nifsc1AdfQp4y8Se4erXQZ+C5Rsz3RDeXsTZrQe MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr3045569lac.38.1423675529488; Wed, 11 Feb 2015 09:25:29 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 09:25:29 -0800 (PST) In-Reply-To: <54DB8DCF.5070108@tzi.org> References: <54DB8DCF.5070108@tzi.org> Date: Wed, 11 Feb 2015 09:25:29 -0800 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:25:55 -0000 On Wed, Feb 11, 2015 at 9:13 AM, Carsten Bormann wrote: > Hi Andy, >> One significant issue not addressed in the CoMI draft is >> the encoding of the 'enumeration' and 'bits' data types. >> Currently, the identifier names are encoded as a string. > > What is the extension model here? > I.e., how can we expect the set of enumeration values, or the set of > bits, to evolve over time? Is the addition linear, or do we have to > cope with cacti? > YANG 1.0 has auto-numbering of enums and bits that do not explicitly define a number. Once a number has been assigned (auto or manual) it can never be changed. YANG 1.1 is considering the removal of this permanent numbering, which would not be good for CoMI. The enumeration or bits definitions have to be directly edited in a new revision of the module, which can only add previously unused values. They cannot be extended from another module. It is a data model designer decision whether to extend enum or bits vs. define a new typedef with a new name. I am not convinced that the former should even be allowed in YANG. > Gr=C3=BC=C3=9Fe, Carsten > Andy From nobody Wed Feb 11 09:30:27 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B5D1A1A32 for ; Wed, 11 Feb 2015 09:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 jKN8Wdy__9Sa for ; Wed, 11 Feb 2015 09:30:20 -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 296931A046D for ; Wed, 11 Feb 2015 09:30:15 -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 t1BHUDWi024425; Wed, 11 Feb 2015 18:30:13 +0100 (CET) Received: from alma.local (p5DCCC7CE.dip0.t-ipconnect.de [93.204.199.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kj7K126r7z2P2k; Wed, 11 Feb 2015 18:30:13 +0100 (CET) Message-ID: <54DB91A4.5040905@tzi.org> Date: Wed, 11 Feb 2015 18:30:12 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andy Bierman References: <54DB8DCF.5070108@tzi.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:30:25 -0000 > YANG 1.1 is considering the removal of this permanent numbering, > which would not be good for CoMI. Is there an issue tracker or some other document/message that explains the rationale for this proposal? Grüße, Carsten From nobody Wed Feb 11 10:01:48 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25C1A00FA for ; Wed, 11 Feb 2015 10:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX-Z5h4hEIwc for ; Wed, 11 Feb 2015 10:01:44 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 762121A1AC1 for ; Wed, 11 Feb 2015 10:01:04 -0800 (PST) Received: by labgm9 with SMTP id gm9so5046085lab.2 for ; Wed, 11 Feb 2015 10:01:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DVxMMJSO3IAeWkF0Gd79cEKly9LxO71/TpD03o0PsyQ=; b=c+ISK+HFf0kEuOcCss8Wv7HYoqunJUdOpDqyEsBLkM7GfPv/Chmi0RCoTwED/H7nTf Nglz8KQ6peVFSRolE+aKCIyaAGoUouUlK83u6gg0I6dNM3IYu5hHxrnB4JIRgpHCJJAh 76QJYn/+EoKuf4RP9YbpEXsLMbR7XiMAGRF6fWHCxUdqU5VYTHVU2iLKGOQqaQ0ptYDa //0Zd7ppYMyiAR0UU4yAqYfAhHMBcpHbviLJXHVnahiqxHzKNlQXlXfL1PfCv0x5R4kl bds1npnQc6H7c+UrSiFHTtdGm46FMM0VX/BMugBzfNKCrQ+tvBi7Nc998PrhYFwnC2ya P1XA== X-Gm-Message-State: ALoCoQm1WqtLq/FadUbBKegod+wNPM1akU+NviEXQ4WVm1z86Ibi8qLSn7bc1j+IyVtdmxlEVQYd MIME-Version: 1.0 X-Received: by 10.152.87.50 with SMTP id u18mr7445733laz.82.1423677662884; Wed, 11 Feb 2015 10:01:02 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 10:01:02 -0800 (PST) In-Reply-To: <54DB91A4.5040905@tzi.org> References: <54DB8DCF.5070108@tzi.org> <54DB91A4.5040905@tzi.org> Date: Wed, 11 Feb 2015 10:01:02 -0800 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Core Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 18:01:47 -0000 On Wed, Feb 11, 2015 at 9:30 AM, Carsten Bormann wrote: >> YANG 1.1 is considering the removal of this permanent numbering, >> which would not be good for CoMI. > > Is there an issue tracker or some other document/message that explains > the rationale for this proposal? > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-26 The rationale is that is more user-friendly to readers/writers of YANG modu= les to be able to insert new enums/bits in the middle of an auto-numbered list (causing it to renumber). Currently, a new value has to put at the end, or explicit (non-sequential) numbering added to existing nodes. > Gr=C3=BC=C3=9Fe, Carsten > Andy From nobody Wed Feb 11 15:01:12 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FA71A1BAC for ; Wed, 11 Feb 2015 15:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFAkxiQKZQWm for ; Wed, 11 Feb 2015 15:01:09 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E961B1A01D5 for ; Wed, 11 Feb 2015 15:01:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B561919D5; Thu, 12 Feb 2015 00:01:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T-hObxfqMZNP; Thu, 12 Feb 2015 00:00:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 Feb 2015 00:01:07 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EE0D20036; Thu, 12 Feb 2015 00:01:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PSC_O6ZUCe3o; Thu, 12 Feb 2015 00:01:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 151A72003C; Thu, 12 Feb 2015 00:01:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2F86531FDE2B; Thu, 12 Feb 2015 00:01:05 +0100 (CET) Date: Thu, 12 Feb 2015 00:01:05 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150211230105.GA97738@elstar.local> Mail-Followup-To: Andy Bierman , Carsten Bormann , Core References: <54DB8DCF.5070108@tzi.org> <54DB91A4.5040905@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Core Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 23:01:11 -0000 On Wed, Feb 11, 2015 at 10:01:02AM -0800, Andy Bierman wrote: > On Wed, Feb 11, 2015 at 9:30 AM, Carsten Bormann wrote: > >> YANG 1.1 is considering the removal of this permanent numbering, > >> which would not be good for CoMI. > > > > Is there an issue tracker or some other document/message that explains > > the rationale for this proposal? > > > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-26 > > > The rationale is that is more user-friendly to readers/writers of YANG modules > to be able to insert new enums/bits in the middle of an auto-numbered list > (causing it to renumber). > > Currently, a new value has to put at the end, or explicit (non-sequential) > numbering added to existing nodes. > I think the real concern is that the order in which enums are defined must never be changed. If someone inserts something new instead of appending or for some other reasons enum definitions are reordered, interoperability is lost. Since NETCONF and RESTCONF never use the number on the wire, the proposal was to get rid of the autonumbering feature. With a CBOR encoding, the assumption that these numbers are never used on the wire might change. Another option is to 'deprecate' auto-numbering and to force module writers to explicitly assign values since this is less brittle when it comes to module updated. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 11 23:03:20 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF211A90D6 for ; Wed, 11 Feb 2015 23:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 aIohRqs2KDxU for ; Wed, 11 Feb 2015 23:03:18 -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 03BC11A90D5 for ; Wed, 11 Feb 2015 23:03:17 -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 t1C73Fx8003842; Thu, 12 Feb 2015 08:03:15 +0100 (CET) Received: from alma.local (p5DCCC7CE.dip0.t-ipconnect.de [93.204.199.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kjTM65wk4z2PWX; Thu, 12 Feb 2015 08:03:14 +0100 (CET) Message-ID: <54DC5032.6030907@tzi.org> Date: Thu, 12 Feb 2015 08:03:14 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andy Bierman , Core References: <54DB8DCF.5070108@tzi.org> <54DB91A4.5040905@tzi.org> <20150211230105.GA97738@elstar.local> In-Reply-To: <20150211230105.GA97738@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 07:03:20 -0000 > With a CBOR encoding, the assumption that these numbers are > never used on the wire might change. Indeed. The functionality of YANG seems to fit our needs here very well. Having been there for half a decade, it should not be removed for convenience reasons now (and, conversely, it is no longer true that this functionality is just "for the convenience of implementers"). Of course, we have lots of experience demonstrating how maintaining a linear number space during the evolution of a protocol is a pain, so I feel with the proposers of Y25. If there is some possible innovation in the YANG format that might help with this, that should be pursued (I'm skeptical though whether a good solution will be found in time for Yang 1.1). Much of this could be automated in tools, by the way; having the number assignment look a bit less intrusive might help with acceptance of that automation. Another hack to ease the pain would be requiring to maintain the evolutionary path only for specifications that need to be efficient for constrained nodes. It may be hard to reliably keep apart the spaces, though. Grüße, Carsten From nobody Wed Feb 11 23:13:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3301A90FA for ; Wed, 11 Feb 2015 23:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YRLSxI6T_we for ; Wed, 11 Feb 2015 23:13:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747F51A90F9 for ; Wed, 11 Feb 2015 23:13:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A4E69172C; Thu, 12 Feb 2015 08:13:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UI6UP-E3wYdN; Thu, 12 Feb 2015 08:12:41 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 Feb 2015 08:13:00 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE5B020036; Thu, 12 Feb 2015 08:12:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XfB7oA7RxgzZ; Thu, 12 Feb 2015 08:12:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EDF320037; Thu, 12 Feb 2015 08:12:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6ABF03202749; Thu, 12 Feb 2015 08:12:58 +0100 (CET) Date: Thu, 12 Feb 2015 08:12:58 +0100 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20150212071258.GB9173@elstar.local> Mail-Followup-To: Carsten Bormann , Andy Bierman , Core References: <54DB8DCF.5070108@tzi.org> <54DB91A4.5040905@tzi.org> <20150211230105.GA97738@elstar.local> <54DC5032.6030907@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DC5032.6030907@tzi.org> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Core Subject: Re: [core] YANG encoding issue for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 07:13:05 -0000 On Thu, Feb 12, 2015 at 08:03:14AM +0100, Carsten Bormann wrote: > > With a CBOR encoding, the assumption that these numbers are > > never used on the wire might change. > > Indeed. The functionality of YANG seems to fit our needs here very > well. Having been there for half a decade, it should not be removed for > convenience reasons now (and, conversely, it is no longer true that this > functionality is just "for the convenience of implementers"). > > Of course, we have lots of experience demonstrating how maintaining a > linear number space during the evolution of a protocol is a pain, so I > feel with the proposers of Y25. If there is some possible innovation in > the YANG format that might help with this, that should be pursued (I'm > skeptical though whether a good solution will be found in time for Yang > 1.1). Much of this could be automated in tools, by the way; having the > number assignment look a bit less intrusive might help with acceptance > of that automation. I do not understand you comment about 'linear space'. YANG supports identities in case a centrally maintained set of enums does not work. The concern behind Y25 is that auto-numbering can lead to subtle errors while updating a YANG module. > Another hack to ease the pain would be requiring to maintain the > evolutionary path only for specifications that need to be efficient for > constrained nodes. It may be hard to reliably keep apart the spaces, > though. I think this is to be avoided. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 12 04:21:55 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB771A1B61 for ; Thu, 12 Feb 2015 04:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Snfpznb5hSZg for ; Thu, 12 Feb 2015 04:21:49 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C4D1A1A0F for ; Thu, 12 Feb 2015 04:21:48 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 12 Feb 2015 13:21:45 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 13:21:45 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , Olaf Bergmann Thread-Topic: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT) Thread-Index: AQHPvAMFzhJj6rUrq0yPxbk5WiCRf5wNQakAgAFZtwCAACndFoAACSoAgN809fA= Date: Thu, 12 Feb 2015 12:21:45 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B53544D52E@MBX110.d.ethz.ch> References: <20140819231205.18772.65775.idtracker@ietfa.amsl.com> <54214D90.5000500@cs.tcd.ie> <874mvy38aa.fsf@tzi.org> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 12:21:52 -0000 Dear all Sorry to open this up again, but I could not find a response to this or if = there actually was one: > > All notifications resulting from a GET request with an Observe Option M= UST be returned within the same epoch of the same connection as the request= . > I'm not a security expert, but I vaguely remember some attack that involv= ed > sending a request in one epoch and sending the response after > renegotiation in another epoch. That's why I put that sentence in. I migh= t > misremember this, though, in which case I would agree that re-establishin= g > the observation should not be necessary. >=20 > Klaus Is this confirmed? Because it would greatly simply things if notifications = would work after a DTLS session was resumed. (I understand that the epoch m= ust be increased on session resumption.) The issue came up now in the context of OMA LWM2M. Ciao Matthias From nobody Thu Feb 12 05:10:27 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129401A6EE1 for ; Thu, 12 Feb 2015 05:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 JxdrBstS99zS for ; Thu, 12 Feb 2015 05:10:01 -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 2416A1A1A96 for ; Thu, 12 Feb 2015 05:09:53 -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 t1CD9lOD029307; Thu, 12 Feb 2015 14:09:47 +0100 (CET) Received: from alma.local (eduroam-pool7-0844.wlan.uni-bremen.de [134.102.115.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kjdV33CZtz2P94; Thu, 12 Feb 2015 14:09:47 +0100 (CET) Message-ID: <54DCA61A.8060301@tzi.org> Date: Thu, 12 Feb 2015 14:09:46 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kovatsch Matthias , Klaus Hartke , Olaf Bergmann References: <20140819231205.18772.65775.idtracker@ietfa.amsl.com> <54214D90.5000500@cs.tcd.ie> <874mvy38aa.fsf@tzi.org> <55877B3AFB359744BA0F2140E36F52B53544D52E@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B53544D52E@MBX110.d.ethz.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:10:06 -0000 Note that Observe doesn't invent anything new here. RFC 7252 says (9.1.1): The following rules are added for matching an Acknowledgement message or Reset message to a Confirmable message, or a Reset message to a Non-confirmable message: The DTLS session MUST be the same, and the epoch MUST be the same. We may want to think through the whole concept of endpoints and session resumption in the context of the TLS 1.3 discussion about replacing resumption by PSK, as well as the discussion we have had about the reconnection resilience (or lack of) of CoAP over (TLS over) TCP. I think we are much better off if we make session continuation (at the CoAP level) more explicit, rather than just relying on the lower layers always doing exactly the right thing for us. So, for Observe, I think we can stay at where we are -- an observation relationship stays or dies with the pair of endpoints. We can then independently work on the concept of an endpoint pair. Grüße, Carsten From nobody Thu Feb 12 05:15:44 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E5B1A87D0 for ; Thu, 12 Feb 2015 05:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ffAwFHmPhGo for ; Thu, 12 Feb 2015 05:15:19 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2621A016A for ; Thu, 12 Feb 2015 05:15:18 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 12 Feb 2015 14:15:16 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 14:15:16 +0100 From: "Kovatsch Matthias" To: Carsten Bormann , Klaus Hartke , "Olaf Bergmann" Thread-Topic: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT) Thread-Index: AQHPvAMFzhJj6rUrq0yPxbk5WiCRf5wNQakAgAFZtwCAACndFoAACSoAgN809fD///4zAIAAEUVg Date: Thu, 12 Feb 2015 13:15:16 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B53544D785@MBX110.d.ethz.ch> References: <20140819231205.18772.65775.idtracker@ietfa.amsl.com> <54214D90.5000500@cs.tcd.ie> <874mvy38aa.fsf@tzi.org> <55877B3AFB359744BA0F2140E36F52B53544D52E@MBX110.d.ethz.ch> <54DCA61A.8060301@tzi.org> In-Reply-To: <54DCA61A.8060301@tzi.org> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.254] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:15:23 -0000 Okay, thanks. I think the main confusion here is "what is an endpoint?" whe= n DTLS with session _resumption_ and epochs is involved. I filly agree that= there must be a clean design here. Taking care of this during the adoption= of TLS 1.3 sounds very good. I will clarify this situation for the OMA LWM2M community. Ciao Matthias > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Donnerstag, 12. Februar 2015 14:10 > To: Kovatsch Matthias; Klaus Hartke; Olaf Bergmann > Cc: core@ietf.org WG > Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core- > observe-14: (with COMMENT) >=20 > Note that Observe doesn't invent anything new here. RFC 7252 says (9.1.1= ): >=20 > The following rules are added for matching an Acknowledgement message > or Reset message to a Confirmable message, or a Reset message to a > Non-confirmable message: The DTLS session MUST be the same, and the > epoch MUST be the same. >=20 > We may want to think through the whole concept of endpoints and session > resumption in the context of the TLS 1.3 discussion about replacing > resumption by PSK, as well as the discussion we have had about the > reconnection resilience (or lack of) of CoAP over (TLS over) TCP. I thin= k we > are much better off if we make session continuation (at the CoAP level) > more explicit, rather than just relying on the lower layers always doing > exactly the right thing for us. >=20 > So, for Observe, I think we can stay at where we are -- an observation > relationship stays or dies with the pair of endpoints. We can then > independently work on the concept of an endpoint pair. >=20 > Gr=FC=DFe, Carsten From nobody Fri Feb 13 12:40:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F11A9075; Thu, 12 Feb 2015 07:38:24 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whB-dWQN-1TR; Thu, 12 Feb 2015 07:38:21 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82241A88E9; Thu, 12 Feb 2015 07:37:31 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t1CFbTdk019201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Feb 2015 15:37:29 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t1CFbTpV021147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 16:37:29 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 12 Feb 2015 16:37:28 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 16:37:28 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available Thread-Index: AdA9Z1V9LrIizW9/SFC3DbYz1F9geAD3GWuAAWV41tA= Date: Thu, 12 Feb 2015 15:37:28 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819623B02DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 45628 X-purgate-ID: 151667::1423755449-00007286-6CE208FD/0/0 Archived-At: X-Mailman-Approved-At: Fri, 13 Feb 2015 12:40:01 -0800 Cc: "i2rs@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "ops-ads@tools.ietf.org" , "app-ads@tools.ietf.org" , "core@ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [core] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:38:24 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819623B02DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, this is a friendly reminder on the WGLC of the Restconf and YANG-Patch draf= ts. As RESTCONF is a major protocol we expect a detailed and thorough review wi= thin NETCONF WG but also by the related WGs before publishing. Please review and send your comments to the NETCONF WG mailing list by Febr= uary 26, 2015 EOB PT. Many Thanks! Cheers, Mehmet From: Ersue, Mehmet (NSN - DE/Munich) Sent: Thursday, February 05, 2015 2:23 PM To: netconf@ietf.org Cc: ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'int-ads@tools.ietf.org= '; 'app-ads@tools.ietf.org'; 'core@ietf.org'; 6tisch@ietf.org; '6lo@ietf.or= g'; 'i2rs@ietf.org' Subject: WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-net= conf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available Dear NETCONF WG, we hereby issue a WG Last Call for 3 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Please review and send your comments to the NETCONF WG mailing list by Febr= uary 26, 2015 EOB PT. The related draft-ietf-netconf-yang-library will follow with LC as soon as = the remaining two issues are solved (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). RESTCONF documents are planned to publish as standard track documents. As RESTCONF is a major protocol we expect a detailed and thorough review wi= thin NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs wil= l be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to rev= iew. Please state explicitly that you have read/reviewed and whether you support= the publication. Please indicate also if you plan to implement or have already implementatio= n experience with RESTCONF. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Saturday, January 31, 2015 4:05 PM To: netconf@ietf.org Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available All, 1 YANG patch and 9 Restconf issues have been solved and provided in the dra= fts below. These issues have been set to the status Review (https://github.com/netconf= -wg/restconf/issues). Please check and comment on the drafts below before we go to WGLC soon: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819623B02DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear All,

=  

= this is a friendly reminder on the WGLC of the Restconf and YANG-Patch drafts.

=  

= As RESTCONF is a major= protocol we expect a detailed and thorough review within NETCONF WG but also by the related WGs before publishing.=

=  

= Please review and send= your comments to the NETCONF WG mailing list by February 26, 2015 EOB PT.

=  

= Many Thanks!

=  

= Cheers,
Mehmet

=  

From: Ersue, Mehmet (NSN - DE/Munich)
Sent: Thursday, February 05,= 2015 2:23 PM
To: netconf@ietf.org
Cc: ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; 'int-ads@tools.ietf.org'; 'app-ads@tools.ietf.org';= 'core@ietf.org'; 6tisch@ietf.org; '6lo@ietf.org'; 'i2rs@ietf.org'
Subject: WG Last Call for dr= aft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: R= estconf-04 and YANG-Patch-03 drafts available

 

= Dear NETCONF WG,<= /o:p>

=  

= we hereby issue a WG L= ast Call for 3 weeks for the drafts below:

=  

https://tools.ietf.org/html/draft-ietf-netconf-restconf-04

https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-= 03

=  

= Please review and send= your comments to the NETCONF WG mailing list by February 26, 2015 EOB PT.

= The related draft-ietf= -netconf-yang-library will follow with LC as soon as the remaining two issues are solved

= (see http= ://tools.ietf.org/html/draft-ietf-netconf-yang-library).

=  

= RESTCONF documents are= planned to publish as standard track documents.

= As RESTCONF is a major= protocol we expect a detailed and thorough review within NETCONF WG but also by the related WGs before publishing.=

= Therefore the WGLC is = planned for 3 weeks and APP, INT and RTG area ADs will be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to review.

=  

= Please state explicitl= y that you have read/reviewed and whether you support the publication.=

= Please indicate also i= f you plan to implement or have already implementation experience with RESTCONF.

=  

= Thank you,<= /span>

= Mehmet and Mahesh=

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Saturday, January 31, = 2015 4:05 PM
To: netconf@ietf.org
Subject: [Netconf] Restconf-= 04 and YANG-Patch-03 drafts available

 

All,

 

1 YANG patch and 9 Restconf = issues have been solved and provided in the drafts below.

These issues have been set t= o the status Review (https://github.com/netconf-wg/restconf/issues).

 

Please check and comment on = the drafts below before we go to WGLC soon:

=  

= Regards,
Mehmet

=  

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819623B02DEMUMBX005nsnin_-- From nobody Fri Feb 20 02:58:29 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FD71A8866 for ; Fri, 20 Feb 2015 02:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTuem5kmMcwb for ; Fri, 20 Feb 2015 02:58:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAEA1A7D84 for ; Fri, 20 Feb 2015 02:58:25 -0800 (PST) Received: from localhost ([::1]:43548 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOlHt-0007nq-2n; Fri, 20 Feb 2015 02:58:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Fri, 20 Feb 2015 10:58:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/379 Message-ID: <060.9d2b4638ddf49356d3a65fd3929d2bdf@trac.tools.ietf.org> X-Trac-Ticket-ID: 379 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: [core] #379 (http-mapping): Section 6 and Fig 1 should appear earlier in document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 10:58:27 -0000 #379: Section 6 and Fig 1 should appear earlier in document Section 6 and Fig 1 should appear earlier in document - to provide a better reading experience. Current text jumps right into the more difficult topic of URI mapping. To be resolved in next version. -- -----------------------------------+----------------------------------- Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: editorial | Status: new Priority: major | Milestone: Component: http-mapping | Version: Severity: - | Keywords: -----------------------------------+----------------------------------- Ticket URL: core From nobody Fri Feb 20 04:23:12 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE771A036C for ; Fri, 20 Feb 2015 04:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-NB_P1jOuV6 for ; Fri, 20 Feb 2015 04:23:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423871A890E for ; Fri, 20 Feb 2015 04:15:52 -0800 (PST) Received: from localhost ([::1]:48531 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOmUp-0004a6-LF; Fri, 20 Feb 2015 04:15:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Fri, 20 Feb 2015 12:15:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/380 Message-ID: <060.0c7a2de2d87ddf402f345044e0c44657@trac.tools.ietf.org> X-Trac-Ticket-ID: 380 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: [core] #380 (http-mapping): Add IANA registration for "core.hc" Resource Type X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:23:10 -0000 #380: Add IANA registration for "core.hc" Resource Type Add IANA registration for "core.hc" Resource Type - in the 'Constrained RESTful Environments (CoRE) Parameters' registry; subregistry 'Resource Type (rt=) Link Target Attribute Values', procedure follows [RFC6690]. -- -----------------------------------+----------------------------------- Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: task | Status: new Priority: major | Milestone: Component: http-mapping | Version: Severity: - | Keywords: -----------------------------------+----------------------------------- Ticket URL: core From nobody Fri Feb 20 13:39:44 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2B1A015F for ; Fri, 20 Feb 2015 13:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEORiTxVpsZx for ; Fri, 20 Feb 2015 13:39:39 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F801A012D for ; Fri, 20 Feb 2015 13:39:39 -0800 (PST) Received: from AM2PR04MB0593.eurprd04.prod.outlook.com (25.160.31.155) by AM2PR04MB1028.eurprd04.prod.outlook.com (25.162.36.139) with Microsoft SMTP Server (TLS) id 15.1.93.16; Fri, 20 Feb 2015 21:36:14 +0000 Received: from DB4PR04CA0017.eurprd04.prod.outlook.com (25.160.41.27) by AM2PR04MB0593.eurprd04.prod.outlook.com (25.160.31.155) with Microsoft SMTP Server (TLS) id 15.1.93.16; Fri, 20 Feb 2015 21:36:10 +0000 Received: from AM1FFO11FD037.protection.gbl (2a01:111:f400:7e00::181) by DB4PR04CA0017.outlook.office365.com (2a01:111:e400:9852::27) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Fri, 20 Feb 2015 21:36:10 +0000 Received: from mail.philips.com (206.191.242.68) by AM1FFO11FD037.mail.protection.outlook.com (10.174.64.226) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Fri, 20 Feb 2015 21:36:08 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.132]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0478.000; Fri, 20 Feb 2015 21:35:46 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Registering a new CoAP content-format for 'coap-group+json' Thread-Index: AdBNVS8Gh/a/x+qpR1mBSVMMVhKbJw== Date: Fri, 20 Feb 2015 21:35:46 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61839ADDC87@AMSPRD9003MB066.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.143.215] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61839ADDC87AMSPRD9003MB066_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(428002)(189002)(199003)(55904004)(85714005)(374574003)(33656002)(6806004)(87936001)(50986999)(69596002)(2656002)(106466001)(81156004)(105586002)(2900100001)(2930100002)(97736003)(54356999)(46102003)(16236675004)(2920100001)(16297215004)(101416001)(92566002)(19580395003)(19625215002)(15975445007)(102836002)(229853001)(86362001)(55846006)(19617315012)(512954002)(107886001)(77156002)(68736005)(450100001)(104016003)(84326002)(62966003)(66066001)(19300405004)(110136001)(64706001)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR04MB0593; H:mail.philips.com; FPR:; SPF:None; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AM2PR04MB0593; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AM2PR04MB0593; X-Forefront-PRVS: 0493852DA9 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AM2PR04MB0593; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2015 21:36:08.1184 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[206.191.242.68] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0593 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AM2PR04MB1028; X-OriginatorOrg: philips.com Archived-At: Subject: [core] Registering a new CoAP content-format for 'coap-group+json' X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:39:42 -0000 --_000_031DD135F9160444ABBE3B0C36CED61839ADDC87AMSPRD9003MB066_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Just noticed that the 'coap-group+json' media type defined in RFC 7390 is r= egistered as an Internet media type but not yet as a CoAP content format. Any ideas how this could be requested? Looking at http://tools.ietf.org/html/rfc7252#section-12.3 I would opt for = the 256-9999 number space, which requires an IETF spec to be in place. Regards Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED61839ADDC87AMSPRD9003MB066_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Just noticed that the ‘coap-group+jsonR= 17; media type defined in RFC 7390 is registered as an Internet media type = but not yet as a CoAP content format.

Any ideas how this could be requested?

 

Looking at http://tools.ietf.org/html/rfc7252#section-12.3 I would opt for the 256= -9999 number space, which requires an IETF spec to be in place.<= /p>

 

Regards

Esko

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED61839ADDC87AMSPRD9003MB066_-- From nobody Sat Feb 21 06:21:26 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3F1A1A2E; Sat, 21 Feb 2015 06:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 EtlNkE2sZONs; Sat, 21 Feb 2015 06:21:19 -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 4805C1A7000; Sat, 21 Feb 2015 06:21:19 -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 t1LELFbN017140; Sat, 21 Feb 2015 15:21:15 +0100 (CET) Received: from alma.local (p5DC7E14D.dip0.t-ipconnect.de [93.199.225.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kqBfM082rz2QKR; Sat, 21 Feb 2015 15:21:14 +0100 (CET) Message-ID: <54E89471.9000106@tzi.org> Date: Sat, 21 Feb 2015 15:21:37 +0100 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, t2trg@irtf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF92, early draft version X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 14:21:22 -0000 A first draft version of the IETF92 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. There are no ROLL or DICE meetings in the agenda this time. Again, the Constrained Node/Network group meetings are nicely spread out over the week, with a peak on Wednesday. I also put in the weekend meeting of the proposed Thing-to-thing Research Group ; I hope to have details for this on Monday. All times are CDT (UTC-0500) (use https://datatracker.ietf.org/meeting/agenda-utc and press the button to get your local time in case you want to listen in from remote). Grüße, Carsten SATURDAY, March 21, 2015 1300-1800 Session I (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group SUNDAY, March 22, 2015 0900-1500 Session II (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group MONDAY, March 23, 2015 0900-1130 Morning Session I Venetian APP appsawg Applications Area Working Group WG - Combined with APPSAREA International INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I International INT dnssd Extensions for Scalable DNS Service Discovery WG Parisian TSV taps Transport Services WG 1520-1650 Afternoon Session II Parisian APP uta Using TLS in Applications WG Continental INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Far East RAI webpush Web-Based Push Notifications WG Gold TSV tsvarea Transport Area Open Meeting TUESDAY, March 24, 2015 0900-1130 Morning Session I International INT homenet Home Networking WG Parisian SEC tokbind Token Binding WG 1300-1500 Afternoon Session I Oak APP httpbis Hypertext Transfer Protocol WG Parisian SEC *** ace Authentication and Authorization for Constrained Environments WG 1520-1720 Afternoon Session II International INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Oak OPS anima Autonomic Networking Integrated Model and Approach WG Parisian TSV tsvwg Transport Area Working Group WG 1730-1830 Afternoon Session III Royal SEC jose Javascript Object Signing and Encryption WG WEDNESDAY, March 25, 2015 0900-1130 Morning Session I International TSV spud Session Protocol for User Datagrams BOF 1300-1500 Afternoon Session I International OPS v6ops IPv6 Operations WG Venetian RTG bier Bit Indexed Explicit Replication WG Royal SEC oauth Web Authorization Protocol WG 1520-1620 Afternoon Session II Oak INT *** lwig Light-Weight Implementation Guidance WG Venetian SEC acme Automated Certificate Management Environment BOF THURSDAY, March 26, 2015 0900-1130 Morning Session I Continental INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Gold OPS v6ops IPv6 Operations WG Oak SEC tls Transport Layer Security WG Venetian TSV rmcat RTP Media Congestion Avoidance Techniques WG 1300-1500 Afternoon Session I International SEC saag Security Area Open Meeting Parisian TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Oak APP *** core Constrained RESTful Environments WG Gold RTG rtgarea Routing Area Open Meeting Parisian TSV tcpinc TCP Increased Security WG 1740-1840 Afternoon Session III Venetian INT intarea Internet Area Working Group WG Continental SEC httpauth Hypertext Transfer Protocol Authentication WG FRIDAY, March 27, 2015 0900-1130 Morning Session I Far East APP *** core Constrained RESTful Environments WG 1150-1320 Afternoon Session I Parisian OPS anima Autonomic Networking Integrated Model and Approach WG Venetian TSV tsvarea Transport Area Open Meeting From nobody Sat Feb 21 14:55:52 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE45F1A0104 for ; Sat, 21 Feb 2015 14:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6wFEG5Kn5Ld for ; Sat, 21 Feb 2015 14:55:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA851A00F9 for ; Sat, 21 Feb 2015 14:55:49 -0800 (PST) Received: from localhost ([::1]:34466 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YPIxd-000361-He; Sat, 21 Feb 2015 14:55:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Sat, 21 Feb 2015 22:55:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/376#comment:1 Message-ID: <075.97d688d691a267c00f245ffa68b735a5@trac.tools.ietf.org> References: <060.d5f29140d8b885894f235764ef20f65f@trac.tools.ietf.org> X-Trac-Ticket-ID: 376 In-Reply-To: <060.d5f29140d8b885894f235764ef20f65f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-http-mapping@ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #376 (http-mapping): CoAP 4.05 response can't be translated to HTTP 405 by HC proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 22:55:50 -0000 #376: CoAP 4.05 response can't be translated to HTTP 405 by HC proxy Comment (by esko.dijk@philips.com): Upon closer look, it is possible to map CoAP 4.05 to HTTP 405. The HC proxy must add the required 'Allow' header field with simply an empty field value. Proposed text is: HTTP code 405 (Method Not Allowed) MUST include an "Allow" response-header field (Section 7.4.1 of [RFC7231]). However, a CoAP response does not include information which methods are allowed on the resource. Therefore, if the proxy does not have further information about which methods are allowed on the resource it SHOULD include an empty field value in the Allow header field. The intended interpretation of an empty Allow in this case is "resource temporarily allows no methods" which complies fully to [RFC7231]. Due to the word "temporarily" the HTTP client is free to retry the request at any later time using another method. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: http- | Resolution: mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Feb 24 06:27:30 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49791A1BAC for ; Tue, 24 Feb 2015 06:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZsG-n7Ydh9E for ; Tue, 24 Feb 2015 06:27:27 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3481A1B89 for ; Tue, 24 Feb 2015 06:27:27 -0800 (PST) Received: by wggx12 with SMTP id x12so5619525wgg.6 for ; Tue, 24 Feb 2015 06:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=528td+aRLEo2Tt/XGUNFrK7fvXiHELAhHM/IHcqfGH8=; b=a+OQUDC389qTUf3D0NJyAfxWlTnpF1xzp9GLRrhXXEErfyT3oCGn3W5O9hJe5nzISa p8Ehg7mwzrbXdAm6WNDAWF+/4DLIS3fEMlEf+86GGm2Z6UCL9ZhHx0/EEm/gOlsTzHlS c7vaeQGtOW/dN5/d6SYcrqnmJHDZDZR1qbb5JNT9xVfNU0q5eYKxh3FOYIc2ERjZibEu T5p9RF1Eim+DvQ84j60IVtI5xP5HWhJXKO/bJ9bzCW825BXJxu/Xb/S6FsE3IRig/Z7+ nP5MfLbWE3XaZZWtxXmNUrT0pdxwCqldASW8NiD7R9tHcMyTmfCa4Dw5+DR6Raqjxnuz lZeQ== MIME-Version: 1.0 X-Received: by 10.180.89.173 with SMTP id bp13mr30769491wib.88.1424788046176; Tue, 24 Feb 2015 06:27:26 -0800 (PST) Received: by 10.28.10.3 with HTTP; Tue, 24 Feb 2015 06:27:26 -0800 (PST) Date: Tue, 24 Feb 2015 15:27:26 +0100 Message-ID: From: Maciej Wasilak To: core WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [core] Checksum for firmware updates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:27:28 -0000 Dear all, we are currently working on OTA firmware update that uses CoAP PUT/POST request with blockwise support. Part of the problem is to implement checksums for firmware image. There are several solutions to send checksum with CoAP: 1) Inside payload as part of the firmware package 2) Together with payload as a CoAP option (existing or new) 3) As a separate transaction Solution 1 should be fine for firmware, but might not be acceptable for other payloads, like human-readable config files etc. Solution 2 is very comfortable for embedded systems, but it might lead to unwanted overhead, as options are repeated in every block Solution 3 is the most complicated I would like to ask if anyone implemented such checksums, and what are your thoughts. Best Regards Maciej Wasilak From nobody Tue Feb 24 06:48:26 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6C1A1BB3 for ; Tue, 24 Feb 2015 06:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.971 X-Spam-Level: X-Spam-Status: No, score=0.971 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35] autolearn=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 r8XIil8xaR_z for ; Tue, 24 Feb 2015 06:48:18 -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 E72A21A06E9 for ; Tue, 24 Feb 2015 06:48:17 -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 t1OEmE6A006611 for ; Tue, 24 Feb 2015 15:48:14 +0100 (CET) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ks3660qH0z2PGX for ; Tue, 24 Feb 2015 15:48:14 +0100 (CET) Received: by mail-vc0-f169.google.com with SMTP id kv19so10062962vcb.0 for ; Tue, 24 Feb 2015 06:48:12 -0800 (PST) X-Received: by 10.52.145.52 with SMTP id sr20mr6733352vdb.53.1424789292552; Tue, 24 Feb 2015 06:48:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.34.69 with HTTP; Tue, 24 Feb 2015 06:47:32 -0800 (PST) In-Reply-To: References: From: Klaus Hartke Date: Tue, 24 Feb 2015 15:47:32 +0100 Message-ID: To: Maciej Wasilak Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: core WG Subject: Re: [core] Checksum for firmware updates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:48:24 -0000 Hi Maciej, instead of POSTing the firmware image itself to the node, I would POST a link to the image along with the checksum. The node then can GET the image at its own pace and compare the checksum. The advantage of this is that caches along the path can improve efficiency if more than one node needs the firmware update. Klaus On 24 February 2015 at 15:27, Maciej Wasilak wrote: > Dear all, > > we are currently working on OTA firmware update that uses CoAP > PUT/POST request with blockwise support. Part of the problem is to > implement checksums for firmware image. There are several solutions to > send checksum with CoAP: > 1) Inside payload as part of the firmware package > 2) Together with payload as a CoAP option (existing or new) > 3) As a separate transaction > > Solution 1 should be fine for firmware, but might not be acceptable > for other payloads, like human-readable config files etc. > Solution 2 is very comfortable for embedded systems, but it might lead > to unwanted overhead, as options are repeated in every block > Solution 3 is the most complicated > > I would like to ask if anyone implemented such checksums, and what are > your thoughts. > > Best Regards > Maciej Wasilak From nobody Tue Feb 24 09:46:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287DC1A1BCD for ; Tue, 24 Feb 2015 09:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=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 y69K59TRdFSP for ; Tue, 24 Feb 2015 09:46:02 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA751A1A38 for ; Tue, 24 Feb 2015 09:46:01 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8210143496; Tue, 24 Feb 2015 18:45:59 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9523955; Tue, 24 Feb 2015 18:45:58 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6425129; Tue, 24 Feb 2015 18:45:58 +0100 (CET) Received: (nullmailer pid 13287 invoked by uid 1000); Tue, 24 Feb 2015 17:45:57 -0000 Date: Tue, 24 Feb 2015 18:45:57 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Julien Vermillard Message-ID: <20150224174557.GM26062@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8c07nsHwQobhlezh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] SenML and delta encoding for samples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:46:04 -0000 --8c07nsHwQobhlezh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Julien, I am working with similar data and have not come up with a good solution yet. On Mon, Feb 02, 2015 at 07:45:39PM +0000, Julien Vermillard wrote: > {"e":[ > { "n": "sensorA", "dv":20 }, > { "n": "sensorB", "t": -5, "dv": 0.2 }, > { "n": "sensorB", "t": -4, "dv": 0.30 }, > { "n": "sensorA", "t": -3, "dv": -10.14 }, > { "n": "sensorB", "t": -2, "dv": 0.5 }, > { "n": "sensorA", "t": -1, "dv": 20.6 }, > { "n": "sensorB", "t": 0, "dv": 0.7 }], > "bn": "urn:dev:mac:0024befffe804f/", > "bt": 1276020076, > "ver": 1, > "bv" : { "sensorA" : 1000, > "sensorB": 250} } Such a scheme would reduce the size of my transmissions as well; my example 271k uncompressed file (no timestamps) goes down to 248k with the established bt mechanism, to 217k with dt (see below), to 210k with dt and dv, to 188k when absence of dv implies dv=3D0 (samples arrive irregularly, so the presence of a record does matter in my application), and down to 130k when I compress names to digits. For CBOR, I'm getting 207k / 207k / 212k / 217k / 178k / 124k, but the numbers show that the implementation I used for testing (the Python version from [1]) does not apply number compression. The number compression part is quite relevant, actually, because numerics matter here; a delta compression that produces small numbers in JSON might produce even bigger representations in CBOR ("0.1" vs a 64bit float with tag), so much care would have to be taken when doing those calculations. Unless one wants to deal with lossy compression at transmission time (which would be neigh impossible to disambiguate for duplicates or similar afterwards), that means that the numeric values have to be designed for compressibility beforehand; once a number like 0.1d shows up there, it will always compress badly with those schemes. If the dv scheme does work out to good savings using appropriate number representations, it should be considered for t as well, as the savings of the time compression decrease when a SenML file spans several weeks. Storing the time in a "dt" field (which would in your example always have the value of 1) would be trivial then. > By the way putting "e" at the end of the document would help streaming and > reduce memory consumption, I wonder why all the samples are this way in t= he > RFC, it could be misleading. The CBOR RFC does allow "CBOR-based protocol [to] prescribe a specific order of serialization", I'm not sure about JSON. I don't see the benefit of a "bv" here; the delta compression could always start from zero and have its initial value in the first entry of e. Same goes for bt if the proposed dt is used. What's left in common use is bn -- somehow dealing with names would give the best results with your and my data sets. A solution might look like that: {"n": {0: "sensorA", 1: "sensorB"}, "e": [{"n":0, dv:20}, {"n":1, "t":-5, "dv": 0.2}]} Would that still be in the spirit of SenML? Best regards Christian [1] https://code.google.com/p/cbor/ --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --8c07nsHwQobhlezh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU7LjPAAoJEDmNERLTpL3hRfMP+gNFO2Vc0lmeeKpr8uW10lU5 nf4m80J+pstQH9g+rlKkbM4rIAwIodGe5qDprISb8pkRm91CRCV4Y8Pzs2xEM9G8 3Ekx4b7bjnj52j8fpE8Yq6Gd6KiEUmnlza4JrgEchGCOBsx1Fp07egPFKNDuFUs9 qoqqy0yskVPu0/3R+3lA1EV674rD5KK4z4bWfPPaDBThMbHHBqRkFO0p41giyVbx QPWS8j+O+rux+P6efD1konjH0kZHD9HWEkumabK5UXIF41gHRbdJCapISo/pBA3+ neUpkELs2TpCee4ajDYh/Do3HTlr4A0tfdil9eq+kXGmqnVjwvdJ3Inn+UVvD3NR YaV6lIOBfJP2RaE+b5OFSkgRhsqi7PqTYNSAe3hGEHu/ii8+1tP60Ka5nf4GXUq5 97K2XHkqxi9LjilAmBC/QxOkRHX93lfYQ5+nu4pmnWO+yidVFwUyWINO32D8Rzw3 bJVBQ+skv+hXJ3RPayIwh3fa8jXiJmFcNB1Edb39U6eueqXF8JvxJ9iabamTevD5 FIJr33JcyMOwQlS5tInVPhDL39Ic7Pkf21KzVwloEHfRaYLNTf3VSIPg5ZR42dUG HWndyc2VMzqov5n2wzSNUrD5waTndnbiWF80Ndw58zYlyqYxevaZ8fQTQQrvdFja 6SKd7KWbnQHn2TfJHHXR =ZKME -----END PGP SIGNATURE----- --8c07nsHwQobhlezh-- From nobody Wed Feb 25 01:19:52 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4931A7034 for ; Wed, 25 Feb 2015 01:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aN4v8fsACzC for ; Wed, 25 Feb 2015 01:19:49 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF051A0334 for ; Wed, 25 Feb 2015 01:19:47 -0800 (PST) Received: from mail1.sbs.de (localhost [127.0.0.1]) by thoth.sbs.de (8.14.3/8.14.3) with ESMTP id t1P9JfRU018157; Wed, 25 Feb 2015 10:19:41 +0100 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail1.sbs.de (8.14.3/8.14.3) with ESMTP id t1P9JdoH001634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 10:19:40 +0100 Received: from DENBGAT9ER4MSX.ww902.siemens.net (139.22.70.91) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Feb 2015 10:19:40 +0100 Received: from DEFTHW99EH1MSX.ww902.siemens.net ([169.254.11.58]) by DENBGAT9ER4MSX.ww902.siemens.net ([139.22.70.91]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 10:19:39 +0100 From: "Peintner, Daniel (ext)" To: =?iso-8859-1?Q?Christian_Ams=FCss?= , Julien Vermillard Thread-Topic: [core] SenML and delta encoding for samples Thread-Index: AQHQPyDjknsBDHM5i0KKQr28S6BsLp0AJHeAgAETYaA= Date: Wed, 25 Feb 2015 09:19:37 +0000 Message-ID: References: <20150224174557.GM26062@hephaistos.amsuess.com> In-Reply-To: <20150224174557.GM26062@hephaistos.amsuess.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.21] Content-Type: multipart/mixed; boundary="_003_D94F68A44EB1954A91DE4AE9659C5A980FC697AEDEFTHW99EH1MSXw_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] SenML and delta encoding for samples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 09:19:51 -0000 --_003_D94F68A44EB1954A91DE4AE9659C5A980FC697AEDEFTHW99EH1MSXw_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christian, Julien, all, If message size matters I think EXI is a good alternative. The original data Julien provided can be represented with the according XML= schema in about 100 Bytes. You can give it a try [1], -- Daniel [1] exificient.sourceforge.net/exificient.jnlp -----Urspr=FCngliche Nachricht----- Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Christian Ams=FCss Gesendet: Dienstag, 24. Februar 2015 18:46 An: Julien Vermillard Cc: core@ietf.org Betreff: Re: [core] SenML and delta encoding for samples Hello Julien, I am working with similar data and have not come up with a good solution ye= t. On Mon, Feb 02, 2015 at 07:45:39PM +0000, Julien Vermillard wrote: > {"e":[ > { "n": "sensorA", "dv":20 }, > { "n": "sensorB", "t": -5, "dv": 0.2 }, > { "n": "sensorB", "t": -4, "dv": 0.30 }, > { "n": "sensorA", "t": -3, "dv": -10.14 }, > { "n": "sensorB", "t": -2, "dv": 0.5 }, > { "n": "sensorA", "t": -1, "dv": 20.6 }, > { "n": "sensorB", "t": 0, "dv": 0.7 }], > "bn": "urn:dev:mac:0024befffe804f/", > "bt": 1276020076, > "ver": 1, > "bv" : { "sensorA" : 1000, > "sensorB": 250} } Such a scheme would reduce the size of my transmissions as well; my example= 271k uncompressed file (no timestamps) goes down to 248k with the establis= hed bt mechanism, to 217k with dt (see below), to 210k with dt and dv, to 1= 88k when absence of dv implies dv=3D0 (samples arrive irregularly, so the p= resence of a record does matter in my application), and down to 130k when I= compress names to digits. For CBOR, I'm getting 207k / 207k / 212k / 217k / 178k / 124k, but the numb= ers show that the implementation I used for testing (the Python version fro= m [1]) does not apply number compression. The number compression part is quite relevant, actually, because numerics m= atter here; a delta compression that produces small numbers in JSON might p= roduce even bigger representations in CBOR ("0.1" vs a 64bit float with tag= ), so much care would have to be taken when doing those calculations. Unles= s one wants to deal with lossy compression at transmission time (which woul= d be neigh impossible to disambiguate for duplicates or similar afterwards)= , that means that the numeric values have to be designed for compressibilit= y beforehand; once a number like 0.1d shows up there, it will always compre= ss badly with those schemes. If the dv scheme does work out to good savings using appropriate number rep= resentations, it should be considered for t as well, as the savings of the = time compression decrease when a SenML file spans several weeks. Storing the time in a "dt" field (which would in your example always have t= he value of 1) would be trivial then. > By the way putting "e" at the end of the document would help streaming=20 > and reduce memory consumption, I wonder why all the samples are this=20 > way in the RFC, it could be misleading. The CBOR RFC does allow "CBOR-based protocol [to] prescribe a specific orde= r of serialization", I'm not sure about JSON. I don't see the benefit of a "bv" here; the delta compression could always = start from zero and have its initial value in the first entry of e. Same go= es for bt if the proposed dt is used. What's left in common use is bn -- so= mehow dealing with names would give the best results with your and my data = sets. A solution might look like that: {"n": {0: "sensorA", 1: "sensorB"}, "e": [{"n":0, dv:20}, {"n":1, "t":-5, "dv": 0.2}]} Would that still be in the spirit of SenML? Best regards Christian [1] https://code.google.com/p/cbor/ -- To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --_003_D94F68A44EB1954A91DE4AE9659C5A980FC697AEDEFTHW99EH1MSXw_ Content-Type: text/xml; name="instance1.xml" Content-Description: instance1.xml Content-Disposition: attachment; filename="instance1.xml"; size=529; creation-date="Wed, 25 Feb 2015 08:51:34 GMT"; modification-date="Wed, 25 Feb 2015 08:59:56 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxzZW5tbCB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpzZW5tbCINCiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3Jn LzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIg0KIHhzaTpzY2hlbWFMb2NhdGlvbj0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpzZW5tbCAuL1Nlbk1MLnhzZCINCiBibj0idXJuOmRldjptYWM6MDAyNGJl ZmZmZTgwNGYvIiBidD0iMTI3NjAyMDA3NiIgdmVyPSIxIiA+DQogPGUgbj0ic2Vuc29yQSIgdj0i MTAyMCIgLz4NCiA8ZSBuPSJzZW5zb3JCIiB0PSItNSIgdj0iMjUwLjIiIC8+DQogPGUgbj0ic2Vu c29yQiIgdD0iLTQiIHY9IjI1MC4zMCIgLz4NCiA8ZSBuPSJzZW5zb3JBIiB0PSItMyIgdj0iOTkw LjE0IiAvPg0KIDxlIG49InNlbnNvckIiIHQ9Ii0yIiB2PSIyNTAuNSIgLz4NCiA8ZSBuPSJzZW5z b3JBIiB0PSItMSIgdj0iMTAyMC42IiAvPg0KIDxlIG49InNlbnNvckIiIHQ9IjAiIHY9IjI1MC43 IiAvPg0KPC9zZW5tbD4NCg== --_003_D94F68A44EB1954A91DE4AE9659C5A980FC697AEDEFTHW99EH1MSXw_ Content-Type: text/xml; name="SenML.xsd" Content-Description: SenML.xsd Content-Disposition: attachment; filename="SenML.xsd"; size=1250; creation-date="Wed, 25 Feb 2015 08:50:06 GMT"; modification-date="Wed, 25 Feb 2015 08:54:48 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjx4czpzY2hlbWEgeG1sbnM6 eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIg0KICAgIGVsZW1lbnRGb3JtRGVm YXVsdD0icXVhbGlmaWVkIg0KICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnht bDpuczpzZW5tbCINCiAgICB4bWxuczpuczE9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c2VubWwi Pg0KICAgIA0KICAgIDx4czplbGVtZW50IG5hbWU9ImUiPg0KICAgICAgICA8eHM6Y29tcGxleFR5 cGU+DQogICAgICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9Im4iIHR5cGU9InhzOnN0cmluZyIg Lz4NCiAgICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0idSIgdHlwZT0ieHM6c3RyaW5nIiAv Pg0KICAgICAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJ2IiB0eXBlPSJ4czpmbG9hdCIgLz4N CiAgICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0ic3YiIHR5cGU9InhzOnN0cmluZyIgLz4N CiAgICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iYnYiIHR5cGU9InhzOmJvb2xlYW4iIC8+ DQogICAgICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InMiIHR5cGU9InhzOmRlY2ltYWwiIC8+ DQogICAgICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9InQiIHR5cGU9InhzOmludCIgLz4NCiAg ICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0idXQiIHR5cGU9InhzOmludCIgLz4NCiAgICAg ICAgPC94czpjb21wbGV4VHlwZT4NCiAgICA8L3hzOmVsZW1lbnQ+DQogICAgPHhzOmVsZW1lbnQg bmFtZT0ic2VubWwiPg0KICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgICA8eHM6 c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9InVuYm91bmRlZCIgcmVmPSJuczE6ZSIvPg0KICAgICAgICAgICAgPC94czpzZXF1ZW5j ZT4NCiAgICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iYm4iIHR5cGU9InhzOnN0cmluZyIv Pg0KICAgICAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJidCIgdHlwZT0ieHM6aW50Ii8+DQog ICAgICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9ImJ1IiB0eXBlPSJ4czpzdHJpbmciLz4NCiAg ICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0idmVyIiB0eXBlPSJ4czppbnQiLz4NCiAgICAg ICAgPC94czpjb21wbGV4VHlwZT4NCiAgICA8L3hzOmVsZW1lbnQ+DQo8L3hzOnNjaGVtYT4= --_003_D94F68A44EB1954A91DE4AE9659C5A980FC697AEDEFTHW99EH1MSXw_-- From nobody Wed Feb 25 05:11:37 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF14E1A01F4 for ; Wed, 25 Feb 2015 05:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 3cEjcG2PXHEh for ; Wed, 25 Feb 2015 05:11:34 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953881A0006 for ; Wed, 25 Feb 2015 05:11:33 -0800 (PST) Received: by lbjb6 with SMTP id b6so3647543lbj.12 for ; Wed, 25 Feb 2015 05:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=UCPjM7WLJKwteck6rYcWKo+AK/shjl5SpYhgLfFdcIw=; b=a9ZEx+WcJ3Bu8HO1VhNEKs0Cx6hBM59bp2iVzjIsXIrhwQonOPYU7rCJLvPFM7sAsZ r6TtO7JGAu1yPKcAdaGskEbFPgzBo/id79KP9eT9msNMzuTendKgnnZSbxYRhMw5MrwR gBORV7MNUkxpMxuWCs+tLiSoRlrt0cb7MT1aGBVByyACqj9nFnVhIgELv/CmhCPdItv+ 2vWiuVGE71SQI0FTBpQ6q9NrE/cHnyOEE4/15aWwlt+t6EMtgdAx6Ni/7czc401I54QL L2cQswOC5F9LIvWl8hlXP5WyT9bODGym2D5xs7JtZUOGxDFmav/OiY/fUfgZAb9Hb8lk n6Zw== X-Received: by 10.152.43.228 with SMTP id z4mr2587311lal.111.1424869878802; Wed, 25 Feb 2015 05:11:18 -0800 (PST) MIME-Version: 1.0 References: <20150224174557.GM26062@hephaistos.amsuess.com> From: Julien Vermillard Date: Wed, 25 Feb 2015 13:11:17 +0000 Message-ID: To: "core@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2280cfa38b5050fe95e59 Archived-At: Subject: Re: [core] SenML and delta encoding for samples X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 13:11:36 -0000 --001a11c2280cfa38b5050fe95e59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2015 at 6:46 PM Christian Ams=C3=BCss < c.amsuess@energyharvesting.at> wrote: > Hello Julien, > > I am working with similar data and have not come up with a good solution > yet. > > On Mon, Feb 02, 2015 at 07:45:39PM +0000, Julien Vermillard wrote: > > {"e":[ > > { "n": "sensorA", "dv":20 }, > > { "n": "sensorB", "t": -5, "dv": 0.2 }, > > { "n": "sensorB", "t": -4, "dv": 0.30 }, > > { "n": "sensorA", "t": -3, "dv": -10.14 }, > > { "n": "sensorB", "t": -2, "dv": 0.5 }, > > { "n": "sensorA", "t": -1, "dv": 20.6 }, > > { "n": "sensorB", "t": 0, "dv": 0.7 }], > > "bn": "urn:dev:mac:0024befffe804f/", > > "bt": 1276020076, > > "ver": 1, > > "bv" : { "sensorA" : 1000, > > "sensorB": 250} } > > Such a scheme would reduce the size of my transmissions as well; my > example 271k uncompressed file (no timestamps) goes down to 248k with > the established bt mechanism, to 217k with dt (see below), to 210k with > dt and dv, to 188k when absence of dv implies dv=3D0 (samples arrive > irregularly, so the presence of a record does matter in my application), > and down to 130k when I compress names to digits. > > For CBOR, I'm getting 207k / 207k / 212k / 217k / 178k / 124k, but the > numbers show that the implementation I used for testing (the Python > version from [1]) does not apply number compression. > Number compression is critical, I use integers for a better result. Maybe a solution is a base value and a multiplication factor in the header and only integer for the sample delta values. > > The number compression part is quite relevant, actually, because > numerics matter here; a delta compression that produces small numbers in > JSON might produce even bigger representations in CBOR ("0.1" vs a 64bit > 0.1 as 64bit float is probably not a good idea, CBOR support 16/32/64bit floating number precisions. float with tag), so much care would have to be taken when doing those > calculations. Unless one wants to deal with lossy compression at > transmission time (which would be neigh impossible to disambiguate for > duplicates or similar afterwards), that means that the numeric values > have to be designed for compressibility beforehand; once a number like > 0.1d shows up there, it will always compress badly with those schemes. > > > If the dv scheme does work out to good savings using appropriate number > representations, it should be considered for t as well, as the savings > of the time compression decrease when a SenML file spans several weeks. > Storing the time in a "dt" field (which would in your example always > have the value of 1) would be trivial then. > > > By the way putting "e" at the end of the document would help streaming > and > > reduce memory consumption, I wonder why all the samples are this way in > the > > RFC, it could be misleading. > > The CBOR RFC does allow "CBOR-based protocol [to] prescribe a specific > order of serialization", I'm not sure about JSON. > > I don't see the benefit of a "bv" here; the delta compression could > always start from zero and have its initial value in the first entry of > e. Same goes for bt if the proposed dt is used. What's left in common > use is bn -- Good idea, it would be simpler than what I proposed. > somehow dealing with names would give the best results with > your and my data sets. A solution might look like that: > > {"n": {0: "sensorA", 1: "sensorB"}, > "e": [{"n":0, dv:20}, {"n":1, "t":-5, "dv": 0.2}]} > > Would that still be in the spirit of SenML? > I don't know.. of course it would save a lot of bytes, but maybe a second pass with gzip/huffman-coding would achieve the same result and keep the format in the spirit of SenML? Anyway I think you are right, does compression feature should be part of SenML or no ? if no, we should also ditch the delta time feature. Julien --001a11c2280cfa38b5050fe95e59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 24, 2015 at 6:46 PM Christian Ams=C3=BCss = <c.amsuess@energyharves= ting.at> wrote:
Hello Julien,

I am working with similar data and have not come up with a good solution yet.

On Mon, Feb 02, 2015 at 07:45:39PM +0000, Julien Vermillard wrote:
> {"e":[
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorA",= "dv":20 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorB",= "t": -5, "dv": 0.2 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorB",= "t": -4, "dv": 0.30 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorA",= "t": -3, "dv": -10.14 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorB",= "t": -2, "dv": 0.5 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorA",= "t": -1, "dv": 20.6 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ "n": "sensorB",= "t": 0,=C2=A0 =C2=A0"dv": 0.7 }],
>=C2=A0 =C2=A0 =C2=A0"bn": "urn:dev:mac:0024befffe804f/&q= uot;,
>=C2=A0 =C2=A0 =C2=A0"bt": 1276020076,
>=C2=A0 =C2=A0 =C2=A0"ver": 1,
>=C2=A0 =C2=A0 =C2=A0"bv" : { "sensorA" : 1000,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"sensorB&qu= ot;: 250} }

Such a scheme would reduce the size of my transmissions as well; my
example 271k uncompressed file (no timestamps) goes down to 248k with
the established bt mechanism, to 217k with dt (see below), to 210k with
dt and dv, to 188k when absence of dv implies dv=3D0 (samples arrive
irregularly, so the presence of a record does matter in my application), and down to 130k when I compress names to digits.

For CBOR, I'm getting 207k / 207k / 212k / 217k / 178k / 124k, but the<= br> numbers show that the implementation I used for testing (the Python
version from [1]) does not apply number compression.

Number compression is critical, I use inte= gers for a better result.
Maybe a solution is a base value an= d a multiplication factor in the header and only integer for the sample del= ta values.
=C2=A0

The number compression part is quite relevant, actually, because
numerics matter here; a delta compression that produces small numbers in JSON might produce even bigger representations in CBOR ("0.1" vs = a 64bit

0.1 as 64bit float is probably not a good = idea,
CBOR support 16/32/64bit floating number precisions.
float with tag), so much care would have to be taken when doing those
calculations. Unless one wants to deal with lossy compression at
transmission time (which would be neigh impossible to disambiguate for
duplicates or similar afterwards), that means that the numeric values
have to be designed for compressibility beforehand; once a number like
0.1d shows up there, it will always compress badly with those schemes.


If the dv scheme does work out to good savings using appropriate number
representations, it should be considered for t as well, as the savings
of the time compression decrease when a SenML file spans several weeks.
Storing the time in a "dt" field (which would in your example alw= ays
have the value of 1) would be trivial then.

> By the way putting "e" at the end of the document would help= streaming and
> reduce memory consumption, I wonder why all the samples are this way i= n the
> RFC, it could be misleading.

The CBOR RFC does allow "CBOR-based protocol [to] prescribe a specific=
order of serialization", I'm not sure about JSON.

I don't see the benefit of a "bv" here; the delta compression= could
always start from zero and have its initial value in the first entry of
e.
Same goes for bt if the prop= osed dt is used. What's left in common
use is bn --

Good idea, it would be s= impler than what I proposed.
=C2=A0
somehow dealing with names would give the best results wit= h
your and my data sets. A solution might look like that:

{"n": {0: "sensorA", 1: "sensorB"},
=C2=A0"e": [{"n":0, dv:20}, {"n":1, "t&q= uot;:-5, "dv": 0.2}]}

Would that still be in the spirit of SenML?

I don&= #39;t know.. of course it would save a lot of bytes, but maybe a second pas= s with gzip/huffman-coding would achieve the same result and keep the forma= t in the spirit of SenML?
Anyway I think you are right, does = compression feature should be part of SenML or no ? if no, we should also d= itch the delta time feature.

= Julien
--001a11c2280cfa38b5050fe95e59-- From nobody Wed Feb 25 07:41:04 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1846F1A90BD for ; Wed, 25 Feb 2015 07:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0yMmFUwI6VI for ; Wed, 25 Feb 2015 07:41:00 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F351A1BB9 for ; Wed, 25 Feb 2015 07:41:00 -0800 (PST) Received: by labgd6 with SMTP id gd6so4700115lab.8 for ; Wed, 25 Feb 2015 07:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=696vhoQokm2wLVvZQNehVOTYvoiBUDUl43lpweXZdr8=; b=drW2SmbcbMukk5pBi/tDzzTFp9rzeGslNCw+EiLN7WB8orWF28IEjW23lZX2UprjL6 qPyxFBwZDoO4fgqlvz7FlPf9QEaArhgQIvwGw3d2Ms454hqRySZ7N/IciAqTYDXpqn7j 5mBcOTc8f8QM/5egdsqq6FY2gCjGBBcRLJ0+75t+lVt3XASqpUkuifcWIGqpUrQTip1L S2DP2tckUvBD15nEOe5GEd16AlCFYWKaEcaRa6oP/jYqqvGrYMjNSVOaBnwAp/v11q/v EQ0PEefCBFd7klLsbs4tPBE66y4YyDF5n/ZKzuUXevU6Bp+wq8dsLIFTIpdbJY7UVll0 ipyg== X-Received: by 10.112.136.201 with SMTP id qc9mr3320189lbb.57.1424878858246; Wed, 25 Feb 2015 07:40:58 -0800 (PST) MIME-Version: 1.0 References: From: Julien Vermillard Date: Wed, 25 Feb 2015 15:40:57 +0000 Message-ID: To: Klaus Hartke , Maciej Wasilak Content-Type: multipart/alternative; boundary=089e011831ac319ffb050feb7682 Archived-At: Cc: core WG Subject: Re: [core] Checksum for firmware updates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 15:41:02 -0000 --089e011831ac319ffb050feb7682 Content-Type: text/plain; charset=UTF-8 Hi, I use option #1: the binary is encapsulated inside a container containing a checksum and/or RSA signature for identifying the binary. HTH Julien On Tue, Feb 24, 2015 at 3:48 PM Klaus Hartke wrote: > Hi Maciej, > > instead of POSTing the firmware image itself to the node, I would POST > a link to the image along with the checksum. The node then can GET the > image at its own pace and compare the checksum. The advantage of this > is that caches along the path can improve efficiency if more than one > node needs the firmware update. > > Klaus > > > On 24 February 2015 at 15:27, Maciej Wasilak wrote: > > Dear all, > > > > we are currently working on OTA firmware update that uses CoAP > > PUT/POST request with blockwise support. Part of the problem is to > > implement checksums for firmware image. There are several solutions to > > send checksum with CoAP: > > 1) Inside payload as part of the firmware package > > 2) Together with payload as a CoAP option (existing or new) > > 3) As a separate transaction > > > > Solution 1 should be fine for firmware, but might not be acceptable > > for other payloads, like human-readable config files etc. > > Solution 2 is very comfortable for embedded systems, but it might lead > > to unwanted overhead, as options are repeated in every block > > Solution 3 is the most complicated > > > > I would like to ask if anyone implemented such checksums, and what are > > your thoughts. > > > > Best Regards > > Maciej Wasilak > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --089e011831ac319ffb050feb7682 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
I use option #1: the binary is= encapsulated inside a container containing a checksum and/or RSA signature= for identifying the binary.
HTH
Julien

On Tue, Feb 24, 2015 at 3:48 PM Klaus Hartke <hartke@tzi.org> wrote:
Hi Maciej,

instead of POSTing the firmware image itself to the node, I would POST
a link to the image along with the checksum. The node then can GET the
image at its own pace and compare the checksum. The advantage of this
is that caches along the path can improve efficiency if more than one
node needs the firmware update.

Klaus


On 24 February 2015 at 15:27, Maciej Wasilak <wasilak@gmail.com> wrote:
> Dear all,
>
> we are currently working on OTA firmware update that uses CoAP
> PUT/POST request with blockwise support. Part of the problem is to
> implement checksums for firmware image. There are several solutions to=
> send checksum with CoAP:
> 1) Inside payload as part of the firmware package
> 2) Together with payload as a CoAP option (existing or new)
> 3) As a separate transaction
>
> Solution 1 should be fine for firmware, but might not be acceptable > for other payloads, like human-readable config files etc.
> Solution 2 is very comfortable for embedded systems, but it might lead=
> to unwanted overhead, as options are repeated in every block
> Solution 3 is the most complicated
>
> I would like to ask if anyone implemented such checksums, and what are=
> your thoughts.
>
> Best Regards
> Maciej Wasilak

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
--089e011831ac319ffb050feb7682-- From nobody Wed Feb 25 15:29:29 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88811A9169 for ; Wed, 25 Feb 2015 15:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgEymkExTboz for ; Wed, 25 Feb 2015 15:29:26 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAF31A9153 for ; Wed, 25 Feb 2015 15:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7552; q=dns/txt; s=iport; t=1424906945; x=1426116545; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=av4cAG7eLXTL49OdfrL6Miu3XWuCnGM+CeflLTSirkE=; b=C9Ko+yjZD4STY91qyA7bew+RzaVU4oOPtt9+ylPH3AglTfWWDxPYrve5 eWMVLshgGwe0uDyGI5RDMMTvv9+wJZoODdDtYqHsxrUutlKgbX1nskd1s MqM4Y3tHSih90pMY8JjEYwgGr0mteinIujpdyQW8UobWTCSORFpKNFZLl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZBQB8We5U/xbLJq1bg1Rawx4BCYVwAoFoAQEBAQEBfIQQAQEEAQEBawoBEAsOCgkWCAcJAwIBAgEPBh8RBgEMAQUCAQEXiAADEQ3DHI0JDYVAAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLE4JEgioHhCsFilCDHYVWhB+BRoEbhUqGDUeCSoM+IoQMIDGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.09,648,1418083200"; d="scan'208,217";a="361282052" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 25 Feb 2015 23:29:01 +0000 Received: from [10.131.65.104] (dhcp-10-131-65-104.cisco.com [10.131.65.104]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1PNSxED010859; Wed, 25 Feb 2015 23:28:59 GMT Message-ID: <54EE5ABA.5020209@cisco.com> Date: Wed, 25 Feb 2015 18:28:58 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julien Vermillard , Klaus Hartke , Maciej Wasilak References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050803080507030509040601" Archived-At: Cc: core WG Subject: Re: [core] Checksum for firmware updates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 23:29:28 -0000 This is a multi-part message in MIME format. --------------050803080507030509040601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Agreed. Option 1. The firmware payload is a blob being moved using CoAP. Internal structure of that blob in not CoAP's concern. Place whatever internal structure you like within the blob. Image, checksum, digital signature, etc. Maybe not appropriate for CoAP solutions, but one example of a blob container can be had at... https://tools.ietf.org/html/rfc5652 Cheers On 2/25/2015 10:40 AM, Julien Vermillard wrote: > Hi, > I use option #1: the binary is encapsulated inside a container > containing a checksum and/or RSA signature for identifying the binary. > HTH > Julien > > On Tue, Feb 24, 2015 at 3:48 PM Klaus Hartke > wrote: > > Hi Maciej, > > instead of POSTing the firmware image itself to the node, I would POST > a link to the image along with the checksum. The node then can GET the > image at its own pace and compare the checksum. The advantage of this > is that caches along the path can improve efficiency if more than one > node needs the firmware update. > > Klaus > > > On 24 February 2015 at 15:27, Maciej Wasilak > wrote: > > Dear all, > > > > we are currently working on OTA firmware update that uses CoAP > > PUT/POST request with blockwise support. Part of the problem is to > > implement checksums for firmware image. There are several > solutions to > > send checksum with CoAP: > > 1) Inside payload as part of the firmware package > > 2) Together with payload as a CoAP option (existing or new) > > 3) As a separate transaction > > > > Solution 1 should be fine for firmware, but might not be acceptable > > for other payloads, like human-readable config files etc. > > Solution 2 is very comfortable for embedded systems, but it > might lead > > to unwanted overhead, as options are repeated in every block > > Solution 3 is the most complicated > > > > I would like to ask if anyone implemented such checksums, and > what are > > your thoughts. > > > > Best Regards > > Maciej Wasilak > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------050803080507030509040601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Agreed.

Option 1.  The firmware payload is a blob being moved using CoAP.  Internal structure of that blob in not CoAP's concern.  Place whatever internal structure you like within the blob.  Image, checksum, digital signature, etc.

Maybe not appropriate for CoAP solutions, but one example of a blob container can be had at...

https://tools.ietf.org/html/rfc5652

Cheers


On 2/25/2015 10:40 AM, Julien Vermillard wrote:
Hi,
I use option #1: the binary is encapsulated inside a container containing a checksum and/or RSA signature for identifying the binary.
HTH
Julien

On Tue, Feb 24, 2015 at 3:48 PM Klaus Hartke <hartke@tzi.org> wrote:
Hi Maciej,

instead of POSTing the firmware image itself to the node, I would POST
a link to the image along with the checksum. The node then can GET the
image at its own pace and compare the checksum. The advantage of this
is that caches along the path can improve efficiency if more than one
node needs the firmware update.

Klaus


On 24 February 2015 at 15:27, Maciej Wasilak <wasilak@gmail.com> wrote:
> Dear all,
>
> we are currently working on OTA firmware update that uses CoAP
> PUT/POST request with blockwise support. Part of the problem is to
> implement checksums for firmware image. There are several solutions to
> send checksum with CoAP:
> 1) Inside payload as part of the firmware package
> 2) Together with payload as a CoAP option (existing or new)
> 3) As a separate transaction
>
> Solution 1 should be fine for firmware, but might not be acceptable
> for other payloads, like human-readable config files etc.
> Solution 2 is very comfortable for embedded systems, but it might lead
> to unwanted overhead, as options are repeated in every block
> Solution 3 is the most complicated
>
> I would like to ask if anyone implemented such checksums, and what are
> your thoughts.
>
> Best Regards
> Maciej Wasilak

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


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

--------------050803080507030509040601-- From Achim.Kraus@bosch-si.com Thu Feb 26 01:16:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45601A1BF5 for ; Thu, 26 Feb 2015 01:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZbAH7ZLu7eL for ; Thu, 26 Feb 2015 01:16:10 -0800 (PST) Received: from mx.bosch-si.com (mx.bosch-si.com [217.24.201.142]) (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 EA7681A1BE3 for ; Thu, 26 Feb 2015 01:16:09 -0800 (PST) X-ASG-Debug-ID: 1424942167-040b7f50902bda0001-aa7cYp Received: from immpwimx01.innoimm.local ([10.55.67.25]) by mx.bosch-si.com with ESMTP id YAZNeWguaaDQl824 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Feb 2015 10:16:07 +0100 (CET) X-Barracuda-Envelope-From: Achim.Kraus@bosch-si.com X-Barracuda-RBL-Trusted-Forwarder: 10.55.67.25 X-ASG-Whitelist: Client Received: from imbvw2exc01.bosch-si.com ([10.55.66.141]) by immpwimx01.innoimm.local over TLS secured channel with Microsoft SMTPSVC(7.5.7601.17514); Thu, 26 Feb 2015 10:16:07 +0100 Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by imbvw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 10:16:06 +0100 X-Barracuda-RBL-IP: 10.55.66.141 From: "Kraus Achim (INST/ESY4)" To: "core@ietf.org" Thread-Topic: blockwise transfers / draft-ietf-core-block-16 X-ASG-Orig-Subj: blockwise transfers / draft-ietf-core-block-16 Thread-Index: AdBRpNneg2n5u0XiRM+Qg01s59j8FA== Date: Thu, 26 Feb 2015 09:16:06 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.144.16] Content-Type: multipart/alternative; boundary="_000_BC36447FF5C62E46BEF3F124D3C1E8920829535Eimbpw2exd01bosc_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2015 09:16:07.0609 (UTC) FILETIME=[DA809290:01D051A4] X-Barracuda-Connect: UNKNOWN[10.55.67.25] X-Barracuda-Start-Time: 1424942167 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://217.24.201.142:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bosch-si.com Archived-At: Subject: [core] blockwise transfers / draft-ietf-core-block-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:18:01 -0000 --_000_BC36447FF5C62E46BEF3F124D3C1E8920829535Eimbpw2exd01bosc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, the "draft-ietf-core-block-16" shows in section 3.2, "Block1 Examples" in f= igure 9, page 21, success responses with "more" and "2.04 changed". According to 2.5, "Using the Block1 Option", page 12, and figure 7, page 20= , success responses with "more" should/must use "2.31 continue". Best regards Achim Kraus Bosch Software Innovations GmbH --_000_BC36447FF5C62E46BEF3F124D3C1E8920829535Eimbpw2exd01bosc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

the „draft-ietf-core-block-16“ shows in = section 3.2, “Block1 Examples” in figure 9, page 21, success re= sponses with “more” and “2.04 changed”.<= /p>

According to 2.5, “Using the Block1 OptionR= 21;, page 12, and figure 7, page 20, success responses with “moreR= 21; should/must use “2.31 continue”.

 

Best regards

 

Achim Kraus

 

Bosch Software Innovations GmbH

--_000_BC36447FF5C62E46BEF3F124D3C1E8920829535Eimbpw2exd01bosc_-- From nobody Thu Feb 26 01:21:24 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7851A1BFF for ; Thu, 26 Feb 2015 01:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUIbBgmt0qGQ for ; Thu, 26 Feb 2015 01:21:21 -0800 (PST) Received: from mx.bosch-si.com (mx.bosch-si.com [217.24.201.142]) (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 4A2C21A1BDF for ; Thu, 26 Feb 2015 01:21:04 -0800 (PST) X-ASG-Debug-ID: 1424942462-040b7f50902c170001-aa7cYp Received: from immpwimx01.innoimm.local ([10.55.67.25]) by mx.bosch-si.com with ESMTP id snpWGhxAtRen8QOt (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Feb 2015 10:21:02 +0100 (CET) X-Barracuda-Envelope-From: Achim.Kraus@bosch-si.com X-Barracuda-RBL-Trusted-Forwarder: 10.55.67.25 X-ASG-Whitelist: Client Received: from imbvw2exc01.bosch-si.com ([10.55.66.141]) by immpwimx01.innoimm.local over TLS secured channel with Microsoft SMTPSVC(7.5.7601.17514); Thu, 26 Feb 2015 10:21:02 +0100 Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by imbvw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 10:21:01 +0100 X-Barracuda-RBL-IP: 10.55.66.141 From: "Kraus Achim (INST/ESY4)" To: "core@ietf.org" Thread-Topic: blockwise transfers / draft-ietf-core-block-16 X-ASG-Orig-Subj: blockwise transfers / draft-ietf-core-block-16 Thread-Index: AdBRpYl/kxmzKZ4jST+MF54lo94JNg== Date: Thu, 26 Feb 2015 09:21:01 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.144.16] Content-Type: multipart/alternative; boundary="_000_BC36447FF5C62E46BEF3F124D3C1E89208295381imbpw2exd01bosc_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Feb 2015 09:21:02.0686 (UTC) FILETIME=[8A61BFE0:01D051A5] X-Barracuda-Connect: UNKNOWN[10.55.67.25] X-Barracuda-Start-Time: 1424942462 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://217.24.201.142:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bosch-si.com Archived-At: Subject: [core] blockwise transfers / draft-ietf-core-block-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:21:22 -0000 --_000_BC36447FF5C62E46BEF3F124D3C1E89208295381imbpw2exd01bosc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, the "draft-ietf-core-block-16" shows in section 3.2, "Block1 Examples" in f= igure 9, page 21, success responses with "more" and "2.04 changed". According to 2.5, "Using the Block1 Option", page 12, and figure 7, page 20= , success responses with "more" should/must use "2.31 continue". Best regards Achim Kraus Bosch Software Innovations GmbH --_000_BC36447FF5C62E46BEF3F124D3C1E89208295381imbpw2exd01bosc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

the „draft-ietf-core-block-16“ shows in = section 3.2, “Block1 Examples” in figure 9, page 21, success re= sponses with “more” and “2.04 changed”.<= /p>

According to 2.5, “Using the Block1 OptionR= 21;, page 12, and figure 7, page 20, success responses with “moreR= 21; should/must use “2.31 continue”.

 

Best regards

 

Achim Kraus

 

Bosch Software Innovations GmbH

 

--_000_BC36447FF5C62E46BEF3F124D3C1E89208295381imbpw2exd01bosc_-- From nobody Thu Feb 26 09:43:25 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744911A0211 for ; Thu, 26 Feb 2015 06:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 WWYJ4OsVnmcm for ; Thu, 26 Feb 2015 06:55:57 -0800 (PST) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2141A0162 for ; Thu, 26 Feb 2015 06:55:57 -0800 (PST) Received: from smtp2.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 888C0180439 for ; Thu, 26 Feb 2015 09:55:56 -0500 (EST) Received: from smtp192.mex07a.mlsrvr.com (unknown [67.192.133.128]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTPS id 68B3318047C for ; Thu, 26 Feb 2015 09:55:56 -0500 (EST) X-Sender-Id: bkinsella@bb-elec.com Received: from smtp192.mex07a.mlsrvr.com ([UNAVAILABLE]. [67.192.133.128]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:25 (trex/5.4.2); Thu, 26 Feb 2015 14:55:56 GMT Received: from DFW1MBX04.mex07a.mlsrvr.com ([169.254.2.188]) by DFW1HUB15.mex07a.mlsrvr.com ([::1]) with mapi; Thu, 26 Feb 2015 08:55:45 -0600 From: Ben Kinsella To: "core@ietf.org" Date: Thu, 26 Feb 2015 08:55:45 -0600 Thread-Topic: Re: [core] CoAP over TCP Thread-Index: AdBR1ApwgnIx4ABnT1yxd2pmumt+7g== Message-ID: <7221955A65891E4C90CEF9A551B5633E564E095C1B@DFW1MBX04.mex07a.mlsrvr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 09:43:23 -0800 Subject: Re: [core] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 14:55:58 -0000 Hi. Apologies for resurrecting this thread, but I haven't seen any updates on t= his topic since November. >> 3) CoAP over TCP. draft-bormann-core-coap-tcp-01 is a summary of the >> design choices. draft-tschofenig-core-coap-tcp-tls selects one option >> without explaining why. > >draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra) >have implemented and deployed. draft-bormann-core-coap-tcp expired in January, and draft-tschofenig-core-c= oap-tcp-tls is due to expire next week. Please excuse my ignorance of how the IETF process works, but my understand= ing was that the IETF would standardise on one approach for CoAP over TCP. Is this still going to happen? My interest is in the use of CoAP and LWM2M over cellular networks, and I h= ave some concerns over the use of UDP in scenarios which do not support VPN= s or private APNs. Can anyone provide real-world examples of the successful use of CoAP over U= DP in this type of environment? For example, my understanding is that LWM2M already makes a slight modifica= tion to CoAP in order to get around the cellular NAT issue: the device init= iates the connection to the head-end. Is UDP as the transport simply not an issue, and therefore there is no real= motivation for CoAP over TCP? I was hoping that IETF standardisation of CoAP over TCP would also trigger = changes in OMA's LWM2M spec. For example, if I adopt the ARM approach outlined in draft-tschofenig-core-= coap-tcp-tls, I presume I cannot use a standard LWM2M server? In what scenarios is the ARM/Zebra approach used? Alternatively, I know that there are also efforts underway to add an MQTT b= inding to LWM2M, as an alternative to CoAP. Which is likely to reach standardisation first: CoAP over TCP, or LWM2M ove= r MQTT? Regards, Ben. Ben Kinsella | Senior Engineer B+B SmartWorx | Westlink Commercial Park, Oranmore, Co. Galway, Ireland Office: +353 91 792444 |=20 Email: bkinsella@bb-smartworx.com | bb-smartworx.com Skype: ben.kinsella | ie.linkedin.com/in/benkinsella/ Hannes Tschofenig | 11 Nov 00:33 2014 Re: CoAP over TCP Hi Carsten, thanks for the write-up. On 10/24/2014 06:11 PM, Carsten Bormann wrote: > In alternative transports, I believe we have three hot topics: >=20 > 1) General issues. draft-silverajan-core-coap-alternative-transports > is a good basis for this and we will do the call for adoption soon. >=20 > 2) CoAP over SMS. This is also related to the question of DTLS over > SMS. We have a good draft for the former, which is mostly waiting > for (1). draft-fossati-dtls-over-gsm-sms merits some discussion. Thanks for mentioning draft-fossati-dtls-over-gsm-sms; I am happy to briefly describe what we had been working on. >=20 > 3) CoAP over TCP. draft-bormann-core-coap-tcp-01 is a summary of the > design choices. draft-tschofenig-core-coap-tcp-tls selects one option > without explaining why. draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra) have implemented and deployed. Our use case is firewall traversal in enterprise networks. Our goal was to use our existing CoAP over UDP implementation. Doing optimizations to CoAP when we already add all the complexity of TCP didn't seem worthwhile to us. Ciao Hannes From nobody Thu Feb 26 09:54:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E4F1A1B7B for ; Thu, 26 Feb 2015 09:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001] autolearn=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 NrrwgPIX2Prj for ; Thu, 26 Feb 2015 09:54:03 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D4B1A1B25 for ; Thu, 26 Feb 2015 09:54:03 -0800 (PST) Received: by iecrd18 with SMTP id rd18so18506818iec.8 for ; Thu, 26 Feb 2015 09:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AO+1bJPHwBJTrWhXa6CwJ3/efGYUrry9HTtYiiqeoIU=; b=aPSE6jz6FM+63T1jGc9b/es9syprO+KdUMz4PzCBe6aFSAAi0kjpf03o6XGqF6HWB+ x2DJ29GsLH2/Tf9L3aRi4Wnf1DBo1AzYf1vV04ssBTrei+yx7HN9yA3yfdMhGxQNCYMd QaseZjwvm1S6i6DBk3giLLRcFET45MrkTg+5qzfWILE17Ek2xMAyid+F7NcBZ0Dsn000 mTCPoKE0plNrpbvHzUnHHJRxcZGYyPKGIAUcznS4RRtFE3BnxWF0PN/hbbD1vHM0uJn1 OjLCyD78uqwQ8n+8nYve4NQ5h9xchqiCTzk+2v7jEPkoDQ8Ci/haexzLIBnt9uGSiuLX OlzA== X-Received: by 10.107.129.138 with SMTP id l10mr13510614ioi.37.1424973242989; Thu, 26 Feb 2015 09:54:02 -0800 (PST) Received: from [192.168.205.140] ([199.15.130.142]) by mx.google.com with ESMTPSA id jf10sm11940169igb.1.2015.02.26.09.54.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Feb 2015 09:54:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Simon Lemay In-Reply-To: <7221955A65891E4C90CEF9A551B5633E564E095C1B@DFW1MBX04.mex07a.mlsrvr.com> Date: Thu, 26 Feb 2015 11:54:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7221955A65891E4C90CEF9A551B5633E564E095C1B@DFW1MBX04.mex07a.mlsrvr.com> To: Ben Kinsella X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:54:05 -0000 Hi,=20 I would say thank you for resurrecting this thread :) We are currently working on new version = draft-tschofenig-core-coap-tcp-tls in order to have out asap so we can = move forward on standerdizing CoAP over TCP. And you are correct, it is = the goal of IETF to make it standards, and was identify as a priority=20 I would say that it should come out soon, we are writing up the final = corner case in the RFC and it will put is out for review very soon. Thanks for raising the the question :) Simon Lemay > On Feb 26, 2015, at 8:55 AM, Ben Kinsella = wrote: >=20 > Hi. >=20 > Apologies for resurrecting this thread, but I haven't seen any updates = on this topic since November. >=20 >>> 3) CoAP over TCP. draft-bormann-core-coap-tcp-01 is a summary of = the >>> design choices. draft-tschofenig-core-coap-tcp-tls selects one = option >>> without explaining why. >>=20 >> draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra) >> have implemented and deployed. >=20 > draft-bormann-core-coap-tcp expired in January, and = draft-tschofenig-core-coap-tcp-tls is due to expire next week. > Please excuse my ignorance of how the IETF process works, but my = understanding was that the IETF would standardise on one approach for = CoAP over TCP. > Is this still going to happen? >=20 > My interest is in the use of CoAP and LWM2M over cellular networks, = and I have some concerns over the use of UDP in scenarios which do not = support VPNs or private APNs. > Can anyone provide real-world examples of the successful use of CoAP = over UDP in this type of environment? > For example, my understanding is that LWM2M already makes a slight = modification to CoAP in order to get around the cellular NAT issue: the = device initiates the connection to the head-end. > Is UDP as the transport simply not an issue, and therefore there is no = real motivation for CoAP over TCP? >=20 > I was hoping that IETF standardisation of CoAP over TCP would also = trigger changes in OMA's LWM2M spec. > For example, if I adopt the ARM approach outlined in = draft-tschofenig-core-coap-tcp-tls, I presume I cannot use a standard = LWM2M server? > In what scenarios is the ARM/Zebra approach used? >=20 > Alternatively, I know that there are also efforts underway to add an = MQTT binding to LWM2M, as an alternative to CoAP. > Which is likely to reach standardisation first: CoAP over TCP, or = LWM2M over MQTT? >=20 > Regards, > Ben. >=20 > Ben Kinsella | Senior Engineer > B+B SmartWorx | Westlink Commercial Park, Oranmore, Co. Galway, = Ireland > Office: +353 91 792444 |=20 > Email: bkinsella@bb-smartworx.com | bb-smartworx.com > Skype: ben.kinsella | ie.linkedin.com/in/benkinsella/ >=20 >=20 > Hannes Tschofenig | 11 Nov 00:33 2014 > Re: CoAP over TCP >=20 > Hi Carsten, >=20 > thanks for the write-up. >=20 > On 10/24/2014 06:11 PM, Carsten Bormann wrote: >> In alternative transports, I believe we have three hot topics: >>=20 >> 1) General issues. draft-silverajan-core-coap-alternative-transports >> is a good basis for this and we will do the call for adoption soon. >>=20 >> 2) CoAP over SMS. This is also related to the question of DTLS over >> SMS. We have a good draft for the former, which is mostly waiting >> for (1). draft-fossati-dtls-over-gsm-sms merits some discussion. >=20 > Thanks for mentioning draft-fossati-dtls-over-gsm-sms; I am happy to > briefly describe what we had been working on. >=20 >>=20 >> 3) CoAP over TCP. draft-bormann-core-coap-tcp-01 is a summary of the >> design choices. draft-tschofenig-core-coap-tcp-tls selects one option >> without explaining why. >=20 > draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra) > have implemented and deployed. >=20 > Our use case is firewall traversal in enterprise networks. Our goal = was > to use our existing CoAP over UDP implementation. Doing optimizations = to > CoAP when we already add all the complexity of TCP didn't seem > worthwhile to us. >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Feb 26 20:03:48 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C1B1A1B7D for ; Thu, 26 Feb 2015 20:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.828 X-Spam-Level: * X-Spam-Status: No, score=1.828 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=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 5ptj4vB3wyb5 for ; Thu, 26 Feb 2015 20:03:45 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7554B1A19EC for ; Thu, 26 Feb 2015 20:03:44 -0800 (PST) Received: from WeiGengyuPC (unknown [222.131.15.246]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 3590E19F390; Fri, 27 Feb 2015 12:03:42 +0800 (HKT) Message-ID: <4E96CF223BCE4171B9B33914D225FE97@WeiGengyuPC> From: "weigengyu" To: "Ben Kinsella" References: <7221955A65891E4C90CEF9A551B5633E564E095C1B@DFW1MBX04.mex07a.mlsrvr.com> In-Reply-To: <7221955A65891E4C90CEF9A551B5633E564E095C1B@DFW1MBX04.mex07a.mlsrvr.com> Date: Fri, 27 Feb 2015 12:03:47 +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] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 04:03:48 -0000 Hi Ben, > My interest is in the use of CoAP and LWM2M over cellular networks, and I > have some concerns over the use of UDP in scenarios which do not support > VPNs or private APNs. I try to give my comments. If you use the SMS in celluler networks, it seems not to have the problem of mobile IP, NAT or VPN. If you use IP over GPRS, EDGE, WCDMA or LTE, you need to concern the problems about Moblile IP, NAT and/or VPN. RFC 3519 handls the problem on mobile IP and NAT. In RFC3519 "Mobile IP Traversal of Network Address Translation (NAT) Devices" "1.2 Problem description A basic assumption that Mobile IP [10] makes is that mobile nodes and foreign agents are uniquely identifiable by a globally routable IP address. This assumption breaks down when a mobile node attempts to communicate from behind a NAT. " OpenVPN use UDP tunnel as default for VPN, the UDP tunnel conveys IP ESP [RFC3948]. Probably the problem is that OpenVPN is based on TLS of OpenSSL. So, in pricinple it is required just to to replace TLS by DTLS for supporting CoAP and OMA LWM2M. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Ben Kinsella Sent: Thursday, February 26, 2015 10:55 PM To: core@ietf.org Subject: Re: [core] CoAP over TCP Hi. Apologies for resurrecting this thread, but I haven't seen any updates on this topic since November. >> 3) CoAP over TCP. draft-bormann-core-coap-tcp-01 is a summary of the >> design choices. draft-tschofenig-core-coap-tcp-tls selects one option >> without explaining why. > >draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra) >have implemented and deployed. draft-bormann-core-coap-tcp expired in January, and draft-tschofenig-core-coap-tcp-tls is due to expire next week. Please excuse my ignorance of how the IETF process works, but my understanding was that the IETF would standardise on one approach for CoAP over TCP. Is this still going to happen? My interest is in the use of CoAP and LWM2M over cellular networks, and I have some concerns over the use of UDP in scenarios which do not support VPNs or private APNs. Can anyone provide real-world examples of the successful use of CoAP over UDP in this type of environment? For example, my understanding is that LWM2M already makes a slight modification to CoAP in order to get around the cellular NAT issue: the device initiates the connection to the head-end. Is UDP as the transport simply not an issue, and therefore there is no real motivation for CoAP over TCP? I was hoping that IETF standardisation of CoAP over TCP would also trigger changes in OMA's LWM2M spec. For example, if I adopt the ARM approach outlined in draft-tschofenig-core-coap-tcp-tls, I presume I cannot use a standard LWM2M server? In what scenarios is the ARM/Zebra approach used? Alternatively, I know that there are also efforts underway to add an MQTT binding to LWM2M, as an alternative to CoAP. Which is likely to reach standardisation first: CoAP over TCP, or LWM2M over MQTT? Regards, Ben. Ben Kinsella | Senior Engineer B+B SmartWorx | Westlink Commercial Park, Oranmore, Co. Galway, Ireland Office: +353 91 792444 | Email: bkinsella@bb-smartworx.com | bb-smartworx.com Skype: ben.kinsella | ie.linkedin.com/in/benkinsella/ Hannes Tschofenig | 11 Nov 00:33 2014 Re: CoAP over TCP Hi Carsten, thanks for the write-up. On 10/24/2014 06:11 PM, Carsten Bormann wrote: > In alternative transports, I believe we have three hot topics: > > 1) General issues. draft-silverajan-core-coap-alternative-transports > is a good basis for this and we will do the call for adoption soon. > > 2) CoAP over SMS. This is also related to the question of DTLS over > SMS. We have a good draft for the former, which is mostly waiting > for (1). draft-fossati-dtls-over-gsm-sms merits some discussion. Thanks for mentioning draft-fossati-dtls-over-gsm-sms; I am happy to briefly describe what we had been working on. > > 3) CoAP over TCP. draft-bormann-core-coap-tcp-01 is a summary of the > design choices. draft-tschofenig-core-coap-tcp-tls selects one option > without explaining why. draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra) have implemented and deployed. Our use case is firewall traversal in enterprise networks. Our goal was to use our existing CoAP over UDP implementation. Doing optimizations to CoAP when we already add all the complexity of TCP didn't seem worthwhile to us. Ciao Hannes _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 27 00:36:16 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE121A1B89 for ; Fri, 27 Feb 2015 00:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.391 X-Spam-Level: ** X-Spam-Status: No, score=2.391 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 PDpzXeAseZ7a for ; Fri, 27 Feb 2015 00:36:08 -0800 (PST) Received: from mx.bosch-si.com (mx.bosch-si.com [217.24.201.142]) (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 28FAB1A0248 for ; Fri, 27 Feb 2015 00:36:07 -0800 (PST) X-ASG-Debug-ID: 1425026166-040b7f509254d40001-aa7cYp Received: from immpwimx01.innoimm.local ([10.55.67.25]) by mx.bosch-si.com with ESMTP id z6u0WBbDGEXvJ36n (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Feb 2015 09:36:06 +0100 (CET) X-Barracuda-Envelope-From: Achim.Kraus@bosch-si.com X-Barracuda-RBL-Trusted-Forwarder: 10.55.67.25 X-ASG-Whitelist: Client Received: from imbvw2exc01.bosch-si.com ([10.55.66.141]) by immpwimx01.innoimm.local over TLS secured channel with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Feb 2015 09:36:06 +0100 Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by imbvw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0224.002; Fri, 27 Feb 2015 09:36:05 +0100 X-Barracuda-RBL-IP: 10.55.66.141 From: "Kraus Achim (INST/ESY4)" To: "core@ietf.org" Thread-Topic: changing block size / draft-ietf-core-block-16 X-ASG-Orig-Subj: changing block size / draft-ietf-core-block-16 Thread-Index: AdBSaGzadbNpPDOeTHCrhAtsf/tdbQ== Date: Fri, 27 Feb 2015 08:36:05 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.144.16] Content-Type: multipart/alternative; boundary="_000_BC36447FF5C62E46BEF3F124D3C1E89208295582imbpw2exd01bosc_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2015 08:36:06.0139 (UTC) FILETIME=[6D8714B0:01D05268] X-Barracuda-Connect: UNKNOWN[10.55.67.25] X-Barracuda-Start-Time: 1425026166 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://217.24.201.142:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bosch-si.com Archived-At: Subject: [core] changing block size / draft-ietf-core-block-16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 08:36:14 -0000 --_000_BC36447FF5C62E46BEF3F124D3C1E89208295582imbpw2exd01bosc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, the examples in draft-ietf-core-block-16 with changing the block size assum= e, that the receiver is able to process larger messages and just prefer sma= ller ones. For devices, which are not able to process larger messages, this= approach fails. Though this case may be processed with retries, it would b= e clearer, if examples for those cases were added. By the way, I would prefer a way, in which the receiver could also inform t= he sender, that only a smaller part of the message could be processed. For = block2 it may be considered, that a client request the next smaller block o= nly having processed the head of the first message sending the next request= with num 1 (e.g. for the example in 3.1., figure 4, page 18, use for secon= d request 2:1/0/64 (in case, only the first 64 bytes could be processes) in= stead of 2:2/0/64 (in case, the whole 128 bytes could be processed)). For b= lock1 it may be considered, that a response with block num 0 and with small= er block size should indicate, that only the smaller block could be process= ed, and response with a block num "(request block size / preferred block si= ze) - 1" should indicate, that the first message was processed completely, = but the smaller block size is preferred by the receiver (e.g. for the examp= le in 3.2., figure 9, page 21, use for response 1:0/1/32 (in case, only the= first 32 bytes could be processes), 1:3/1/32 (in case, the whole 128 bytes= could be processed)). Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus Bosch Software Innovations GmbH Communications (INST/ESY4) Stuttgarter Stra=DFe 130 71332 Waiblingen GERMANY www.bosch-si.de www.blog.bosch-si.com Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB = 148411 B Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn --_000_BC36447FF5C62E46BEF3F124D3C1E89208295582imbpw2exd01bosc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear All,

the examples in draft-ietf-core-block-16 with changi= ng the block size assume, that the receiver is able to process larger messa= ges and just prefer smaller ones. For devices, which are not able to proces= s larger messages, this approach fails. Though this case may be processed with retries, it would be clearer, if ex= amples for those cases were added.

By the way, I would prefer a way, in which the recei= ver could also inform the sender, that only a smaller part of the message c= ould be processed. For block2 it may be considered, that a client request t= he next smaller block only having processed the head of the first message sending the next request with num = 1 (e.g. for the example in 3.1., figure 4, page 18, use for second request = 2:1/0/64 (in case, only the first 64 bytes could be processes) instead of 2= :2/0/64 (in case, the whole 128 bytes could be processed)). For block1 it may be considered, that a respon= se with block num 0 and with smaller block size should indicate, that only = the smaller block could be processed, and response with a block num “= (request block size / preferred block size) – 1” should indicate, that the first message was process= ed completely, but the smaller block size is preferred by the receiver (e.g= . for the example in 3.2., figure 9, page 21, use for response 1:0/1/32 (in= case, only the first 32 bytes could be processes), 1:3/1/32 (in case, the whole 128 bytes could be processed)).

 

Mit freundlichen Gr=FC=DFen /= Best regards

 

Achim Kraus

 

Bosch Software= Innovations GmbH

Communications= (INST/ESY4)

Stuttgarter Stra=DFe 130=

71332 Waiblingen

GERMANY

ww= w.bosch-si.de

www.blog.bosch-si.com

 

Registered office: Berlin, Reg= ister court: Amtsgericht Charlottenburg, HRB 148411 B

Executives: Dr.-Ing. Rainer Ka= llenbach; Michael Hahn

 

 

--_000_BC36447FF5C62E46BEF3F124D3C1E89208295582imbpw2exd01bosc_--