From nobody Fri Apr 1 02:17:23 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1659E12D14A for ; Fri, 1 Apr 2016 02:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.531 X-Spam-Level: ** X-Spam-Status: No, score=2.531 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.741, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOIJfwi85xft for ; Fri, 1 Apr 2016 02:17:19 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2E49412D0ED for ; Fri, 1 Apr 2016 02:17:18 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.193]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUCiePP5WeSpSCQ--.58121S2; Fri, 01 Apr 2016 17:17:18 +0800 (CST) Date: Fri, 1 Apr 2016 17:17:03 +0800 From: "qinxiaowei@cnnic.cn" To: t2trg , bill.wu X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2016040117170283951218@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart244637528681_=----" X-CM-TRANSID: AQAAf0BJUCiePP5WeSpSCQ--.58121S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUOf7k0a2IF6w4kM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26ryj 6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gc CE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxI r21l5I8CrVAaz4v26cxKscIFY7kG0wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6xIIjx v20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx 8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41l4I8I3I0E 4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGV WUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_ Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rV W3JVWrJr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8 JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07bwo7_UUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [T2TRG] draft-wu-t2trg-network-telemetry-00 X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 09:17:21 -0000 This is a multi-part message in MIME format. ------=_001_NextPart244637528681_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksIFFpbiBhbmQgZm9sa3MsDQpJJ3ZlIHRyaWVkIHRvIGRvIGEgdGhvcm91Z2ggcmV2aWV3IG9m IHRoZSBkcmFmdC13dS10MnRyZy1uZXR3b3JrLXRlbGVtZXRyeS0wMC4gDQpNeSBnZW5lcmFsIGZl ZWxpbmcgYWJvdXQgdGhlIGRvY3VtZW50IGlzIHRoYXQgaXQgbWF5IGJlIGEgZ29vZCB3YXkgdG8g aW1wcm92ZSB0aGUgdmlzaWJpbGl0eSBvZiB0aGUgSW9UIG5ldHdvcmsgdG9wb2xvZ3kgYW5kIHRo ZSBhdmFpbGFibGUgbmV0d29yayByZXNvdXJjZXMuIA0KQXMgd2Uga25vdywgbmV0d29yayBhZG1p bmlzdHJhdG9yIHNob3VsZCBrbm93IHJlYWwtdGltZSBydW5uaW5nIHN0YXRlIG9mIHRoZSB3aG9s ZSBJb1QgZGV2aWNlcywgYXQgbGVhc3QsIHNob3VsZCBrbm93IHdoZXRoZXIgYSBkZXZpY2Ugd29y a3Mgd2VsbC4gDQpGb3IgaGlnaC1jYXBhY2l0eSBJb1QgZGV2aWNlcyBzdWNoIGFzIGFwcGxpYW5j ZXMgKGUuZy4sIHRlbGV2aXNpb24sIHJlZnJpZ2VyYXRvciwgYWlyIGNvbmRpdGlvbmVyLCBhbmQg d2FzaGluZyBtYWNoaW5lKSwgd2hpY2ggY2FuIGJlIGRpcmVjdGx5IGNvbm5lY3RlZCB0byBpbnRl cm5ldCB0aHJvdWdoIGFjY2VzcyBkZXZpY2UsIHdlIG1heSByZWFkIHRoZSBsb2dzIG9mIHRoZXNl IGFjY2VzcyBkZXZpY2VzIHRvIGdldCB0aGUgc3RhdGUgZGF0YS4gIA0KRm9yIGxvdy1jYXBhY2l0 eSBhbmQgbm9uLUlQIElvVCBkZXZpY2VzIHN1Y2ggYXMgc2Vuc29ycyAoZS5nLiwgbGlnaHQsIG1l dGVyLCByb29tIHRlbXBlcmF0dXJlIGNvbnRyb2xsZXIsIGFuZCBzZW5zb3JzKSAsIHdoaWNoIG1h eSBiZSBmaXJzdCBjb25uZWN0IHRvIGEgdHJhbnNmb3JtIGRldmljZShzdWNoIGFzIGNsdXN0ZXIg aGVhZGVyLCBob21lIGdhdGV3YXkgb3IgYnJpZGdlLCBldGMuKSBhbmQgdGhlbiB0byBpbnRlcm5l dCwgdGhlIHNpdHVhdGlvbiBpcyBldmVuIG1vcmUgY29tcGxpY2F0ZWQuIFRoZSBub24tSVAgSW9U IGRldmljZXMgbWF5IHVzZSBkaWZmZXJlbnQgcHJvdG9jb2xzKGUuZy4sIFdpRmksIEJsdWV0b290 aCwgYW5kIFppZ0JlZSkgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgdHJhbnNmb3JtIGRldmljZSwg YW5kIHVzZSBsaWtlImhlYXJ0LWJlYXQgbWVzc2FnZSIgdG8gdGVsbCB0aGVpciBtYW5hZ2VyIHRo ZXkgYXJlIHN0aWxsIG9uIGxpbmUgYW5kIHdvcmsgd2VsbC4gd2UgbWF5IGhhdmUgdG8gYWNjZXNz IGVhY2ggdHJhbnNmb3JtIGRldmljZSB0byBleHRyYWN0IHRoZXNlICJoZWFydC1iZWF0IG1lc3Nh Z2UiIHRvIGdldCB0aGUgc3RhdGUgZGF0YS4gVGhlIGFib3ZlIG1hbnVhbCBvcGVyYXRpb24gd2ls bCBiZSBjdW1iZXJzb21lIGFuZCB0aW1lLWNvbnN1bWluZyBhcyB0aGUgbnVtYmVyIG9mIHRoZW0g aW5jcmVhc2VzIHJhcGlkbHkgaW4gYSBuZXR3b3JrLg0KU28sIG5ldHdvcmsgdGVsZW1ldHJ5IGlz IHdvcnRoIHRvIGRvLiAgDQoNCkJlc3Qgd2lzaGVzDQpYaWFvd2VpIFFpbg0KDQoNCg0KDQoNCg== ------=_001_NextPart244637528681_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= body>=0A
Hi, Qin a= nd folks,
I've tried to do a thorough review of the draft-wu-t2trg= -network-telemetry-00. =0A
My general feeling about the document is tha= t it may be a good way to improve the visibility of the IoT network topolo= gy and the available network resources.=0A
As we know, network administ= rator should know real-time running state of the whole IoT devices, at lea= st, should know whether a device works well.=0A
For high-capacity IoT d= evices such as appliances (e.g., television, refrigerator, air conditioner= , and washing machine), which can be directly connected to internet throug= h access device, we may read the logs of these access devices to get the s= tate data.  
For low-capacity and non-IP IoT devices such as sensors (e.g.= , light, meter, room temperature controller, and sensors) , which may be= first connect to a transform device(such as cluster header, home gateway = or bridge, etc.) and then to internet, the situation is even more complica= ted. The non-IP IoT devices may use different protocols(e.g., WiFi, Blueto= oth, and ZigBee) to communicate with the transform device, and use like"he= art-beat message" to tell their manager they are still on line and work we= ll. we may have to access each transform device= to extract these "heart-beat message" to get the state data. The above = manual operation will be cumbersome and time-consuming as the number of th= em increases rapidly in a network.
So, netw= ork telemetry is worth to do.  

<= /span>
Best wishes
Xiaowei Qin


=0A


= =0A
=0A ------=_001_NextPart244637528681_=------ From nobody Thu Apr 7 13:25:05 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F92B12D1CA for ; Thu, 7 Apr 2016 13:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irR7emxinH4F for ; Thu, 7 Apr 2016 13:25:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4B012D5A9 for ; Thu, 7 Apr 2016 13:24:56 -0700 (PDT) Received: from [192.168.10.140] ([31.133.155.135]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LqQTl-1bS1DB3ElF-00e1Eh; Thu, 07 Apr 2016 22:24:53 +0200 To: Mohit Sethi From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5706C210.6060902@gmx.net> Date: Thu, 7 Apr 2016 22:24:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xOT2gaLC0u5H4dEBD5tk3DA4u3IN3Q9hT" X-Provags-ID: V03:K0:hfpPYP4DpyUPsCCyUn3CNulPbd+hOA80a0SIKFKo8eMAEwXHcat /FlZrleIfiewZVO5As4oWK/XW56/7BlpzgJrHj1zX41E2siYjXIBGRQ96bBZGcLWIadYmeu q1Hqu6p7gI7tpok+eqXNp0WAdslVYjCXTGzfBoBrLwv+C7XxsXa53eIaoZdUV0+EDtt5+3X WaxTLXSLFS/b7i9H6e8ng== X-UI-Out-Filterresults: notjunk:1;V01:K0:Rek9mqAgHQI=:2N1CcxITlIDON0hngmz43x r3Qt+TXvaLu4Dw/oWLnfM9gBShGvOwH/zZlKlu9/TP4Q3FX/YPD48HAjDpUfbRg9Y8m5rK0PP alfvBdtgwn713wVQBkG2hV6X4znTepIiYTquAjdwHHq2SWVk8xnyH7J2jaYb4hVf/ilt57pwS v4zfjJo8JqG+JD0uPC6suBDCf0znJktqapKwtZV/Ly5xeXfi0S7nFpLBBIxCkbeE21wrYQJb2 0SJRjrtwDSngJqgunhDt3XXJCAqCZbP7hE1TasMgo+tnZI2rBpwxGlYIJRpNjV217cUHAZmlN bK34uKH4LsN4rET5MXXTIQjlOFyL11khyHWB2ONxBNZ4pSJmLPAtF8XmCJ/rScBWwXhwSEzPf URrSiPVCJ/jom/lLM7P/Of5itgG8iedEgs7xpVcX/aZkJdL2qk5g5lNjMhbY9SrW226JNuBCE q+rvHiOX2K+Du/UJDCrrOZmWrN+8dgFeVM6D+k/O+i/ElBCbnq+XJhWBVvF9KEw1wTDv2Pmu3 KzSddGmY5Vu3YoPfZB7+vmJjqlXJzsSDRSqmfKLlSJyLVPlh6TG+Srefo3mUWPvbrMazHlvQt kM8mxt5R1/WcZ1xmAQPAVnuad+/ptZ74ZYWRGCCsOFHRYvTh1PTSaf1szuq+apElDA+y2Z0n2 k7egPHNbXDKm/Ilc0xglGKQLMubJnU6s9N94LzNN1QamfQZkGy1de324sWDjCixDT+nHx1yvL 7iC9xZVY/0T99YO81xqXcUthIztZn2PVJYe97OY9RWbCCGPhCkDYgCYg8p4= Archived-At: Cc: "t2trg@irtf.org" Subject: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:25:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xOT2gaLC0u5H4dEBD5tk3DA4u3IN3Q9hT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In his presentation Mohit used the term 'Device Identity'. I have heard this term in various conversation over the past few years and I have the fear that there are different interpretations what it mean= s. What does it mean for you, Mohit? Ciao Hannes --xOT2gaLC0u5H4dEBD5tk3DA4u3IN3Q9hT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXBsIRAAoJEGhJURNOOiAtO8cH/R2UtII0wijaAhB2ts6mozg/ Y1tbyYg9btyou0rOPSs9mNy6QCXOtCei9Ck8nJO7fZUBes7Hh6LZ5JAQgkqTH729 JA00tivDw8jJVkUqLfN8JvTMQS7GG24QDycFZnJESpYa6efimSMJqHowYRzeHsgZ z+XUgUwtRwCDZxmVd/qvb/QxUj3nuGnkmjh+1Otw/wO1d4Qojf1U8oZLbbA6dylw Oqa7S8PNWahvP4fTWpHpzGsG+9938LAH1RU+1UuByG1kbhd4U8zXr24n13es4F6u OM+J84rjqOG3/AeL4T834d+5OrtgosXlNkl/8DFJkoPMlpRK33QE+gu6BTLacho= =gzz+ -----END PGP SIGNATURE----- --xOT2gaLC0u5H4dEBD5tk3DA4u3IN3Q9hT-- From nobody Thu Apr 7 13:47:50 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811A212D175 for ; Thu, 7 Apr 2016 13:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i48w2ePlFD4f for ; Thu, 7 Apr 2016 13:47:46 -0700 (PDT) Received: from nm27-vm3.bullet.mail.ne1.yahoo.com (nm27-vm3.bullet.mail.ne1.yahoo.com [98.138.91.157]) (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 970C812D10C for ; Thu, 7 Apr 2016 13:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460062065; bh=JbpFPMDhO/JVoCSTD6PyobgJmmR0hVAw4VOY9eZMCr4=; h=From:Date:Subject:To:From:Subject; b=amWffeUUciJ7By2HGpZlnaLLTjQM7HWH1CWDAvnNu7095tLzNxUiA0RuCer86qCa9BRuBuh3yHP2WLWTzz/cNt8sQc559fac++EpGJL0owghoY0N0rzHxhtyB1TfsOl2Ac3K4fsAdQxCvODmsSwxNRHTKh9vdaPIAAheXzUwOsBxIAQz5ekk0n9HI/JPbhtMydFZa7YH5+ViOtsQch34c+0ekrYwAXOBmsPu7RCX0pp1Z6aC+s2BZ5SWEx1dlQW3dbzlxR9WcZyAE8HQHpcp6CEcd9u2Q8mrFeudcYc/CKEMnGHHzrGNDCphbQ8HNM0IkNxERnbMGRf4RjyGFrqvIA== Received: from [98.138.101.128] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 20:47:45 -0000 Received: from [98.138.226.57] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 20:47:45 -0000 Received: from [127.0.0.1] by smtp208.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 20:47:45 -0000 X-Yahoo-Newman-Id: 787064.51708.bm@smtp208.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9UwvE9EVM1kc_AcXwqeMf69kOE3_.WsOsvm_oHoNmuPSqUq iRU138bwgHgp4W4WSEcUGkMxIR3YamZzsE6obL1K9PoYhSD0UCtg2C8EKOmk jCol8vNwQQ3gwfcrMUEpfXtvPgNfvb4OxO2etHcpBtrxDK8i85FpkSMS_HjE mAMw.BBc9UaE_6OiZpRmkwB.SfiVM9HjWLkEfi1LAk.tOAlOGyrXSzFlZVkk cS0s.ynq6EivshcKZRyAcd3uYEtkYIckAXKO7_Z5vpAvL8jC1bl_45q_9NsI tBT.4HvcmwP6fZTypNZurwmDn4FPzK.BAdSCLk46XNV2qPmXu5_5EPqWSH26 A3BfJf5ZTUyrp5.FtygkIabo6tNJ6XdI9wBL3Kq6gTXJZf0MIM.xr5s_Ds3o XQkQqhAyMRuCdRav_oXUVKlPpANLdtBtoWshBDr5dNIndK4MVHB4rd2CZAGv 7TR.zvdP8TZU_UzuZhIO2_yLZo1qpo2Mf61sUXucBxUOrc.faF5Lu8A5pXUe SqOpQa.fDqzf9VqiJhW1bOHKqBu2kDsaMV.fg_3ncU5pzmoE- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-oi0-f48.google.com with SMTP id p188so113685709oih.2 for ; Thu, 07 Apr 2016 13:47:45 -0700 (PDT) X-Gm-Message-State: AD7BkJKkOAao2o3hR1iIrc4+9FRn7MDQ3yPJ8O4A/tWeC0TSKjlqMWPDBtOwFadPZjmczEtiUE26j2Ln/c7hoQ== X-Received: by 10.157.3.111 with SMTP id 102mr2647849otv.180.1460062064705; Thu, 07 Apr 2016 13:47:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.42.133 with HTTP; Thu, 7 Apr 2016 13:47:25 -0700 (PDT) From: mike amundsen Date: Thu, 7 Apr 2016 16:47:25 -0400 X-Gmail-Original-Message-ID: Message-ID: To: t2trg@irtf.org Content-Type: multipart/alternative; boundary=94eb2c047272b799f1052feb30b4 Archived-At: Subject: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:47:48 -0000 --94eb2c047272b799f1052feb30b4 Content-Type: text/plain; charset=UTF-8 This is a follow up on the convo today at IET around draft-keranen-t2trg-rest-iot-01. Rather than casting IoT style guidance as a copy of (some or all) of REST, I suggest we create IoT-specific architectural style guidance. REST is the style used to describe WWW, not IoT. To do this, I suggest we identify System Properties and Constraints to induce them. This is what Fielding describes in chapter 2[1] as his method of developing the REST style from chapter 5[2]. This would change the document from a description of Fielding's REST to a description of An IoT Architectural Style. Of course, it is likely that some (many?) of Fielding System Properties are compatible w/ IoT. But some may not and creating an IoT specific style will reduce the occurrences of discussions on whether IoT is "RESTful" [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm [2] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm mamund Mike Amundsen +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund --94eb2c047272b799f1052feb30b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a follow up on the convo today at IET around draft= -keranen-t2trg-rest-iot-01.

Rather than casting IoT styl= e guidance as a copy of (some or all) of REST, I suggest we create IoT-spec= ific architectural style guidance. REST is the style used to describe WWW, = not IoT.

To do this, I suggest we identify System = Properties and Constraints to induce them.=C2=A0 This is what Fielding desc= ribes in chapter 2[1] as his method of developing the REST style from chapt= er 5[2].

This would change the document from a des= cription of Fielding's REST to a description of An IoT Architectural St= yle. Of course, it is likely that some (many?) of Fielding System Propertie= s are compatible w/ IoT. But some may not and creating an IoT specific styl= e will reduce the occurrences of discussions on whether IoT is "RESTfu= l"


--94eb2c047272b799f1052feb30b4-- From nobody Thu Apr 7 13:58:09 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007B512D55A for ; Thu, 7 Apr 2016 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdTF-2c3N_KU for ; Thu, 7 Apr 2016 13:58:04 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCA712D65D for ; Thu, 7 Apr 2016 13:58:03 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-4d-5706c9d959e8 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BD.4F.23401.9D9C6075; Thu, 7 Apr 2016 22:58:02 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.248.2; Thu, 7 Apr 2016 22:58:01 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D972F510C6; Fri, 8 Apr 2016 00:01:37 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0BA704E9B6; Fri, 8 Apr 2016 00:01:35 +0300 (EEST) To: Hannes Tschofenig , Mohit Sethi References: <5706C210.6060902@gmx.net> From: Mohit Sethi Message-ID: <5706C9D5.6060304@ericsson.com> Date: Thu, 7 Apr 2016 17:57:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5706C210.6060902@gmx.net> Content-Type: multipart/alternative; boundary="------------080609070805090500010607" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7qO6tk2zhBu/62SyW7rzHavH+QQ+L A5PH4k372TwmbzzMFsAUxWWTkpqTWZZapG+XwJVx/YVPwVzxikONSxgbGK8JdTFyckgImEjs 3drDBGGLSVy4t56ti5GLQ0jgCKPE4h+drBDOVkaJ1133GSGcdYwSj1Z8ZoJw5jNKvPk3gxGk X1hARaJh+hQgm4NDRCBW4soxYZCwkICaRPOfM8wgNrOAqsTUQ/dYQGw2AT2JznPHweK8AtoS Ky81go1hARrzZvYCMFtUIELiydyTjBA1ghInZz4B6+UUUJdonngHamaYxMSph9khXlCTuHpu EzPEXnWJrR0HGCcwCs9C0j4LScssoEuZBewlHmwtgwjLS2x/O4cZwtaXuH7nPitMvHnrbOYF jGyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQLj5OCW31Y7GA8+dzzEKMDBqMTDq7CfNVyI NbGsuDL3EKMEB7OSCO/s42zhQrwpiZVVqUX58UWlOanFhxilOViUxHlzIv+FCQmkJ5akZqem FqQWwWSZODilGhh5zvuKMc397Khjfehq2P7S5Jce+uVOu237lDnrKot22H+2Cb70Yc0tlexH L5yDF0tfrrbhsV/8/7Oy3enZFdVSWhHVKmHVW/6b3yrOXZBww1Mn3UWu6eaydpHcuEcbjLeb 73jVm87gmzqBmevUpJMSzWuFTf59SsqojCjeN0nB+u2mC9ennVNiKc5INNRiLipOBABXgOba jwIAAA== Archived-At: Cc: "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:58:08 -0000 --------------080609070805090500010607 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi As my slides pointed out, there are a bunch of definitions for both bootstrapping as well device identity. If anyone wants to point to different interpretations on the list, we will be happy to discuss them in the survey draft. The draft does not intend to select one definition over the other. Perhaps we don't want to get bogged down in the discussion on the philosophical differences between identifier and identity etc. and rather consider the practical use of identifiers. Regards Mohit On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: > In his presentation Mohit used the term 'Device Identity'. > > I have heard this term in various conversation over the past few years > and I have the fear that there are different interpretations what it means. > > What does it mean for you, Mohit? > > Ciao > Hannes > > > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg --------------080609070805090500010607 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi

As my slides pointed out, there are a bunch of definitions for both bootstrapping as well device identity. If anyone wants to point to different interpretations on the list, we will be happy to discuss them in the survey draft. The draft does not intend to select one definition over the other. Perhaps we don't want to get bogged down in the discussion on the philosophical differences between identifier and identity etc. and rather consider the practical use of identifiers.

Regards
Mohit

On 04/07/2016 05:24 PM, Hannes Tschofenig wrote:
In his presentation Mohit used the term 'Device Identity'.

I have heard this term in various conversation over the past few years
and I have the fear that there are different interpretations what it means.

What does it mean for you, Mohit?

Ciao
Hannes



_______________________________________________
T2TRG mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

--------------080609070805090500010607-- From nobody Thu Apr 7 14:22:16 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7093012D718 for ; Thu, 7 Apr 2016 14:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BABqO6M8oSgH for ; Thu, 7 Apr 2016 14:22:06 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E142F12D191 for ; Thu, 7 Apr 2016 14:22:05 -0700 (PDT) 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.266.1; Thu, 7 Apr 2016 23:21:56 +0200 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.0266.001; Thu, 7 Apr 2016 23:22:02 +0200 From: "Kovatsch Matthias" To: mike amundsen , "t2trg@irtf.org" Thread-Topic: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? Thread-Index: AQHRkQ7D+PuWV3871Uy6thSY1mIeTZ9+/3Wd Date: Thu, 7 Apr 2016 21:22:01 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54F187B18@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: [31.133.154.53] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54F187B18MBX110dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:22:12 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54F187B18MBX110dethzch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Mike > Rather than casting IoT style guidance as a copy of (some or all) of REST= , I suggest we create > IoT-specific architectural style guidance. REST is the style used to desc= ribe WWW, not IoT. Here I disagree: REST is a style for networked software that was derived fr= om the Web and idealized. Large parts of the Web do not even follow the con= straints (see all the "RESTful API" that are more like RPC over HTTP). So, = REST was already a step toward what you are recommending. > To do this, I suggest we identify System Properties and Constraints to in= duce them. This is what > Fielding describes in chapter 2[1] as his method of developing the REST s= tyle from chapter 5[2]. > This would change the document from a description of Fielding's REST to a= description of An IoT > Architectural Style. Of course, it is likely that some (many?) of Fieldin= g System Properties are > compatible w/ IoT. But some may not and creating an IoT specific style wi= ll reduce the occurrences > of discussions on whether IoT is "RESTful" A Problem is that many of Fielding's concepts are misunderstood or used inc= orrectly to cut corners. We want to make sure they are used correctly, sinc= e we also see them useful for the IoT. We do not want to fight religiously = about "RESTful or not RESTful"; we want to help, so that the useful pieces = are used correctly (and are actually useful). Yet I agree that some things are different in the IoT and that those need t= o be reflected in the document. We decided on a "two step program" here: Fi= rst create a common understanding of "REST as we use it" and then progress = to "Beyond REST". Since CoRE and the T2TRG somewhat dedicated themselves to adopt the REST st= yle to the IoT, we do not want to start from scratch and come up with a new= style. As feedback for us, may I paraphraze your mail maybe as "do it a bi= t less by the book" (i.e., Roy's thesis) and focus a bit more on the curren= t situation (which, for instance, includes using the language that has beco= me common today; cf. Bob's comment in the T2TRG session)? Best regards Matthias --_000_55877B3AFB359744BA0F2140E36F52B54F187B18MBX110dethzch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Mike

> Rather than casting IoT style guidance as a copy of (some or all)= of REST, I suggest we create
> IoT-specific architectural style guidance. REST is the style used to d= escribe WWW, not IoT.

Here I= disagree: REST is a style for networked software that was derived from the Web and idealized. Large parts of the Web do not even follow the constraints (see all the "RESTful API" th= at are more like RPC over HTTP). So, REST was alread= y a step toward what you are recommending.

> To do this, I suggest we identify System Properties and Constrain= ts to induce them.  This is what
> Fielding describes in chapter 2[1] as his method of developing the RES= T style from chapter 5[2].

> This would change the document from a description of Fielding's R= EST to a description of An IoT
> Architectural Style. Of course, it is likely that some (many?) of Fiel= ding System Properties are
> compatible w/ IoT. But some may not and creating an IoT specific style= will reduce the occurrences
> of discussions on whether IoT is "RESTful"

A Problem is that many of Fielding's concepts are misundersto= od or used incorrectly to cut corners. We want to make sure they are used c= orrectly, since we also see them useful for the IoT. We do not want to figh= t religiously about "RESTful or not RESTful"= ; we want to help, so that th= e useful pieces are used correctly (and are actually= useful).

Yet I agree that some th= ings are different in the IoT and that those need to= be reflected in the document. We decided on a "two ste= p program" here: First create a common understanding of "REST as = we use it" and then progress to "Beyond REST".

Since CoRE and the T2TRG somewhat dedicated themselv= es to adopt the REST style to the IoT, we do not want to start from scratch and come up with a new style. As feedback for us, may = I paraphraze your mail maybe as "do it a bit less by the book" (i.e., Roy's thesis) an= d focus a bit more on the current situation (which, for instance, includes using the language that has become common today; cf.= Bob's comment in the T2TRG session)?

Best regards
Matthias


--_000_55877B3AFB359744BA0F2140E36F52B54F187B18MBX110dethzch_-- From nobody Thu Apr 7 14:33:07 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2660D12D191 for ; Thu, 7 Apr 2016 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-5n-Aa922Jc for ; Thu, 7 Apr 2016 14:33:04 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC66112D10C for ; Thu, 7 Apr 2016 14:33:03 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:e16a:7c4a:cb7e:d55a]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7BC6CA80DD; Thu, 7 Apr 2016 23:32:59 +0200 (CEST) Message-ID: <5706D208.1090606@tzi.org> Date: Thu, 07 Apr 2016 18:32:56 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: mike amundsen References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: t2trg@irtf.org Subject: Re: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:33:06 -0000 Hi Mike, thank you for your input. The Internet/Web of Things can very much be part of the greater Web (as long as that is not equated to the Browser Web), but you are right that not all of the constraints described by Fielding apply or are even possible. E.g., the use of mobile code on the Web of Things is currently not a mainstream approach. Since the IoT needs to be secure, we also need better ways to include caches than are available in HTTP(S). Indeed, an objective of the work here is to describe a form of REST that is appropriate for IoT. This requires us to find out what parts of REST work (and are beneficial!) for the IoT and which parts aren't or need to be modified. In CoRE, we already have added notifications to the CoAP protocol; this goes beyond REST as originally defined. One other use of a document describing the use of REST in the IoT (WoT) is that it can be used to create awareness that the REST style (appropriately adapted) can be beneficial in the IoT. Exercise for the reader: find a good name for the IoT-adapted variant of REST. Grüße, Carsten From nobody Thu Apr 7 15:30:31 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2CF12D169 for ; Thu, 7 Apr 2016 15:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH8tnWFvS9_r for ; Thu, 7 Apr 2016 15:30:28 -0700 (PDT) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (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 2588212D154 for ; Thu, 7 Apr 2016 15:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460068227; bh=axv5oIZ9uUJ0bBTtQoyohY7ov/VS3gQZkOWZAnbhYVg=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=nwfoEEcNyz+5ukM49HymIiKn6pSzKCCHDuOjIWtFScv2tdjAZLG5BpY2v8+aAXMJzIxvi9QMJ55SLE1g5qnN6CGMAUkKhfpTecCgDPZg87CoO2goN1vXcOd4bVOuwhnmaVjdjgMtRIekaio8bcTLfkquzFpYVfCc4jsvCCXY43MPd6ObuKgTPlImArXJtkzh34NrcCoA3YMF8hB8+N4hz8TAcCEB8XZtJjEobBQraEZONInKJtemw8MDJaHZ1AnESkdPlBUIY7bDNzDJPuGaNULMbawpTvU/ghFahU6EN3bSfI9KNwx2jt2Ax/Owam9/pq4a0KWhekp29sPv34ZSkQ== Received: from [98.138.100.116] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 22:30:27 -0000 Received: from [98.138.104.112] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 22:30:27 -0000 Received: from [127.0.0.1] by smtp221.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 22:30:27 -0000 X-Yahoo-Newman-Id: 268020.99448.bm@smtp221.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9lNimzYVM1k4RpOuD8nyYloNqqhEzsf6g4epyBN_wRwBAiP 8AF9c.0nC0V_KOd_HW3qliucUSuI.AoKvamhdabz.aK63c4Qqzirl.VR4lJX .qcSJBqVPAYxEwnzFkglDQ2d60tVQ0v2zGJfHBhEDcJ_nebobL0LvLZFa93M LKVawMl61KYV2ojQ5ixueVdi_5l88kmYroz_CDDS8tBEYuNhXvbTVtX9fmcC GEYtzCgSg1TnjXTJqJ6253IRfCevUOxo4BZc4sG5wS8Z6oyTKhYR4YYEOdlm wHbHxidtBpotWQl3HFHIW9Z8pFyLjr3DaxUczzewy75_oug6bv3lMA.Zo.CA BJkL04_ZjUjaKu6.Jya8p68G57GhyX8nkxDuwHlIms_l4CgCfJ1LroWRyV8_ vRTPY9TksrzG0seUVwIcatcLwLaxzoemE2eHKj.Euu6NaChD5vhM4ZAsUZ4X IPeBSivbllEgkdVlzWLXSRqJvjrsEVc.W8_taXmkl2lNlOZirXFt.drs9urQ 7yu3erWWoDWuGLOUFHFup_12KKYM5vdE4cTR0qPxyoLp5rsw- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-oi0-f50.google.com with SMTP id w85so116839164oiw.0 for ; Thu, 07 Apr 2016 15:30:27 -0700 (PDT) X-Gm-Message-State: AD7BkJKPMEih5MRNhFA1KbjwVZ9i8AePAwjUyIsgiy1A6H+jhbCis754BWOB0C4OomFxKFWpACpT078VqW9Diw== X-Received: by 10.157.13.53 with SMTP id 50mr2909064oti.35.1460068226642; Thu, 07 Apr 2016 15:30:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.42.133 with HTTP; Thu, 7 Apr 2016 15:30:07 -0700 (PDT) In-Reply-To: <5706D208.1090606@tzi.org> References: <5706D208.1090606@tzi.org> From: mike amundsen Date: Thu, 7 Apr 2016 18:30:07 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c15990ff5036052fec9f0c Archived-At: Cc: t2trg@irtf.org Subject: Re: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:30:30 -0000 --001a11c15990ff5036052fec9f0c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carsten/Kovatsch: First, fine session today in the t2trg room. thanks for that. Now, I am not suggesting we NOT adopt *any* of Fielding's Constraints (there are ten[1] to consider). But we should keep in mind that the ten *requirements* (think 2119 words) he selected are based on the 16 Architectural Properties of Key Interest [2] Fielding identified in Chapter 2. IoT might not share all those desireable properties and some IoT ones might be missing from Fielding's WWW-inspired list. As a simple exercise, we can tick down the list of ten Constraints and see what 2119 words we want to invoke in our guidance document. here's my straw-man: *** Applying Fielidng's Constraints to IoT using RFC2119 Words *** Client-Server : MAY Stateless : SHOULD Cache : MUST Uniform Interface : MUST Identification of Resources : MUST Manipulation of Resources through Representations : MUST Self-Describing Messages : SHOULD Hypermedia as the Engine of App State : MAY Layered System : MUST Code-On-Demand : MAY Now, rather than say "is it RESTful" we can look at this list and start asking about the value of each of these ten constraints when it comes to IoT. Even more important, I suspect that there are constraints *missing* from this list that would be important to IoT. And we haven't even started on the list of Properties of Key Interest for IoT. BTW - naming is fun. I toss out IoTA for Internet of Things Architecture Cheers. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec= _5_1 [2] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_= 3 mamund Mike Amundsen +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Thu, Apr 7, 2016 at 5:32 PM, Carsten Bormann wrote: > Hi Mike, > > thank you for your input. > The Internet/Web of Things can very much be part of the greater Web (as > long as that is not equated to the Browser Web), but you are right that > not all of the constraints described by Fielding apply or are even > possible. E.g., the use of mobile code on the Web of Things is > currently not a mainstream approach. Since the IoT needs to be secure, > we also need better ways to include caches than are available in HTTP(S). > > Indeed, an objective of the work here is to describe a form of REST that > is appropriate for IoT. This requires us to find out what parts of REST > work (and are beneficial!) for the IoT and which parts aren't or need to > be modified. In CoRE, we already have added notifications to the CoAP > protocol; this goes beyond REST as originally defined. > > One other use of a document describing the use of REST in the IoT (WoT) > is that it can be used to create awareness that the REST style > (appropriately adapted) can be beneficial in the IoT. > > Exercise for the reader: find a good name for the IoT-adapted variant of > REST. > > Gr=C3=BC=C3=9Fe, Carsten > --001a11c15990ff5036052fec9f0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carsten/Kovatsch:

First,= fine session today in the t2trg room. thanks for that.

Now, = I am not suggesting we NOT adopt *any* of Fielding's Constraints (there= are ten[1] to consider). But we should keep in mind that the ten *requirem= ents* (think 2119 words) he selected are based on the 16 Architectural Prop= erties of Key Interest [2] Fielding identified in Chapter 2. IoT might not = share all those desireable properties and some IoT ones might be missing fr= om Fielding's WWW-inspired list. =C2=A0

As a s= imple exercise, we can tick down the list of ten Constraints and see what 2= 119 words we want to invoke in our guidance document.=C2=A0

<= /div>
here's my straw-man:

*** Applying Fi= elidng's Constraints to IoT using RFC2119 Words ***
Client-Se= rver : =C2=A0MAY=C2=A0
Stateless : SHOULD
Cache : MUST<= /div>
Uniform Interface : MUST
Identification of Resources : = MUST
Manipulation of Resources through Representations : MUST
Self-Describing Messages : SHOULD
Hypermedia as the Engine= of App State : MAY
Layered System : MUST
Code-On-Deman= d : MAY

Now, rather than say "is it RESTful&q= uot; we can look at this list and start asking about the value of each of t= hese ten constraints when it comes to IoT. Even more important, I suspect t= hat there are constraints *missing* from this list that would be important = to IoT.

And we haven't even started on the lis= t of Properties of Key Interest for IoT.

BTW - nam= ing is fun. I toss out IoTA for Internet of Things Architecture<G>

Cheers.

=C2=A0


On Thu, Apr 7, 2016 at 5:32 PM, Carsten Borm= ann <cabo@tzi.org> wrote:
Hi Mi= ke,

thank you for your input.
The Internet/Web of Things can very much be part of the greater Web (as
long as that is not equated to the Browser Web), but you are right that
not all of the constraints described by Fielding apply or are even
possible.=C2=A0 E.g., the use of mobile code on the Web of Things is
currently not a mainstream approach.=C2=A0 Since the IoT needs to be secure= ,
we also need better ways to include caches than are available in HTTP(S).
Indeed, an objective of the work here is to describe a form of REST that is appropriate for IoT.=C2=A0 This requires us to find out what parts of RE= ST
work (and are beneficial!) for the IoT and which parts aren't or need t= o
be modified.=C2=A0 In CoRE, we already have added notifications to the CoAP=
protocol; this goes beyond REST as originally defined.

One other use of a document describing the use of REST in the IoT (WoT)
is that it can be used to create awareness that the REST style
(appropriately adapted) can be beneficial in the IoT.

Exercise for the reader: find a good name for the IoT-adapted variant of REST.

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

--001a11c15990ff5036052fec9f0c-- From nobody Thu Apr 7 15:48:48 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C971E12D118 for ; Thu, 7 Apr 2016 15:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IxQpNobQhyg for ; Thu, 7 Apr 2016 15:48:44 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F69812D15D for ; Thu, 7 Apr 2016 15:48:44 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c20so63926542pfc.1 for ; Thu, 07 Apr 2016 15:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=/YuWmYuGX6Fi+tw2YVOMkiR++b3jreAN1LLYVg3VOdQ=; b=mQdFtgfylabEiw1Z/sBu8T+iHPuVjk+/lvDqMClgx4Q048oDyBkdxi6xp8yGEd7oUe tm1sG/JD4QT5+mB5JpsPoO20tBd1tdgHxbb2fAcphlJTL88FVsJVJMPGw8Lz7iDGxo3E BXxEk57UXj9xnMvH4X6J1LIqv0evlZGm8L6C+tfRA3+GbJsdxsfxJMVGT6ZZDZX50+St xe3YZdt3+KnETCzJo+3IJayODbOsPvQB+5HqjjV3efBzEh62fSlREIoHESduDxTkGnvd tnv9vbMMmPxlJSZ7UcwrDNN8qlj6a3ChOf06YdzD0H/fhjjmiqtgGls7JjlOPLYR48HZ l22Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/YuWmYuGX6Fi+tw2YVOMkiR++b3jreAN1LLYVg3VOdQ=; b=NJIpeag1wT95JNHB6qU3fQO5eSpa93CLoad72C8lFEqVL8ct7eam2SpGArQcQ1Y5s+ IgvleKkZ2U78jjhaMI/q2WV+s/c1EiHzk/q5w20zLAf8lgRpb0lI+WPDji+kSJ8EzC4T sMxPBnIimzUtgl/KlBXLxvy1btUrJrnvA3McgI+SioDiYjh/bXkotfqqRrQwmOO21jTt YUi+nImDWZ+4xFLZWgD5I8WQK14putKLesA5pCpuuKCkwQlZYYjeYxpryla00SYIzaxy ywF+K7xqr8raEh4Rsx3qGv7DcI9dDnwFsA7JTqbTD6wYg6bfwQorNG6wcXVy6X24OFTa 5VUQ== X-Gm-Message-State: AD7BkJJlC9rT8MZeQv0b7uJLio+E1+nbyMdvP2Zh+MWDWDAv/DmtC1WqHlP8CigE9PaqAg== X-Received: by 10.98.8.196 with SMTP id 65mr7895095pfi.53.1460069323880; Thu, 07 Apr 2016 15:48:43 -0700 (PDT) Received: from [172.28.32.119] ([162.246.216.202]) by smtp.gmail.com with ESMTPSA id k65sm14412912pfb.30.2016.04.07.15.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 15:48:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_63DB277A-6FEF-4EEA-AAEE-935719F56A71" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54F187B18@MBX110.d.ethz.ch> Date: Thu, 7 Apr 2016 15:48:41 -0700 Message-Id: References: <55877B3AFB359744BA0F2140E36F52B54F187B18@MBX110.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.2104) Archived-At: Cc: mike amundsen , "t2trg@irtf.org" Subject: Re: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:48:47 -0000 --Apple-Mail=_63DB277A-6FEF-4EEA-AAEE-935719F56A71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Can you please copy the original correspondence to the list? This looks = like a very interesting discussion; unfortunately I can't see the = context so don't feel like joining though I have some comments regarding = Fielding's approach and what we can learn. Thanks, Michael > On Apr 7, 2016, at 2:22 PM, Kovatsch Matthias = wrote: >=20 > Dear Mike >=20 > > Rather than casting IoT style guidance as a copy of (some or all) of = REST, I suggest we create > > IoT-specific architectural style guidance. REST is the style used to = describe WWW, not IoT. >=20 > Here I disagree: REST is a style for networked software that was = derived from the Web and idealized. Large parts of the Web do not even = follow the constraints (see all the "RESTful API" that are more like RPC = over HTTP). So, REST was already a step toward what you are = recommending. >=20 > > To do this, I suggest we identify System Properties and Constraints = to induce them. This is what > > Fielding describes in chapter 2[1] as his method of developing the = REST style from chapter 5[2]. >=20 > > This would change the document from a description of Fielding's REST = to a description of An IoT=20 > > Architectural Style. Of course, it is likely that some (many?) of = Fielding System Properties are=20 > > compatible w/ IoT. But some may not and creating an IoT specific = style will reduce the occurrences=20 > > of discussions on whether IoT is "RESTful" >=20 > A Problem is that many of Fielding's concepts are misunderstood or = used incorrectly to cut corners. We want to make sure they are used = correctly, since we also see them useful for the IoT. We do not want to = fight religiously about "RESTful or not RESTful"; we want to help, so = that the useful pieces are used correctly (and are actually useful). >=20 > Yet I agree that some things are different in the IoT and that those = need to be reflected in the document. We decided on a "two step program" = here: First create a common understanding of "REST as we use it" and = then progress to "Beyond REST". >=20 > Since CoRE and the T2TRG somewhat dedicated themselves to adopt the = REST style to the IoT, we do not want to start from scratch and come up = with a new style. As feedback for us, may I paraphraze your mail maybe = as "do it a bit less by the book" (i.e., Roy's thesis) and focus a bit = more on the current situation (which, for instance, includes using the = language that has become common today; cf. Bob's comment in the T2TRG = session)? >=20 > Best regards > Matthias >=20 >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg = --Apple-Mail=_63DB277A-6FEF-4EEA-AAEE-935719F56A71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi,

Can = you please copy the original correspondence to the list? This looks like = a very interesting discussion; unfortunately I can't see the context so = don't feel like joining though I have some comments regarding Fielding's = approach and what we can learn.

Thanks,

Michael

On Apr 7, 2016, at 2:22 PM, Kovatsch Matthias <kovatsch@inf.ethz.ch> wrote:

Dear Mike

> Rather than casting IoT style guidance as a copy of = (some or all) of REST, I suggest we create
> = IoT-specific architectural style guidance. REST is the style used to = describe WWW, not IoT.

Here I = disagree: REST is a style for = networked software that was derived from the Web and idealized. Large parts of the Web do not even follow the constraints = (see all the "RESTful API" that are more like RPC over HTTP). So, = REST was already a step toward what you are = recommending.

> = To do this, I suggest we identify System Properties and Constraints to = induce them.  This is what
> Fielding describes in = chapter 2[1] as his method of developing the REST style from chapter = 5[2].

> = This would change the document from a description of Fielding's REST to = a description of An IoT 
> = Architectural Style. Of course, it is likely that some (many?) of = Fielding System Properties are 
> = compatible w/ IoT. But some may not and creating an IoT specific style = will reduce the occurrences 
> of = discussions on whether IoT is "RESTful"

A Problem is that many of Fielding's concepts are misunderstood or used incorrectly to cut = corners. We want to make sure they are used correctly, since we also see = them useful for the IoT. We do not want to fight religiously about "RESTful or not RESTful"; we want to help, so that the useful = pieces are used correctly (and are actually useful).

=
Yet I agree that some things are different in the IoT and that those need to be reflected in the document. We decided on a "two step = program" here: First create a common understanding of "REST as we use = it" and then progress to "Beyond REST".

Since= CoRE and the T2TRG somewhat dedicated themselves to adopt the REST style to the IoT, = we do not want to start from scratch and = come up with a new = style. As = feedback for us, may I paraphraze your mail maybe as = "do it a bit less by the book" (i.e., Roy's thesis) = and focus a bit more on the current situation (which, for instance, = includes using the language that has become common = today; cf. Bob's comment in the T2TRG session)?

Best regards
Matthias

<= br class=3D"">
_______________________________________________
T2TRG mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

= --Apple-Mail=_63DB277A-6FEF-4EEA-AAEE-935719F56A71-- From nobody Thu Apr 7 16:32:09 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E712012D11E for ; Thu, 7 Apr 2016 16:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH6tV9n1qoal for ; Thu, 7 Apr 2016 16:32:05 -0700 (PDT) Received: from nm17-vm6.bullet.mail.ne1.yahoo.com (nm17-vm6.bullet.mail.ne1.yahoo.com [98.138.91.110]) (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 6596612D59A for ; Thu, 7 Apr 2016 16:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460071924; bh=DFfa++q7XaFzAWbs2q2exv0QUpoIhToiEicXklvy6mY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=qQyl/ZdlVI8zpaFBYj0y2gIL013s/oHTS9lZOXtSxmXHygVpbtEZo49W8dZmbXTs146isBjH7wHbcWqK6xFvsFxC2PXmngZ4ow9fmdgdc+uS+lVfvGxX1wlWSXAD1Q/UG7vyuMKbWXLuFw/0v+lW6jbuSLLvvYzM5W2RAgYoOUCI2igHK1q1bUM2KsGTPX8dEeHmvT6q9pxbyT1TNFaDOIShccMhkxsOEVlE8+qj7R8/27C2+GQjcNsdw6rbOnwyxITZTAAVB1lkJqPB0nLUHxW+QdJ0hG+x6Dypb9OaPTr5ZnwxPtw8ID5zLZy8T9luiHhgCaQFG3BC34Tfe/dyXw== Received: from [98.138.101.131] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 23:32:04 -0000 Received: from [98.138.226.61] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 23:32:04 -0000 Received: from [127.0.0.1] by smtp212.mail.ne1.yahoo.com with NNFMP; 07 Apr 2016 23:31:46 -0000 X-Yahoo-Newman-Id: 723890.47055.bm@smtp212.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: h57SqlIVM1nhI2GHTExo7Gan9ZkwWLm1HvNC37RtBtdLtSn 87cCM49RDuhE8sz5IdFoF25mZhL3_483hk3zMpv_vbfgKqLV1UWUcrIaKB3z pVBSszUh6Vr9.Kpsj1us4je843Jf8G.lwLhJepkE09wzB3LKhox3pVw8zkro MV_k2HRhd58waLLVlE17sYXx3Efh8aPTmjVPvdgZWIe84qqmlR5wplGtO8lC FI38z9U5usC6fUNIICIUCO_atP34u0Pp3Pvfjm0y.QbgIhm7oG7kXCNGQWlJ lOqknRoGth7rt_yDQ796F6MDWshANHpbNgnw0f_Eh3Dba4sysiXzgx7sOhED dl3NTYx9vJX8zkJ0_R7RRWspIvdpHexz0WgWOXxowjtU6lGoAyuoxZJs21Ov kAqxc5duGcO5pPyCX91z5cwycVIuyuyrT6Hff8SnKMRDa6AaJDzeDfW9yvCZ X161y3L6_TldLTzbdyrIyM2vsBCj_NszNaXrwvbrXGovVy1Z6RZ9Ajr7YFnG eOqW2waPqf4thz55YbqlopGSOQBYGlB8- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-oi0-f43.google.com with SMTP id s79so118171701oie.1 for ; Thu, 07 Apr 2016 16:32:04 -0700 (PDT) X-Gm-Message-State: AD7BkJKctM4/Rvh/bbmdHdlufnCs5jM6LRIHSv7iV3ExfjLSpFzaYVHlOIpmRmZZ1BDvTIbamcQNo7wB72SE3g== X-Received: by 10.202.91.135 with SMTP id p129mr2798317oib.19.1460071924241; Thu, 07 Apr 2016 16:32:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.42.133 with HTTP; Thu, 7 Apr 2016 16:31:44 -0700 (PDT) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B54F187B18@MBX110.d.ethz.ch> From: mike amundsen Date: Thu, 7 Apr 2016 19:31:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Michael Koster Content-Type: multipart/alternative; boundary=001a113d4b90644d6b052fed7c48 Archived-At: Cc: Kovatsch Matthias , "t2trg@irtf.org" Subject: Re: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 23:32:08 -0000 --001a113d4b90644d6b052fed7c48 Content-Type: text/plain; charset=UTF-8 Michael: there's not much missing from Matthias' reply but here's the original posting: https://mailarchive.ietf.org/arch/msg/t2trg/m2mscd-sD2gjAwOkt786J9EWHS8 mamund Mike Amundsen +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Thu, Apr 7, 2016 at 6:48 PM, Michael Koster wrote: > Hi, > > Can you please copy the original correspondence to the list? This looks > like a very interesting discussion; unfortunately I can't see the context > so don't feel like joining though I have some comments regarding Fielding's > approach and what we can learn. > > Thanks, > > Michael > > On Apr 7, 2016, at 2:22 PM, Kovatsch Matthias > wrote: > > Dear Mike > > > Rather than casting IoT style guidance as a copy of (some or all) of > REST, I suggest we create > > IoT-specific architectural style guidance. REST is the style used to > describe WWW, not IoT. > > Here I disagree: REST is a style for networked software that was derived > from the Web and idealized. Large parts of the Web do not even follow the > constraints (see all the "RESTful API" that are more like RPC over HTTP). > So, REST was already a step toward what you are recommending. > > > To do this, I suggest we identify System Properties and Constraints to > induce them. This is what > > Fielding describes in chapter 2[1] as his method of developing the REST > style from chapter 5[2]. > > > This would change the document from a description of Fielding's REST to > a description of An IoT > > Architectural Style. Of course, it is likely that some (many?) of > Fielding System Properties are > > compatible w/ IoT. But some may not and creating an IoT specific style > will reduce the occurrences > > of discussions on whether IoT is "RESTful" > > A Problem is that many of Fielding's concepts are misunderstood or used > incorrectly to cut corners. We want to make sure they are used correctly, > since we also see them useful for the IoT. We do not want to fight religiously > about "RESTful or not RESTful"; we want to help, so that the useful > pieces are used correctly (and are actually useful). > > Yet I agree that some things are different in the IoT and that those need > to be reflected in the document. We decided on a "two step program" here: > First create a common understanding of "REST as we use it" and then > progress to "Beyond REST". > > Since CoRE and the T2TRG somewhat dedicated themselves to adopt the REST > style to the IoT, we do not want to start from scratch and come up with a > new style. As feedback for us, may I paraphraze your mail maybe as "do it a > bit less by the book" (i.e., Roy's thesis) and focus a bit more on the > current situation (which, for instance, includes using the language that > has become common today; cf. Bob's comment in the T2TRG session)? > > Best regards > Matthias > > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > > > --001a113d4b90644d6b052fed7c48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael:

there's not much missing f= rom Matthias' reply but here's the original posting:

=


On Thu, Apr 7, 2016 at 6:48 PM, Michael Kost= er <michaeljohnkoster@gmail.com> wrote:
Hi,

Can you please copy the original correspondence to the list? This l= ooks like a very interesting discussion; unfortunately I can't see the = context so don't feel like joining though I have some comments regardin= g Fielding's approach and what we can learn.

T= hanks,

Michael

On Apr 7, 2016, at 2:22 PM, Kov= atsch Matthias <kovatsch@inf.ethz.ch> wrote:

Dear=C2= =A0Mike
=
> Rather than casting IoT style guidance as a copy of (so= me or all) of REST, I suggest we create
> IoT-specific architectural = style guidance. REST is the style used to describe WWW, not IoT.
=
Here= I disagree: REST is a style for networked software that was=C2=A0de= rived from the Web and idealized.=C2=A0= Large parts of the Web do not even follow the constraints (see all the "RESTful API" that are<= span>=C2=A0more like=C2=A0RPC over HTTP). So, REST was already a step toward what you are recommendi= ng.

> To do this, I suggest we identify System Prope= rties and Constraints to induce them.=C2=A0 This is what
> Fielding d= escribes in chapter 2[1] as his method of developing the REST style from ch= apter 5[2].

> This would change the document fr= om a description of Fielding's REST to a description of An IoT=C2= =A0
> Architectural Style. Of course, it is likely that some (= many?) of Fielding System Properties are=C2=A0
> compati= ble w/ IoT. But some may not and creating an IoT specific style will reduce= the occurrences=C2=A0
> of discussions on whether IoT i= s "RESTful"

<= font color=3D"3366FF">A Problem is that many of Fielding&#= 39;s concepts are misunderstood or used incorrectly to cut corners. We want= to make sure they are used correctly, since we also see them useful for th= e IoT. We do not want to fight=C2=A0rel= igiously about "RESTful or not RESTful"; w= e want to help, so that the useful pieces are used correctly (and are actually useful).

=
Yet I agree that=C2=A0some things are different in the IoT and= that those need to be reflected in the document.=C2=A0We decided on a "two step progr= am" here: First create a common understanding of "REST as we use = it" and then progress to "Beyond REST".

Since CoRE an= d the T2TRG somewhat dedicated=C2=A0the= mselves to adopt the REST style to the IoT, we=C2=A0do not want to s= tart from scratch and come up with a new style.=C2=A0As feedback for us,= =C2=A0may I paraphraze your mail maybe= as "do it=C2=A0a bit less by the = book" (i.e., Roy's thesis) and focus a bit more on the current sit= uation (which, for instance, includes=C2=A0using the language that has become common today; cf. Bob's comment = in the T2TRG session)?

Best regards
Matthias

=

_______________________________________= ________
T2TRG mailing list
T2TRG@irtf.org
https://= www.irtf.org/mailman/listinfo/t2trg

<= /blockquote>

--001a113d4b90644d6b052fed7c48-- From nobody Thu Apr 7 23:47:56 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D11112D15A for ; Thu, 7 Apr 2016 23:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f24LxIhpsh1T for ; Thu, 7 Apr 2016 23:47:52 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 B45A312D10A for ; Thu, 7 Apr 2016 23:47:51 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id c126so72719638lfb.2 for ; Thu, 07 Apr 2016 23:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=yOMfQOyuwZcRr1bHk9KuAEQzAq1j0pXyf8iir3TUBoE=; b=OVvug6V0bvY5Km1k4ep7ic7yko2xcENAPXSOWzvIQ7YuwG8hfnDW4YmTpcqnZI52T0 L8ZnYJqZL9kptsmTfyVz6ChoK/gCfngZvjdS9X9Iu3pzPNDYDDMZmo3yoS/3NGPIOhlo xIeiebWAPyf8B7foxhhjDM8OIKWTeBJap+oBUHtU1kEjmiupvY9VSzadDZN80kaZN3/b NMbOwbTcndJWPT6ddMMRe0fLGH2aTAElRWFPNhBFWGF779PGnInkSW9jk/SpgU2YE4BD DYgNtukIzUMkDnuAjDWY99vGFSAUOWByvkQVf6oap/adr45bcWJVRZ63FQVmBIwNZXGo zA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=yOMfQOyuwZcRr1bHk9KuAEQzAq1j0pXyf8iir3TUBoE=; b=b982KGNLqrAL1F/3uZHQT6pDZn9pDU3bIUcJr45nypyThhWKwOTem7ipq8UmPw9s9D Mo+5N6DHvUzvfyXvTBc0iRax8qgAzFgSVypapnbdjqx7OabBuWIcIHmBw2ftyjJLXCKq tzKqzdLbiBu5IDqbJ0EwP0sz8YEdf7G/lwnUlKoyHyens+bVLQg6Dwb97kGUZtCxLtgg 7i3Z9GN0FU7D01Vsd/0fc7desvYf665Qurdksc2Toyt0UDwsB4un/7nv7ohXyg4VwA/7 nVEVSbnVw+Nf6OsrbN3LOWedq6WW1bRlsHIRzzeK5JZG/CnIs4qY/SaeP6K1f3+XXiKk Dftw== X-Gm-Message-State: AD7BkJKqBlE5jRz7xbByn46FUuJgPtqbEvisA7ClJ7ABPLi0YHVQx2DXQmHp8GynhyWfQETU X-Received: by 10.25.79.16 with SMTP id d16mr2456086lfb.73.1460098069731; Thu, 07 Apr 2016 23:47:49 -0700 (PDT) Received: from [192.168.0.167] ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id ai2sm1792198lbc.46.2016.04.07.23.47.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 23:47:48 -0700 (PDT) To: mike amundsen References: <55877B3AFB359744BA0F2140E36F52B54F187B18@MBX110.d.ethz.ch> From: Ludwig Seitz Message-ID: <5707540D.9060304@sics.se> Date: Fri, 8 Apr 2016 08:47:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020302030107060707030202" Archived-At: Cc: "t2trg@irtf.org" Subject: Re: [T2TRG] draft-keranen-t2trg-rest-iot-01 : RESTful? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 06:47:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020302030107060707030202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable > Hi, > > Can you please copy the original correspondence to the list? This look= s > like a very interesting discussion; unfortunately I can't see the cont= ext > so don't feel like joining though I have some comments regarding=20 Fielding's > approach and what we can learn. > > Thanks, > > Michael Mike it seems that gmail classes your mails as spam, which could be the=20 reason why Michael isn't seeing them. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms020302030107060707030202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjA0MDgwNjQ3NDFaMC8GCSqGSIb3DQEJBDEiBCDl3ZuEwC3f KgJ6bx8Ndc86l36HxuAh9dgh5C7YraPhETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQBjmWJUMay9ZYTQIy88gx1l FoJNeJYw6DoBMzSCqI2uB27poqNJZCGOuJYt3jRj1w2Tp5jMaxq1pKwOCdlHK6se/w5MFHIQ qk9QgcwGSXnw9yWG5U6vbZxWQfv4Uhk/blHJ+bZWNVjSxQPSokejOlP9whohNQSgChTaUqk8 6WZ0+ITYzvZPs5J0r3I1ECetxLdKi97k00gjZDxhF0iK0edNHyofDeZ69LIpzUwmikibkS0Z gZCnbEkM3AefDt/sOmezlAazFu6KHXRG8fhtNtQz2f6tIAghvEptKnHYSy1NdgVo0U6aj1Je a2398KvGDVetLqyYgvvueBmti/RDW7GqAAAAAAAA --------------ms020302030107060707030202-- From nobody Fri Apr 8 14:22:23 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963ED12D129 for ; Fri, 8 Apr 2016 14:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDa78QQTpPCP for ; Fri, 8 Apr 2016 14:22:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5986C12D0A8 for ; Fri, 8 Apr 2016 14:22:19 -0700 (PDT) Received: from [192.168.10.140] ([201.177.61.57]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MWT8s-1bHqvs1tyU-00XfAL; Fri, 08 Apr 2016 23:22:15 +0200 To: Mohit Sethi References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57082102.4020301@gmx.net> Date: Fri, 8 Apr 2016 23:22:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5706C9D5.6060304@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JC6wP27lfFP4OJOdqGNv4ckn2BwtmGNL" X-Provags-ID: V03:K0:jqmQNSoLvjG7oBKnsGCpjUbYneusgW2G0ngI/p8xKqXqIXXWeFA DAls7NTrZHFFod9JcaIhqAr/rPPe/TPmVvsP5a4I9PhLA4yF/Nau353n3a07vu5NNQAwlcV AnJcDInYKgGKAsyDiMBBVB+a4AQ2r6uk/4Qsqh88mjVq1PocuKXvxgfZ4DRsjRfrmkDfDXD P36mUdGjXf0nEqT/GIUQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:V9uUed5YdyY=:A19MctDQKV0f+RST9HOcX8 LrOcILi3HAs6N6OvKA/TjrW5lzfFqh8PZxJ437ycJLg1QVWBdppmcPpAMNkaOWoP8UHqWarGF KfRz1P55hi0TU5AkQlJQyco+ulQ+5zQcp2/GBUwkHffeyMxZvlgRka5Gd5CgkD9zQ+js4gsMs RcuA4mibDQPqRVFvR00XJa77RUCtrgB7WLxS5SISaTEZuAbn5OvT70XWn52QMHY+Pxb/YRlsl dY9AkJWfI7lDZAugQGxGNS/f5Vwcl+oL0GfQ0xAQOmiQOhQME6UdwvZi4WOFTl7GpftilEci6 f6jPT0PYyoqgOuN8eL4j66g5eppu4W0sfkRqcwfa+NKkJ4rStpANUdQ8pbNeFCvhV+NWX/WUX zg8reSbjBnwRV+K/nMxDp0O8IchBW53kZPV42XdXpgIO7ADdmbHhqdYcTKP1XDLWTxIBSv/er 17IaylLXN6d9p1PY56YLMEQ2McPB5tsclf0wvv2Bpo1SPwCjnNih1kdSrd2EZQMCgLfR+hWgV m1a/HbrcRhRt+VRPcC/82LhfZhQsdNnEQPSzN79hBoEfTlbBdLwRWgF/DM7X7q4kmWg86psZX YhNqwwWCxG+8TVfEOihMPXqjGpXxrPJ9+i8e5YDJDIIKUoTKpfRCb54pq27v/0ck7XYm1VR6J migQ7CyF7nbo6LIMVzKYsyc0tR9fIzm4SzWK0pvxFTpZ7DuLKg30ee7zh2oVGtrOcl6msQElh E9Sj/t3eNhTzO14aFZQ9BcmquKl7E096bg2XWPQxtSdv2/UVjFjhZ6mp82g= Archived-At: Cc: "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:22:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7JC6wP27lfFP4OJOdqGNv4ckn2BwtmGNL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mohit, there is no definition of device identity (or identity) in your draft . Hence, I am asking. Ciao Hannes PS: Btw, I wrote a document for the ACE working group that gives an overview as well: https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 On 04/07/2016 10:57 PM, Mohit Sethi wrote: > Hi >=20 > As my slides pointed out, there are a bunch of definitions for both > bootstrapping as well device identity. If anyone wants to point to > different interpretations on the list, we will be happy to discuss them= > in the survey draft. The draft does not intend to select one definition= > over the other. Perhaps we don't want to get bogged down in the > discussion on the philosophical differences between identifier and > identity etc. and rather consider the practical use of identifiers.=20 >=20 > Regards > Mohit >=20 > On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: >> In his presentation Mohit used the term 'Device Identity'. >> >> I have heard this term in various conversation over the past few years= >> and I have the fear that there are different interpretations what it m= eans. >> >> What does it mean for you, Mohit? >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> T2TRG mailing list >> T2TRG@irtf.org >> https://www.irtf.org/mailman/listinfo/t2trg >=20 >=20 >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg >=20 --7JC6wP27lfFP4OJOdqGNv4ckn2BwtmGNL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXCCEDAAoJEGhJURNOOiAtAM0H/1yAakKnfxNUwEyogEb2gK9w bp8vw0lbkvEi4Ao7OpK18X4k/rihTlj+9p+PAyT06Q5G7q1W9aVS4GUo5Yc+iLTC p1f1QbK3lCmpZWHVPSt6V9kpmL9OtA2O/72jwalUkZFaorhiJGrCDWqQeZdnWSfT GWRW4HiPoBKxlfp54tnNJDY5L7yu3gKeT5Y7YR28HIKxxlTvV+Ap7zhRDn4y///v 9I2Z8vSuxn1fDmLuSjA/n/iVQi2Z6wpyAuEtXiztB4djzz7uM96E+Dbt4mMG7R5E iozWHOG726LBk7sydxqT3LDYc13lBjl998K6wWmo+Mi7vdT9gfPxsaYa2elZ8iA= =dXzj -----END PGP SIGNATURE----- --7JC6wP27lfFP4OJOdqGNv4ckn2BwtmGNL-- From nobody Sat Apr 9 14:28:53 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C4112D199 for ; Sat, 9 Apr 2016 14:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrwO08-o27Bi for ; Sat, 9 Apr 2016 14:28:49 -0700 (PDT) Received: from nm15-vm3.bullet.mail.ne1.yahoo.com (nm15-vm3.bullet.mail.ne1.yahoo.com [98.138.91.145]) (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 6272B12D195 for ; Sat, 9 Apr 2016 14:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460237334; bh=GyztqH7G0CYYrPZfxAt2YVboLCeJTcX0MZvxh734+/8=; h=From:Date:Subject:To:From:Subject; b=t8d3Mg8Zl7mAyo6qBEO6sGkt3A/iPuJqbGgamDa/6agUt/spNSKe1VYZZNNAcrSIHMXQfMWQ+cfIt6KopXfIjAkIN+OVxFxCYpWQ2DMeCmL4owFTRARKhiHZ+tB0mIlnY12XZFnnxz8bh8mJSoP+ozDqnWJ9ImvYoK7KyYAN/rxvweRJVarQ7om3VDJuL50xpkJkb1bFz5A2c2Ccvo0nAp5wiCM/GU5qXhMb3xSDvvn32L+jZ2B3oG2dFgCBSXjexolBWDmmPCvcHmDbUCTerHZbrLA+Y81O4t5aZeDmZkKgQmp1bjt6bbrcOFEk4Y/MboPMZ2l0MfADy6e2gzvydA== Received: from [98.138.101.132] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 09 Apr 2016 21:28:54 -0000 Received: from [98.138.226.56] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 09 Apr 2016 21:28:48 -0000 Received: from [127.0.0.1] by smtp207.mail.ne1.yahoo.com with NNFMP; 09 Apr 2016 21:28:48 -0000 X-Yahoo-Newman-Id: 743232.18191.bm@smtp207.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZrzlvEwVM1n2JI6iXSL2KjecUHD3U0JQD7xChI8Tid59xss a3sePA2ZcKy0MleQItgE8Ktmx5ylom4O9pW0s0okvdQKjVggpFrkADWPwc0X iy7cWL1cIPHG_zpBewwODvReKEqRiDwckqZSYUI_SNnoxuN9axwt0CvrYbg4 iVcQyR0A9KgOQO3Yv4X2O2kx_7yKy7ri7RQRHAbGuCr66vn2uYzFeLm1SP3V S8cpL27h3wycUN2M5F7ViHumWgI96NduSMSFdllW8NHsirMrIJMUoioylyN3 eIO4gQVfSVqMkM0IrMD5b4Mn8O2ctiu3TIWaE3YK7H9LVzaeCKmBqaOznGq5 .Gvls0MfTpt7Sf8sdWvqcBrhMJkWXpFTQOK_0cPptZ7IxkZDyTkJa.749CdW gD1zTimifKQAQZRNhRva4hTlXLzMGtdml3xuHNr1L.rQeW.eYuaSNPI1rruC acGPpv.xaMkfFq_eauqLvoddfW5mLtQmsamslPcz_4XI.DqRcTbyVKdfOHXz CT4kFFWcKTtBq0LOUtxHSLcgNmXw.iFLFqzE7hv6CM.xNIeTg X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-ob0-f182.google.com with SMTP id fp4so90894654obb.2 for ; Sat, 09 Apr 2016 14:28:47 -0700 (PDT) X-Gm-Message-State: AD7BkJJ2jVwMaGXZQfYyTmM9SZWB3mqRe14W9VIGnxpKx1KO8CH++4r86f+gksuVZNpUt78rt57G5tN7c4cq7g== X-Received: by 10.182.24.104 with SMTP id t8mr6918972obf.1.1460237326357; Sat, 09 Apr 2016 14:28:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.42.133 with HTTP; Sat, 9 Apr 2016 14:28:26 -0700 (PDT) From: mike amundsen Date: Sat, 9 Apr 2016 17:28:26 -0400 X-Gmail-Original-Message-ID: Message-ID: To: t2trg@irtf.org Content-Type: multipart/alternative; boundary=001a11c29c9e2033f2053013ffde Archived-At: Subject: [T2TRG] comments on draft-keranen-t2trg-rest-iot X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 21:28:52 -0000 --001a11c29c9e2033f2053013ffde Content-Type: text/plain; charset=UTF-8 I read through the draft this week and am send along my initial comments for discussion. I like the notion of providing guidance to IoT developers and hope this document can be a cornerstone of that effort. Section 1. Introduction The intro says this document is meant as guidance for designing IoT systems that follow the principles of the REST style but those principles do not appear anywhere in this document nor are the appropriate sections in Fielding's dissertation noted. You come close with the following: "RESTful design facilitates many desirable features for a system, such as good scaling properties." This is where I'd refer to the full set of "Architectural Properties of Key Interest" from the dissertation[0]. I think it is then worthwhile to mention Fielding's requirements[1] (note these are WWW requirements, not IoT requirements) and the constraints [2] he selects to *induce* the properties. The remainder of the document focuses not on archtectural issues, but on protocol issues and is limited in even this area to focusing on HTTP and CoAP. I'm not sure if you want to provide protocol guidance or design guidance and will leave that up to discussion before making any other comments on this part of the doc. Section 2 Terminology - no comment for now Section 3.,1 - no comment Section 3.2 I suggest using the words "client state" and "resource state" in section 3.2 of draft-keranen-t2trg-rest-iot. This more clearly identifies who is responsible for which state elements and avoids discussions about "application" and "session" definitions. Flow control MAY be managed from either the client ("please set this valve to position 3") or the resource server ("According to my configuration data, your client certificate only allows you to do one of the following...") Rather than try to define "session state" as flow control, I think it s better the establish lines of responsibility for client state and resource state. Section 3.3 I suggest the following updated wording for the opening: "Important part of designing a system is to model is as a set of resources which represent the "state of the system." Clients MAY be allowed to modify the state of resources by passing representations to the server (using request bodies). Servers manipulate the state of clients by passing representations of resources (using response bodies)." Section 3.4 I think most of the text here can be removed and replaced with a reference to existing RFCs on URI (e.g. 3986). I think it would also be good guidance to reference RFC7320 ("URI Design and Ownership")[3]. Section 3.5 & 3.6 I think a reference to the relevant RFCs is all that is needed here. Listing methods here runs the risk of becoming outdated as the list of valid methods changes over time. Section 4 I think it's a mistake to call out RFCs here since even media types will have security considerations and we can't know which types are in use (including new types as they are created). I suggest something about "Relavent RFCs" or something here. I appreciate the oppty to comment and look forward to any follow up discussions. thanks. [0] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3 [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1 [2] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1 [3] https://tools.ietf.org/html/rfc7320 mamund Mike Amundsen +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund --001a11c29c9e2033f2053013ffde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I read through the draft this week and am send along = my initial comments for discussion. I like the notion of providing guidance= to IoT developers and hope this document can be a cornerstone of that effo= rt.

Section 1. Introduction
The intro sa= ys this document is meant as guidance for designing IoT systems that follow= the principles of the REST style but those principles do not appear anywhe= re in this document nor are the appropriate sections in Fielding's diss= ertation noted.=C2=A0

You come close with the foll= owing: "RESTful = design facilitates many desirable features for a system, such as good scaling properties.= " This is where I'd refer to the full set of "Architectural P= roperties of Key Interest" from the dissertation[0]. I think it is the= n worthwhile to mention Fielding's requirements[1] (note these are WWW = requirements, not IoT requirements) and the constraints [2] he selects to *= induce* the properties.

The remainder of th= e document focuses not on archtectural issues, but on protocol issues and i= s limited in even this area to focusing on HTTP and CoAP. I'm not sure = if you want to provide protocol guidance or design guidance and will leave = that up to discussion before making any other comments on this part of the = doc.

Section 2 Terminology - no comment for now

Section 3.,1 - no comment

S= ection 3.2
I suggest using the words "client state" and &quo= t;resource state" in section 3.2 of draft-keranen-t2trg-rest-iot. This= more clearly identifies who is responsible for which state elements and av= oids discussions about "application" and "session" defi= nitions.

Flow control MAY be managed from either the cli= ent ("please set this valve to position 3") or the resource serve= r ("According to my configuration data, your client certificate only a= llows you to do one of the following...") Rather than try to define &q= uot;session state" as flow control, I think it s better the establish = lines of responsibility for client state and resource state.

=
Section 3.3
I suggest the following updated wording fo= r the opening:
"Important part of designing a system is to model is= as a set=C2=A0of resources which represent the "state of the system.&= quot; Clients MAY be allowed to modify the state of resources by passing re= presentations to the server (using request bodies). Servers manipulate the = state of clients by passing representations of resources (using response bo= dies)."

Section 3.4
I think most of= the text here can be removed and replaced with a reference to existing RFC= s on URI (e.g. 3986). I think it would also be good guidance to reference R= FC7320 ("URI Design and Ownership")[3].

= Section 3.5 & 3.6
I think a reference to the relevant RFCs is= all that is needed here. Listing methods here runs the risk of becoming ou= tdated as the list of valid methods changes over time.=C2=A0

=
Section 4=C2=A0
I think it's a mistake to call out= RFCs here since even media types will have security considerations and we = can't know which types are in use (including new types as they are crea= ted). I suggest something about "Relavent RFCs" or something here= .

I appreciate the oppty to comment and look forwa= rd to any follow up discussions.

thanks.


--001a11c29c9e2033f2053013ffde-- From nobody Sun Apr 10 05:43:55 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6412D15F for ; Sun, 10 Apr 2016 05:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K0c75N9twen for ; Sun, 10 Apr 2016 05:43:51 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7308612B007 for ; Sun, 10 Apr 2016 05:43:51 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-c9-570a4a85ab01 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.DD.30858.58A4A075; Sun, 10 Apr 2016 14:43:49 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Sun, 10 Apr 2016 14:43:48 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: mike amundsen Thread-Topic: [T2TRG] comments on draft-keranen-t2trg-rest-iot Thread-Index: AQHRkqbSUZzleQBxXEG4Od0MdyjXTZ+DBmwA Date: Sun, 10 Apr 2016 12:43:48 +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: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7h26rF1e4waVHUhaHT7SzW7x/0MPi wOQxeeNhNo9Zsw4zBTBFcdmkpOZklqUW6dslcGV8WDifteChXsXb108YGxjvqHYxcnJICJhI NLw5xAJhi0lcuLeerYuRi0NI4AijxJOr35lAEkICSxglrmysBLHZBOwlJq/5yAhiiwioSKyb /5QNxGYWUJXY/GkqM4gtLGArcWnBBVaIGjuJBxdus0DYRhJLDzWD2SxA9RuXtAH1cnDwAs08 /dofYlWAxO1ZJ5lBwpwCgRJb7/CBhBmBTvt+ag0TxCZxiVtP5jNBnCwgsWTPeWYIW1Ti5eN/ rBC2ksSi25+h6vUkbkydAnWltcSk83uh4toSyxa+BuvlFRCUODnzCcsERvFZSFbMQtI+C0n7 LCTts5C0L2BkXcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGGsHt/w22MH48rnjIUYBDkYl Ht6Eas5wIdbEsuLK3EOMEhzMSiK8Jx24woV4UxIrq1KL8uOLSnNSiw8xSnOwKInzZkf+CxMS SE8sSc1OTS1ILYLJMnFwSjUwehzWXW31zUMr6LDW/JNP9febZc7+1Cd9cU3+qsa2E9u/FE15 zj5JI871wRqVZpPl8U4lfnyKN1jmTf4rfnpLyBUJdq59Asfvn3jj+WDyIcWbzkd4VfsKjTcL xmn7dN1YfWv2Pn01v1knepOv7Zj7wfCOWHMq/zrm2AVTVgqxh52SOF3M3/orQImlOCPRUIu5 qDgRAF0q4aexAgAA Archived-At: Cc: "t2trg@irtf.org" Subject: Re: [T2TRG] comments on draft-keranen-t2trg-rest-iot X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 12:43:54 -0000 Hi Mike, Thanks a lot for your review and comments! Please see inline. > On 09 Apr 2016, at 18:28, mike amundsen wrote: >=20 > I read through the draft this week and am send along my initial comments = for discussion. I like the notion of providing guidance to IoT developers a= nd hope this document can be a cornerstone of that effort. >=20 > Section 1. Introduction > The intro says this document is meant as guidance for designing IoT syste= ms that follow the principles of the REST style but those principles do not= appear anywhere in this document nor are the appropriate sections in Field= ing's dissertation noted.=20 >=20 > You come close with the following: " > RESTful design facilitates many desirable features for a system, such >=20 > as good scaling properties." This is where I'd refer to the full set of "= Architectural Properties of Key Interest" from the dissertation[0]. I think= it is then worthwhile to mention Fielding's requirements[1] > (note these are WWW requirements, not IoT requirements) and the constrai= nts [2] he selects to *induce* the properties. >=20 >=20 > The remainder of the document focuses not on archtectural issues, but on = protocol issues and is limited in even this area to focusing on HTTP and Co= AP. I'm not sure if you want to provide protocol guidance or design guidanc= e and will leave that up to discussion before making any other comments on = this part of the doc. Indeed the requirements and constraints from the Fielding thesis are not ex= plicitly mentioned or discussed in detail in the draft. As discussed in the= other thread, not all requirements apply to same extent for IoT cases. Als= o, we try to keep the information in this draft brief and practical. That s= aid, having a bit more information and pointers on this topic could be appr= opriate; will have a a look at that. And we are open for discussion what is= the right balance here. > Section 2 Terminology - no comment for now >=20 > Section 3.,1 - no comment >=20 > Section 3.2 > I suggest using the words "client state" and "resource state" in section = 3.2 of draft-keranen-t2trg-rest-iot. This more clearly identifies who is re= sponsible for which state elements and avoids discussions about "applicatio= n" and "session" definitions. >=20 > Flow control MAY be managed from either the client ("please set this valv= e to position 3") or the resource server ("According to my configuration da= ta, your client certificate only allows you to do one of the following...")= Rather than try to define "session state" as flow control, I think it s be= tter the establish lines of responsibility for client state and resource st= ate. OK; so that would mean using "client state" instead of "session state". Sou= nds reasonable to me, but I'd like to hear from Matthias and Klaus (and oth= ers). We did already spend quite some time discussing what is the right for= mulation here. > Section 3.3 > I suggest the following updated wording for the opening: > "Important part of designing a system is to model is as a set of resource= s which represent the "state of the system." Clients MAY be allowed to modi= fy the state of resources by passing representations to the server (using r= equest bodies). Servers manipulate the state of clients by passing represen= tations of resources (using response bodies)." Sounds good to me, thanks! > Section 3.4 > I think most of the text here can be removed and replaced with a referenc= e to existing RFCs on URI (e.g. 3986). I think it would also be good guidan= ce to reference RFC7320 ("URI Design and Ownership")[3]. I think we should keep this text here. This is an area where I have seen lo= ts of confusion with some APIs and I think it's worth spending one page for= . Maybe some parts of this could be made more concise; will have a look at = that. But yes, we should add reference to RFC7320. > Section 3.5 & 3.6 > I think a reference to the relevant RFCs is all that is needed here. List= ing methods here runs the risk of becoming outdated as the list of valid me= thods changes over time.=20 Proper used of methods is again one of the practical basics that I've seen = many systems getting wrong and hence I think it would be good to have it he= re, even if it is to large extent identical to RFC 7231 text. If we have on= ly reference, it is likely to be skipped by many readers of the document. B= ut adding a note about the fact that new methods are coming sounds good to = me (could perhaps reference PATCH and/or FETCH?). > Section 4=20 > I think it's a mistake to call out RFCs here since even media types will = have security considerations and we can't know which types are in use (incl= uding new types as they are created). I suggest something about "Relavent R= FCs" or something here. I think references to key RFC sections is more valuable than generic remark= here; again in the spirit of giving brief overview and pointers in this dr= aft. But we should perhaps make it more clear that the list is not exhausti= ve. And have a look at the media types too and add the IoT security conside= rations draft (draft-irtf-t2trg-iot-seccons). > I appreciate the oppty to comment and look forward to any follow up discu= ssions. Thanks again and looking forward to continue discussion on this! Cheers, Ari > thanks. >=20 >=20 > [0] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#= sec_2_3 > [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.h= tm#sec_4_1 > [2] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.h= tm#sec_5_1 > [3] https://tools.ietf.org/html/rfc7320 >=20 > mamund > Mike Amundsen > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://linkedin.com/in/mamund From nobody Tue Apr 12 12:34:42 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A5412D56E for ; Tue, 12 Apr 2016 12:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMLMG6iOc3kw for ; Tue, 12 Apr 2016 12:34:40 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 1A00B12D145 for ; Tue, 12 Apr 2016 12:34:40 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id e190so4082240lfe.1 for ; Tue, 12 Apr 2016 12:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=+6p+K3mwTBFuvNP0Phr5MyYH1Gqcq0R/SkEGUvXgsxc=; b=JoxPCnu+igXL55dkYj78uWO281wCitimLaPK612u8k2C5HdCmAcjGAP/z2eLCjf2pL 78Aiz9sO0BGoHuxyLxNV8DSmo0RnG2O5zPpx+sW6EPQS/KQuWbpWM5L/wqrFaI26PKSu uMc6uGij+AMqlxvRRc4euc592TYuD21NpHoFOELN0r5eD4OdkOX7HO6HFbJQ7L8UE0Zx nSxPs8gvDDFCguNe6QF1E1Lv5mmAYVcE3idwh+jc3vuMm5utImtgUllF4NyZ+wAvTSKL yUZSmmfA45oEWGTF6sHQLEl9NcOU2YyCPJGcSZmrKomfg2A4H1xW6BJjhnacO9ICxea8 V+dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=+6p+K3mwTBFuvNP0Phr5MyYH1Gqcq0R/SkEGUvXgsxc=; b=SchaVOG+5WEgLESctyaSonwjuthaFbuDrrrtEG3juHHxLp4VwK7Uh6wZODSDTfxUcX XIC8oaGUOvEVw3X1aKJGoAESW9Vu+D/zDVSEk/z3b47D9icNPDYpW19667f3eSdzzrKT vTUZrGMMf8zDMoDIPgR05Bzy6wNyBWCw8pqmsrptN29o/Ethd6zhk+zsuJoETE7G/rm2 EsiSrAd9qRX73Lri5TmkQIECCsruC0gLUh72omfZ+t2gF62d2FXdrRi683fTIisPWW4d hJdGQnHOfakmPN1qI5QBCjDvlvwN3xKOsAaR/3wzh+N6gIJ56Fvu4xcwvF+qPojQiFiE zPQQ== X-Gm-Message-State: AOPr4FUVKS3XAZF5lEQe3U6zu0WsMAVsiNepoJdGH9abRKhcRyiHxTere9kciT4yomZ5mrhAy0wKjiaVJooLAg== MIME-Version: 1.0 X-Received: by 10.25.159.3 with SMTP id i3mr1809215lfe.137.1460489678302; Tue, 12 Apr 2016 12:34:38 -0700 (PDT) Received: by 10.112.252.135 with HTTP; Tue, 12 Apr 2016 12:34:38 -0700 (PDT) In-Reply-To: <57082102.4020301@gmx.net> References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> Date: Tue, 12 Apr 2016 14:34:38 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 19:34:42 -0000 Hi Hannes, Thanks for pointing out the ace-overview draft. Having taken a look at it, I don't see a definition of identity there either. I am not sure how much identity is relevant to the secure bootstrapping. Regards, Behcet On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig wrote: > Hi Mohit, > > there is no definition of device identity (or identity) in your draft > . Hence, I am asking. > > Ciao > Hannes > > PS: Btw, I wrote a document for the ACE working group that gives an > overview as well: > https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 > > > On 04/07/2016 10:57 PM, Mohit Sethi wrote: >> Hi >> >> As my slides pointed out, there are a bunch of definitions for both >> bootstrapping as well device identity. If anyone wants to point to >> different interpretations on the list, we will be happy to discuss them >> in the survey draft. The draft does not intend to select one definition >> over the other. Perhaps we don't want to get bogged down in the >> discussion on the philosophical differences between identifier and >> identity etc. and rather consider the practical use of identifiers. >> >> Regards >> Mohit >> >> On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: >>> In his presentation Mohit used the term 'Device Identity'. >>> >>> I have heard this term in various conversation over the past few years >>> and I have the fear that there are different interpretations what it means. >>> >>> What does it mean for you, Mohit? >>> >>> Ciao >>> Hannes >>> >>> >>> >>> _______________________________________________ >>> T2TRG mailing list >>> T2TRG@irtf.org >>> https://www.irtf.org/mailman/listinfo/t2trg >> >> >> >> _______________________________________________ >> T2TRG mailing list >> T2TRG@irtf.org >> https://www.irtf.org/mailman/listinfo/t2trg >> > > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > From nobody Wed Apr 13 03:11:45 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC1E12E44D for ; Wed, 13 Apr 2016 03:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPN0o-BYdtLX for ; Wed, 13 Apr 2016 03:11:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C93A12E444 for ; Wed, 13 Apr 2016 03:11:35 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LbuIK-1bXMMY1ziG-00jHuV; Wed, 13 Apr 2016 12:11:30 +0200 To: sarikaya@ieee.org References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <570E1B51.1070308@gmx.net> Date: Wed, 13 Apr 2016 12:11:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iXrJN3SpLggAfuwcNl6wqQMWiWjERLe2U" X-Provags-ID: V03:K0:o5jP5Z/RDumPwd7uVfh0yDQ0o5cGFlvNky5hKvN0WEerK6ksI6i YfGLWLnPjH1vhu7TLgzHrWyFsWnhS7a2QAtnSEv43+/gR1WzCL7gDX5zp0hsOAc9hfh65XS pcFzGH4OybSID5BZUL1x3Iu8VImE1CvLc6zV23EPQCDJ6fEqBT1sAiSrwcmVb/PqD0PEClQ dRpqoXKAAgOfIk4BcU8ow== X-UI-Out-Filterresults: notjunk:1;V01:K0:ddVCkx1HtOE=:RlmlYE7N1QPsp5x2QY1YMq Ev8bG96Jz4HxWco4TUjCfwOsF4+avmX7wx8o7qNEC9iLyali7lpwVh8tvGMP682KgvOTrY4YL yKgtGuV9iw5lQVlh8s+SBV6vRw6Te8x5Y99Lmp0UbMApBeQyE20oIcdEnraQuQHXeNSXLyZWr L+M3OBLwtd00iJal8hImbbjB9wj/+uh8H3NunJ9n8aXXh+Bwz6OVr1/Y/XRnYpRQX1iBqaldp LPJBXOe0RXeNbu5fmMFfrg0RdR+HndbFZV9/FUcWy7oyB6VPAuLoALVGCe7zOH15w5NPkcdWi Q9Z0xAW0X9YH2LhiXcNCRrNKNaJXQVapFTig0HjbHj14jML6FdFn9w0cEl2oUziq5M9v5C2T0 qrO+lccubobyDWyTCc6IELYlDrA7PUDiQwGvs5WN1loiv/vnEQdb6xjQkpWIGy/Qgd2dkUv+C alpRYarBKzxdrJi1j+e+zujKNR5aCCSYU4d0z6NycK12KFIqpqxkprjtATO3HAN8ZE+39H7t8 hH66FDTMMe7wvesjgSR2ikZGJ6rbw1TqV0qqfgGEpPt+1pdDyIJzrKbeh3/bgy1CHIEhzr8Em GysR2FlXOjDBpyp5hcHGujPIrhS5sba9Uvtrsi9zVGhdg/xG3Ri8zJzOnEd8JAX1Zczidw480 00NKAWtUFCoyC3bmtqObG1HeAZ6+ZHNEfjtQWrMBN/DLV9LixOOhXzDax154fS91Dm/8H9Lu7 H6sPnB+pCZiux/rippGase3h9v064QgoWkr6LheniLwe32UbGvO7NKaQsc8= Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:11:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iXrJN3SpLggAfuwcNl6wqQMWiWjERLe2U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Btw, I noticed that the GBA text from https://tools.ietf.org/html/draft-tschofenig-enroll-next-steps-00 and the text from https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 could help you to get to a survey in draft-sarikaya-t2trg-sbootstrapping much quicke= r. Regarding 'identity' it is hard to say whether it is relevant since it is not defined yet. Mohit mentioned it in his presentation and hence I have been wondering about it. In my discussions it turns out to be useful to distinguish two types of processes: (a) initial establishment of keys and configuration information (b) subsequent provisioning of keys and configuration information The OIC/OCF, for example, uses the term onboarding for (a) and bootstrapping for (b). Some specification consider (a) out of scope and assume that this information is manufacturer provisioned. Ciao Hannes On 04/12/2016 09:34 PM, Behcet Sarikaya wrote: > Hi Hannes, >=20 > Thanks for pointing out the ace-overview draft. > Having taken a look at it, I don't see a definition of identity there e= ither. >=20 > I am not sure how much identity is relevant to the secure bootstrapping= =2E >=20 > Regards, >=20 > Behcet >=20 > On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig > wrote: >> Hi Mohit, >> >> there is no definition of device identity (or identity) in your draft >> . Hence, I am asking. >> >> Ciao >> Hannes >> >> PS: Btw, I wrote a document for the ACE working group that gives an >> overview as well: >> https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 >> >> >> On 04/07/2016 10:57 PM, Mohit Sethi wrote: >>> Hi >>> >>> As my slides pointed out, there are a bunch of definitions for both >>> bootstrapping as well device identity. If anyone wants to point to >>> different interpretations on the list, we will be happy to discuss th= em >>> in the survey draft. The draft does not intend to select one definiti= on >>> over the other. Perhaps we don't want to get bogged down in the >>> discussion on the philosophical differences between identifier and >>> identity etc. and rather consider the practical use of identifiers. >>> >>> Regards >>> Mohit >>> >>> On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: >>>> In his presentation Mohit used the term 'Device Identity'. >>>> >>>> I have heard this term in various conversation over the past few yea= rs >>>> and I have the fear that there are different interpretations what it= means. >>>> >>>> What does it mean for you, Mohit? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> _______________________________________________ >>>> T2TRG mailing list >>>> T2TRG@irtf.org >>>> https://www.irtf.org/mailman/listinfo/t2trg >>> >>> >>> >>> _______________________________________________ >>> T2TRG mailing list >>> T2TRG@irtf.org >>> https://www.irtf.org/mailman/listinfo/t2trg >>> >> >> >> _______________________________________________ >> T2TRG mailing list >> T2TRG@irtf.org >> https://www.irtf.org/mailman/listinfo/t2trg >> --iXrJN3SpLggAfuwcNl6wqQMWiWjERLe2U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXDhtRAAoJEGhJURNOOiAt10AIAI9hWfNPlyN3naFWroVLoau4 MyjBNyk3p73M+ibTYK5Y+ZQghmhzZ0zOnCkahPaD5lAmVY8S5+PjpZaKkDmTqGn0 bR4SjeMHbKQqfGYHzLARCQcp9Lwuc3EhZQ9g25qI+U9tmk1rJ87HBnhjwbIHKAkk vlxV5F+pXMN1LRdJQkbz/GBih48grBYjTZxEsPx7CDGXbyywwbRdf4pbbhwUHLzl lG5HthzTduU3Tvl3gWNGjYwZxmU6IZ765rLXLw/VUu28s2OPRQhVPMAxbK7yuDDi OD5txkt5RhN+gqN7PXjK2fPgZyIB4x/CPmkP+0r/skb4b/abNL/WxrH2Zfv2s10= =BXBv -----END PGP SIGNATURE----- --iXrJN3SpLggAfuwcNl6wqQMWiWjERLe2U-- From nobody Wed Apr 13 04:19:05 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C2F12D7DE for ; Wed, 13 Apr 2016 04:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWcGLifqvcQp for ; Wed, 13 Apr 2016 04:19:00 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984A112DAFC for ; Wed, 13 Apr 2016 04:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11490; q=dns/txt; s=iport; t=1460546339; x=1461755939; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=VPf+mj5YdPt7J21uzL7zhji2MCGr/6YObL7ZWPLQzZY=; b=gQY/4SsQdeYRsx6Y6+u8wjGFdrDudR4AHZZnnuWnv8MIW/kZ/Up94BU1 QBB+BlK+1ppHHM1Iu6heSr3VCgHsAg25Fr+yylZsLYycB2tTOLwIJN9ul 0PKFlmTD77nhYVYBnfEKHeF6L3oM58XwteaT9ruTsusWXSu8lnJdGDa0q E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBABDKg5X/xbLJq1UAQmECn28UhcBC?= =?us-ascii?q?oVsAoIQAQEBAQEBZieEQgEBBAEBARULSwoBEAsYCRYLAgIJAwIBAgEVMAYBDAQ?= =?us-ascii?q?CAgEBiA8DEg6wOpIcAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEimyCQYFUAYMpg?= =?us-ascii?q?lYBBJgIgySBZm2IFoFnhE6DBYVWjydig2k6Ay2JegEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="asc'?scan'208,217";a="635162364" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 11:18:57 +0000 Received: from [10.61.69.239] (ams3-vpn-dhcp1519.cisco.com [10.61.69.239]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3DBIulc000890; Wed, 13 Apr 2016 11:18:56 GMT To: sarikaya@ieee.org, Hannes Tschofenig References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> From: Eliot Lear Message-ID: <570E2B1F.5070006@cisco.com> Date: Wed, 13 Apr 2016 13:18:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7gk90qfhpsbSgLTSThPmLRoSlS1ixaGOF" Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:19:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7gk90qfhpsbSgLTSThPmLRoSlS1ixaGOF Content-Type: multipart/mixed; boundary="xGQ2NrejWojnX02TDuplBNcXXuJWoRUkX" From: Eliot Lear To: sarikaya@ieee.org, Hannes Tschofenig Cc: Mohit Sethi , "t2trg@irtf.org" Message-ID: <570E2B1F.5070006@cisco.com> Subject: Re: [T2TRG] Device Identity References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> In-Reply-To: --xGQ2NrejWojnX02TDuplBNcXXuJWoRUkX Content-Type: multipart/alternative; boundary="------------010501090401000702080801" This is a multi-part message in MIME format. --------------010501090401000702080801 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm a bit new to T2TRG, so please forgive me if this is well trodden grou= nd. The notion of device identity depends on what we mean by a device or thing, if you will. More precisely, how does one determine whether something is a component or a network element unto itself? Must a thing have an IP or 6lopan-based stack? These are surely things this RG has covered. The IEEE does have a standard for device identity, which is IEEE 802.1AR. While it may not be perfect, it is something upon which to build. If I might channel my friend John Strassner for a moment, however, device identity is probably meaningless without some notion of attributes. 802.1AR could cover that ground nicely through constraints. As we presented in several places last week, MUD[1] borrows from AR to make use of constraints. The problem with .AR of course is that it requires at least the basics of a PKI to establish the validity of an identity. There is work in the ANIMA working group to do just that in a bilateral way.[2] The network goal is quite simple: * Identify the element sufficiently to establish an appropriate posture= =2E Someone MUST take responsibility for an element's behavior in that process. In this sense, a possible =E2=80=93 albeit counter-intuitive =E2= =80=93 definition of a thing could be that it is sufficiently robust to provide necessary identity assertion to others, and in particular the network.=20 Otherwise it could be viewed as a component of a thing. Eliot On 4/12/16 9:34 PM, Behcet Sarikaya wrote: > Hi Hannes, > > Thanks for pointing out the ace-overview draft. > Having taken a look at it, I don't see a definition of identity there e= ither. > > I am not sure how much identity is relevant to the secure bootstrapping= =2E > > Regards, > > Behcet > > On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig > wrote: >> Hi Mohit, >> >> there is no definition of device identity (or identity) in your draft >> . Hence, I am asking. >> >> Ciao >> Hannes >> >> PS: Btw, I wrote a document for the ACE working group that gives an >> overview as well: >> https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 >> >> >> On 04/07/2016 10:57 PM, Mohit Sethi wrote: >>> Hi >>> >>> As my slides pointed out, there are a bunch of definitions for both >>> bootstrapping as well device identity. If anyone wants to point to >>> different interpretations on the list, we will be happy to discuss th= em >>> in the survey draft. The draft does not intend to select one definiti= on >>> over the other. Perhaps we don't want to get bogged down in the >>> discussion on the philosophical differences between identifier and >>> identity etc. and rather consider the practical use of identifiers. >>> >>> Regards >>> Mohit >>> >>> On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: >>>> In his presentation Mohit used the term 'Device Identity'. >>>> >>>> I have heard this term in various conversation over the past few yea= rs >>>> and I have the fear that there are different interpretations what it= means. >>>> >>>> What does it mean for you, Mohit? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> _______________________________________________ >>>> T2TRG mailing list >>>> T2TRG@irtf.org >>>> https://www.irtf.org/mailman/listinfo/t2trg >>> >>> >>> _______________________________________________ >>> T2TRG mailing list >>> T2TRG@irtf.org >>> https://www.irtf.org/mailman/listinfo/t2trg >>> >> >> _______________________________________________ >> T2TRG mailing list >> T2TRG@irtf.org >> https://www.irtf.org/mailman/listinfo/t2trg >> > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > --------------010501090401000702080801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

I'm a bit new to T2TRG, so please forgive me if this is well trodden ground.

The notion of device identity depends on what we mean by a device or thing, if you will.=C2=A0 More precisely, how does one determine whet= her something is a component or a network element unto itself?=C2=A0 Must= a thing have an IP or 6lopan-based stack?=C2=A0 These are surely things= this RG has covered.

The IEEE does have a standard for device identity, which is IEEE 802.1AR.=C2=A0 While it may not be perfect, it is something upon whic= h to build.=C2=A0 If I might channel my friend John Strassner for a moment= , however, device identity is probably meaningless without some notion of attributes.=C2=A0 802.1AR could cover that ground nicely through constraints.=C2=A0 As we presented in several places last week, MUD[1= ] borrows from AR to make use of constraints.

The problem with .AR of course is that it requires at least the basics of a PKI to establish the validity of an identity.=C2=A0 There= is work in the ANIMA working group to do just that in a bilateral way.[2]

The network goal is quite simple:
  • Identify the element sufficiently to establish an appropriate posture.

Someone MUST take responsibility for an element's behavior in that process.=C2=A0 In this sense, a possible =E2=80=93 albeit counter-intuitive =E2=80=93 definition of a thing could be that it = is sufficiently robust to provide necessary identity assertion to others, and in particular the network.=C2=A0 Otherwise it could be viewed as a component of a thing.

Eliot

On 4/12/16 9:34 PM, Behcet Sarikaya wrote:
Hi Hannes,

Thanks for pointing out  the ace-overview draft.
Having taken a look at it, I don't see a definition of identity there eit=
her.

I am not sure how much identity is relevant to the secure bootstrapping.

Regards,

Behcet

On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
Hi Mohit,

there is no definition of device identity (or identity) in your draft
<draft-sarikaya-t2trg-sbootstrapping>. Hence, I am asking.

Ciao
Hannes

PS: Btw, I wrote a document for the ACE working group that gives an
overview as well:
https://tools.ietf.org/html/draft-tschofe=
nig-ace-overview-00


On 04/07/2016 10:57 PM, Mohit Sethi wrote:
Hi

As my slides pointed out, there are a bunch of definitions for both
bootstrapping as well device identity. If anyone wants to point to
different interpretations on the list, we will be happy to discuss them
in the survey draft. The draft does not intend to select one definition
over the other. Perhaps we don't want to get bogged down in the
discussion on the philosophical differences between identifier and
identity etc. and rather consider the practical use of identifiers.

Regards
Mohit

On 04/07/2016 05:24 PM, Hannes Tschofenig wrote:
In his presentation Mohit used the term 'Devic=
e Identity'.

I have heard this term in various conversation over the past few years
and I have the fear that there are different interpretations what it mean=
s.

What does it mean for you, Mohit?

Ciao
Hannes



_______________________________________________
T2TRG mailing list
T2TR=
G@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg


_______________________________________________
T2TRG mailing list
T2TR=
G@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg


_______________________________________________
T2TRG mailing list
T2TR=
G@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

_______________________________________________
T2TRG mailing list
T2TR=
G@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg


--------------010501090401000702080801-- --xGQ2NrejWojnX02TDuplBNcXXuJWoRUkX-- --7gk90qfhpsbSgLTSThPmLRoSlS1ixaGOF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXDisfAAoJEIe2a0bZ0nozAuAIANATr42ltZ67rxrOGRb0vLoC orFUmfGgcQ2DjvhmgP2UWgNmqI7gahHBlPaKp/C8dGlWZqBDOlqAjzGLBd7bsnvj 9L6sqzQwBMEEKD89xdAp4WoqZN16weQ0ln331ivAM5pBrjbp6Nw+cS/uI6FAqOPv +JDmO2CFGwj6zRFAHxmKYPNMh/H5iR4OzHZt11d6a2VNxRK3ZndlQNZzd7NPsecW cW3QV/buKQFy2DdMsOzJpGq3DQOIKFVsUHUQpXPELKstz2o8o5q3W+wHHpAmvaiA voduNfQyjKomeYhiwKc37b60V80KAC/NqzlCTXSJPMo9Piq1/ZoWx7+meyJ6Zfc= =toSO -----END PGP SIGNATURE----- --7gk90qfhpsbSgLTSThPmLRoSlS1ixaGOF-- From nobody Wed Apr 13 06:08:57 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0140612DC08 for ; Wed, 13 Apr 2016 06:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ0jmHXyzrej for ; Wed, 13 Apr 2016 06:08:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DAC12D156 for ; Wed, 13 Apr 2016 06:08:53 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1boNPn1YQQ-011WBu; Wed, 13 Apr 2016 15:08:45 +0200 To: Eliot Lear , sarikaya@ieee.org References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <570E44DB.2040305@gmx.net> Date: Wed, 13 Apr 2016 15:08:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570E2B1F.5070006@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7cXFTG3rjiosJIoKgrnK7fmaAubkLXtu2" X-Provags-ID: V03:K0:fE9++qWrcb+D6KKiKmXtDfQe5/5xgAhmbTuXfNgenF6KQhKuqao 1qPMvg9CuorlpaxD+NgPkvoKLw84OwJH25A7yMd02nNCZCANmZqIZmPepOXFXovSSa2sNc5 xyCE59FLPAZR67pwYJR4YrDnbmdC502Hs1rOaz1ucAfojUyW3J+AeHFK/BF2f736xp6xng3 7szu2YDYS5gRJH90Xo4PA== X-UI-Out-Filterresults: notjunk:1;V01:K0:mqT8qyQ9vKk=:NG5P0qXiYmnBG4wY7KNBuy Fu7F6+qLrHVFjiSJYBBXAju+6GimQXuN05pr37Z0TzRIE8dQ3ASh/OGoZF32U9qSTOyoBxgMo RzdOC1v6By8jD7g5Cwoe0JMtQVHhtl4K38Bl3Fpgq2BphR0I3cc5WzpTkClRsl7OA4IsO5Wjc BJmmUTn4UjJbpT+KzQNaIan1vlhXWWLgydA8ebYbeXKJTy4O80Hzf/YRUc03hedtjCRfclwKd XmNHQj2NKtuB5hvj9A5VQa65mJO3FgFT6rl3kB1SCzFQyw6XiMZDJI/IIJOkfMNY02wX4PDpY QE3nuwmKXLTKo7tV/7HSt62YF3CuB8rq9zAPmrLH4BG3jCNnUaqCLw4z0Ivar2YO1X1PoWDDv hWpLmwh0RsPVROzZJqKqj52/r7M9qa4ASfClrbNFTZHIiiUTeXi7KbOPrQy68BT56/pM09O0N +WD5pXH9me86tsIGZ1XFUuCsLA1Y8B0nn/RCC2X4VokKxW7eXnUmCdlnuTMjr8exjJ2HVhXjw P2JHX49xQ+baMwLsldW/2NktKD/NM9VEV+kP2MiuCCZdcohKlm2wVyz9BrEnf4gnCv7Ikkxnf pX6ezJEukSVtPYF4gjPiwgPKRpzMobyUm3vhnMLjmW4StOVqaeFNgr71hGLEovl5/v2YWfCCw 6wxLyarqN5rsep57sJ830MO/e4jyroNwe2Zycon1v71a1PeB4vwoJ7cuzvwsDUsuf0FSPAEQv B13flWXrTCL/P6c9QHUR6yPzhTyBRiOh8oqjy585URGEPfdWXtXWpSi6yzA= Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 13:08:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7cXFTG3rjiosJIoKgrnK7fmaAubkLXtu2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am not sure about the value of IEEE 802.1AR It says: Provision devices with X.509 certificates (either RSA or ECC) and the spec defines a MIB for configuration. It also lists the fields of a certificate and defines the "device identity" in Section 7.2.8 as "This may include the unique device serial number assigned by the manufacturer or any other suitable unique DN value that the issuer prefers." So, it essentially does not say what the identifier is in the certificate= =2E In the context of this discussion I believe it would be better to just say use the term credential instead. Credentials contain identifiers and attributes. If we only want to talk about certificates (which I doubt in the IoT context) then we should just be specific and refer to end entity certificates and trust anchors. Ciao Hannes PS: As we tried to explain in https://tools.ietf.org/html/draft-fossati-core-server-name-id-00 the use of certificates (and specifically the identifiers used in there) raises challenges in some IoT deployments. For this (and other reasons) I am arguing that X.509 certificates are not a good choice of technology for come IoT deployments. On 04/13/2016 01:18 PM, Eliot Lear wrote: > Hi, >=20 > I'm a bit new to T2TRG, so please forgive me if this is well trodden gr= ound. >=20 > The notion of device identity depends on what we mean by a device or > thing, if you will. More precisely, how does one determine whether > something is a component or a network element unto itself? Must a thin= g > have an IP or 6lopan-based stack? These are surely things this RG has > covered. >=20 > The IEEE does have a standard for device identity, which is IEEE > 802.1AR. While it may not be perfect, it is something upon which to > build. If I might channel my friend John Strassner for a moment, > however, device identity is probably meaningless without some notion of= > attributes. 802.1AR could cover that ground nicely through > constraints. As we presented in several places last week, MUD[1] > borrows from AR to make use of constraints. >=20 > The problem with .AR of course is that it requires at least the basics > of a PKI to establish the validity of an identity. There is work in th= e > ANIMA working group to do just that in a bilateral way.[2] >=20 > The network goal is quite simple: >=20 > * Identify the element sufficiently to establish an appropriate postu= re. >=20 > Someone MUST take responsibility for an element's behavior in that > process. In this sense, a possible =96 albeit counter-intuitive =96 > definition of a thing could be that it is sufficiently robust to provid= e > necessary identity assertion to others, and in particular the network. = > Otherwise it could be viewed as a component of a thing. >=20 > Eliot >=20 > On 4/12/16 9:34 PM, Behcet Sarikaya wrote: >> Hi Hannes, >> >> Thanks for pointing out the ace-overview draft. >> Having taken a look at it, I don't see a definition of identity there = either. >> >> I am not sure how much identity is relevant to the secure bootstrappin= g. >> >> Regards, >> >> Behcet >> >> On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig >> wrote: >>> Hi Mohit, >>> >>> there is no definition of device identity (or identity) in your draft= >>> . Hence, I am asking. >>> >>> Ciao >>> Hannes >>> >>> PS: Btw, I wrote a document for the ACE working group that gives an >>> overview as well: >>> https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 >>> >>> >>> On 04/07/2016 10:57 PM, Mohit Sethi wrote: >>>> Hi >>>> >>>> As my slides pointed out, there are a bunch of definitions for both >>>> bootstrapping as well device identity. If anyone wants to point to >>>> different interpretations on the list, we will be happy to discuss t= hem >>>> in the survey draft. The draft does not intend to select one definit= ion >>>> over the other. Perhaps we don't want to get bogged down in the >>>> discussion on the philosophical differences between identifier and >>>> identity etc. and rather consider the practical use of identifiers. >>>> >>>> Regards >>>> Mohit >>>> >>>> On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: >>>>> In his presentation Mohit used the term 'Device Identity'. >>>>> >>>>> I have heard this term in various conversation over the past few ye= ars >>>>> and I have the fear that there are different interpretations what i= t means. >>>>> >>>>> What does it mean for you, Mohit? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> T2TRG mailing list >>>>> T2TRG@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/t2trg >>>> >>>> >>>> _______________________________________________ >>>> T2TRG mailing list >>>> T2TRG@irtf.org >>>> https://www.irtf.org/mailman/listinfo/t2trg >>>> >>> >>> _______________________________________________ >>> T2TRG mailing list >>> T2TRG@irtf.org >>> https://www.irtf.org/mailman/listinfo/t2trg >>> >> _______________________________________________ >> T2TRG mailing list >> T2TRG@irtf.org >> https://www.irtf.org/mailman/listinfo/t2trg >> >=20 >=20 >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg >=20 --7cXFTG3rjiosJIoKgrnK7fmaAubkLXtu2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXDkTcAAoJEGhJURNOOiAtExwH/Ah4nUHWtt3cvTC3IdxLQyo0 XEy8400FLyEBR7GNkyMdqMjjtG5Xlyf+QjGURVf/OIVuRPUOcBj8aqNHyZDMtfnV Pr0AoNmfVGq41UOyZpuvqX44H8Csp0w8Sfz+hvl8dDFZt0ff6cB2AF38ISDeATPm P2Lp+qbIub9XK0aaeALUY1wYCsLfxEXuKseWbuacU1HMI6SIKPC+9NT/6S/A7JAT SBPbQBQbAccK/DLFSpOSOpdI5xq+T3T/hoAPFcSrG620aRKR3ZMnJqYC2/cmDZ6p l+tiOIrn3d1VUl2ac8D8tJl9346yMsH7ZivEOyJU2x38C/S6T4UJluU/3lZ/zMM= =nK0C -----END PGP SIGNATURE----- --7cXFTG3rjiosJIoKgrnK7fmaAubkLXtu2-- From nobody Wed Apr 13 13:12:15 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACFE12E1F9 for ; Wed, 13 Apr 2016 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 125eCDi33ldH for ; Wed, 13 Apr 2016 13:12:13 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 9A1DE12E156 for ; Wed, 13 Apr 2016 13:12:12 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id e190so9031290lfe.1 for ; Wed, 13 Apr 2016 13:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=rQugL6X3tb/3oOq7sCyJshd219TjboaPgaU+ZcGQX7Y=; b=ZqM6nDb0eOhEcZIwbeekeNNO9hNHYcyreDWWhGKqNQtYvTgumvokAj+vzc9SDf1ryI rcBlYjyWDRmWZsHd0d3kUPMgNXwXbdeCbn/lbz+b6yjm86od3n9U7b3NC9rICBc8q1kQ 0ODZ/VAkzHyb50iJ3m6iG99A9AwxvdECmoxE+0w/H1Qg96WLKYiwTqw0CJJ8A7rtnBai wqigYhVzKEzkZxgT6W/0YO+eSYFddgLCUWgrbzYFPCecY//dsyotce+X402wd4iamUbl qr9Zgx6sBtj4pk0cL9VMcjxOWijk89vzeJdCEDgm1F81G565O8oNV+bGROrKi9u5qPVH qtfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=rQugL6X3tb/3oOq7sCyJshd219TjboaPgaU+ZcGQX7Y=; b=mZCHnXdbq8Z4VhGnozNN96f3BhBimCXxlvaFrGCHXFsUZSJBReM1emfCQpbdXvH7iC zNOt92WoWMp2lKaVX7J0Wl+VpefqyH2+CHrgf93F8erO+Iglgu1CNFiQM28z7cRFj6ad ESyphKzxH8sFs8VppsCUiEk1Ex6MAACOncLUicc8hSlcJvVSbncE+D5DA5N0U6gE9ITu dMIXlljvGOhtBAqxt+STQogsDDNMKQmOQtE5UKpIfk5QGmb1vIO7M+66QbZuRbrNInMQ qgcpXXdpcQaKPf0PTxIsK5jgOvoytl8zwn6SJCXT+GL2w24iaDdVb1rwbXeBvOvBYe/A cvNw== X-Gm-Message-State: AOPr4FUksXRn0Mv3roZ9SCXiKRjnGXlzqTLCAEhwkP/36YESXMt6Z64SgWcy5a6aFY2dAzgXxC7CzzDlcqrX4w== MIME-Version: 1.0 X-Received: by 10.25.159.3 with SMTP id i3mr4037941lfe.137.1460578330748; Wed, 13 Apr 2016 13:12:10 -0700 (PDT) Received: by 10.112.252.135 with HTTP; Wed, 13 Apr 2016 13:12:10 -0700 (PDT) In-Reply-To: <570E44DB.2040305@gmx.net> References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> <570E44DB.2040305@gmx.net> Date: Wed, 13 Apr 2016 15:12:10 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" , Eliot Lear Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 20:12:14 -0000 On Wed, Apr 13, 2016 at 8:08 AM, Hannes Tschofenig wrote: > I am not sure about the value of IEEE 802.1AR > +1 Behcet > It says: Provision devices with X.509 certificates (either RSA or ECC) > and the spec defines a MIB for configuration. > > It also lists the fields of a certificate and defines the "device > identity" in Section 7.2.8 as "This may include the unique device serial > number assigned by the manufacturer or any other suitable unique DN > value that the issuer prefers." > > So, it essentially does not say what the identifier is in the certificate= . > > In the context of this discussion I believe it would be better to just > say use the term credential instead. Credentials contain identifiers and > attributes. > > If we only want to talk about certificates (which I doubt in the IoT > context) then we should just be specific and refer to end entity > certificates and trust anchors. > > Ciao > Hannes > > PS: As we tried to explain in > https://tools.ietf.org/html/draft-fossati-core-server-name-id-00 the use > of certificates (and specifically the identifiers used in there) raises > challenges in some IoT deployments. For this (and other reasons) I am > arguing that X.509 certificates are not a good choice of technology for > come IoT deployments. > > On 04/13/2016 01:18 PM, Eliot Lear wrote: >> Hi, >> >> I'm a bit new to T2TRG, so please forgive me if this is well trodden gro= und. >> >> The notion of device identity depends on what we mean by a device or >> thing, if you will. More precisely, how does one determine whether >> something is a component or a network element unto itself? Must a thing >> have an IP or 6lopan-based stack? These are surely things this RG has >> covered. >> >> The IEEE does have a standard for device identity, which is IEEE >> 802.1AR. While it may not be perfect, it is something upon which to >> build. If I might channel my friend John Strassner for a moment, >> however, device identity is probably meaningless without some notion of >> attributes. 802.1AR could cover that ground nicely through >> constraints. As we presented in several places last week, MUD[1] >> borrows from AR to make use of constraints. >> >> The problem with .AR of course is that it requires at least the basics >> of a PKI to establish the validity of an identity. There is work in the >> ANIMA working group to do just that in a bilateral way.[2] >> >> The network goal is quite simple: >> >> * Identify the element sufficiently to establish an appropriate postur= e. >> >> Someone MUST take responsibility for an element's behavior in that >> process. In this sense, a possible =E2=80=93 albeit counter-intuitive = =E2=80=93 >> definition of a thing could be that it is sufficiently robust to provide >> necessary identity assertion to others, and in particular the network. >> Otherwise it could be viewed as a component of a thing. >> >> Eliot >> >> On 4/12/16 9:34 PM, Behcet Sarikaya wrote: >>> Hi Hannes, >>> >>> Thanks for pointing out the ace-overview draft. >>> Having taken a look at it, I don't see a definition of identity there e= ither. >>> >>> I am not sure how much identity is relevant to the secure bootstrapping= . >>> >>> Regards, >>> >>> Behcet >>> >>> On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig >>> wrote: >>>> Hi Mohit, >>>> >>>> there is no definition of device identity (or identity) in your draft >>>> . Hence, I am asking. >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: Btw, I wrote a document for the ACE working group that gives an >>>> overview as well: >>>> https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 >>>> >>>> >>>> On 04/07/2016 10:57 PM, Mohit Sethi wrote: >>>>> Hi >>>>> >>>>> As my slides pointed out, there are a bunch of definitions for both >>>>> bootstrapping as well device identity. If anyone wants to point to >>>>> different interpretations on the list, we will be happy to discuss th= em >>>>> in the survey draft. The draft does not intend to select one definiti= on >>>>> over the other. Perhaps we don't want to get bogged down in the >>>>> discussion on the philosophical differences between identifier and >>>>> identity etc. and rather consider the practical use of identifiers. >>>>> >>>>> Regards >>>>> Mohit >>>>> >>>>> On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: >>>>>> In his presentation Mohit used the term 'Device Identity'. >>>>>> >>>>>> I have heard this term in various conversation over the past few yea= rs >>>>>> and I have the fear that there are different interpretations what it= means. >>>>>> >>>>>> What does it mean for you, Mohit? >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> T2TRG mailing list >>>>>> T2TRG@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/t2trg >>>>> >>>>> >>>>> _______________________________________________ >>>>> T2TRG mailing list >>>>> T2TRG@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/t2trg >>>>> >>>> >>>> _______________________________________________ >>>> T2TRG mailing list >>>> T2TRG@irtf.org >>>> https://www.irtf.org/mailman/listinfo/t2trg >>>> >>> _______________________________________________ >>> T2TRG mailing list >>> T2TRG@irtf.org >>> https://www.irtf.org/mailman/listinfo/t2trg >>> >> >> >> >> _______________________________________________ >> T2TRG mailing list >> T2TRG@irtf.org >> https://www.irtf.org/mailman/listinfo/t2trg >> > From nobody Wed Apr 13 17:55:58 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDDD12E530 for ; Wed, 13 Apr 2016 17:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9AOYe8qgwGz for ; Wed, 13 Apr 2016 17:55:54 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 D502812E526 for ; Wed, 13 Apr 2016 17:55:54 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3E0pwHg026152; Wed, 13 Apr 2016 17:55:47 -0700 Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0a-0016f401.pphosted.com with ESMTP id 226y3kqbh5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2016 17:55:46 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 17:55:45 -0700 Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Wed, 13 Apr 2016 17:55:45 -0700 From: Paul Lambert To: Eliot Lear , "sarikaya@ieee.org" , Hannes Tschofenig Thread-Topic: [T2TRG] Device Identity Thread-Index: AQHRkQuiRYTFps7KpkaQp3o5rD+n/J9/c5SAgAGZGQCABitIAIABB9SAgABu3wA= Date: Thu, 14 Apr 2016 00:55:45 +0000 Message-ID: References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> In-Reply-To: <570E2B1F.5070006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.94.250.30] Content-Type: multipart/alternative; boundary="_000_D334375C8DABCpaulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-14_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604140011 Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 00:55:57 -0000 --_000_D334375C8DABCpaulmarvellcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm a bit new to T2TRG, so please forgive me if this is well trodden ground= . Yes, but new paths should be considered that are not as well traveled. The notion of device identity depends on what we mean by a device or thing,= if you will. More precisely, how does one determine whether something is = a component or a network element unto itself? Must a thing have an IP or 6= lopan-based stack? These are surely things this RG has covered. Addresses should be considered 'attributes' of an entity and not the base = identity. The IEEE does have a standard for device identity, which is IEEE 802.1AR. = While it may not be perfect, it is something upon which to build. If I mig= ht channel my friend John Strassner for a moment, however, device identity = is probably meaningless without some notion of attributes. 802.1AR could c= over that ground nicely through constraints. As we presented in several pl= aces last week, MUD[1] borrows from AR to make use of constraints. The problem with .AR of course is that it requires at least the basics of a= PKI to establish the validity of an identity. There is work in the ANIMA = working group to do just that in a bilateral way.[2] ... 802.11AR is not the right path. A 'key centric' architecture is a better direction (IMHO). Public keys and= ways to create a identifier for a public key are a simple and scaleable st= arting point. Paul The network goal is quite simple: * Identify the element sufficiently to establish an appropriate posture= . Someone MUST take responsibility for an element's behavior in that process.= In this sense, a possible - albeit counter-intuitive - definition of a th= ing could be that it is sufficiently robust to provide necessary identity a= ssertion to others, and in particular the network. Otherwise it could be v= iewed as a component of a thing. Eliot On 4/12/16 9:34 PM, Behcet Sarikaya wrote: Hi Hannes, Thanks for pointing out the ace-overview draft. Having taken a look at it, I don't see a definition of identity there eithe= r. I am not sure how much identity is relevant to the secure bootstrapping. Regards, Behcet On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig wrote: Hi Mohit, there is no definition of device identity (or identity) in your draft . Hence, I am asking. Ciao Hannes PS: Btw, I wrote a document for the ACE working group that gives an overview as well: https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 On 04/07/2016 10:57 PM, Mohit Sethi wrote: Hi As my slides pointed out, there are a bunch of definitions for both bootstrapping as well device identity. If anyone wants to point to different interpretations on the list, we will be happy to discuss them in the survey draft. The draft does not intend to select one definition over the other. Perhaps we don't want to get bogged down in the discussion on the philosophical differences between identifier and identity etc. and rather consider the practical use of identifiers. Regards Mohit On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: In his presentation Mohit used the term 'Device Identity'. I have heard this term in various conversation over the past few years and I have the fear that there are different interpretations what it means. What does it mean for you, Mohit? Ciao Hannes _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg --_000_D334375C8DABCpaulmarvellcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1C7D16CEFEDAB5409A840EF1DF4A9EEB@marvell.com> Content-Transfer-Encoding: quoted-printable





I'm a bit new to T2TRG, so please forgive me if this is well trodden ground= .
Yes, but new paths should be considered that are not as well traveled.=



The notion of device identity depends on what we mean by a device or thing,= if you will.  More precisely, how does one determine whether somethin= g is a component or a network element unto itself?  Must a thing have = an IP or 6lopan-based stack?  These are surely things this RG has covered.
Addresses should be considered 'attributes’  of an entity a= nd not the base identity.



The IEEE does have a standard for device identity, which is IEEE 802.1AR.&n= bsp; While it may not be perfect, it is something upon which to build. = ; If I might channel my friend John Strassner for a moment, however, device= identity is probably meaningless without some notion of attributes.  802.1AR could cover that ground nicely th= rough constraints.  As we presented in several places last week, MUD[1= ] borrows from AR to make use of constraints.

The problem with .AR of course is that it requires at least the basics of a= PKI to establish the validity of an identity.  There is work in the A= NIMA working group to do just that in a bilateral way.[2]

 … 802.11AR is not the right path.

A ‘key centric’ architecture is a better direction (IMHO).=  Public keys and ways to create a identifier for a public key are a s= imple and scaleable starting point.  

Paul




The network goal is quite simple:
  • Identify the element sufficiently to establish an appropriate posture. =

Someone MUST take responsibility for an element's behavior in that proce= ss.  In this sense, a possible – albeit counter-intuitive –= ; definition of a thing could be that it is sufficiently robust to provide = necessary identity assertion to others, and in particular the network.  Otherwise it could be viewed as a component of a thing.=

Eliot

On 4/12/16 9:34 PM, Behcet Sarikaya wrote:
Hi Hannes,

Thanks for pointing out  the ace-overview draft.
Having taken a look at it, I don't see a definition of identity there eithe=
r.

I am not sure how much identity is relevant to the secure bootstrapping.

Regards,

Behcet

On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
Hi Mohit,

there is no definition of device identity (or identity) in your draft
<draft-sarikaya-t2trg-sbootstrapping>. Hence, I am asking.

Ciao
Hannes

PS: Btw, I wrote a document for the ACE working group that gives an
overview as well:
https://tools.ietf.org/html/draft-tschofenig-=
ace-overview-00


On 04/07/2016 10:57 PM, Mohit Sethi wrote:
Hi

As my slides pointed out, there are a bunch of definitions for both
bootstrapping as well device identity. If anyone wants to point to
different interpretations on the list, we will be happy to discuss them
in the survey draft. The draft does not intend to select one definition
over the other. Perhaps we don't want to get bogged down in the
discussion on the philosophical differences between identifier and
identity etc. and rather consider the practical use of identifiers.

Regards
Mohit

On 04/07/2016 05:24 PM, Hannes Tschofenig wrote:
In his presentation Mohit used the term 'Device Identity'.

I have heard this term in various conversation over the past few years
and I have the fear that there are different interpretations what it means.

What does it mean for you, Mohit?

Ciao
Hannes



_______________________________________________
T2TRG mailing list
T2TRG@=
irtf.orghttps://www.irtf.org/mailman/listinfo/t2trg
_______________________________________________
T2TRG mailing list
T2TRG@=
irtf.orghttps://www.irtf.org/mailman/listinfo/t2trg
_______________________________________________
T2TRG mailing list
T2TRG@=
irtf.orghttps://www.irtf.org/mailman/listinfo/t2trg
_______________________________________________
T2TRG mailing list
T2TRG@=
irtf.orghttps://www.irtf.org/mailman/listinfo/t2trg



--_000_D334375C8DABCpaulmarvellcom_-- From nobody Wed Apr 13 23:23:59 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC712D1B3 for ; Wed, 13 Apr 2016 23:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi1gYVyzdoMI for ; Wed, 13 Apr 2016 23:23:55 -0700 (PDT) Received: from mxi.ltu.se (mxi.ltu.se [IPv6:2001:6b0:10:42::42:23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974E112DD8C for ; Wed, 13 Apr 2016 23:23:54 -0700 (PDT) Received: from ltuex1.ltuad.ltu.se (ltuex1.ltuad.ltu.se [130.240.20.71]) by mxi.ltu.se (8.14.4/8.14.4) with ESMTP id u3E6Nfqj020782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 08:23:41 +0200 Received: from ltuex1.ltuad.ltu.se (130.240.20.71) by ltuex1.ltuad.ltu.se (130.240.20.71) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 14 Apr 2016 08:23:41 +0200 Received: from ltuex1.ltuad.ltu.se ([fe80::c184:6d39:a728:cf6d]) by ltuex1.ltuad.ltu.se ([fe80::c184:6d39:a728:cf6d%15]) with mapi id 15.00.1156.000; Thu, 14 Apr 2016 08:23:41 +0200 From: Hasan Derhamy To: Paul Lambert , Eliot Lear , "sarikaya@ieee.org" , Hannes Tschofenig Thread-Topic: [T2TRG] Device Identity Thread-Index: AQHRkQucMveSR2oPaEagoyL2tGHxM59+3LSAgAGZGQCABitIAIABB9SAgADkOYCAAHyIwA== Date: Thu, 14 Apr 2016 06:23:41 +0000 Message-ID: References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> In-Reply-To: Accept-Language: en-GB, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.240.20.16] Content-Type: multipart/alternative; boundary="_000_d704906a18ee43d4b5aed78f7c0c3046ltuex1ltuadltuse_" MIME-Version: 1.0 Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 06:23:58 -0000 --_000_d704906a18ee43d4b5aed78f7c0c3046ltuex1ltuadltuse_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Do you have any reading material regarding 'key centric' architecture used = as identity? -Hasan From: T2TRG [mailto:t2trg-bounces@irtf.org] On Behalf Of Paul Lambert Sent: den 14 april 2016 02:56 To: Eliot Lear; sarikaya@ieee.org; Hannes Tschofenig Cc: Mohit Sethi; t2trg@irtf.org Subject: Re: [T2TRG] Device Identity I'm a bit new to T2TRG, so please forgive me if this is well trodden ground= . Yes, but new paths should be considered that are not as well traveled. The notion of device identity depends on what we mean by a device or thing,= if you will. More precisely, how does one determine whether something is = a component or a network element unto itself? Must a thing have an IP or 6= lopan-based stack? These are surely things this RG has covered. Addresses should be considered 'attributes' of an entity and not the base = identity. The IEEE does have a standard for device identity, which is IEEE 802.1AR. = While it may not be perfect, it is something upon which to build. If I mig= ht channel my friend John Strassner for a moment, however, device identity = is probably meaningless without some notion of attributes. 802.1AR could c= over that ground nicely through constraints. As we presented in several pl= aces last week, MUD[1] borrows from AR to make use of constraints. The problem with .AR of course is that it requires at least the basics of a= PKI to establish the validity of an identity. There is work in the ANIMA = working group to do just that in a bilateral way.[2] ... 802.11AR is not the right path. A 'key centric' architecture is a better direction (IMHO). Public keys and= ways to create a identifier for a public key are a simple and scaleable st= arting point. Paul The network goal is quite simple: * Identify the element sufficiently to establish an appropriate posture= . Someone MUST take responsibility for an element's behavior in that process.= In this sense, a possible - albeit counter-intuitive - definition of a th= ing could be that it is sufficiently robust to provide necessary identity a= ssertion to others, and in particular the network. Otherwise it could be v= iewed as a component of a thing. Eliot On 4/12/16 9:34 PM, Behcet Sarikaya wrote: Hi Hannes, Thanks for pointing out the ace-overview draft. Having taken a look at it, I don't see a definition of identity there eithe= r. I am not sure how much identity is relevant to the secure bootstrapping. Regards, Behcet On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tschofenig wrote: Hi Mohit, there is no definition of device identity (or identity) in your draft . Hence, I am asking. Ciao Hannes PS: Btw, I wrote a document for the ACE working group that gives an overview as well: https://tools.ietf.org/html/draft-tschofenig-ace-overview-00 On 04/07/2016 10:57 PM, Mohit Sethi wrote: Hi As my slides pointed out, there are a bunch of definitions for both bootstrapping as well device identity. If anyone wants to point to different interpretations on the list, we will be happy to discuss them in the survey draft. The draft does not intend to select one definition over the other. Perhaps we don't want to get bogged down in the discussion on the philosophical differences between identifier and identity etc. and rather consider the practical use of identifiers. Regards Mohit On 04/07/2016 05:24 PM, Hannes Tschofenig wrote: In his presentation Mohit used the term 'Device Identity'. I have heard this term in various conversation over the past few years and I have the fear that there are different interpretations what it means. What does it mean for you, Mohit? Ciao Hannes _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg _______________________________________________ T2TRG mailing list T2TRG@irtf.orghttps://www.irtf.org/mailman/listinfo/= t2trg --_000_d704906a18ee43d4b5aed78f7c0c3046ltuex1ltuadltuse_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Do you have any reading m= aterial regarding ‘key centric’ architecture used as identity?<= o:p>

 <= /p>

-Hasan<= /p>

 <= /p>

 <= /p>

 <= /p>

From: T2TRG [m= ailto:t2trg-bounces@irtf.org] On Behalf Of Paul Lambert
Sent: den 14 april 2016 02:56
To: Eliot Lear; sarikaya@ieee.org; Hannes Tschofenig
Cc: Mohit Sethi; t2trg@irtf.org
Subject: Re: [T2TRG] Device Identity

 

 

 

 



I'm a bit new to T2TRG, so please forgive me if this is well trodden ground= .

Yes, but new paths should b= e considered that are not as well traveled.

 



The notion of device identity depends on what we mean by a device or thing,= if you will.  More precisely, how does one determine whether somethin= g is a component or a network element unto itself?  Must a thing have = an IP or 6lopan-based stack?  These are surely things this RG has covered.

Addresses should be conside= red 'attributes’  of an entity and not the base identity.

 



The IEEE does have a standard for device identity, which is IEEE 802.1AR.&n= bsp; While it may not be perfect, it is something upon which to build. = ; If I might channel my friend John Strassner for a moment, however, device= identity is probably meaningless without some notion of attributes.  802.1AR could cover that ground nicely th= rough constraints.  As we presented in several places last week, MUD[1= ] borrows from AR to make use of constraints.

The problem with .AR of course is that it requires at least the basics of a= PKI to establish the validity of an identity.  There is work in the A= NIMA working group to do just that in a bilateral way.[2]
=

 

 … 802.11AR is n= ot the right path.

 

A ‘key centric’= architecture is a better direction (IMHO).  Public keys and ways to c= reate a identifier for a public key are a simple and scaleable starting poi= nt.  

 

Paul

 

 



The network goal is quite simple:

  • Identify the element sufficiently to establish an appropriate = posture.

Someone MUST take responsibility for an element= 's behavior in that process.  In this sense, a possible – albeit= counter-intuitive – definition of a thing could be that it is suffic= iently robust to provide necessary identity assertion to others, and in particula= r the network.  Otherwise it could be viewed as a component of a thing= .

Eliot

On 4/12/16 9:34 PM, Behcet = Sarikaya wrote:

Hi Hannes,
 
Thanks for pointing out  the ace-over=
view draft.
Having taken a look at it, I don't see a d=
efinition of identity there either.
 
I am not sure how much identity is relevan=
t to the secure bootstrapping.
 
Regards,
 
Behcet
 
On Fri, Apr 8, 2016 at 4:22 PM, Hannes Tsc=
hofenig
<hannes.tschofenig@gmx.net> wrote:
Hi Mohit,
 
there is no definition of device identity =
(or identity) in your draft
<draft-sarikaya-t2trg-sbootstrapping>=
;. Hence, I am asking.
 
Ciao
Hannes
 
PS: Btw, I wrote a document for the ACE wo=
rking group that gives an
overview as well:
https://tools.ietf.org/html/draft-tschofenig=
-ace-overview-00
 
 
On 04/07/2016 10:57 PM, Mohit Sethi wrote:=
Hi
 
As my slides pointed out, there are a bunc=
h of definitions for both
bootstrapping as well device identity. If =
anyone wants to point to
different interpretations on the list, we =
will be happy to discuss them
in the survey draft. The draft does not in=
tend to select one definition
over the other. Perhaps we don't want to g=
et bogged down in the
discussion on the philosophical difference=
s between identifier and
identity etc. and rather consider the prac=
tical use of identifiers.
 
Regards
Mohit
 
On 04/07/2016 05:24 PM, Hannes Tschofenig =
wrote:
In his presentation Mohit used the term 'D=
evice Identity'.
 
I have heard this term in various conversa=
tion over the past few years
and I have the fear that there are differe=
nt interpretations what it means.
 
What does it mean for you, Mohit?
 
Ciao
Hannes
 
 
 
__________________________________________=
_____
T2TRG mailing list
T2TRG@ir=
tf.orghttps://w=
ww.irtf.org/mailman/listinfo/t2trg
 
__________________________________________=
_____
T2TRG mailing list
T2TRG@ir=
tf.orghttps://w=
ww.irtf.org/mailman/listinfo/t2trg
__________________________________________=
_____
T2TRG mailing list
T2TRG@ir=
tf.orghttps://w=
ww.irtf.org/mailman/listinfo/t2trg
__________________________________________=
_____
T2TRG mailing list
T2TRG@ir=
tf.orghttps://w=
ww.irtf.org/mailman/listinfo/t2trg

 

 

 

--_000_d704906a18ee43d4b5aed78f7c0c3046ltuex1ltuadltuse_-- From nobody Thu Apr 14 01:11:24 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E4A12DD2C for ; Thu, 14 Apr 2016 01:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frkOjQoC0jzH for ; Thu, 14 Apr 2016 01:11:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DF112DD27 for ; Thu, 14 Apr 2016 01:11:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DKAgDQowxX/yYyC4dUCRoBAQGCbyuBUAa6XQENgXKGDQKBLTgUAQEBAQEBAWUnQRIBg20BAQEBAxIoPwwEAgEIDQQEAQELFAkHMhQJCAIEAQ0FCBqIBQGjR5x4AQEBAQEBAQECAQEBAQEBAQEBAQEVhiKESoQWKYMrgisFmAcBl12FP48nHgEBQoNnbIIrhlwBfQEBAQ X-IPAS-Result: A2DKAgDQowxX/yYyC4dUCRoBAQGCbyuBUAa6XQENgXKGDQKBLTgUAQEBAQEBAWUnQRIBg20BAQEBAxIoPwwEAgEIDQQEAQELFAkHMhQJCAIEAQ0FCBqIBQGjR5x4AQEBAQEBAQECAQEBAQEBAQEBAQEVhiKESoQWKYMrgisFmAcBl12FP48nHgEBQoNnbIIrhlwBfQEBAQ X-IronPort-AV: E=Sophos;i="5.24,472,1454994000"; d="scan'208";a="150834813" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2016 04:11:17 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 14 Apr 2016 04:11:17 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 14 Apr 2016 10:11:14 +0200 From: "Romascanu, Dan (Dan)" To: Hannes Tschofenig , Eliot Lear , "sarikaya@ieee.org" Thread-Topic: [T2TRG] Device Identity Thread-Index: AQHRlPJeGsHQPCZgwkKrSrz8u85khp+HoRyAgAAerYCAAWAE4A== Date: Thu, 14 Apr 2016 08:11:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA751C7504@AZ-FFEXMB04.global.avaya.com> References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> <570E44DB.2040305@gmx.net> In-Reply-To: <570E44DB.2040305@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:11:23 -0000 FWIW - the IEEE 802.1 Security TG is engaged in the transition of the manag= ement interface from SMIv2 MIB modules used to SNMP to YANG modules which c= an be used with NETCONF and RESTCONF. So the 'MIB for configuration' aspect= will be sometimes probably soon Historical.=20 Regards, Dan > -----Original Message----- > From: T2TRG [mailto:t2trg-bounces@irtf.org] On Behalf Of Hannes > Tschofenig > Sent: Wednesday, April 13, 2016 4:09 PM > To: Eliot Lear; sarikaya@ieee.org > Cc: Mohit Sethi; t2trg@irtf.org > Subject: Re: [T2TRG] Device Identity >=20 > I am not sure about the value of IEEE 802.1AR >=20 > It says: Provision devices with X.509 certificates (either RSA or ECC) an= d the > spec defines a MIB for configuration. >=20 From nobody Thu Apr 14 14:03:43 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2727112D642 for ; Thu, 14 Apr 2016 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV5lpCEKV0dB for ; Thu, 14 Apr 2016 14:03:40 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD5312D88A for ; Thu, 14 Apr 2016 14:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8374; q=dns/txt; s=iport; t=1460667820; x=1461877420; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=DxBguUkOhUuXgA9UVm3Q5u4lpDqfl+1d1poilOnxOJc=; b=FlBnem/qbRPoJKjl7TTmM4CqUtc1EIkuXWS/UbsiKZFIKgeHAODiGLDH d7ByRbQK9PbWA17vEZ70rKtxhNjtV+xtPWkrLXsMSYXF4X6CJGgHNQmL/ 89/6C8JXbYrQ6NNWtwX9HswS2oxc5ioL3Kvpzz1DQRb936HDViaa3M5nl 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAgDgBBBX/xbLJq1VCYQLtjiEcw6Bc?= =?us-ascii?q?SKFbAKBeBQBAQEBAQEBZSeEQQEBAQMBI1UBEAsYCQ8HCwICCQMCAQIBRQYBDAg?= =?us-ascii?q?BAYgdCA6wIZI0AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEiWqBAoQWAw5mgjKCV?= =?us-ascii?q?gEEh3mFWYo5gySBZm2IFok6hVaPKR4BQ4IEGYFMOog5gT0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="asc'?scan'208,217";a="634166306" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 21:03:37 +0000 Received: from [10.61.70.138] (ams3-vpn-dhcp1674.cisco.com [10.61.70.138]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3EL3bqR007175; Thu, 14 Apr 2016 21:03:37 GMT To: Hannes Tschofenig , sarikaya@ieee.org References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> <570E44DB.2040305@gmx.net> From: Eliot Lear Message-ID: <571005A7.3020408@cisco.com> Date: Thu, 14 Apr 2016 23:03:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570E44DB.2040305@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uLPq1Acn0GNhPFWTPxxlsv8V8IwejFXMk" Archived-At: Cc: Mohit Sethi , "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 21:03:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uLPq1Acn0GNhPFWTPxxlsv8V8IwejFXMk Content-Type: multipart/mixed; boundary="ssNK9PqWKAqNjHo2XruwQfDc2tU2su7pu" From: Eliot Lear To: Hannes Tschofenig , sarikaya@ieee.org Cc: Mohit Sethi , "t2trg@irtf.org" Message-ID: <571005A7.3020408@cisco.com> Subject: Re: [T2TRG] Device Identity References: <5706C210.6060902@gmx.net> <5706C9D5.6060304@ericsson.com> <57082102.4020301@gmx.net> <570E2B1F.5070006@cisco.com> <570E44DB.2040305@gmx.net> In-Reply-To: <570E44DB.2040305@gmx.net> --ssNK9PqWKAqNjHo2XruwQfDc2tU2su7pu Content-Type: multipart/alternative; boundary="------------060100080602070504010807" This is a multi-part message in MIME format. --------------060100080602070504010807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Hannes, On 4/13/16 3:08 PM, Hannes Tschofenig wrote: > I am not sure about the value of IEEE 802.1AR > > It says: Provision devices with X.509 certificates (either RSA or ECC) > and the spec defines a MIB for configuration. > > It also lists the fields of a certificate and defines the "device > identity" in Section 7.2.8 as "This may include the unique device seria= l > number assigned by the manufacturer or any other suitable unique DN > value that the issuer prefers." > > So, it essentially does not say what the identifier is in the certifica= te. That's only a problem if and only if the following are true: 1. One has a need to treat the subject contents in other than an opaque form; AND 2. Anything other than a manufacturer site or tool needs to parse that subject. I add that last point because the key bootstrapping draft anticipates, but does not require, that (2) is not true. > > In the context of this discussion I believe it would be better to just > say use the term credential instead. Credentials contain identifiers an= d > attributes. > > If we only want to talk about certificates (which I doubt in the IoT > context) then we should just be specific and refer to end entity > certificates and trust anchors. And these are the points that are worth exploring. If the best we can say is that the device hold a credential, we haven't really said much.=20 Credentials come in many forms. While it is true that credentials can be characterized as having attributes, many are highly limited. A credential could be of the form username/password, for instance, but as we all know, that doesn't scale. This may just go to use and requirements. But if a manufacturer wants to assert anything about the Thing, then those assertions must be authenticated somehow. For admission purposes, the network needs the manufacturer to assert probably two things: *some* form of identifier, probably unique; and what class of thing that is. I like a resolvable URI. Others may differ= =2E > > Ciao > Hannes > > PS: As we tried to explain in > https://tools.ietf.org/html/draft-fossati-core-server-name-id-00 the us= e > of certificates (and specifically the identifiers used in there) raises= > challenges in some IoT deployments. For this (and other reasons) I am > arguing that X.509 certificates are not a good choice of technology for= > come IoT deployments. > And I might agree, for some deployments, if something better presented itself or it could be shown that admission could be handled in some other way. The draft you mention specifies a new SAN. But perhaps you have other ideas for that identifier? Eliot --------------060100080602070504010807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Hannes,

On 4/13/16 3:08 PM, Hannes Tschofenig wrote:
I am not sure about the value of IEEE 802.1AR

It says: Provision devices with X.509 certificates (either RSA or ECC)
and the spec defines a MIB for configuration.

It also lists the fields of a certificate and defines the "device
identity" in Section 7.2.8 as "This may include the unique device serial
number assigned by the manufacturer or any other suitable unique DN
value that the issuer prefers."

So, it essentially does not say what the identifier is in the certificate=
=2E

That's only a problem if and only if the following are true:
  1. One has a need to treat the subject contents in other than an opaque form; AND
  2. Anything other than a manufacturer site or tool needs to parse that subject.

I add that last point because the key bootstrapping draft anticipates, but does not require, that (2) is not true.


In the context of this discussion I believe it would be better to just
say use the term credential instead. Credentials contain identifiers and
attributes.

If we only want to talk about certificates (which I doubt in the IoT
context) then we should just be specific and refer to end entity
certificates and trust anchors.

And these are the points that are worth exploring.=C2=A0 If the best = we can say is that the device hold a credential, we haven't really said much.=C2=A0 Credentials come in many forms.=C2=A0 While it is true th= at credentials can be characterized as having attributes, many are highly limited.=C2=A0 A credential could be of the form username/password, for instance, but as we all know, that doesn't scale.=C2=A0 This may just go to use and requirements.=C2=A0 But if a= manufacturer wants to assert anything about the Thing, then those assertions must be authenticated somehow.=C2=A0 For admission purpose= s, the network needs the manufacturer to assert probably two things: = some form of identifier, probably unique; and what class of thing that is.=C2=A0 I like a resolvable URI.=C2=A0 Others may differ.



Ciao
Hannes

PS: As we tried to explain in
https://tools.ietf.org/html/draft-fos=
sati-core-server-name-id-00 the use
of certificates (and specifically the identifiers used in there) raises
challenges in some IoT deployments. For this (and other reasons) I am
arguing that X.509 certificates are not a good choice of technology for
come IoT deployments.


And I might agree, for some deployments, if something better presented itself or it could be shown that admission could be handled in some other way.=C2=A0 The draft you mention specifies a ne= w SAN.=C2=A0 But perhaps you have other ideas for that identifier?

Eliot
--------------060100080602070504010807-- --ssNK9PqWKAqNjHo2XruwQfDc2tU2su7pu-- --uLPq1Acn0GNhPFWTPxxlsv8V8IwejFXMk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXEAWpAAoJEIe2a0bZ0nozEh4H+wd05rYcb0TsDvJL51/OUPR9 eGnp+CwNujRQjSUrKCNi7MoKG8mHQnEIeeoTxdxRj50rPkbBSFuXljD07bXLPtbP m6copmzZE89b5gNyCmklOuvi5QoyHKqIxKAjFFYDMn1n4MUxgWulizskPwDqWuth za7bHwQHobJN0vDIIZKESNEtoCqAxoiTV+ZzdrfHiuSvtHaiV7sO077MFA+wn/bJ qSyZJR+Ixr/OW6OKTyf6mkhCn4c8NepZsl2A1FJdKSGP41EfZ6o72PdHYgBs5Pwr La6LHJE6gmr9WvKJp26tYmQdQmgDfqnC4yIq9zNQZHGSYQoLkB58+Kx0od/GYxQ= =Ijr4 -----END PGP SIGNATURE----- --uLPq1Acn0GNhPFWTPxxlsv8V8IwejFXMk-- From nobody Wed Apr 20 14:07:15 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC5212E909 for ; Wed, 20 Apr 2016 14:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIe11geViP9q for ; Wed, 20 Apr 2016 14:07:12 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F6912E63E for ; Wed, 20 Apr 2016 14:06:59 -0700 (PDT) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id DDFE341C08E; Wed, 20 Apr 2016 23:06:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 73PAUwYsLYTz; Wed, 20 Apr 2016 23:06:56 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id CCF3941C080; Wed, 20 Apr 2016 23:06:55 +0200 (CEST) Message-ID: <5717EF6D.4030502@tzi.org> Date: Wed, 20 Apr 2016 23:06:53 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" , "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [T2TRG] Update it or throw it away: IoT Software Update Workshop (IoTSU) X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 21:07:13 -0000 While some of us see performing software updates to IoT devices over the Internet as a solved engineering problem, there must be a reason why this capability is not considered a matter of course. This area does need work. We are organizing a workshop on software/firmware updates for IoT devices. More information, with a call for position papers: https://down.dsg.cs.tcd.ie/iotsu/ Grüße, Carsten From nobody Thu Apr 21 12:35:43 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830AE12E2D6 for ; Thu, 21 Apr 2016 12:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMMVtMca3XQp for ; Thu, 21 Apr 2016 12:35:39 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D42912E351 for ; Thu, 21 Apr 2016 12:35:39 -0700 (PDT) Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id D9FFC41C07D; Thu, 21 Apr 2016 21:35:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EMD7Xz6X2rcZ; Thu, 21 Apr 2016 21:35:36 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id D0DA541C097; Thu, 21 Apr 2016 21:35:35 +0200 (CEST) Message-ID: <57192B84.902@tzi.org> Date: Thu, 21 Apr 2016 21:35:32 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [T2TRG] Schema conversion opportunity: OMA LWM2M objects to YANG? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 19:35:41 -0000 Around the IOTSI workshop, we had a discussion about modeling/schema languages and the opportunities for conversion in order to create semantic interoperability. In CoRE, we are having this discussion about device management right now, and one interesting question is whether the little XML DSL that OMA LWM2M has here is a candidate for automatic conversion to another management modeling language, e.g., YANG. Anybody up to hacking together a prototype? See https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications-hurts.pdf for an example of such a conversion prototype. Grüße, Carsten -------- Original Message -------- Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00 Date: Thu, 21 Apr 2016 19:48:06 +0200 From: Juergen Schoenwaelder Reply-To: Juergen Schoenwaelder To: Michel Veillette CC: core@ietf.org WG On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote: > > First, LWM2M have its own modeling language encoded in xml. > A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang. > A simple xml transform can probably do the conversion between the two without any lost. > LWM2M just have a simpler (subset) modeling language. > These are pretty bold statements. Claiming something is simple and knowing something is simple are sometimes different things. Have you worked throught the details? Is there a decent public definition of the 'simpler (subset) modeling language'? And with public I mean public, not hidden behind all sorts of registration walls. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Apr 21 12:40:59 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266D412E5AD for ; Thu, 21 Apr 2016 12:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCLMH8Ru47jW for ; Thu, 21 Apr 2016 12:40:56 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 C21EA12E53A for ; Thu, 21 Apr 2016 12:40:55 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id u3LJerV8005700 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Apr 2016 21:40:53 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id u3LJeqq6005095 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 21:40:53 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.253]) by DEFTHW99ERIMSX.ww902.siemens.net ([139.22.70.134]) with mapi id 14.03.0294.000; Thu, 21 Apr 2016 21:40:52 +0200 From: "Kovatsch, Matthias" To: "t2trg@irtf.org" , "cabo@tzi.org" Thread-Topic: [T2TRG] Schema conversion opportunity: OMA LWM2M objects to YANG? Thread-Index: AQHRnAUUm57BUh1yTkarcPkgZQYmKZ+U02MJ Date: Thu, 21 Apr 2016 19:40:52 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01762051@DEFTHW99EL4MSX.ww902.siemens.net> References: <57192B84.902@tzi.org> In-Reply-To: <57192B84.902@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [T2TRG] Schema conversion opportunity: OMA LWM2M objects to YANG? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 19:40:58 -0000 Could you please provide a pointer to the DSL to which you are referring? Thanks :) Matthias -----Original Message----- From: Carsten Bormann [cabo@tzi.org] Received: Thursday, 21 Apr 2016, 21:36 To: t2trg@irtf.org [t2trg@irtf.org] Subject: [T2TRG] Schema conversion opportunity: OMA LWM2M objects to YANG? Around the IOTSI workshop, we had a discussion about modeling/schema languages and the opportunities for conversion in order to create semantic interoperability. In CoRE, we are having this discussion about device management right now, and one interesting question is whether the little XML DSL that OMA LWM2M has here is a candidate for automatic conversion to another management modeling language, e.g., YANG. Anybody up to hacking together a prototype? See https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications-= hurts.pdf for an example of such a conversion prototype. Gr=FC=DFe, Carsten -------- Original Message -------- Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00 Date: Thu, 21 Apr 2016 19:48:06 +0200 From: Juergen Schoenwaelder Reply-To: Juergen Schoenwaelder To: Michel Veillette CC: core@ietf.org WG On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote: > > First, LWM2M have its own modeling language encoded in xml. > A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundament= ally different than something than can be named security.yang. > A simple xml transform can probably do the conversion between the two wit= hout any lost. > LWM2M just have a simpler (subset) modeling language. > These are pretty bold statements. Claiming something is simple and knowing something is simple are sometimes different things. Have you worked throught the details? Is there a decent public definition of the 'simpler (subset) modeling language'? And with public I mean public, not hidden behind all sorts of registration walls. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ T2TRG mailing list T2TRG@irtf.org https://www.irtf.org/mailman/listinfo/t2trg From nobody Thu Apr 21 13:40:00 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA212D70A for ; Thu, 21 Apr 2016 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjqzDccw5L81 for ; Thu, 21 Apr 2016 13:39:56 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33EB12D1C7 for ; Thu, 21 Apr 2016 13:39:56 -0700 (PDT) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 1ABC5C5A49; Thu, 21 Apr 2016 22:39:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Sgmy-XOhwr_e; Thu, 21 Apr 2016 22:39:53 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id F0924C5A55; Thu, 21 Apr 2016 22:39:52 +0200 (CEST) Message-ID: <57193A96.6050106@tzi.org> Date: Thu, 21 Apr 2016 22:39:50 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Kovatsch, Matthias" References: <57192B84.902@tzi.org> <4EBB3DDD0FBF694CA2A87838DF129B3C01762051@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01762051@DEFTHW99EL4MSX.ww902.siemens.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "t2trg@irtf.org" Subject: Re: [T2TRG] Schema conversion opportunity: OMA LWM2M objects to YANG? X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 20:39:58 -0000 Kovatsch, Matthias wrote: > Could you please provide a pointer to the DSL to which you are referring? Hey, you are making the exercise too easy :-) If you look at: https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/wiki/OMA-LwM2M-Technical-Specifications there are links to "Supporting Documents", eight of them in total. These are all XML files that essentially define the LWM2M objects in an ad-hoc DSL -- we briefly discussed this in San Jose. (Unfortunately, part of the info is in English-language comments; these will require manual translation; the rest should be translatable right away however.) Grüße, Carsten From nobody Wed Apr 27 00:04:05 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0876D12D097 for ; Wed, 27 Apr 2016 00:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn1FZFhCuRtI for ; Wed, 27 Apr 2016 00:04:00 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id EA16212B046 for ; Wed, 27 Apr 2016 00:03:59 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.43]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMDheZCBXciRfCQ--.648S2; Wed, 27 Apr 2016 15:03:58 +0800 (CST) Date: Wed, 27 Apr 2016 15:03:43 +0800 From: "qinxiaowei@cnnic.cn" To: t2trg X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <201604271503436945934@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart066441253682_=----" X-CM-TRANSID: AQAAf0ApMDheZCBXciRfCQ--.648S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUOh7k0a2IF6w1UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26ryj 6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26r xl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv 0487Mc02F40En4AKxVAvwIkv4cxYr24l5I8CrVC20s02628v4x8GjsIEw4AK0wAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2Iqxw Cjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r4xMxAIw28IcxkI7VAKI48JMxC20s02 6xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_Jr I_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v2 6r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj4 0_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j 6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0eHq3UUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 07:04:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart066441253682_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksZm9sa3MNCg0KQ29uc2lkZXJpbmcgdGhlIGxhcmdlLXNjYWxlIGJ1dCBzbWFsbC1zaXplZCBp bmZvcm1hdGlvbiBleGNoYW5nZSBpbiB0aGUgSU9ULCBpbiBvcmRlciB0byBtYWtlIHRoZSBkYXRh IGdlbmVyYXRlZCBieSBJT1QgZGV2aWNlcyB0cmFuc21pc3Npb24gbW9yZSBlZmZpY2llbnQsIHdl IG1heSBuZWVkIGEgZGF0YSBhZ2dyZWdhdGlvbiBzY2hlbWUgaW4gSU9ULiANCkNvbnNpZGVyIHRo aXMgc2NlbmFyaW86IGluIGEgaG9tZSBuZXR3b3JrIG1heSBjb25zaXN0IG9mIG1hbnkgc2Vuc29y cywgc3VjaCBhcyBsaWdodCBzZW5zb3IsIG1ldGVyLCBhbmQgZmlyZSBkZXRlY3RvciwgZXRjLCBl YWNoIGZyYW1lIGhhcyB2ZXJ5IHNtYWxsIHBheWxvYWQoMTUgqEMgMTAwIGJ5dGUpIGFuZCBsaW1p dCBudW1iZXIgb2YgZnJhbWVzIHBlciBkYXkoMTApLiBJT1QgdXNlcnMgbmVlZCByZW1vdGUgYWNj ZXNzIHRoZXNlIHNlbnNvcnMgZm9yIHRoZSBlYXN5IG1hbmFnZW1lbnQgYW5kIHNhZmV0eSBvZiBo b3VzZS4gSWYgaW5pdGlhdGUgYW4gaW50ZXJuZXQgdHJhbnNtaXNzaW9uIGZvciBldmVyeSBmcmFt ZSBvZiBlYWNoIHNlbnNvciwgdGhlIHBheWxvYWQgbXVzdCBhY2NvdW50IHZlcnkgbG93IHBlcmNl bnQgb2YgdGhlIHdob2xlIGZyYW1lKGJlY2F1c2Ugb2YgdGhlIElQIGhlYWRlciwgTUFDIGhlYWRl ciwgUEhZIGhlYWRlcikuIA0KU28sSU1PLCBkYXRhIGdlbmVyYXRlZCBieSBzb21lIElPVCBkZXZp Y2VzIHNob3VsZCBiZSBhZ2dyZWdhdGVkIGF0IHRoZSB0cmFuc21pdHRlciBhbmQgZGUtYWdncmVn YXRlZCBieSB0aGUgcmVjZWl2ZXIgZm9yIG1vcmUgZWZmaWNpZW50Lg0KDQpSZWdhcmRzDQpYaWFv d2VpIFFpbg0KDQoNCg== ------=_001_NextPart066441253682_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
Hi,folks

Considering the large-sc= ale but small-sized information exchange in the IOT, in order to make the = data generated by IOT devices transmission more efficient, we may need a d= ata aggregation scheme in IOT. 
Consider this scenario: in a = home network may consist of many sensors, such as light sensor, meter, and= fire detector, etc, each frame has very small payload(15 =A8C 100 byte) a= nd limit number of frames per day(10). IOT users need remote access these = sensors for the easy management and safety of house. If initiate an intern= et transmission for every frame of each sensor, the payload must account v= ery low percent of the whole frame(because of the IP header, MAC header, P= HY header).=0A
So,IMO, data generated by some IOT devices should be aggrega= ted at the transmitter and de-aggregated by the receiver for more efficien= t.
Regards
Xiaowei Qin

=0A
=0A ------=_001_NextPart066441253682_=------ From nobody Wed Apr 27 00:28:40 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2807912B046 for ; Wed, 27 Apr 2016 00:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFvCv3xjVmS9 for ; Wed, 27 Apr 2016 00:28:37 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id EE08412B04D for ; Wed, 27 Apr 2016 00:28:36 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.43]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEEwlaiBXfSVfCQ--.57795S2; Wed, 27 Apr 2016 15:28:37 +0800 (CST) Date: Wed, 27 Apr 2016 15:28:22 +0800 From: "qinxiaowei@cnnic.cn" To: t2trg References: <201604271503436945934@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2016042715282254691415@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart606632367336_=----" X-CM-TRANSID: AQAAf0AJEEwlaiBXfSVfCQ--.57795S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUOL7k0a2IF6w4kM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j 6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26r xl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv 0487Mc02F40En4AKxVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24l5I8CrVC20s02628v4x 8GjsIEw4AK0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S 6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lFc xC0VAYjxAxZF0Ex2IqxwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07 bwvttUUUUU= X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: [T2TRG] Two use case in information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 07:28:39 -0000 This is a multi-part message in MIME format. ------=_001_NextPart606632367336_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrGZvbGtzDQpPbmUgdXNlIGNhc2UgaXMgdGhhdCBzZXZlcmFsIGZyYW1lcyBnZW5lcmF0ZWQg Ynkgb25lIElPVCBkZXZpY2UgYXJlIGFnZ3JlZ2F0ZWQgaW50byBvbmUgSVAgcGFja2V0LiANClRo aXMgdXNlIGNhc2Ugc3VpdHMgbm9uZS1yZWFsLXRpbWUgcmVxdWlyZW1lbnRzIHNjZW5hcmlvLiBE YXRhIGdlbmVyYXRlZCBieSBlYWNoIElPVCBkZXZpY2UgY2FuIGJlIHN0b3JlZCB0ZW1wb3Jhcmls eSBhdCBsb2NhbCBjYWNoZSwgYW5kIHRoZW4gc2VuZCB3aXRoIGFnZ3JlZ2F0aW9uIGNoYWluLiAN ClRoZSBzZWNvbmQgdXNlIGNhc2UgaXMgdGhhdCBzZXZlcmFsIGZyYW1lcyBnZW5lcmF0ZWQgYnkg c29tZSBkaWZmZXJlbnQgSU9UIGRldmljZXMgYXJlIGFnZ3JlZ2F0ZWQgaW50byBvbmUgSVAgcGFj a2V0LiANClRoaXMgdXNlIGNhc2Ugc3VpdHMgcmVhbC10aW1lIHJlcXVpcmVtZW50cyBzY2VuYXJp by4gRGF0YSBnZW5lcmF0ZWQgYnkgZGlmZmVyZW50IElPVCBkZXZpY2VzIHdpbGwgYmUgdHJhbnNt aXR0ZWQgaW1tZWRpYXRlbHkgd2l0aCBmcmFtZSBhZ2dyZWdhdGlvbiBjaGFpbi4gDQoNClJlZ2Fy ZHMNClhpYW93ZWkgUWluDQoNCg0KDQoNCiANCreivP7Iy6O6IHFpbnhpYW93ZWlAY25uaWMuY24N Creiy83Ksbzko7ogMjAxNi0wNC0yNyAxNTowMw0KytW8/sjLo7ogdDJ0cmcNCtb3zOKjuiBJbmZv cm1hdGlvbiBhZ2dyZWdhdGlvbiBpbiBpbnRlcm5ldCBvZiB0aGluZ3MNCkhpLGZvbGtzDQoNCkNv bnNpZGVyaW5nIHRoZSBsYXJnZS1zY2FsZSBidXQgc21hbGwtc2l6ZWQgaW5mb3JtYXRpb24gZXhj aGFuZ2UgaW4gdGhlIElPVCwgaW4gb3JkZXIgdG8gbWFrZSB0aGUgZGF0YSBnZW5lcmF0ZWQgYnkg SU9UIGRldmljZXMgdHJhbnNtaXNzaW9uIG1vcmUgZWZmaWNpZW50LCB3ZSBtYXkgbmVlZCBhIGRh dGEgYWdncmVnYXRpb24gc2NoZW1lIGluIElPVC4gDQpDb25zaWRlciB0aGlzIHNjZW5hcmlvOiBp biBhIGhvbWUgbmV0d29yayBtYXkgY29uc2lzdCBvZiBtYW55IHNlbnNvcnMsIHN1Y2ggYXMgbGln aHQgc2Vuc29yLCBtZXRlciwgYW5kIGZpcmUgZGV0ZWN0b3IsIGV0YywgZWFjaCBmcmFtZSBoYXMg dmVyeSBzbWFsbCBwYXlsb2FkKDE1IKhDIDEwMCBieXRlKSBhbmQgbGltaXQgbnVtYmVyIG9mIGZy YW1lcyBwZXIgZGF5KDEwKS4gSU9UIHVzZXJzIG5lZWQgcmVtb3RlIGFjY2VzcyB0aGVzZSBzZW5z b3JzIGZvciB0aGUgZWFzeSBtYW5hZ2VtZW50IGFuZCBzYWZldHkgb2YgaG91c2UuIElmIGluaXRp YXRlIGFuIGludGVybmV0IHRyYW5zbWlzc2lvbiBmb3IgZXZlcnkgZnJhbWUgb2YgZWFjaCBzZW5z b3IsIHRoZSBwYXlsb2FkIG11c3QgYWNjb3VudCB2ZXJ5IGxvdyBwZXJjZW50IG9mIHRoZSB3aG9s ZSBmcmFtZShiZWNhdXNlIG9mIHRoZSBJUCBoZWFkZXIsIE1BQyBoZWFkZXIsIFBIWSBoZWFkZXIp LiANClNvLElNTywgZGF0YSBnZW5lcmF0ZWQgYnkgc29tZSBJT1QgZGV2aWNlcyBzaG91bGQgYmUg YWdncmVnYXRlZCBhdCB0aGUgdHJhbnNtaXR0ZXIgYW5kIGRlLWFnZ3JlZ2F0ZWQgYnkgdGhlIHJl Y2VpdmVyIGZvciBtb3JlIGVmZmljaWVudC4NCg0KUmVnYXJkcw0KWGlhb3dlaSBRaW4NCg0KDQo= ------=_001_NextPart606632367336_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
Hi=A3=ACfolks
One use case is that several frames generated by one IOT device are agg= regated into one IP packet.=0A
This use case suits none-real-time requi= rements scenario. Data generated by each IOT device can be stored temporar= ily at local cache, and then send with aggregation chain. 
The second use case is that several frames generated by some differ= ent IOT devices are aggregated into one IP packet. =0A
This use case su= its real-time requirements scenario. Data generated by different IOT devic= es will be transmitted immediately with frame aggregation chain. 
=

Regards
Xiaowei Qin

=0A


=0A
= =0A
 
=B7=A2=BC=FE=C8= =CB=A3=BA qinxiaowei@cnnic= .cn
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2016-04-27&nb= sp;15:03
=CA=D5=BC=FE=C8=CB=A3=BA t2trg
=D6=F7=CC=E2=A3=BA Informa= tion aggregation in internet of things
=0A
Hi,folks
<= div>
Considering the la= rge-scale but small-sized information exchange in the IOT, in order to mak= e the data generated by IOT devices transmission more efficient, we may ne= ed a data aggregation scheme in IOT. 
<= span style=3D"background-color: rgba(0, 0, 0, 0);">Consider this scenario:= in a home network may consist of many sensors, such as light sensor, mete= r, and fire detector, etc, each frame has very small payload(15 =A8C 100 b= yte) and limit number of frames per day(10). IOT users need remote access = these sensors for the easy management and safety of house. If initiate an = internet transmission for every frame of each sensor, the payload must acc= ount very low percent of the whole frame(because of the IP header, MAC hea= der, PHY header).=0A
So,IMO, data generated by some IOT devices should be a= ggregated at the transmitter and de-aggregated by the receiver for more ef= ficient.

Regards
Xiaowei Qin

=0A
=0A
=0A ------=_001_NextPart606632367336_=------ From nobody Wed Apr 27 00:41:51 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6A012D5A8 for ; Wed, 27 Apr 2016 00:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI6BdG3TvzWR for ; Wed, 27 Apr 2016 00:41:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73B312D09C for ; Wed, 27 Apr 2016 00:41:48 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-73-57206d3a1b6e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.84.12516.A3D60275; Wed, 27 Apr 2016 09:41:46 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 09:41:46 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "qinxiaowei@cnnic.cn" Thread-Topic: [T2TRG] Information aggregation in internet of things Thread-Index: AQHRoFL9EJlqNa5GlUOzu+IK+nx1Xp+dTlGA Date: Wed, 27 Apr 2016 07:41:45 +0000 Message-ID: <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com> References: <201604271503436945934@cnnic.cn> In-Reply-To: <201604271503436945934@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <417930356285F9479C43CCF6A0D097AB@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7n65VrkK4wddNphbXnzawW7x/0MPi wOSx6Zqkx+SNh9kCmKK4bFJSczLLUov07RK4MnY/Ospe8IyvYs/G+UwNjFv4uhg5OSQETCSe LNrADGGLSVy4t56ti5GLQ0jgCKPEmrM/mCGcxYwSB9YfBatiE7CVeNK6jxXEFhHQl5iy9jF7 FyMHB7OAqkRXfx5IWFjASWLpw//sECXOEj0vJzJB2EYSz2ZMYQOxWYDKN268DDaSV8BeYsq9 n2C2kICOxL9pqxlBbE4BXYnOeW0sIDYj0HHfT60Bm8MsIC5x68l8JoijBSSW7DkP9YCoxMvH /1ghbCWJRbc/M0Gcpimxfpc+RKu1xNSF09ghbEWJKd0P2SFOEJQ4OfMJywRG8VlINsxC6J6F pHsWku5ZSLoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMtINbfuvuYFz92vEQowAH oxIPr4KsQrgQa2JZcWXuIUYJDmYlEd5TGUAh3pTEyqrUovz4otKc1OJDjNIcLErivDmR/8KE BNITS1KzU1MLUotgskwcnFINjKGp9sXm5j6pRQJF19MjHoS43drhazI5ZdaseQZG9Xm/V713 S28vSZi0+4qJiOLuf/ZpRq8OFPYqT79i93rxmd2lVSd3Kr13lou0Z7uYqXyOTUA1Yt6/12J2 XZx6vJWNGwxy3z/xXHvZtvnkg4Y1EneS+qe29H98YB/W8ufO4ad+xe9M7117rMRSnJFoqMVc VJwIAO8mcemwAgAA Archived-At: Cc: "T2TRG@irtf.org" Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 07:41:50 -0000 SGksDQoNCkluZGVlZCBkYXRhIGFnZ3JlZ2F0aW9uIGlzIG9uZSBrZXkgbWVjaGFuaXNtIGZvciBy ZWR1Y2luZyB0aGUgb3ZlcmhlYWQgaW4gSW9UIHNjZW5hcmlvcy4gVGhhdCdzIHdoeSBmb3IgZXhh bXBsZSBpbiBTZW5NTCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29y ZS1zZW5tbC0wMCkgd2UgaGF2ZSBwdXQgcXVpdGUgYSBsb3Qgb2YgZWZmb3J0IGludG8gbWFraW5n IGJhdGNoZXMgb2YgZGF0YSBlZmZpY2llbnQgYW5kIHNpbXBsZSB0byBleGNoYW5nZS4NCg0KDQpD aGVlcnMsDQpBcmkNCg0KPiBPbiAyNyBBcHIgMjAxNiwgYXQgMTA6MDMsIHFpbnhpYW93ZWlAY25u aWMuY24gd3JvdGU6DQo+IA0KPiBIaSxmb2xrcw0KPiANCj4gQ29uc2lkZXJpbmcgdGhlIGxhcmdl LXNjYWxlIGJ1dCBzbWFsbC1zaXplZCBpbmZvcm1hdGlvbiBleGNoYW5nZSBpbiB0aGUgSU9ULCBp biBvcmRlciB0byBtYWtlIHRoZSBkYXRhIGdlbmVyYXRlZCBieSBJT1QgZGV2aWNlcyB0cmFuc21p c3Npb24gbW9yZSBlZmZpY2llbnQsIHdlIG1heSBuZWVkIGEgZGF0YSBhZ2dyZWdhdGlvbiBzY2hl bWUgaW4gSU9ULiANCj4gQ29uc2lkZXIgdGhpcyBzY2VuYXJpbzogaW4gYSBob21lIG5ldHdvcmsg bWF5IGNvbnNpc3Qgb2YgbWFueSBzZW5zb3JzLCBzdWNoIGFzIGxpZ2h0IHNlbnNvciwgbWV0ZXIs IGFuZCBmaXJlIGRldGVjdG9yLCBldGMsIGVhY2ggZnJhbWUgaGFzIHZlcnkgc21hbGwgcGF5bG9h ZCgxNSDigJMgMTAwIGJ5dGUpIGFuZCBsaW1pdCBudW1iZXIgb2YgZnJhbWVzIHBlciBkYXkoMTAp LiBJT1QgdXNlcnMgbmVlZCByZW1vdGUgYWNjZXNzIHRoZXNlIHNlbnNvcnMgZm9yIHRoZSBlYXN5 IG1hbmFnZW1lbnQgYW5kIHNhZmV0eSBvZiBob3VzZS4gSWYgaW5pdGlhdGUgYW4gaW50ZXJuZXQg dHJhbnNtaXNzaW9uIGZvciBldmVyeSBmcmFtZSBvZiBlYWNoIHNlbnNvciwgdGhlIHBheWxvYWQg bXVzdCBhY2NvdW50IHZlcnkgbG93IHBlcmNlbnQgb2YgdGhlIHdob2xlIGZyYW1lKGJlY2F1c2Ug b2YgdGhlIElQIGhlYWRlciwgTUFDIGhlYWRlciwgUEhZIGhlYWRlcikuIA0KPiBTbyxJTU8sIGRh dGEgZ2VuZXJhdGVkIGJ5IHNvbWUgSU9UIGRldmljZXMgc2hvdWxkIGJlIGFnZ3JlZ2F0ZWQgYXQg dGhlIHRyYW5zbWl0dGVyIGFuZCBkZS1hZ2dyZWdhdGVkIGJ5IHRoZSByZWNlaXZlciBmb3IgbW9y ZSBlZmZpY2llbnQuDQo+IA0KPiBSZWdhcmRzDQo+IFhpYW93ZWkgUWluDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFQyVFJHIG1haWxpbmcgbGlz dA0KPiBUMlRSR0BpcnRmLm9yZw0KPiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3QydHJnDQoNCg== From nobody Wed Apr 27 02:35:35 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A277A12D691 for ; Wed, 27 Apr 2016 02:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9YCQvb7u1q2 for ; Wed, 27 Apr 2016 02:35:30 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11E12D688 for ; Wed, 27 Apr 2016 02:35:29 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.43]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CJkDjVhyBXRypfCQ--.63735S2; Wed, 27 Apr 2016 17:35:17 +0800 (CST) Date: Wed, 27 Apr 2016 17:35:02 +0800 From: "qinxiaowei@cnnic.cn" To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <201604271503436945934@cnnic.cn>, <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2016042717350201316425@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart208761654038_=----" X-CM-TRANSID: AQAAf0CJkDjVhyBXRypfCQ--.63735S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WryfAF18GFyrKw48ZrW8WFg_yoW8Wr1Upw 48Gw1UKF1DGr1rJw1xWF48Ww1Yy393Aay8Gry5KryIy398A3WY9rZxtw45ury2k3s8XayY vFyagw1UAFn5ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQCb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAaz4v2 6cxKscIFY7kG0wAqx4xG6xAIxVCFxsxG0wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_ Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s 07Mx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41l4I8I 3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxV WUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAF wI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcI k0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_ Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUkrWFDUUUU X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Cc: t2trg Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:35:33 -0000 This is a multi-part message in MIME format. ------=_001_NextPart208761654038_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGnvvIwNCg0KSU1PLCBTZW5NTCAoU2Vuc29yIE1hcmt1cCBMYW5ndWFnZSkgbWF5IGJlIG9uZSBr aW5kIG9wZW4sIHRoZSBzZWxmIC0gZGVzY3JpcHRpb24gd2F5IGRlZmluaXRpb24gY29uc3RydWN0 aW9uIG9mIGRhdGEuIFNvLCBldmVyeSBJT1QgZGV2aWNlIGNhbiB1c2UgdGhlIGNvbW1vbiBTZW5N TCBkYXRhIG1vZGVsIHRvIHNlbmQgaW5mb3JtYXRpb24gYW5kIGVhY2ggdHJhbnNtaXNzaW9uIGNh biBzZW5kIGxhcmdlIGRhdGEuIEJ1dCwgZG9lcyBpdCBwbGFjZSBhIGJ1cmRlbiBvbiB0aGUgdHJh bnNwb3J0YXRpb24gc3lzdGVtIG9mIElPVD8gQWZ0ZXIgYWxsLCBpdCBuZWVkIHBhY2thZ2VkIGlu dG8gc2ltaWxhciB0byBYTUwgZG9jdW1lbnQ/IA0KSW5mb3JtYXRpb24gYWdncmVnYXRpb24gc2No ZW1lIGluIGludGVybmV0IG9mIHRoaW5ncyhJQVNJT1QpIGlzIGJhc2VkIG9uIElQIHBhY2tldC4g VGhlIGRhdGEgZ2VuZXJhdGVkIGJ5IElPVCBkZXZpY2VzIHdvdWxkIGJlIGFnZ3JlZ2F0ZWQgaW50 byBvbmUgZnJhbWUgY2hhaW4gYXQgc2VuZGVycywgd2hpY2ggYmVjb21lcyB0aGUgcGF5bG9hZChN QUMgZGF0YSkgb2YgdGhlIElQIHBhY2tldC4gDQpBbnkgbW9yZT8NCg0KQmVzdCB3aXNoZXMNClhp YW93ZWkgUWluDQoNCg0KDQogDQpGcm9tOiBBcmkgS2Vyw6RuZW4NCkRhdGU6IDIwMTYtMDQtMjcg MTU6NDENClRvOiBxaW54aWFvd2VpQGNubmljLmNuDQpDQzogVDJUUkdAaXJ0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbVDJUUkddIEluZm9ybWF0aW9uIGFnZ3JlZ2F0aW9uIGluIGludGVybmV0IG9mIHRo aW5ncw0KSGksDQogDQpJbmRlZWQgZGF0YSBhZ2dyZWdhdGlvbiBpcyBvbmUga2V5IG1lY2hhbmlz bSBmb3IgcmVkdWNpbmcgdGhlIG92ZXJoZWFkIGluIElvVCBzY2VuYXJpb3MuIFRoYXQncyB3aHkg Zm9yIGV4YW1wbGUgaW4gU2VuTUwgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNvcmUtc2VubWwtMDApIHdlIGhhdmUgcHV0IHF1aXRlIGEgbG90IG9mIGVmZm9ydCBpbnRv IG1ha2luZyBiYXRjaGVzIG9mIGRhdGEgZWZmaWNpZW50IGFuZCBzaW1wbGUgdG8gZXhjaGFuZ2Uu DQogDQogDQpDaGVlcnMsDQpBcmkNCiANCj4gT24gMjcgQXByIDIwMTYsIGF0IDEwOjAzLCBxaW54 aWFvd2VpQGNubmljLmNuIHdyb3RlOg0KPiANCj4gSGksZm9sa3MNCj4gDQo+IENvbnNpZGVyaW5n IHRoZSBsYXJnZS1zY2FsZSBidXQgc21hbGwtc2l6ZWQgaW5mb3JtYXRpb24gZXhjaGFuZ2UgaW4g dGhlIElPVCwgaW4gb3JkZXIgdG8gbWFrZSB0aGUgZGF0YSBnZW5lcmF0ZWQgYnkgSU9UIGRldmlj ZXMgdHJhbnNtaXNzaW9uIG1vcmUgZWZmaWNpZW50LCB3ZSBtYXkgbmVlZCBhIGRhdGEgYWdncmVn YXRpb24gc2NoZW1lIGluIElPVC4gDQo+IENvbnNpZGVyIHRoaXMgc2NlbmFyaW86IGluIGEgaG9t ZSBuZXR3b3JrIG1heSBjb25zaXN0IG9mIG1hbnkgc2Vuc29ycywgc3VjaCBhcyBsaWdodCBzZW5z b3IsIG1ldGVyLCBhbmQgZmlyZSBkZXRlY3RvciwgZXRjLCBlYWNoIGZyYW1lIGhhcyB2ZXJ5IHNt YWxsIHBheWxvYWQoMTUg4oCTIDEwMCBieXRlKSBhbmQgbGltaXQgbnVtYmVyIG9mIGZyYW1lcyBw ZXIgZGF5KDEwKS4gSU9UIHVzZXJzIG5lZWQgcmVtb3RlIGFjY2VzcyB0aGVzZSBzZW5zb3JzIGZv ciB0aGUgZWFzeSBtYW5hZ2VtZW50IGFuZCBzYWZldHkgb2YgaG91c2UuIElmIGluaXRpYXRlIGFu IGludGVybmV0IHRyYW5zbWlzc2lvbiBmb3IgZXZlcnkgZnJhbWUgb2YgZWFjaCBzZW5zb3IsIHRo ZSBwYXlsb2FkIG11c3QgYWNjb3VudCB2ZXJ5IGxvdyBwZXJjZW50IG9mIHRoZSB3aG9sZSBmcmFt ZShiZWNhdXNlIG9mIHRoZSBJUCBoZWFkZXIsIE1BQyBoZWFkZXIsIFBIWSBoZWFkZXIpLiANCj4g U28sSU1PLCBkYXRhIGdlbmVyYXRlZCBieSBzb21lIElPVCBkZXZpY2VzIHNob3VsZCBiZSBhZ2dy ZWdhdGVkIGF0IHRoZSB0cmFuc21pdHRlciBhbmQgZGUtYWdncmVnYXRlZCBieSB0aGUgcmVjZWl2 ZXIgZm9yIG1vcmUgZWZmaWNpZW50Lg0KPiANCj4gUmVnYXJkcw0KPiBYaWFvd2VpIFFpbg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUMlRSRyBt YWlsaW5nIGxpc3QNCj4gVDJUUkdAaXJ0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90MnRyZw0KIA0K ------=_001_NextPart208761654038_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi=EF=BC=8C

IMO, SenML (Sensor Markup Language) m= ay be one kind open, the self - description way definition construction of= data. So, every IOT device can use the common SenML data model to send in= formation and each transmission can send large data. But, does it place a = burden on the transportation system of IOT? After all, it need packaged in= to similar to XML document? 
Informat= ion aggregation scheme in internet of things(IASIOT) is based on IP packet= . The data generated by IOT devices would be aggregated into one frame cha= in at senders, which becomes the payload(MAC data) of the IP packet. =
Any more?

Best wishes
Xiaowei Qin


=0A
=0A
 
Date: 2016-04-27 15:41<= /div>
Subject: Re: [T2TRG] Information= aggregation in internet of things
Hi,
=0A=
 
=0A
Indeed data aggregation is one key mechanism for = reducing the overhead in IoT scenarios. That's why for example in SenML (h= ttps://tools.ietf.org/html/draft-ietf-core-senml-00) we have put quite a l= ot of effort into making batches of data efficient and simple to exchange.=
=0A
 
=0A
 
=0A
Cheers,
=0AAri
=0A
 
=0A
> On 27 Apr 2016, at 10:03, qinxi= aowei@cnnic.cn wrote:
=0A
>
=0A
> Hi,folks
= =0A
>
=0A
> Considering the large-scale but small-size= d information exchange in the IOT, in order to make the data generated by = IOT devices transmission more efficient, we may need a data aggregation sc= heme in IOT.
=0A
> Consider this scenario: in a home network = may consist of many sensors, such as light sensor, meter, and fire detecto= r, etc, each frame has very small payload(15 =E2=80=93 100 byte) and limit= number of frames per day(10). IOT users need remote access these sensors = for the easy management and safety of house. If initiate an internet trans= mission for every frame of each sensor, the payload must account very low = percent of the whole frame(because of the IP header, MAC header, PHY heade= r).
=0A
> So,IMO, data generated by some IOT devices should b= e aggregated at the transmitter and de-aggregated by the receiver for more= efficient.
=0A
>
=0A
> Regards
=0A
>= Xiaowei Qin
=0A
> ___________________________________________= ____
=0A
> T2TRG mailing list
=0A
> T2TRG@irtf.org=
=0A
> https://www.irtf.org/mailman/listinfo/t2trg
=0A 
=0A
=0A ------=_001_NextPart208761654038_=------ From nobody Wed Apr 27 02:41:55 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56E412D697 for ; Wed, 27 Apr 2016 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8zHLjrthqfC for ; Wed, 27 Apr 2016 02:41:51 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id BE22D12D5E9 for ; Wed, 27 Apr 2016 02:41:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,540,1454972400"; d="scan'208,217";a="3723200" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 27 Apr 2016 11:41:49 +0200 Received: from [132.227.125.154] (unknown [132.227.125.154]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 9914E23C for ; Wed, 27 Apr 2016 11:41:48 +0200 (CEST) To: t2trg@irtf.org References: <201604271503436945934@cnnic.cn> <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com> <2016042717350201316425@cnnic.cn> From: Soumya Kanti Datta Message-ID: <57208988.2000001@eurecom.fr> Date: Wed, 27 Apr 2016 15:12:32 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2016042717350201316425@cnnic.cn> Content-Type: multipart/alternative; boundary="------------050002040709010401040701" Archived-At: Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:41:54 -0000 This is a multi-part message in MIME format. --------------050002040709010401040701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Xiaowei, My replies inline. Regards, Soumya Research Engineer, EURECOM, France | +33658194342 | @skdatta2010 | https://sites.google.com/site/skdunfolded | Skype id: soumyakantidatta On 27-04-2016 15:05, qinxiaowei@cnnic.cn wrote: > Hi, > > IMO, SenML (Sensor Markup Language) may be one kind open, the self - > description way definition construction of data. So, every IOT device > can use the common SenML data model to send information and each > transmission can send large data. But, does it place a burden on the > transportation system of IOT? After all, it need packaged into similar > to XML document? [Soumya] SenML metadata can be encoded in JSON, CBOR or EXI. JSON encoding takes very minimal resources in IoT devices and not place so much burden on the transportation system (from my prototyping experience). > Information aggregation scheme in internet of things(IASIOT) is based > on IP packet. The data generated by IOT devices would be aggregated > into one frame chain at senders, which becomes the payload(MAC data) > of the IP packet. [Soumya] Depending on the scenario, you may need to process each data or the aggregated data. Having a local processing on the device could ease the process. > Any more? > > Best wishes > Xiaowei Qin > > ------------------------------------------------------------------------ > > *From:* Ari Keränen > *Date:* 2016-04-27 15:41 > *To:* qinxiaowei@cnnic.cn > *CC:* T2TRG@irtf.org > *Subject:* Re: [T2TRG] Information aggregation in internet of things > Hi, > Indeed data aggregation is one key mechanism for reducing the > overhead in IoT scenarios. That's why for example in SenML > (https://tools.ietf.org/html/draft-ietf-core-senml-00) we have put > quite a lot of effort into making batches of data efficient and > simple to exchange. > Cheers, > Ari > > On 27 Apr 2016, at 10:03, qinxiaowei@cnnic.cn wrote: > > > > Hi,folks > > > > Considering the large-scale but small-sized information exchange > in the IOT, in order to make the data generated by IOT devices > transmission more efficient, we may need a data aggregation scheme > in IOT. > > Consider this scenario: in a home network may consist of many > sensors, such as light sensor, meter, and fire detector, etc, each > frame has very small payload(15 – 100 byte) and limit number of > frames per day(10). IOT users need remote access these sensors for > the easy management and safety of house. If initiate an internet > transmission for every frame of each sensor, the payload must > account very low percent of the whole frame(because of the IP > header, MAC header, PHY header). > > So,IMO, data generated by some IOT devices should be aggregated > at the transmitter and de-aggregated by the receiver for more > efficient. > > > > Regards > > Xiaowei Qin > > _______________________________________________ > > T2TRG mailing list > > T2TRG@irtf.org > > https://www.irtf.org/mailman/listinfo/t2trg > > > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg --------------050002040709010401040701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Xiaowei,

My replies inline.

Regards,
Soumya
Research Engineer, EURECOM, France | +33658194342 | @skdatta2010 | 
https://sites.google.com/site/skdunfolded | Skype id: soumyakantidatta
On 27-04-2016 15:05, qinxiaowei@cnnic.cn wrote:
Hi,

IMO, SenML (Sensor Markup Language) may be one kind open, the self - description way definition construction of data. So, every IOT device can use the common SenML data model to send information and each transmission can send large data. But, does it place a burden on the transportation system of IOT? After all, it need packaged into similar to XML document?
[Soumya] SenML metadata can be encoded in JSON, CBOR or EXI. JSON encoding takes very minimal resources in IoT devices and not place so much burden on the transportation system (from my prototyping experience).
Information aggregation scheme in internet of things(IASIOT) is based on IP packet. The data generated by IOT devices would be aggregated into one frame chain at senders, which becomes the payload(MAC data) of the IP packet.
[Soumya] Depending on the scenario, you may need to process each data or the aggregated data. Having a local processing on the device could ease the process.
Any more?

Best wishes
Xiaowei Qin


 
Date: 2016-04-27 15:41
Subject: Re: [T2TRG] Information aggregation in internet of things
Hi,
 
Indeed data aggregation is one key mechanism for reducing the overhead in IoT scenarios. That's why for example in SenML (https://tools.ietf.org/html/draft-ietf-core-senml-00) we have put quite a lot of effort into making batches of data efficient and simple to exchange.
 
 
Cheers,
Ari
 
> On 27 Apr 2016, at 10:03, qinxiaowei@cnnic.cn wrote:
>
> Hi,folks
>
> Considering the large-scale but small-sized information exchange in the IOT, in order to make the data generated by IOT devices transmission more efficient, we may need a data aggregation scheme in IOT.
> Consider this scenario: in a home network may consist of many sensors, such as light sensor, meter, and fire detector, etc, each frame has very small payload(15 – 100 byte) and limit number of frames per day(10). IOT users need remote access these sensors for the easy management and safety of house. If initiate an internet transmission for every frame of each sensor, the payload must account very low percent of the whole frame(because of the IP header, MAC header, PHY header).
> So,IMO, data generated by some IOT devices should be aggregated at the transmitter and de-aggregated by the receiver for more efficient.
>
> Regards
> Xiaowei Qin
> _______________________________________________
> T2TRG mailing list
 


_______________________________________________
T2TRG mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

--------------050002040709010401040701-- From nobody Wed Apr 27 02:51:18 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0112D69D for ; Wed, 27 Apr 2016 02:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXgxSTvovK6e for ; Wed, 27 Apr 2016 02:51:15 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8A12D6A7 for ; Wed, 27 Apr 2016 02:51:15 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 24C43534A9A; Wed, 27 Apr 2016 11:45:20 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 245EFFB8BC; Wed, 27 Apr 2016 11:45:18 +0200 (CEST) Message-ID: <57208A2C.6090708@tzi.org> Date: Wed, 27 Apr 2016 11:45:16 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "qinxiaowei@cnnic.cn" References: <201604271503436945934@cnnic.cn>, <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com> <2016042717350201316425@cnnic.cn> In-Reply-To: <2016042717350201316425@cnnic.cn> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , t2trg Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:51:17 -0000 qinxiaowei@cnnic.cn wrote: > But, does it place a burden on the transportation system of IOT? After > all, it need packaged into similar to XML document? SenML, as its name suggests, started out as an XML format. This encoding alternative continues to be available, but -- reflecting industry trends from XML to JSON-based data models -- has recently been de-emphasized. The best way to use SenML in a constrained environment is to encode it in CBOR. Once you transition to a more powerful environment, you way want to transform data into equivalent JSON if you value ease-of-use over performance. Grüße, Carsten From nobody Wed Apr 27 04:00:46 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C5112D748 for ; Wed, 27 Apr 2016 04:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_TslmUlaKUC for ; Wed, 27 Apr 2016 04:00:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594D712D74B for ; Wed, 27 Apr 2016 04:00:41 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-6c-57209bd75b9a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.45.27088.7DB90275; Wed, 27 Apr 2016 13:00:39 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.248.2; Wed, 27 Apr 2016 13:00:39 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A3CA04F9B2; Wed, 27 Apr 2016 13:56:09 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3997B4E9B6; Wed, 27 Apr 2016 13:56:09 +0300 (EEST) To: Hannes Tschofenig References: <5706C210.6060902@gmx.net> From: Mohit Sethi Message-ID: <572099D6.5050308@ericsson.com> Date: Wed, 27 Apr 2016 13:52:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5706C210.6060902@gmx.net> Content-Type: multipart/alternative; boundary="------------070107090409060501030104" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7pe712QrhBuffWlss3XmP1eL9gx4W ByaPxZv2s3lM3niYLYApissmJTUnsyy1SN8ugStjdtMGtoJfohWXJz1kb2A8K9jFyMkhIWAi MfnDGzYIW0ziwr31YLaQwBFGiV1dLl2MXED2NkaJTzO2MEEk1jFKfFvqDpGYzyhx6elEsISw gIpEw/QpjCC2iIChxPWZ01khGtQkmv+cYQaxmQVUJaYeuscCYrMJ6El0njsOFucV0JZY++kd 2GYWoJquX9/BekUFIiRWr7sGVSMocXLmE7BeTgF1ieaJd4DiHEAzwyTWfLeFeEBN4uq5TcwQ a9UltnYcYJzAKDwLSfcshA4I017iwdayWWC3yUtsfzuHGcLWl7h+5z4rsvgCRrZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIExcnDLb4MdjC+fOx5iFOBgVOLhVZBVCBdiTSwrrsw9xCjB wawkwms3CyjEm5JYWZValB9fVJqTWnyIUZqDRUmcNzvyX5iQQHpiSWp2ampBahFMlomDU6qB kT9Da6PixQNtRzVb97aylS/p8lh/8yefzO9Al4mnGkRPLWxIcHK6qb2sf5HqjYq+y6vzj3W+ EuDlNbK8XznxX8wF/qPmu/4X3vXRyJuc0bm6Vtrpi+lVVun7K3Z+PFrnWRJbzyp1ln9WjHrT 08mnTx56miGktpVLWHNS9ynWyeG/G8rmxO5mUmIpzkg01GIuKk4EALWG85mNAgAA Archived-At: Cc: "t2trg@irtf.org" Subject: Re: [T2TRG] Device Identity X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 11:00:44 -0000 --------------070107090409060501030104 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes During the presentation of the IoT security bootstrapping survey draft you pointed out that the current definition of bootstrapping in the draft is not to your liking. You also pointed out that OIC/OCF has a better definition. To help the authors prepare the next version, could you kindly provide this definition by OIC/OCF (and any other definitions which you deem relevant). Thanks --Mohit On 04/07/2016 11:24 PM, Hannes Tschofenig wrote: > In his presentation Mohit used the term 'Device Identity'. > > I have heard this term in various conversation over the past few years > and I have the fear that there are different interpretations what it means. > > What does it mean for you, Mohit? > > Ciao > Hannes > > > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg --------------070107090409060501030104 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit Hi Hannes

During the presentation of the IoT security bootstrapping survey draft you pointed out that the current definition of bootstrapping in the draft is not to your liking. You also pointed out that OIC/OCF has a better definition.

To help the authors prepare the next version, could you kindly provide this definition by OIC/OCF (and any other definitions which you deem relevant).

Thanks
--Mohit


On 04/07/2016 11:24 PM, Hannes Tschofenig wrote:
In his presentation Mohit used the term 'Device Identity'.

I have heard this term in various conversation over the past few years
and I have the fear that there are different interpretations what it means.

What does it mean for you, Mohit?

Ciao
Hannes



_______________________________________________
T2TRG mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

--------------070107090409060501030104-- From nobody Wed Apr 27 20:46:01 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997BF12B061 for ; Wed, 27 Apr 2016 20:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgIgFKFmzVMy for ; Wed, 27 Apr 2016 20:45:57 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8B12D5D1 for ; Wed, 27 Apr 2016 20:45:55 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0DZ4DhshyFX_VZfCQ--.63104S2; Thu, 28 Apr 2016 11:45:48 +0800 (CST) Date: Thu, 28 Apr 2016 11:45:33 +0800 From: "qinxiaowei@cnnic.cn" To: "Soumya Kanti Datta" , t2trg References: <201604271503436945934@cnnic.cn>, <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com>, <2016042717350201316425@cnnic.cn>, <57208988.2000001@eurecom.fr> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2016042811453313999210@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart656236062663_=----" X-CM-TRANSID: AQAAf0DZ4DhshyFX_VZfCQ--.63104S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJFy3Cry3Ar1xAF48tryfXrb_yoW5Aw15pF WUGF43KF4kGr18Jw1kZF48Wr1Fy395Aay8Gry3tryIya9xCFyY9r4ft3yruFy7Cry5Ww1Y yF1Y9w4UZr1kZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdGb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kE wI0EY4vaYxAvb48xMc02F40E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcV AYj21l5I8CrVC20s02628v4x8GjsIEw4AK0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2 IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCjr7xvwVCIw2I0I7xG6c02F41l c2xSY4AK67AK6r48MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I 0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU XVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcS sGvfC2KfnxnUUI43ZEXa7IUYeSotUUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 03:45:59 -0000 This is a multi-part message in MIME format. ------=_001_NextPart656236062663_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgU291bXlhLA0KPltTb3VteWFdIFNlbk1MIG1ldGFkYXRhIGNhbiBiZSBlbmNvZGVkIGluIEpT T04sIENCT1Igb3IgRVhJLiBKU09OIGVuY29kaW5nIHRha2VzIHZlcnkgbWluaW1hbCByZXNvdXJj ZXMgaW4gSW9UIGRldmljZXMgYW5kIG5vdCBwbGFjZSBzbyBtdWNoIGJ1cmRlbiBvbiB0aGUgdHJh bnNwb3J0YXRpb24gc3lzdGVtIChmcm9tIG15ID5wcm90b3R5cGluZyBleHBlcmllbmNlKS4NCk9L LCAgSSBoYXZlIGdvdCBpdC4gU2VuTUwgZm9jdXMgb24g4oCcZGF0YSBlbmNhcHN1bGF0aW9uIiwg YW5kIGF0dGVtcHRzIHRvIGdpdmUgYSBnZW5lcmFsIOKAnGRhdGEgbW9kdWxlIiAgZm9yIHNlbWFu dGljIGludGVyb3BlcmFiaWxpdHkgb2YgSU9ULiANCg0KPltTb3VteWFdIERlcGVuZGluZyBvbiB0 aGUgc2NlbmFyaW8sIHlvdSBtYXkgbmVlZCB0byBwcm9jZXNzIGVhY2ggZGF0YSBvciB0aGUgYWdn cmVnYXRlZCBkYXRhLiBIYXZpbmcgYSBsb2NhbCBwcm9jZXNzaW5nIG9uIHRoZSBkZXZpY2UgY291 bGQgZWFzZSB0aGUgcHJvY2Vzcy4NCg0KWWVzLCB0aGF0J3MgZXhhY3RseSB3aGF0IGkgbWVhbnMs IHRoZSBkYXRhIGdlbmVyYXRlZCBieSBJT1QgZGV2aWNlcyBzaG91bGQgYmUgc3RvcmVkIHRvIGxv Y2FsIGNhY2hlKGlmIHVzZSBhZ2dyZWdhdGlvbiBzY2hlbWUpLiANCkJhc2VkIG9uIENST1NTQk9X IHNlbnNvcnMsIEkgZGlkIGFuIGludGVsbGlnZW50IGFncmljdWx0dXJhbCBzeXN0ZW0gZm9yIGZh cm1zIGluIEJlaWppbmcuIEluIGVhY2ggZ3JlZW5ob3VzZXMgdGhlcmUgYXJlIG1hbnkgc2Vuc29y cyhzdWNoIGFzIHRlbXBlcmF0dXJlLCBodW1pZGl0eSwgZXRjLikgLCBhbmQgdGhlc2Ugc2Vuc29y LWdlbmVyYXRlLWRhdGEgYXJlIHNlbmQgdG8gQ2x1c3RlciBIZWFkZXIoZ2F0ZXdheSkgYnkgU2Vu c29yIE5vZGUgb2YgQ1JPU1NCT1cuIFRoZSBDbHVzdGVyIEhlYWRlciB3aWxsIHN0b3JlIHRoZXNl IGRhdGEgdGVtcG9yYXJpbHkgYW5kIGVuY2Fwc3VsYXRlIHRoZW0gaW50byBhbiBhZ2dyZWdhdGlv biBjaGFpbi4gQXQgbGFzdCwgdGhlIGFnZ3JlZ2F0aW9uIGNoYWluIHdpbGwgYmUgdHJhbnNtaXR0 ZWQgdXNpbmcgV0NETUEuIA0KQnkgZG9pbmcgdGhpcywgaXQgc2ltcGxpZnkgaW1wbGVtZW50YXRp b24gYXMgd2VsbCBhcyB0byBsb3dlciB0aGUgY29zdChiZWNhdXNlIHNvbWUgZ3JlZW5ob3VzZSBj YW4gbm90IGNvbm5lY3QgdG8gaW50ZXJuZXQgdGhyb3VnaCB3aXJlZCBsaW5lLCBpZiBpbml0aWF0 ZWQgZXZlcnkgdHJhbnNtaXNzaW9uIGZvciBlYWNoIGRhdGEgb2Ygc2Vuc29yLCB0aGF0IHdvdWxk IGJlIGEgd2FzdGUgb2YgYmFuZHdpZHRoICkuDQoNClJlZ2FyZHMNClhpYW93ZWkgUWluIA0KDQoN Cg0KDQoNCiANCkZyb206IFNvdW15YSBLYW50aSBEYXR0YQ0KRGF0ZTogMjAxNi0wNC0yNyAxODox Mg0KVG86IHQydHJnDQpTdWJqZWN0OiBSZTogW1QyVFJHXSBJbmZvcm1hdGlvbiBhZ2dyZWdhdGlv biBpbiBpbnRlcm5ldCBvZiB0aGluZ3MNCkhpIFhpYW93ZWksDQoNCk15IHJlcGxpZXMgaW5saW5l Lg0KDQpSZWdhcmRzLA0KU291bXlhDQpSZXNlYXJjaCBFbmdpbmVlciwgRVVSRUNPTSwgRnJhbmNl IHwgKzMzNjU4MTk0MzQyIHwgQHNrZGF0dGEyMDEwIHwgCmh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNv bS9zaXRlL3NrZHVuZm9sZGVkIHwgU2t5cGUgaWQ6IHNvdW15YWthbnRpZGF0dGENCk9uIDI3LTA0 LTIwMTYgMTU6MDUsIHFpbnhpYW93ZWlAY25uaWMuY24gd3JvdGU6DQpIae+8jA0KDQpJTU8sIFNl bk1MIChTZW5zb3IgTWFya3VwIExhbmd1YWdlKSBtYXkgYmUgb25lIGtpbmQgb3BlbiwgdGhlIHNl bGYgLSBkZXNjcmlwdGlvbiB3YXkgZGVmaW5pdGlvbiBjb25zdHJ1Y3Rpb24gb2YgZGF0YS4gU28s IGV2ZXJ5IElPVCBkZXZpY2UgY2FuIHVzZSB0aGUgY29tbW9uIFNlbk1MIGRhdGEgbW9kZWwgdG8g c2VuZCBpbmZvcm1hdGlvbiBhbmQgZWFjaCB0cmFuc21pc3Npb24gY2FuIHNlbmQgbGFyZ2UgZGF0 YS4gQnV0LCBkb2VzIGl0IHBsYWNlIGEgYnVyZGVuIG9uIHRoZSB0cmFuc3BvcnRhdGlvbiBzeXN0 ZW0gb2YgSU9UPyBBZnRlciBhbGwsIGl0IG5lZWQgcGFja2FnZWQgaW50byBzaW1pbGFyIHRvIFhN TCBkb2N1bWVudD8gDQpbU291bXlhXSBTZW5NTCBtZXRhZGF0YSBjYW4gYmUgZW5jb2RlZCBpbiBK U09OLCBDQk9SIG9yIEVYSS4gSlNPTiBlbmNvZGluZyB0YWtlcyB2ZXJ5IG1pbmltYWwgcmVzb3Vy Y2VzIGluIElvVCBkZXZpY2VzIGFuZCBub3QgcGxhY2Ugc28gbXVjaCBidXJkZW4gb24gdGhlIHRy YW5zcG9ydGF0aW9uIHN5c3RlbSAoZnJvbSBteSBwcm90b3R5cGluZyBleHBlcmllbmNlKS4NCklu Zm9ybWF0aW9uIGFnZ3JlZ2F0aW9uIHNjaGVtZSBpbiBpbnRlcm5ldCBvZiB0aGluZ3MoSUFTSU9U KSBpcyBiYXNlZCBvbiBJUCBwYWNrZXQuIFRoZSBkYXRhIGdlbmVyYXRlZCBieSBJT1QgZGV2aWNl cyB3b3VsZCBiZSBhZ2dyZWdhdGVkIGludG8gb25lIGZyYW1lIGNoYWluIGF0IHNlbmRlcnMsIHdo aWNoIGJlY29tZXMgdGhlIHBheWxvYWQoTUFDIGRhdGEpIG9mIHRoZSBJUCBwYWNrZXQuIA0KW1Nv dW15YV0gRGVwZW5kaW5nIG9uIHRoZSBzY2VuYXJpbywgeW91IG1heSBuZWVkIHRvIHByb2Nlc3Mg ZWFjaCBkYXRhIG9yIHRoZSBhZ2dyZWdhdGVkIGRhdGEuIEhhdmluZyBhIGxvY2FsIHByb2Nlc3Np bmcgb24gdGhlIGRldmljZSBjb3VsZCBlYXNlIHRoZSBwcm9jZXNzLg0KQW55IG1vcmU/DQoNCkJl c3Qgd2lzaGVzDQpYaWFvd2VpIFFpbg0KDQoNCg0KIA0KRnJvbTogQXJpIEtlcsOkbmVuDQpEYXRl OiAyMDE2LTA0LTI3IDE1OjQxDQpUbzogcWlueGlhb3dlaUBjbm5pYy5jbg0KQ0M6IFQyVFJHQGly dGYub3JnDQpTdWJqZWN0OiBSZTogW1QyVFJHXSBJbmZvcm1hdGlvbiBhZ2dyZWdhdGlvbiBpbiBp bnRlcm5ldCBvZiB0aGluZ3MNCkhpLA0KIA0KSW5kZWVkIGRhdGEgYWdncmVnYXRpb24gaXMgb25l IGtleSBtZWNoYW5pc20gZm9yIHJlZHVjaW5nIHRoZSBvdmVyaGVhZCBpbiBJb1Qgc2NlbmFyaW9z LiBUaGF0J3Mgd2h5IGZvciBleGFtcGxlIGluIFNlbk1MIChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLTAwKSB3ZSBoYXZlIHB1dCBxdWl0ZSBhIGxvdCBv ZiBlZmZvcnQgaW50byBtYWtpbmcgYmF0Y2hlcyBvZiBkYXRhIGVmZmljaWVudCBhbmQgc2ltcGxl IHRvIGV4Y2hhbmdlLg0KIA0KIA0KQ2hlZXJzLA0KQXJpDQogDQo+IE9uIDI3IEFwciAyMDE2LCBh dCAxMDowMywgcWlueGlhb3dlaUBjbm5pYy5jbiB3cm90ZToNCj4gDQo+IEhpLGZvbGtzDQo+IA0K PiBDb25zaWRlcmluZyB0aGUgbGFyZ2Utc2NhbGUgYnV0IHNtYWxsLXNpemVkIGluZm9ybWF0aW9u IGV4Y2hhbmdlIGluIHRoZSBJT1QsIGluIG9yZGVyIHRvIG1ha2UgdGhlIGRhdGEgZ2VuZXJhdGVk IGJ5IElPVCBkZXZpY2VzIHRyYW5zbWlzc2lvbiBtb3JlIGVmZmljaWVudCwgd2UgbWF5IG5lZWQg YSBkYXRhIGFnZ3JlZ2F0aW9uIHNjaGVtZSBpbiBJT1QuIA0KPiBDb25zaWRlciB0aGlzIHNjZW5h cmlvOiBpbiBhIGhvbWUgbmV0d29yayBtYXkgY29uc2lzdCBvZiBtYW55IHNlbnNvcnMsIHN1Y2gg YXMgbGlnaHQgc2Vuc29yLCBtZXRlciwgYW5kIGZpcmUgZGV0ZWN0b3IsIGV0YywgZWFjaCBmcmFt ZSBoYXMgdmVyeSBzbWFsbCBwYXlsb2FkKDE1IOKAkyAxMDAgYnl0ZSkgYW5kIGxpbWl0IG51bWJl ciBvZiBmcmFtZXMgcGVyIGRheSgxMCkuIElPVCB1c2VycyBuZWVkIHJlbW90ZSBhY2Nlc3MgdGhl c2Ugc2Vuc29ycyBmb3IgdGhlIGVhc3kgbWFuYWdlbWVudCBhbmQgc2FmZXR5IG9mIGhvdXNlLiBJ ZiBpbml0aWF0ZSBhbiBpbnRlcm5ldCB0cmFuc21pc3Npb24gZm9yIGV2ZXJ5IGZyYW1lIG9mIGVh Y2ggc2Vuc29yLCB0aGUgcGF5bG9hZCBtdXN0IGFjY291bnQgdmVyeSBsb3cgcGVyY2VudCBvZiB0 aGUgd2hvbGUgZnJhbWUoYmVjYXVzZSBvZiB0aGUgSVAgaGVhZGVyLCBNQUMgaGVhZGVyLCBQSFkg aGVhZGVyKS4gDQo+IFNvLElNTywgZGF0YSBnZW5lcmF0ZWQgYnkgc29tZSBJT1QgZGV2aWNlcyBz aG91bGQgYmUgYWdncmVnYXRlZCBhdCB0aGUgdHJhbnNtaXR0ZXIgYW5kIGRlLWFnZ3JlZ2F0ZWQg YnkgdGhlIHJlY2VpdmVyIGZvciBtb3JlIGVmZmljaWVudC4NCj4gDQo+IFJlZ2FyZHMNCj4gWGlh b3dlaSBRaW4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gVDJUUkcgbWFpbGluZyBsaXN0DQo+IFQyVFJHQGlydGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vdDJ0cmcNCiANCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUMlRSRyBtYWlsaW5nIGxpc3QKVDJUUkdA aXJ0Zi5vcmcKaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90MnRyZwoNCg== ------=_001_NextPart656236062663_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A = =0A =0A
Hi Soumya,
>[Soumya] SenML met= adata can be encoded in JSON, CBOR or EXI. JSON encoding takes very minima= l resources in IoT devices and not place so much burden on the transportat= ion system (from my >prototyping experience).
OK, &nbs= p;I have got it. SenML focus on =E2=80=9Cdata encapsulation", an= d attempts to give a general =E2=80=9Cdata module"  for semantic inte= roperability of IOT. 

>= ;[Soumya] Depending on the scenario, you may need to process each data or = the aggregated data. Having a local processing on the device could ease th= e process.

Yes, that's exactly what i means, the data generated by IOT = devices should be stored to local cache(if use aggregation scheme). =0ABased on CROSSBOW sensors, I did an intelligent agricultural system for f= arms in Beijing. In each greenhouses there are many sensors(such as temper= ature, humidity, etc.) , and these sensor-generate-data are send to Cluste= r Header(gateway) by Sensor Node of CROSSBOW. The Cluster Header will stor= e these data temporarily and encapsulate them into an aggregation chain. A= t last, the aggregation chain will be transmitted using WCDMA.=0A
By do= ing this, it simplify implementation as well as to lower the cost(because = some greenhouse can not connect to internet through wired line, if initiat= ed every transmission for each data of sensor, that would be a waste of ba= ndwidth ).

Regards
Xiaowei Qin 


=0A


=0A
=0A
 
From:&nb= sp;Soumya Kanti Datta=
Date: 2016-04-27 18:12
To:&nb= sp;t2trg
Subject:&n= bsp;Re: [T2TRG] Information aggregation in internet of things
<= /div>
=0A =0A =0A =0A = =0A Hi Xiaowei,
=0A
=0A My replies inline.
=0A
= =0A Regards,
=0A Soumya
=0A
Research Engineer, EURECOM, France | +33658194342 | @skdatta2010=
 | =0Ahttps://sites.google.com/site/skdunfolded | Skype id=
: soumyakantidatta
=0A
On 27-04-201= 6 15:05,=0A qinxiaowei@cnnic.cn wrote:
=0A
=0A =0A =0A= =0A
Hi= =EF=BC=8C
=0A

=0A
=0A
IMO, SenML (Sen= sor Markup Language) may be one kind open,=0A the self - descript= ion way definition construction of data.=0A So, every IOT device = can use the common SenML data model to=0A send information and ea= ch transmission can send large data.=0A But, does it place a burd= en on the transportation system of=0A IOT? After all, it need pac= kaged into similar to XML document?=0A
=0A =0A
=0A [Soumya] SenML metadata can be encoded in JSO= N, CBOR or EXI. JSON=0A encoding takes very minimal resources in IoT de= vices and not place=0A so much burden on the transportation system (fro= m my prototyping=0A experience).
=0A
=0A
Information aggregation scheme in=0A internet of things(IASIOT= ) is based on IP packet. The data=0A generated by IOT devices wou= ld be aggregated into one frame=0A chain at senders, which become= s the payload(MAC data) of the=0A IP packet.
=0A
=0A
=0A [Soumya] Depending on the scenario, you= may need to process each=0A data or the aggregated data. Having a loca= l processing on the device=0A could ease the process.
=0A =0A
Any= more?
=0A

=0A
=0A
Best wishes=0A
Xiaowei Qin
=0A
=
=0A
=0A
=0A
=0A
=0A
 
=0A =
=0A
=0A =0A =
Date: 2016-04-27 15:41
=0A To: qinxiaowei@cnnic.cn
=0A
CC: T2TRG@irtf.org
=0A
Subject: Re: [T2TRG] Information ag= gregation in=0A internet of things
=0A
= =0A
=0A
=0A
Hi,
=0A <= div> 
=0A
Indeed data aggregation is one key mecha= nism for reducing=0A the overhead in IoT scenarios. That's why = for example in=0A SenML (https://tools.i= etf.org/html/draft-ietf-core-senml-00)=0A we have put quite= a lot of effort into making batches of=0A data efficient and s= imple to exchange.
=0A
 
=0A
&n= bsp;
=0A
Cheers,
=0A
Ari
=0A =
 
=0A
> On 27 Apr 2016, at 10:03, <= a class=3D"moz-txt-link-abbreviated" href=3D"mailto:qinxiaowei@cnnic.cn">q= inxiaowei@cnnic.cn wrote:
=0A
>
=0A =
> Hi,folks
=0A
>
=0A
= > Considering the large-scale but small-sized=0A information= exchange in the IOT, in order to make the data=0A generated by= IOT devices transmission more efficient, we may=0A need a data= aggregation scheme in IOT.
=0A
> Consider this sce= nario: in a home network may=0A consist of many sensors, such a= s light sensor, meter, and=0A fire detector, etc, each frame ha= s very small payload(15 =E2=80=93=0A 100 byte) and limit number= of frames per day(10). IOT users=0A need remote access these s= ensors for the easy management and=0A safety of house. If initi= ate an internet transmission for=0A every frame of each sensor,= the payload must account very=0A low percent of the whole fram= e(because of the IP header, MAC=0A header, PHY header).
= =0A
> So,IMO, data generated by some IOT devices should b= e=0A aggregated at the transmitter and de-aggregated by the=0A = receiver for more efficient.
=0A
>
= =0A
> Regards
=0A
> Xiaowei Qin=0A
> _______________________________________________=0A
> T2TRG mailing list
=0A =0A =0A
 
=0A =
=0A =0A
=0A
=0A
=0A
_______=
________________________________________=0AT2TRG mailing list=0AT2TRG@irtf.or=
g=0Ahttps://www.irtf.org/mailman/listinfo/t2trg=0A=0A    =0A    
=0A =0A
=0A ------=_001_NextPart656236062663_=------ From nobody Wed Apr 27 20:55:30 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A430612D599 for ; Wed, 27 Apr 2016 20:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7arIJlZd_t9 for ; Wed, 27 Apr 2016 20:55:28 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id EC5F312D0C3 for ; Wed, 27 Apr 2016 20:55:27 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIFSpiSFXb1dfCQ--.662S2; Thu, 28 Apr 2016 11:55:21 +0800 (CST) Date: Thu, 28 Apr 2016 11:55:06 +0800 From: "qinxiaowei@cnnic.cn" To: "Carsten Bormann" References: <201604271503436945934@cnnic.cn>, <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com>, <2016042717350201316425@cnnic.cn>, <57208A2C.6090708@tzi.org> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2016042811550632056114@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart481720841858_=----" X-CM-TRANSID: AQAAf0AZIFSpiSFXb1dfCQ--.662S2 X-Coremail-Antispam: 1UD129KBjvdXoW7JrWDWryxuFWxZry3XFyxZrb_yoWfWrb_X3 47tryY9Fn0y39Fq3yUKr1UZF4q9ay8KFWvv3W3XFWUK34vvrZ5JryqgF92qw40q3ZYkwnI 93ZIkr93Kr4a9jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbWxYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40En4AK xVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67 k08wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6xIIjxv20xvE14v26r106r15McIj6I8E 87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0V AYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I8CrwCY 02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y 6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcS sGvfC2KfnxnUUI43ZEXa7IU0zMNUUUUUU== X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , t2trg Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 03:55:29 -0000 This is a multi-part message in MIME format. ------=_001_NextPart481720841858_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGnvvIwNCj5UaGUgYmVzdCB3YXkgdG8gdXNlIFNlbk1MIGluIGEgY29uc3RyYWluZWQgZW52aXJv bm1lbnQgaXMgdG8gZW5jb2RlIGl0IGluIENCT1IuDQoNCkluIHRoaXMgc2NlbmFyaW8sIHdobyBp cyB0aGUgImV4ZWN1dG9yIj8gSSBtZWFuIHdobyBlbmNvZGUgaXQgaW50byBDQlJPLCBzZW5zb3Jz IG9yIGdhdGV3YXksIG9yIGFueSBvdGhlciBJT1QgZGV2aWNlcz8gSU1PLCBhIGxvdCBvZiBJT1Qg c2Vuc29ycyBoYXZlIHZlcnkgbG93IGNhcGFjaXR5LCB2ZXJ5IHNtYWxsIHBheWxvYWQoMTUg4oCT IDEwMCBieXRlKSBhbmQgbGltaXQgbnVtYmVyIG9mIGZyYW1lcyBwZXIgZGF5KDEwIG9yIGxlc3Mp Lg0KDQpYaWFvd2VpDQoNCg0KIA0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uDQpEYXRlOiAyMDE2LTA0 LTI3IDE3OjQ1DQpUbzogcWlueGlhb3dlaUBjbm5pYy5jbg0KQ0M6IEFyaSBLZXLDpG5lbjsgdDJ0 cmcNClN1YmplY3Q6IFJlOiBbVDJUUkddIEluZm9ybWF0aW9uIGFnZ3JlZ2F0aW9uIGluIGludGVy bmV0IG9mIHRoaW5ncw0KcWlueGlhb3dlaUBjbm5pYy5jbiB3cm90ZToNCj4gQnV0LCBkb2VzIGl0 IHBsYWNlIGEgYnVyZGVuIG9uIHRoZSB0cmFuc3BvcnRhdGlvbiBzeXN0ZW0gb2YgSU9UPyBBZnRl cg0KPiBhbGwsIGl0IG5lZWQgcGFja2FnZWQgaW50byBzaW1pbGFyIHRvIFhNTCBkb2N1bWVudD8g DQogDQpTZW5NTCwgYXMgaXRzIG5hbWUgc3VnZ2VzdHMsIHN0YXJ0ZWQgb3V0IGFzIGFuIFhNTCBm b3JtYXQuDQpUaGlzIGVuY29kaW5nIGFsdGVybmF0aXZlIGNvbnRpbnVlcyB0byBiZSBhdmFpbGFi bGUsIGJ1dCAtLSByZWZsZWN0aW5nDQppbmR1c3RyeSB0cmVuZHMgZnJvbSBYTUwgdG8gSlNPTi1i YXNlZCBkYXRhIG1vZGVscyAtLSBoYXMgcmVjZW50bHkgYmVlbg0KZGUtZW1waGFzaXplZC4NCiAN ClRoZSBiZXN0IHdheSB0byB1c2UgU2VuTUwgaW4gYSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCBp cyB0byBlbmNvZGUgaXQNCmluIENCT1IuDQpPbmNlIHlvdSB0cmFuc2l0aW9uIHRvIGEgbW9yZSBw b3dlcmZ1bCBlbnZpcm9ubWVudCwgeW91IHdheSB3YW50IHRvDQp0cmFuc2Zvcm0gZGF0YSBpbnRv IGVxdWl2YWxlbnQgSlNPTiBpZiB5b3UgdmFsdWUgZWFzZS1vZi11c2Ugb3Zlcg0KcGVyZm9ybWFu Y2UuDQogDQpHcsO8w59lLCBDYXJzdGVuDQo= ------=_001_NextPart481720841858_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi=EF=BC=8C
=
>The best way to use SenML in a constrained environment is to enco= de it in CBOR.

In this scenario, who= is the "executor"? I mean who encode it into CBRO, sensors or gateway, or= any other IOT devices? IMO, a lot of IOT sensors have very low capacity,= very small payload(15 =E2=80=93 100 byte) and limit number of frames per= day(10 or less).
=0A

Xiaowei

=0A
=0A
 
Date: 2016-04-27 17:45
Subject: Re: [T2TRG] Information aggregation in int= ernet of things
qinxiaowei@cnnic.cn wrote:=0A
> But, does it place a burden on the transportation system of = IOT? After
=0A
> all, it need packaged into similar to XML doc= ument?
=0A
 
=0A
SenML, as its name suggests, star= ted out as an XML format.
=0A
This encoding alternative continues= to be available, but -- reflecting
=0A
industry trends from XML = to JSON-based data models -- has recently been
=0A
de-emphasized.=
=0A
 
=0A
The best way to use SenML in a constrain= ed environment is to encode it
=0A
in CBOR.
=0A
Once you= transition to a more powerful environment, you way want to
=0A
t= ransform data into equivalent JSON if you value ease-of-use over
=0A<= div>performance.
=0A
 
=0A
Gr=C3=BC=C3=9Fe, Carsten=
=0A
=0A ------=_001_NextPart481720841858_=------ From nobody Wed Apr 27 22:57:08 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5512D5D4 for ; Wed, 27 Apr 2016 22:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7inhz7A31Lp for ; Wed, 27 Apr 2016 22:57:04 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF5E12D5AF for ; Wed, 27 Apr 2016 22:57:04 -0700 (PDT) Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D9840A80E9; Thu, 28 Apr 2016 07:57:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id DHB5GM2UjlbC; Thu, 28 Apr 2016 07:57:01 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B069EA80E1; Thu, 28 Apr 2016 07:57:00 +0200 (CEST) Message-ID: <5721A62A.70901@tzi.org> Date: Thu, 28 Apr 2016 07:56:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "qinxiaowei@cnnic.cn" References: <201604271503436945934@cnnic.cn>, <26DBDAB4-6D8B-497E-BB10-61B7B7C25FB4@ericsson.com>, <2016042717350201316425@cnnic.cn>, <57208A2C.6090708@tzi.org> <2016042811550632056114@cnnic.cn> In-Reply-To: <2016042811550632056114@cnnic.cn> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: t2trg Subject: Re: [T2TRG] Information aggregation in internet of things X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 05:57:08 -0000 qinxiaowei@cnnic.cn wrote: > Hi, >>The best way to use SenML in a constrained environment is to encode > it in CBOR. > > In this scenario, who is the "executor"? I mean who encode it into CBRO, > sensors or gateway, or any other IOT devices? As the name implies, SenML was originally designed for collecting data from sensors. Gateways and other aggregation/processing may use SenML on both sides. SenML could also be used to send information to actuators, even if we haven't discussed this very much. > IMO, a lot of IOT sensors > have very low capacity, very small payload(15 – 100 byte) That is exactly where CBOR was designed for. > and limit > number of frames per day(10 or less). Now this would a "millibit" scenario (not all of IoT happens in "LP-WANs"), but CBOR still applies. Grüße, Carsten From nobody Thu Apr 28 01:57:09 2016 Return-Path: X-Original-To: t2trg@ietfa.amsl.com Delivered-To: t2trg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593BC12B044 for ; Thu, 28 Apr 2016 01:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow9cgYSQdv1W for ; Thu, 28 Apr 2016 01:57:06 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84DF71200A0 for ; Thu, 28 Apr 2016 01:57:01 -0700 (PDT) Received: from CNNIC-PC (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMDhd0CFX9GBfCQ--.930S2; Thu, 28 Apr 2016 16:57:01 +0800 (CST) Date: Thu, 28 Apr 2016 16:56:46 +0800 From: "qinxiaowei@cnnic.cn" To: t2trg X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2016042816564623686328@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart434280330644_=----" X-CM-TRANSID: AQAAf0ApMDhd0CFX9GBfCQ--.930S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUOt7k0a2IF6w4kM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j 6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26r xl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv 0487Mc02F40En4AKxVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24l5I8CrVC2j2CEjI02cc xYII8I67AEr4CY67k08wAqx4xG6I8I3I0E8cIF7480aVAKz4kxMcIj6xIIjxv20xvE14v2 6r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2 Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK 67AK6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r1j 6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa 73UjIFyTuYvjxUySAJUUUUU X-CM-SenderInfo: xtlq5x5drzvxw6fq0xffof0/ Archived-At: Subject: [T2TRG] Fw: Some practical deployment experience of data aggregation in IOT/LP_WAN X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 08:57:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart434280330644_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGnvvIxmb2xrcw0KDQpJIGFtIGdsYWQgdG8gaW50cm9kdWNlIG15IGV4aXN0aW5nIGRlcGxveW1l bnQgZXhwZXJpZW5jZSBhcyBtZW50aW9uZWQgeWVzdGVyZGF5Lg0KU2luY2UgMjAxMiwgSSBoYXZl IGJlZW4gZGVwbG95aW5nIGludGVsbGlnZW50IGFncmljdWx0dXJhbCBzeXN0ZW1zIGZvciBzb21l IGZhcm1zLiBBdCBiZWdpbm5pbmcsIEkgdXNlZCBDUk9TU0JPVydzIHNlbnNvcnMgYW5kIG5vZGVz LCBub3csSSBhbHNvIHVzZSBvdGhlciBjb21wYW55cycgcHJvZHVjdHMuIA0KSW4gZWFjaCBncmVl bmhvdXNlIHRoZXJlIGFyZSBtYW55IHNlbnNvcnMgc3VjaCBhcyB0ZW1wZXJhdHVyZSwgaHVtaWRp dHksIGFuZCBvbmUgQ2x1c3RlciBIZWFkZXIoZ2F0ZXdheSkuIE9uZSBvciBtb3JlIHNlbnNvcnMg d2VyZSBpbnRlZ3JhdGVkIGludG8gb25lIHdpcmVsZXNzIG5vZGUgd2hpY2ggd2VyZSBjb250cm9s bGVkIGJ5IFRpbnlPUy4gU2Vuc29yLWdlbmVyYXRlLWRhdGEgaXMgZmlyc3QgdHJhbnNtaXR0ZWQg dG8gdGhlIENsdXN0ZXIgSGVhZGVyIGJ5IHdpcmVsZXNzIG5vZGUgdmlhIDgwMi4xNS40IHByb3Rv Y29sIGFuZCBwcml2YXRlIG1lc2ggcHJvdG9jb2wuIFRoZSBDbHVzdGVyIEhlYWRlciBmb3J3YXJk IHRoZXNlIHNlbnNvci1nZW5lcmF0ZS1kYXRhIHRvIGEgZ2F0ZXdheSB0aHJvdWdoIFVTQiBwb3J0 KHBsMjMwMyBvciBGVERJKS4gVGhlIGdhdGV3YXkgd2lsbCBzdG9yZSB0aGVzZSBkYXRhIHRlbXBv cmFyaWx5IGFuZCB0aGVuIGVuY2Fwc3VsYXRlIHRoZW0gaW50byBhbiBhZ2dyZWdhdGlvbiBjaGFp biBhbmQgYXQgdGhlIGxhc3Qgc2VuZCB0aGUgYWdncmVnYXRpb24gY2hhaW4gdG8gYWN0dWFsIGRl c3RpbmF0aW9uIHRocm91Z2ggV0NETUEuDQpCeSBkb2luZyB0aGlzLCBpdCBzaW1wbGlmeSBpbXBs ZW1lbnRhdGlvbiBhcyB3ZWxsIGFzIHRvIGxvd2VyIHRoZSBjb3N0IGJlY2F1c2Ugc29tZSBncmVl bmhvdXNlcyBjYW4gbm90IGNvbm5lY3QgdG8gaW50ZXJuZXQgdGhyb3VnaCB3aXJlZCBsaW5lLiBJ dCB3b3VsZCBiZSBhIHdhc3RlIG9mIGJhbmR3aWR0aCBpZiBpbml0aWF0ZWQgdGhlIHRyYW5zbWlz c2lvbiBmb3IgZXZlcnkgc2Vuc29yJ3MgZnJhbWUuIEJlY2F1c2UgZWFjaCBzZW5zb3ItZ2VuZXJh dGUtZGF0YSBpcyB2ZXJ5IHNtYWxsOiBUaW55T1MgaGVhZGVyKDUgYnl0ZXMpLCBYbWVzaCBIZWFk ZXIoMC83IGJ5dGVzKSwgQWRkcmVzcyBpbmZvcm1hdGlvbiBhbmQgU2VxdWVuY2UgbnVtYmVyKDgg Ynl0ZXMpLCBwYXlsb2FkKDggYnl0ZXMpLiBUaGVyZWZvcmUgYWNjb3VudHMgdmVyeSBzbWFsbCBw cm9wb3J0aW9uIG9mIHRoZSB3aG9sZSBXQ0RNQSBwYWNrZXQuIA0KQWN0dWFsbHksIHRoYXQgZG9l cyBtYWtlIHNlbnNlIGluIHNvbWUgTFctUEFOIHNjZW5hcmlvczogbWFueSBzZW5zb3JzIGJ1dCBl YWNoIHNlbnNvciBoYXMgbGltaXQgbnVtYmVyIG9mIGZyYW1lcyBwZXIgZGF5Lg0KDQpSZWdhcmRz DQpYaWFvd2VpIFFpbg0KDQoNCg0K ------=_001_NextPart434280330644_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
= Hi=EF=BC=8Cfolks

I am glad to introduce m= y existing deployment experience as mentioned yesterday.
= Since 2012, I have bee= n deploying intelligent agricultural systems for some farms. At beginning,= I used CROSSBOW's sensors and nodes, now,I also use other companys' produ= cts. =0A
In each greenhouse there are many sensors such as temperature,= humidity, and one Cluster Header(gateway). One or more sensors were integ= rated into one wireless node which were controlled by TinyOS. Sensor-gener= ate-data is first transmitted to the Cluster Header by wireless node via 8= 02.15.4 protocol and private mesh protocol. The Cluster Header forward the= se sensor-generate-data to a gateway through USB port(pl2303 or FTDI). The= gateway will store these data temporarily and then encapsulate them into = an aggregation chain and at the last send the aggregation chain to actual = destination through WCDMA.
By doing this, = it simplify implementation as well as to lower the cost because some green= houses can not connect to internet through wired line. It would be a waste= of bandwidth if initiated the transmission for every sensor's frame. Beca= use each sensor-generate-data is very small: TinyOS header(5 bytes), Xmesh= Header(0/7 bytes), Address information and Sequence number(8 bytes), payl= oad(8 bytes). Therefore accounts very small proportion of the whole WCDMA = packet. 
Actual= ly, that does make sense in some LW-PAN scenarios: many sensors but each s= ensor has limit number of frames per day.

Regards
Xiaowei Qin
=0A
<= br>

=0A
=0A
=0A ------=_001_NextPart434280330644_=------