From nobody Fri Jan 5 00:49:42 2018 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 08A811242F5 for ; Fri, 5 Jan 2018 00:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syTyf7JRsCEz for ; Fri, 5 Jan 2018 00:49:37 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id D22C5120724 for ; Fri, 5 Jan 2018 00:49:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,317,1511823600"; d="scan'208,217";a="7421599" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 05 Jan 2018 09:49:34 +0100 Received: from [192.168.1.1] (i16-les01-ntr-213-44-230-95.sfr.lns.abo.bbox.fr [213.44.230.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 184F5246 for ; Fri, 5 Jan 2018 09:49:34 +0100 (CET) To: "t2trg@irtf.org" From: Soumya Kanti Datta Message-ID: Date: Fri, 5 Jan 2018 14:19:14 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1093BECF7E1F2A2B67120A3C" Content-Language: en-US Archived-At: Subject: [T2TRG] Call for papers - workshop on semantic interoperability X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 08:49:41 -0000 This is a multi-part message in MIME format. --------------1093BECF7E1F2A2B67120A3C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, I am chairing a workshop on semantic interoperability in IoT and WoT which is a part of GIoTS 2018. The scope of the workshop is highly relevant to the WoT groups. I welcome your submission. Please find below the call for papers. ******************Call for papers************************ Internet of Things (IoT) requires not only the development of infrastructure but also deployment of new services capable of supporting multiple, scalable and interoperable applications. It is widely acknowledged that interoperability is the key to achieve the full potential of the IoT ecosystem. Due to the highly dynamic nature of the IoT, a strong need of interoperability at data level has emerged so that it becomes easier to combine/aggregate, process, manage and store the data/event coming from heterogeneous data sources. Several European and international IoT research projects have shown the semantic interoperability to address the problem. Standard development organizations (W3C, oneM2M, AIOTI WG3) also recognize this. The next step is to develop test methodologies and tools that validate the semantic compliance and interoperability among systems under test. Such tools are of urgent need to boost the acceptance and adoption of the semantic technologies by the general IoT market. This workshop will examine the current landscape on semantic interoperability and create a platform for advance discussion on the same. The technical topics of interest include, but are not limited to: • Semantic interoperability in IoT and WoT • IoT Platform interoperability • Semantic interoperability testing methodology • Semantic interoperability current state and future outlook • Standardizing Semantic interoperability • Performance evaluation of Semantic interoperability tools This workshop is supported by EU project F-Interop. T*he workshop is a part of Global IoT Summit 2018 conference which is co-located with IoT Week 2018 during 4-7 June 2018 in Bilbao, Spain.* For more info, visit - http://globaliotsummit.org/ *Important Dates* Paper submission deadline: February 28, 2018 Acceptance Notification: March 31, 2018 Camera-Ready Paper Submission: April 30, 2018 All final submissions should be written in English with a maximum paper length of six (6) printed pages see web conference for instructions. *Papers must be submitted through EDAS at the following link – https://edas.info/newPaper.php?c=24130&track=89111 * *Workshop Chairs: * Soumya Kanti Datta, EURECOM, France Mengxuan Zhao, Easy Global Market, France Franck Le Gall, Easy Global Market, France Hamza Baqa, Easy Global Market, France Best regards Soumya -- Research Engineer, EURECOM, France | @skdatta2010 | http://iot.eurecom.fr --------------1093BECF7E1F2A2B67120A3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear all,

I am chairing a workshop on semantic interoperability in IoT and WoT which is a part of GIoTS 2018. The scope of the workshop is highly relevant to the WoT groups. I welcome your submission. Please find below the call for papers.

******************Call for papers************************

Internet of Things (IoT) requires not only the development of infrastructure but also deployment of new services capable of supporting multiple, scalable and interoperable applications. It is widely acknowledged that interoperability is the key to achieve the full potential of the IoT ecosystem. Due to the highly dynamic nature of the IoT, a strong need of interoperability at data level has emerged so that it becomes easier to combine/aggregate, process, manage and store the data/event coming from heterogeneous data sources. Several European and international IoT research projects have shown the semantic interoperability to address the problem. Standard development organizations (W3C, oneM2M, AIOTI WG3) also recognize this. The next step is to develop test methodologies and tools that validate the semantic compliance and interoperability among systems under test. Such tools are of urgent need to boost the acceptance and adoption of the semantic technologies by the general IoT market. This workshop will examine the current landscape on semantic interoperability and create a platform for advance discussion on the same. The technical topics of interest include, but are not limited to: 

• Semantic interoperability in IoT and WoT 
• IoT Platform interoperability 
• Semantic interoperability testing methodology 
• Semantic interoperability current state and future outlook 
• Standardizing Semantic interoperability 
• Performance evaluation of Semantic interoperability tools 

This workshop is supported by EU project F-Interop. The workshop is a part of Global IoT Summit 2018 conference which is co-located with IoT Week 2018 during 4-7 June 2018 in Bilbao, Spain. For more info, visit - http://globaliotsummit.org/

Important Dates
Paper submission deadline: February 28, 2018 
Acceptance Notification: March 31, 2018 
Camera-Ready Paper Submission: April 30, 2018

All final submissions should be written in English with a maximum paper length of six (6) printed pages see web conference for instructions. 
Papers must be submitted through EDAS at the following link – https://edas.info/newPaper.php?c=24130&track=89111

Workshop Chairs: 
Soumya Kanti Datta, EURECOM, France 
Mengxuan Zhao, Easy Global Market, France 
Franck Le Gall, Easy Global Market, France 
Hamza Baqa, Easy Global Market, France

Best regards
Soumya
-- 
Research Engineer, EURECOM, France | @skdatta2010 | 
http://iot.eurecom.fr
--------------1093BECF7E1F2A2B67120A3C-- From nobody Fri Jan 5 08:10:39 2018 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 7836E126C0F for ; Fri, 5 Jan 2018 08:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6zvF7qzn3vd for ; Fri, 5 Jan 2018 08:10:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51412124C27 for ; Fri, 5 Jan 2018 08:10:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6311ABE5C for ; Fri, 5 Jan 2018 16:10:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87QBIkEyiNBD for ; Fri, 5 Jan 2018 16:10:30 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B401BE3E for ; Fri, 5 Jan 2018 16:10:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1515168630; bh=xtwdS5OZwGoReCCpi03Oc8vqgP3YkNYvMdne56WHOdw=; h=To:From:Subject:Date:From; b=UdgfOHMbpQkIUmHPGS5Pg85qNkGvGS4QR/E0l2Q2ne/DBkcbWUYI8K24A5/ehIqX4 aAd9H91idREXcS7bT7Znjg2puR6qSvcJQCT3ooMgULErj+979juykyS0NFAZIC/b+Y msnEmWWY74LtJFDp0M4hxNVniavdQeQy9lU+Paco= To: t2trg@irtf.org From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> Date: Fri, 5 Jan 2018 16:10:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VAWfuBt0eOrcN9aX0ScvAfypqCrnYQYT4" Archived-At: Subject: [T2TRG] review of draft-irtf-t2trg-iot-seccons X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 16:10:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VAWfuBt0eOrcN9aX0ScvAfypqCrnYQYT4 Content-Type: multipart/mixed; boundary="ku08gHJa9CN0KFvMm9KBXJydGOGnFRKEm"; protected-headers="v1" From: Stephen Farrell To: t2trg@irtf.org Message-ID: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> Subject: review of draft-irtf-t2trg-iot-seccons --ku08gHJa9CN0KFvMm9KBXJydGOGnFRKEm Content-Type: multipart/mixed; boundary="------------11B648C3E3491C4F886CDAF0" Content-Language: en-GB This is a multi-part message in MIME format. --------------11B648C3E3491C4F886CDAF0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Carsten asked me to take a look at this draft and I said I would over the holidays, so I'm only a wee bit later than promised:-) In general, I think some more work is needed. Aside from the specific points in the attached, I wasn't clear who are the intended readers - if this is mainly meant for the RG, then does it need to be an RFC? If the intended readership is someone else, then who? And will the current text be useful for that set of folks? Apologies in advance if some of the issues I raise have been discussed in the RG before - I haven't had time to participate in the RG to date. (I'm also not subscribed to the RG list so please do cc me on any follow ups.) Cheers, S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------11B648C3E3491C4F886CDAF0 Content-Type: text/plain; charset=UTF-8; name="iot-rev.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="iot-rev.txt" ClNGIHJldmlldyBvZiBkcmFmdC1pcnRmLXQydHJnLWlvdC1zZWNjb25zLTA5CjIwMTgwMTA1 CgooTm90ZSB0aGF0IEkgc3VnZ2VzdCByZWZlcnJpbmcgdG8gcmZjIDgyNDAgYW5kIHRoZSBM UFdBTgpvdmVydmlldyBkcmFmdCBhbmQgYW0gYW4gZWRpdG9yIGZvciBib3RoIG9mIHRob3Nl LiBJIGRvCnRoaW5rIHRoZXknZCBiZSBnb29kIGFkZGl0aW9ucywgYnV0IGRpZG4ndCB3YW50 IHlvdSB0byB0aGluawpJJ20gc25lYWtpbHkgdHJ5aW5nIHRvIHVwIG15IGgtaW5kZXg6LSkK Ci0gNTAgcGFnZXMsIHNoZWVzaAoKLSBwMTogY3JhcCBjb2RlIGlzIHN1cmVseSB0aGUgYmln Z2VzdCBzZWN1cml0eSBjaGFsbGxlbmdlCiAgaGVyZSwgaWYgdGhpcyBkb2MgaXMgdG8gYmUg dXNlZnVsIGl0J2xsIG5lZWQgdG8gcmVjb2duaXNlCnRoYXQuCgotIHAzOiBJIGRvbid0IHNl ZSB0aGUgcG9pbnQgb2Ygc2FsZXMtc3BlYWsgc3VjaCBhcyAiVGhlCiAgdGhpbmdzIHRoYXQg YXJlIHBhcnQgb2YgdGhlIEludGVybmV0IG9mIFRoaW5ncyBhcmUgbm8KbG9uZ2VyIHVucmVz cG9uc2l2ZSBhbmQgaGF2ZSB0cmFuc2Zvcm1lZCBpbnRvIGNvbXB1dGluZwpkZXZpY2VzIHRo YXQgdW5kZXJzdGFuZCBhbmQgcmVhY3QgdG8gdGhlIGVudmlyb25tZW50IHRoZXkKcmVzaWRl IGluLiIKCi0gcDQsIHRoZSBsaWZlY3ljbGUgZG9lc24ndCBzdGFydCB3aGVuIGEgdGFuZ2li bGUgZGV2aWNlIGlzCiAgbWFudWZhY3R1cmVkIGJ1dCByYXRoZXIgd2hlbiB0aGUgb2xkZXN0 IGJpdCBvZiBjb2RlIHRoZQplbmRzIHVwIGluIHRoZSBkZXZpY2Ugd2FzIHdyaXR0ZW4uICBU aGF0J3MgYSBzaWduaWZpY2FudApwb2ludCwgZXNwIGZvciBzbWFsbGVyIHZlbmRvcnMgd2hv IG9mdGVuIHJlLXVzZSB1bnBhdGNoZWQKb2xkIGJ1aWxkcyB0aGF0ICJ3b3JrIiBidXQgbWF5 IGJlIHdpbGRseSBpbnNlY3VyZS4KCi0gcDQsIEknZCBhcmd1ZSB0aGF0IHRoZSBsaWZlY3lj bGUgY291bGQgaW5jbHVkZSBzb21lCnJlY29nbml0aW9uIG9mIE9TUywgYnV0IEknbSBub3Qg c3VyZSBob3cgdG8gcHJvcGVybHkKaW5jbHVkZSB0aGF0LgoKLSBwNCwgdGhlIGxpZmVjeWNs ZSBjb3VsZCBhbHNvIGluY2x1ZGUgYW4gb24tdGhlLXNoZWxmIHBoYXNlCiAgYW5kIGEgcGhh c2Ugd2hlcmUgYSBkZXZpY2UgaXMgcmUtYmFkZ2VkIGJ5IHNvbWUgdmVuZG9yIHdobwp3YXNu J3QgdGhlIGFjdHVhbCBvcmlnaW5hbCBtYW51Zi4gIFN1Y2ggcGhhc2VzIGNhbgpzaWduaWZp Y2FudGx5IGNvbXBsaWNhdGUgcy93IHVwZGF0ZSBhbmQgYm9vdHN0cmFwcGluZy4KCi0gcDQs IHRoZXJlIGFyZSB0d28gb3RoZXIgZW5kLXN0YXRlcyB0aGF0IHByb2JhYmx5IG91Z2h0IGJl CiAgcGFydCBvZiB0aGUgbGlmZWN5Y2xlIC0gd2hlcmUgYSB2ZW5kb3IgZW5kLW9mLWxpZmUn cyBhCmRldmljZSB0eXBlIHRoYXQncyBzdGlsbCBpbiB1c2UgYW5kIHdoZXJlIGEgZGV2aWNl IGlzIHNpbXBseQpmb3Jnb3R0ZW4gYnV0IGtlZXBzIG9uIHRydWNraW5nLiAKCi0gcDYsIFNl Y3VyaXR5IGZvciB0aGVzZSBkZXZpY2VzIGlzIG5vdCBtb3JlIGltcG9ydGFudCB0aGFuCiAg Zm9yIG90aGVyIChzdWIpc3lzdGVtcy4gVGhlIHJlYXNvbiBzZWN1cml0eSBmb3IgdGhlc2UK ZGV2aWNlcyBkZXNlcnZlcyBhZGRpdGlvbmFsIGVmZm9ydCBpcyB0aGF0IHRvLWRhdGUsIHZl bmRvcnMKaGF2ZSBkb25lIGEgdGVycmlibGUgam9iLiBUaGUgc2l0dWF0aW9uIHRvZGF5IHdp dGggdGhlc2UKZGV2aWNlcyByZXNlbWJsZXMgUEMgc2VjdXJpdHkgYWJvdXQgMjArIHllYXJz IGFnby4KCi0gcDcsIHNlY3Rpb24gMi4yIHNlZW1zIHBvaW50bGVzcyBpZiBpdCdzIG5vdCB1 c2VkIGxhdGVyIGluCiAgdGhlIGRvY3VtZW50IC0geW91IG1heSBhcyB3ZWxsIGRlbGV0ZSB0 aGlzLiBGV0lXLCBJIGRvbid0CmZpbmQgZmlndXJlIDMgdXNlZnVsLgoKLSBwOSwgdGhlIGxp c3Qgc2VlbXMgdG8gbWUgdG8gYmUgdmVyeSBmb3ItcHJvZml0LXZlbmRvcgogIG9yaWVudGVk LiAgSSB3b25kZXIgd291bGQgYSBub24tcHJvZml0IG9yIGRldmljZS11c2luZwpvcmdhbmlz YXRpb24gd3JpdGUgYSBkaWZmZXJlbnQgbGlzdD8gSSB0aGluayB0aGV5IHdvdWxkLAplLmcu IHRoZXkgbWlnaHQgaW5jbHVkZSAiY3JhcCBzL3ciIGFuZCAiYXR0ZW1wdGVkIGNhcHR1cmUK dmlhIHByb3ByaWV0YXJ5IEFQSXMvZGF0YSBmb3JtYXRzL2Nsb3VkeSBzZXJ2aWNlcyIgYXMK dGhyZWF0cy4KCi0gcDExLCBJIHdvdWxkIGFyZ3VlIHRoYXQgcHJpdmFjeSBkZXNlcnZlcyBt dWNoIG1vcmUKICBhdHRlbnRpb24gaW4gdGhpcyBkb2N1bWVudCB0aGFuIHRoaXMsIGFuZCB0 aGF0IHRoaXMKZG9jdW1lbnQgaXNuJ3QgbXVjaCB1c2Ugd2l0aG91dCB0aGF0LiBGb3IgZXhh bXBsZSwgaXQncwppbXBvcnRhbnQgdG8gaW5jbHVkZSB0aGUgc2NlbmFyaW8gd2hlcmUgYSBz dGF0aWMgc2Vuc29yCmVtaXRzIGEgcGFja2V0IGR1ZSB0byB0aGUgcHJlc2VuY2UvYWJzZW5j ZSBvZiBwZW9wbGUgLSBpbgp0aGF0IHNjZW5hcmlvIGFueW9uZSB3aG8gY2FuIHNlZSB0aGF0 IHBhY2tldCBjYW4gcG90ZW50aWFsbHkKaW52YWRlIHRoZSBwcml2YWN5IG9mIHRoZSBwZW9w bGUgaW52b2x2ZWQuICBZb3UgZG8gaW5jbHVkZQptb3JlIGluIHNlY3Rpb24gNSwgYnV0IHNl ZSBteSBjb21tZW50IGJlbG93IGFib3V0IGhvdyB0aGF0CnNlY3Rpb24gaXMobid0Oi0pIG9y Z2FuaXNlZC4KCi0gcDEyLCBNaXJhaSBzaG93cyB0aGF0IHNldHMgb2YgY3JhcCBkZXZpY2Vz IGNhbiBjcmVhdGUgYQogIEREb1MgdmVjdG9yIC0gdGhhdCBkZXNlcnZlcyBhIG1lbnRpb24g aGVyZS4gKEFuZCB5b3Ugbm90ZQppdCBpbiA0LjMuKQoKLSBwMjAsICJ0aGUgZmFjdCBpcyB0 aGF0IG1hbnkgSW9UIGRldmljZXMgYW5kIHN5c3RlbXMgaGF2ZQogIHZlcnkgbGltaXRlZCBz ZWN1cml0eS4iIEl0IHNlZW1zIGEgYml0IGxhdGUgdG8gc2F5IHRoaXMgb24KcGFnZSAyMDot KQoKLSBwMjEsIEknbSBub3Qgc3VyZSBhbiBSRkMgaXMgYSBnb29kIHBsYWNlIHRvIHdvbmRl ciBhYm91dAogIHBvdGVudGlhbCBmdXR1cmUgcmVndWxhdGlvbiwgdW5sZXNzIHRoYXQncyB0 byBiZSBkb25lIGluIGEKbW9yZSB0aG9yb3VnaCBtYW5uZXIuIEknZCBzYXkgZGVsZXRpbmcg dGhlIGxhc3QgdHdvCnBhcmFncmFwaHMgb2Ygc2VjdGlvbiA0LjMgYW5kIHJlcGxhY2luZyB0 aG9zZSB3aXRoIGEgc2luZ2xlCnNlbnRlbmNlIHRoYXQgInJlZGlvbmFsIHJlZ3VsYXRpb25z IGFyZW4ndCB1bmxpa2VseSIgbWlnaHQKYmUgYmV0dGVyLiAKCi0gcDIyLCBJIGRvbid0IGFn cmVlIHdpdGggdGhlIGNyeXB0byBwb2ludHMgbWFkZSAoSU1PLCBvbmx5CiAgZGV2aWNlcyB0 aGF0IGNhbiB2ZXJpZnkgYW4gb2NjYXNpb25hbCBzaWduYXR1cmUgb3VnaHQgYmUKZXhwb3Nl ZCB0byB0aGUgSW50ZXJuZXQpIC0gYnV0IGV2ZW4gc28gdGhlIHJlZmVyZW5jZXMgaGVyZQph cmVuJ3QgZ29vZCAtIGN1cnZlIDI1NTE5IG91Z2h0IGJlIHRoZSBtYWluIEVDQyByZWZlcmVu Y2UKcmVsYXRpbmcgdG8gbGVzc2VuZWQgQ1BVIHJlcXVpcmVtZW50cy4gSXQncyBhbHNvIGEg c3VycHJpc2UKdG8gbm90IHNlZSBhIG1lbnRpb24gb2YgY2hhY2hhLgoKLSBwMTIsICJUaHVz LCBlbnN1cmluZyBhIHByb3BlciBsZXZlbCBvZiBzZWN1cml0eSBpbiBhbiBJb1QKICBzeXN0 ZW0gYXQgYW55IHBvaW50IG9mIHRpbWUgaXMgY2hhbGxlbmdpbmcuICBUbyBhZGRyZXNzCnRo aXMgY2hhbGxlbmdlLCBhIHByb2Nlc3MgZm9yIHNlY3VyZSBwcm9kdWN0IGNyZWF0aW9uIGlz CnJlcXVpcmVkIHRvIGVuc3VyZSB0aGF0IGFuIElvVCBzeXN0ZW0gaXMgc2VjdXJlIGFuZCBu bwpzZWN1cml0eSByaXNrcyBhcmUgcHJlc2VudC4iIFRoYXQncyBqdXN0IHNpbGx5IC0gYWlt aW5nIGZvcgphIHBlcmZlY3Qgc3lzdGVtICgibm8gc2VjdXJpdHkgcmlza3MiKSBpcyBwb2lu dGxlc3MgYXMgdGhvc2UKZG8gbm90IGV4aXN0LgoKLSBwMTIsIGEgUElBIG91Z2h0IGFsc28g Y29uc2lkZXIgdGhlIGtpbmQgb2YgaW5mZXJlbmNlcyB0aGF0CiAgYW4gb2JzZXJ2ZXIgb2Yg dGhlIHN5c3RlbSBjYW4gbWFrZSBhbmQgcmUtaWRlbnRpZmljYXRpb24KYW5kIGlzIG5vdCBv bmx5IGFib3V0IGhhbmRsaW5nIFBJSQoKLSBwMTMsIDQuMSBzaG91bGQgaGF2ZSBzb21lIG1l bnRpb24gb2YgTFBXQU5zIGFuZCBpbmRlZWQKICB0aG9zZSBkZXNlcnZlIG1vcmUgdGV4dCBp biBnZW5lcmFsIGFzIHRoZSBzZXQgb2YgdXNhYmxlCnNlY3VyaXR5IG1lY2hhbmlzbXMgYW5k IGNoYWxsZW5nZXMgZGlmZmVyIGluIHRob3NlIHBhcnRzIG9mCm5ldHdvcmtzLiAgWW91IGRv IG1lbnRpb24gTFBXQU4gaW4gNS4xLjQgLSB3aGljaCBjb25mdXNlZCBtZQphcyB0aGF0IHRl eHQgcHJvYmFibHkgc2hvdWxkIGJlIGhlcmUgaW4gNC54LiAgWW91IG1pZ2h0IGFsc28Kd2Fu bmEgcmVmZXJlbmNlIHRoZSBMUFdBTiBvdmVydmlldyBkcmFmdCwgY3VycmVudGx5IGluIElF VEYKTEMuIAoKLSBwMTYgYW5kIGVsc2V3aGVyZSAtIHRoZSBzdGF0ZS1vZi10aGUtYXJ0IHRl eHQgc2hvdWxkCiAgcmVhbGx5IHRyeSB0byBpbmRpY2F0ZSB3aGljaCB0aGluZ3MgYXJlIG9y IG1vcmUsIG9yIGxlc3MsCmltcG9ydGFuY3QuIFRoYXQgY2FuIGJlIHRyaWNreSwgYnV0IGUu Zy4gIHByZXNlbnRpbmcgSElQIGFzCmJlaW5nIG9mIGVxdWFsIGltcG9ydGFuY2UgdG8gKEQp VExTIGhlcmUgaXNuJ3QgdXNlZnVsLCBub3IKcGFydGljdWxhcmx5IGNyZWRpYmxlLiBJIGFs c28gd29uZGVyIGlmIE9TQ09BUCBpcyBhcyBtYXR1cmUKYW5kIGltcG9ydGFudCBhcyB0aGUg dGV4dCBpbXBsaWVzLgoKLSBwMjEsIEkgZG9uJ3QgZ2V0IHRoZSBsb2dpYyBiZWhpbmQgdGhl IG9yZ2FuaXNhdGlvbiBvZgogIHNlY3Rpb24gNSwgaXQgc2VlbXMgdG8gYmUgYSBqdXN0LXNv IGxpc3QgaWYgdGhpbmdzCmRlc2NyaWJlZCBhdCBmYWlybHkgZGlmZmVyZW50IGxldmVscyBv ZiBkZXRhaWwsIGUuZy4gIDUuMSB2cwo1LjIuIEknZCBzYXkgYSBiaXQgb2YgdGhvdWdodCBh cyB0byBob3cgdG8gb3JnYW5pc2UgdGhpcwpzZWN0aW9uIGNvdWxkIGxlYWQgdG8gYSBiZXR0 ZXIgb3JnYW5pc2VkIHRleHQuICBJJ20gbm90IHN1cmUKaG93IHRoYXQnZCBiZSBiZXN0IGRv bmUgbXlzZWxmLCBidXQgcGVyaGFwcyBzb21lIGRpc2N1c3Npb24Kd2l0aGluIHRoZSBSRyB3 b3VsZCBoZWxwIHRoZXJlLgoKLSBwMjEsIG9uZSBvZiB0aGUgc2lnbmlmaWNhbnQgY2hhbGxl bmdlcyBoZXJlIGlzIHZlbmRvcgogIGxvY2staW4uIElNTywgdGhhdCBlbmNvdXJhZ2VzIHNo b3J0LXRlcm0gdGhpbmtpbmcgKGUuZy4KIml0J2xsIGJlIG1vcmUgc2VjdXJlIHNpbmNlIGl0 IG9ubHkgdGFsa3MgdG8gb3VyCmNsb3VkLXNlcnZlciIpIGJ1dCBhdCB0aGUgcG9zc2libGUg bG9uZ2VyIHRlcm0gY29zdCBvZiBub3QKZ2V0dGluZyBzZWN1cml0eSBhbmQgbXVsdGktdmVu ZG9yIGludGVyb3AuIHdoaWNoIGlzIHdoYXQgdGhlCmJ1eWVycyBvZiBkZXZpY2VzIHByZXN1 bWFibHkgd291bGQgcHJlZmVyLgoKLSBwMjQsIGhvbW9tb3JwaGljIGNyeXB0bz8gSHVoPyBJ IGRvbid0IGJ1eSB0aGF0IGF0IGFsbC4KICBBbmQgZm9sbG93aW5nIHRoZSBbU0VBTF0gcmVm ZXJlbmNlIGxlYWRzIHRvIGEgZGVhZCBlbmQuCklmIHlvdSB3YW50IHRvIG1ha2UgYSBjbGFp bSBsaWtlIHRoaXMgbW9yZSBkZXRhaWwgd291bGQgYmUKbmVlZGVkLiBJJ2Qgc2F5IGRlbGV0 aW5nIHRoaXMgaXMgYmVzdC4KCi0gcDI4IC0gaG93IGlzIHJlZmVycmluZyB0byBhbiBleHBp cmVkIGRyYWZ0IGZyb20gOSB5ZWFycwogIGFnbyAoeWVzLCAyMDA5ISkgdXNlZnVsPwoKLSBw MjgsIFtpb3RzdV0gaXMgYmV0dGVyIHJlZmVycmVkIHRvIHZpYSByZmMgODI0MCBhbmQgSQog IHRoaW5rIGEgbG90IG9mIHRoZSB0ZXh0IGluIDUuNCBpcyBsaWtlbHkgaW5jbHVkZWQgaW4g dGhhdApyZXBvcnQuIFRoZSBvdmVybGFwIGlzIHByb2JhYmx5IGZpbmUsIGJ1dCBpdCdkIGJl IG5vIGhhcm0gdG8KanVzdCBjaGVjayB0byBzZWUgaWYgYW55dGhpbmcgZWxzZSBmcm9tIDgy NDAgd291bGQgYmUgd29ydGgKaW5jbHVkaW5nIGhlcmUuCgotIHAzMywgYXQgdGhlIHN0YXJ0 IG9mIDUuOSAiVXNlcnMiIGlzIHRoZSB3cm9uZyB0ZXJtLCB5b3UKICBzaG91bGQgc2F5ICJQ ZW9wbGUiIC0gdGhhdCdzIG5vdCBqdXN0IGEgbml0LCBidXQgYW4KaW1wb3J0YW50IGRpZmZl cmVuY2UgKGFuZCBvbmUgd29ydGggZXhwbGljaXRseSBjYWxsaW5nIG91dCkKYXMgdGhlIHBl b3BsZSB3aG9zZSBwcml2YWN5IGlzIGFmZmVjdGVkIGJ5IGRldmljZXMgbmVlZCBub3QKYmUg InVzZXJzIiBpbiBhbnkgc2Vuc2UgYXQgYWxsLiBBdXRvbWF0aWMgbnVtYmVyIHBsYXRlCnNj YW5uZXJzIG9yIGNhbWVyYSBiYXNlZCBzeXN0ZW1zIGFyZSB1c3VhbGx5IGdvb2QgZXhhbXBs ZXMuCgotIHAzNCwgaW4gNS4xMCB5b3UgY291bGQgYWRkIHNvbWUgbWVudGlvbiBvZiBhbmQg cmVmZXJlbmNlCiAgdG8gbWV0aG9kcyBmb3IgaC93IHRhbXBlciBkZXRlY3Rpb24vcmVzaXN0 YW5jZS4KCi0gcDM2IHNheXMgIlRodXMsIGEgcG90ZW50aWFsIGFwcHJvYWNoIGlzIHRoZSBk ZWZpbml0aW9uIGFuZAogIHN0YW5kYXJkaXphdGlvbiBvZiBzZWN1cml0eSBwcm9maWxlcywu Li4iIFRoYXQgY29uY2x1c2lvbgppcyBub3QganVzdGlmaWVkIGJhc2VkIG9uIHRoZSB0ZXh0 IG9mIHRoaXMgZG9jdW1lbnQuCihXaGVyZSdzIHRoZXJlIGFueXRoaW5nIHRoYXQgaW1wbGll cyB0aGF0IHRoaXMgY29uY2x1c2lvbiBpcwp3YXJyYW50ZWQ/KSBTZWNvbmRseSwgSSBkb24n dCBhZ3JlZSB3aXRoIHRoZSBjb25jbHVzaW9uCml0c2VsZiAtIGluIHRoZSBjYXNlIG9mIFJQ TCB0aGF0IGFwcHJvYWNoIGhhcyBsZWFkIHRvCm5vdGhpbmcgZ29vZCBoYXBwZW5pbmcgdGhh dCBJJ3ZlIHNlZW4sIGFuZCBJJ2QgZXhwZWN0IGl0IHRvCmxlYWQgdG8gbW9yZSBmaWctbGVh dmVzIGlmIGFwcGxpZWQgaW4gb3RoZXIgY2FzZXMuIE5vdywKd2hpbGUgSSBtYXkgYmUgd3Jv bmcsIGFuZCB5b3VyIGNvbmx1c2lvbiBtYXkgYmUgcmlnaHQsIEkKdGhpbmsgSSdtIGZhaXJs eSBzYWZlIGluIHNheWluZyB0aGF0IG11Y2ggbW9yZSBqdXN0aWZpY2F0aW9uCmlzIG5lZWRl ZCBiZWZvcmUgdGhpcyBjb25jbHVzaW9uIGNvdWxkIGJlIGNyZWRpYmx5IGRyYXduLgo= --------------11B648C3E3491C4F886CDAF0 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------11B648C3E3491C4F886CDAF0-- --ku08gHJa9CN0KFvMm9KBXJydGOGnFRKEm-- --VAWfuBt0eOrcN9aX0ScvAfypqCrnYQYT4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaT6N2AAoJEFqy+vF7Fyvq4c8QAMKSkns1Ea8tuXE/hRFJoR7W TiSLMHmKSJLoM33L4m89xB1FE97ELSC+rhgWmN7ZYrJcDT7SfWFNwYFgbFUw/Vjh 538yoI3AIEY3lhKV7uynQxjZfVdjlwYn0rsxyUdlAmEIkzG8uKt8RJZ6UA/FixWV NhFyba0/p/wCcIOBPPZQaMcAbB5Iy8aLlHezBXLKdNj7Bfj37yMBIPsrFNZgZVL5 X9OF7f03l6QRo+Es3ezTa/nLLNjMjFRZfAS4BnvsTiXftnHBYEsD/FbQe49DwGU9 5/1K3W+4LVubfu2jc+F/moQbraRsK+U0iOFipLoGwCObhKqZGW/Gc0C2IoPfxlkm fcLd8eKKQhZkqOrfHadKqeyywtXUIPe+zwm6DwICArTaAC55FWqXsTLWWDGNg20s Ca4vKEs5+zBZd34cyhUDPgEVd3C+8luYQZdAejEgZ5f7saCiSAuNZ6g8aIpPoCiO socViNRbMfmRIJbEUVSuk4yas3S+gluwiQvhjdY8rhC3vAt0WtztLzQ76vneYewC e6IU4pbojP1sZdzx4QIT0p5+tDThv3zamuPhnQqyYK3o5rL+XN2hBA3KNLcJaP7n p/Is0HsKL4JqQmUkCvkc9BVEFFa5wzxhwzxJmEUsqy5prrhF8YyWSmcYdCpdcZBw 2R1VE3XyjUGOhUOQNEPS =5//i -----END PGP SIGNATURE----- --VAWfuBt0eOrcN9aX0ScvAfypqCrnYQYT4-- From nobody Fri Jan 5 08:52:23 2018 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 8F78B127AD4 for ; Fri, 5 Jan 2018 08:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 KJEHkYd3hP1X for ; Fri, 5 Jan 2018 08:52:19 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8F61274D2 for ; Fri, 5 Jan 2018 08:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23454; q=dns/txt; s=iport; t=1515171138; x=1516380738; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=H2IPcxchIemxhf3GKnOO5+io2o/bkwh6GSn2MUf7WyE=; b=l6YgvVTASkmtrP6eG0UFfVY+3uJGdT5kk+tcOx9ZrjApxFtc14y9gaFx Oeb8iPZaa3HylMb6wlvFnMRIlkBUVQlDtVcT99PpcOxVamOnzDcw6v3Ay cdxhz0eNBEWNbvw2cvzXV2tJxVyrwBqxlBxOntPluBByoVIAL6zzWBfQk w=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQDcrE9a/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKgk6ELosYj3h9kFyHZgcDhTsChHQUAQEBAQEBAQEBayiFJAE?= =?us-ascii?q?FI2YLGCoCAlcGAQwIAQEVihawU4InJooYAQEBAQEBBAEBAQEBAQEBARAPhBSBD?= =?us-ascii?q?hyEKimBd1g2hHcRgy2CZQWHd4JrmHqEVIIthC6EOoVTgheKBodpil+MNIE8NiK?= =?us-ascii?q?BUDIaCBsVPYIrhFdAh0eCSwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,319,1511827200"; d="asc'?scan'208,217";a="1282404" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2018 16:52:01 +0000 Received: from [10.61.166.110] ([10.61.166.110]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w05Gq1w0011290; Fri, 5 Jan 2018 16:52:01 GMT To: Stephen Farrell , t2trg@irtf.org References: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> From: Eliot Lear Message-ID: <3efc08b9-2e14-2b96-d00f-0b72524fb415@cisco.com> Date: Fri, 5 Jan 2018 17:52:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KrmCJf7fLhVXsqIclg2xtJcwusQ2Ut8hu" Archived-At: Subject: Re: [T2TRG] review of draft-irtf-t2trg-iot-seccons X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 16:52:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KrmCJf7fLhVXsqIclg2xtJcwusQ2Ut8hu Content-Type: multipart/mixed; boundary="r2veUD7CkMOfNtRwXAoXiUI3vHABu7wNK"; protected-headers="v1" From: Eliot Lear To: Stephen Farrell , t2trg@irtf.org Message-ID: <3efc08b9-2e14-2b96-d00f-0b72524fb415@cisco.com> Subject: Re: [T2TRG] review of draft-irtf-t2trg-iot-seccons References: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> In-Reply-To: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> --r2veUD7CkMOfNtRwXAoXiUI3vHABu7wNK Content-Type: multipart/alternative; boundary="------------A25C3F91380B926619602155" Content-Language: en-US This is a multi-part message in MIME format. --------------A25C3F91380B926619602155 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, Just a few comments on top of your comments: On 05.01.18 17:10, Stephen Farrell wrote: > > SF review of draft-irtf-t2trg-iot-seccons-09 > 20180105 > > (Note that I suggest referring to rfc 8240 and the LPWAN > overview draft and am an editor for both of those. I do > think they'd be good additions, but didn't want you to think > I'm sneakily trying to up my h-index:-) > > - 50 pages, sheesh A few of us are considering writing a book on this subject.=C2=A0 The challenge will be keeping it under 600 pages.=C2=A0 Of course, picking th= e RIGHT 50 pages for this work is a different story. Totally agree with your top point that the audience and intended use has to be crystal clear up front. > > - p1: crap code is surely the biggest security challlenge > here, if this doc is to be useful it'll need to recognise > that. Yes, but it has to mesh with your top point. > > - p3: I don't see the point of sales-speak such as "The > things that are part of the Internet of Things are no > longer unresponsive and have transformed into computing > devices that understand and react to the environment they > reside in." If you think THAT's sales speak...=C2=A0 Emm... we're talking about massi= ve swathes of devices that have nothing whatsoever in common except for the idea that they have a transceiver, and are all classed IoT.=C2=A0 The spi= n started a long time ago. > > - p4, the lifecycle doesn't start when a tangible device is > manufactured but rather when the oldest bit of code the > ends up in the device was written. That's a significant > point, esp for smaller vendors who often re-use unpatched > old builds that "work" but may be wildly insecure. There are actually two points: old code and unpatched code.=C2=A0 Old cod= e isn't necessarily bad if there are no known vulnerabilities with it.=C2=A0= Let's face it: there aren't too many reports of problems with /bin/true. > > - p4, I'd argue that the lifecycle could include some > recognition of OSS, but I'm not sure how to properly > include that. > > - p4, the lifecycle could also include an on-the-shelf phase > and a phase where a device is re-badged by some vendor who > wasn't the actual original manuf. Such phases can > significantly complicate s/w update and bootstrapping. Different devices need to handle this differently, and this is a fundamental challenge to keeping such a doc smaller.=C2=A0 For instance, Internet Barbie probably needs different capabilities in this regard than, say, building lighting and management, which has different requirements from, say, a car, which has different requirements from, say, a manufacturer floor robot.=C2=A0 The best I think one can do is establish a bit of a matrix. > > - p4, there are two other end-states that probably ought be > part of the lifecycle - where a vendor end-of-life's a > device type that's still in use and where a device is simply > forgotten but keeps on trucking.=20 > > - p6, Security for these devices is not more important than > for other (sub)systems. The reason security for these > devices deserves additional effort is that to-date, vendors > have done a terrible job. The situation today with these > devices resembles PC security about 20+ years ago. There's SOME of that but I would take care not to lay all of that on IoT vendors.=C2=A0 Shining security successes of any form are hard to come by= =2E=C2=A0 To me the key is that "IP on everything" has become a bit more of a reality, and when one gets beyond general purpose computing with its well known business model and environmental constraints, there's some fresh thinking needed to look a problems we either thought solved or didn't care about.=C2=A0 And you've hit on some of that above.=C2=A0 How = long does a device remain active?=C2=A0 What are the crypto implications for that?=C2= =A0 What about planning updates, not to mention memory (which really hits COGS)?=C2=A0 How long to do that for?=C2=A0 Those were relatively easy qu= estions when 4 years is the average lifetime of a laptop with oodles of memory.=C2= =A0 Harder when we're talking 15. > > - p7, section 2.2 seems pointless if it's not used later in > the document - you may as well delete this. FWIW, I don't > find figure 3 useful. > > - p9, the list seems to me to be very for-profit-vendor > oriented. I wonder would a non-profit or device-using > organisation write a different list? I think they would, > e.g. they might include "crap s/w" and "attempted capture > via proprietary APIs/data formats/cloudy services" as > threats. > > - p11, I would argue that privacy deserves much more > attention in this document than this, and that this > document isn't much use without that. For example, it's > important to include the scenario where a static sensor > emits a packet due to the presence/absence of people - in > that scenario anyone who can see that packet can potentially > invade the privacy of the people involved. You do include > more in section 5, but see my comment below about how that > section is(n't:-) organised. > > - p12, Mirai shows that sets of crap devices can create a > DDoS vector - that deserves a mention here. (And you note > it in 4.3.) > > - p20, "the fact is that many IoT devices and systems have > very limited security." It seems a bit late to say this on > page 20:-) > > - p21, I'm not sure an RFC is a good place to wonder about > potential future regulation, unless that's to be done in a > more thorough manner. I'd say deleting the last two > paragraphs of section 4.3 and replacing those with a single > sentence that "redional regulations aren't unlikely" might > be better.=20 It depends on the goal and audience. > > - p22, I don't agree with the crypto points made (IMO, only > devices that can verify an occasional signature ought be > exposed to the Internet) - but even so the references here > aren't good - curve 25519 ought be the main ECC reference > relating to lessened CPU requirements. It's also a surprise > to not see a mention of chacha. > > - p12, "Thus, ensuring a proper level of security in an IoT > system at any point of time is challenging. To address > this challenge, a process for secure product creation is > required to ensure that an IoT system is secure and no > security risks are present." That's just silly - aiming for > a perfect system ("no security risks") is pointless as those > do not exist. Agree.=C2=A0 Suggest, "to minimize risks at a reasonable cost, and to mitigate vulnerabilities as and when they are discovered."=C2=A0 Or some = such. > > - p12, a PIA ought also consider the kind of inferences that > an observer of the system can make and re-identification > and is not only about handling PII > > - p13, 4.1 should have some mention of LPWANs and indeed > those deserve more text in general as the set of usable > security mechanisms and challenges differ in those parts of > networks. You do mention LPWAN in 5.1.4 - which confused me > as that text probably should be here in 4.x. You might also > wanna reference the LPWAN overview draft, currently in IETF > LC.=20 > > - p16 and elsewhere - the state-of-the-art text should > really try to indicate which things are or more, or less, > importanct. That can be tricky, but e.g. presenting HIP as > being of equal importance to (D)TLS here isn't useful, nor > particularly credible. I also wonder if OSCOAP is as mature > and important as the text implies. > > - p21, I don't get the logic behind the organisation of > section 5, it seems to be a just-so list if things > described at fairly different levels of detail, e.g. 5.1 vs > 5.2. I'd say a bit of thought as to how to organise this > section could lead to a better organised text. I'm not sure > how that'd be best done myself, but perhaps some discussion > within the RG would help there. > > - p21, one of the significant challenges here is vendor > lock-in. IMO, that encourages short-term thinking (e.g. > "it'll be more secure since it only talks to our > cloud-server") but at the possible longer term cost of not > getting security and multi-vendor interop. which is what the > buyers of devices presumably would prefer. I am not sure I understand your point.=C2=A0 multi-vendor interop is itse= lf a threat vector, from an epidemiological perspective.=C2=A0 That is- interoperability comes at a cost, but one people often think is worth paying.=C2=A0 My favorite example of this was the Morris worm, not becaus= e of how widely it spread, but because it didn't go father due to processor differences.=C2=A0 But it also goes to Geer at al and monocultures.=C2=A0= I don't know if I would address that in this work, other than perhaps to point out that a convergence in IoT approaches will have the usual pluses and minuses, just as has happened elsewhere (e.g, SNMP or even the processor fiasco). Eliot --------------A25C3F91380B926619602155 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Stephen,

Just a few comments on top of your comments:



On 05.01.18 17:10, Stephen Farrell wrote:

SF review of draft-irtf-t2trg-iot-seccons-09
20180105

(Note that I suggest referring to rfc 8240 and the LPWAN
overview draft and am an editor for both of those. I do
think they'd be good additions, but didn't want you to think
I'm sneakily trying to up my h-index:-)

- 50 pages, sheesh

A few of us are considering writing a book on this subject.=C2=A0 The= challenge will be keeping it under 600 pages.=C2=A0 Of course, pickin= g the RIGHT 50 pages for this work is a different story.

Totally agree with your top point that the audience and intended use has to be crystal clear up front.


- p1: crap code is surely the biggest security challlenge
  here, if this doc is to be useful it'll need to recognise
that.

Yes, but it has to mesh with your top point.

- p3: I don't see the point of sales-speak such as "The
  things that are part of the Internet of Things are no
longer unresponsive and have transformed into computing
devices that understand and react to the environment they
reside in."

If you think THAT's sales speak...=C2=A0 Emm... we're talking about massive swathes of devices that have nothing whatsoever in common except for the idea that they have a transceiver, and are all classed IoT.=C2=A0 The spin started a long time ago.

- p4, the lifecycle doesn't start when a tangible device is
  manufactured but rather when the oldest bit of code the
ends up in the device was written.  That's a significant
point, esp for smaller vendors who often re-use unpatched
old builds that "work" but may be wildly insecure.

There are actually two points: old code and unpatched code.=C2=A0 Old= code isn't necessarily bad if there are no known vulnerabilities with it.=C2=A0 Let's face it: there aren't too many reports of proble= ms with /bin/true.


- p4, I'd argue that the lifecycle could include some
recognition of OSS, but I'm not sure how to properly
include that.

- p4, the lifecycle could also include an on-the-shelf phase
  and a phase where a device is re-badged by some vendor who
wasn't the actual original manuf.  Such phases can
significantly complicate s/w update and bootstrapping.

Different devices need to handle this differently, and this is a fundamental challenge to keeping such a doc smaller.=C2=A0 For instan= ce, Internet Barbie probably needs different capabilities in this regard than, say, building lighting and management, which has different requirements from, say, a car, which has different requirements from, say, a manufacturer floor robot.=C2=A0 The best I think one can= do is establish a bit of a matrix.


- p4, there are two other end-states that probably ought be
  part of the lifecycle - where a vendor end-of-life's a
device type that's still in use and where a device is simply
forgotten but keeps on trucking.=20

- p6, Security for these devices is not more important than
  for other (sub)systems. The reason security for these
devices deserves additional effort is that to-date, vendors
have done a terrible job. The situation today with these
devices resembles PC security about 20+ years ago.

There's SOME of that but I would take care not to lay all of that on IoT vendors.=C2=A0 Shining security successes of any form are hard to= come by.=C2=A0 To me the key is that "IP on everything" has become a = bit more of a reality, and when one gets beyond general purpose computing with its well known business model and environmental constraints, there's some fresh thinking needed to look a problems we either thought solved or didn't care about.=C2=A0 And you've hit o= n some of that above.=C2=A0 How long does a device remain active?=C2=A0= What are the crypto implications for that?=C2=A0 What about planning updates, = not to mention memory (which really hits COGS)?=C2=A0 How long to do that= for?=C2=A0 Those were relatively easy questions when 4 years is the average lifetime of a laptop with oodles of memory.=C2=A0 Harder when= we're talking 15.


- p7, section 2.2 seems pointless if it's not used later in
  the document - you may as well delete this. FWIW, I don't
find figure 3 useful.

- p9, the list seems to me to be very for-profit-vendor
  oriented.  I wonder would a non-profit or device-using
organisation write a different list? I think they would,
e.g. they might include "crap s/w" and "attempted capture
via proprietary APIs/data formats/cloudy services" as
threats.

- p11, I would argue that privacy deserves much more
  attention in this document than this, and that this
document isn't much use without that. For example, it's
important to include the scenario where a static sensor
emits a packet due to the presence/absence of people - in
that scenario anyone who can see that packet can potentially
invade the privacy of the people involved.  You do include
more in section 5, but see my comment below about how that
section is(n't:-) organised.

- p12, Mirai shows that sets of crap devices can create a
  DDoS vector - that deserves a mention here. (And you note
it in 4.3.)

- p20, "the fact is that many IoT devices and systems have
  very limited security." It seems a bit late to say this on
page 20:-)

- p21, I'm not sure an RFC is a good place to wonder about
  potential future regulation, unless that's to be done in a
more thorough manner. I'd say deleting the last two
paragraphs of section 4.3 and replacing those with a single
sentence that "redional regulations aren't unlikely" might
be better. 

It depends on the goal and audience.


- p22, I don't agree with the crypto points made (IMO, only
  devices that can verify an occasional signature ought be
exposed to the Internet) - but even so the references here
aren't good - curve 25519 ought be the main ECC reference
relating to lessened CPU requirements. It's also a surprise
to not see a mention of chacha.

- p12, "Thus, ensuring a proper level of security in an IoT
  system at any point of time is challenging.  To address
this challenge, a process for secure product creation is
required to ensure that an IoT system is secure and no
security risks are present." That's just silly - aiming for
a perfect system ("no security risks") is pointless as those
do not exist.
Agree.=C2=A0 Suggest, "to minimize risks at a reasonable cost, and to= mitigate vulnerabilities as and when they are discovered."=C2=A0 Or s= ome such.

- p12, a PIA ought also consider the kind of inferences that
  an observer of the system can make and re-identification
and is not only about handling PII

- p13, 4.1 should have some mention of LPWANs and indeed
  those deserve more text in general as the set of usable
security mechanisms and challenges differ in those parts of
networks.  You do mention LPWAN in 5.1.4 - which confused me
as that text probably should be here in 4.x.  You might also
wanna reference the LPWAN overview draft, currently in IETF
LC.=20

- p16 and elsewhere - the state-of-the-art text should
  really try to indicate which things are or more, or less,
importanct. That can be tricky, but e.g.  presenting HIP as
being of equal importance to (D)TLS here isn't useful, nor
particularly credible. I also wonder if OSCOAP is as mature
and important as the text implies.

- p21, I don't get the logic behind the organisation of
  section 5, it seems to be a just-so list if things
described at fairly different levels of detail, e.g.  5.1 vs
5.2. I'd say a bit of thought as to how to organise this
section could lead to a better organised text.  I'm not sure
how that'd be best done myself, but perhaps some discussion
within the RG would help there.

- p21, one of the significant challenges here is vendor
  lock-in. IMO, that encourages short-term thinking (e.g.
"it'll be more secure since it only talks to our
cloud-server") but at the possible longer term cost of not
getting security and multi-vendor interop. which is what the
buyers of devices presumably would prefer.

I am not sure I understand your point.=C2=A0 multi-vendor interop is itself a threat vector, from an epidemiological perspective.=C2=A0 Th= at is- interoperability comes at a cost, but one people often think is worth paying.=C2=A0 My favorite example of this was the Morris worm, = not because of how widely it spread, but because it didn't go father due to processor differences.=C2=A0 But it also goes to Geer at al and monocultures.=C2=A0 I don't know if I would address that in this work= , other than perhaps to point out that a convergence in IoT approaches will have the usual pluses and minuses, just as has happened elsewhere (e.g, SNMP or even the processor fiasco).

Eliot
--------------A25C3F91380B926619602155-- --r2veUD7CkMOfNtRwXAoXiUI3vHABu7wNK-- --KrmCJf7fLhVXsqIclg2xtJcwusQ2Ut8hu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpPrTAACgkQh7ZrRtnS ejPkEgf+OqgD+zsCJqxl92Q58cUOmyLOYrXJD+MS27QS2JTVOfT2p8LC8JRLvrBk Va33XrBJP4/lPKXdy38Pb0vRSpn5kxUdiyoLHBh/0EzxkvjMLd6tVQPgg1/kK3OO KEZZWfLOkVOk4TpJddzaWYpPRgAPkLnvovqSDWcBnws0MWnjQbl8KROKeDTPScfQ HEKokG8WM4xI5a8ucUvPBI66ff5jMg7EXr8DErp9enpQpvqAY32Eq/lKa9K1P/sr NcSRWiFmGz7AA5z/KJCqljychKUqK8f9nEM1kaGbVk497wKPgJO3+OCO1uM8YmVW 6hKZT5hvXr6/fBn3ej6rL714hMb/EQ== =tk6P -----END PGP SIGNATURE----- --KrmCJf7fLhVXsqIclg2xtJcwusQ2Ut8hu-- From nobody Fri Jan 5 09:29:48 2018 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 D42CA127241 for ; Fri, 5 Jan 2018 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1J6UYN8WKjX for ; Fri, 5 Jan 2018 09:29:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4787312708C for ; Fri, 5 Jan 2018 09:29:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DE743BE58; Fri, 5 Jan 2018 17:29:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_w7hfjEzE_X; Fri, 5 Jan 2018 17:29:38 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6E71CBE56; Fri, 5 Jan 2018 17:29:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1515173378; bh=gfEn/7DKNdR6XeDRbldQt5/QLjOzWxUTroAHBzgPQM8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lSbwXNpsksVtg9oTuaj/mFYxmqfsyyQtwdE258EKNa5z2EcbiIrrM2OAvY54I71KT Yqe8O8B54fn3UtOqOFOwr6/EgnCot1Lq+kPORKvsRVBTZdgOrnTkN2J+5Gmdf6Gfbc s8rSrQAcwn2KyzztLHB3pVgCWJh/lyR5VTG4t5V4= To: Eliot Lear , t2trg@irtf.org References: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> <3efc08b9-2e14-2b96-d00f-0b72524fb415@cisco.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <2c266434-937b-7c56-189e-5c92d56750d3@cs.tcd.ie> Date: Fri, 5 Jan 2018 17:29:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3efc08b9-2e14-2b96-d00f-0b72524fb415@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QDCCcocgmluIvG7M3HJr2nrqAB9sc1nz4" Archived-At: Subject: Re: [T2TRG] review of draft-irtf-t2trg-iot-seccons X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 17:29:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QDCCcocgmluIvG7M3HJr2nrqAB9sc1nz4 Content-Type: multipart/mixed; boundary="Wx6uNWIjQ7hEOzj4ikUq9LvBkKKG1drpA"; protected-headers="v1" From: Stephen Farrell To: Eliot Lear , t2trg@irtf.org Message-ID: <2c266434-937b-7c56-189e-5c92d56750d3@cs.tcd.ie> Subject: Re: [T2TRG] review of draft-irtf-t2trg-iot-seccons References: <4c4023dd-4f36-eb55-8178-2e12f40c52a8@cs.tcd.ie> <3efc08b9-2e14-2b96-d00f-0b72524fb415@cisco.com> In-Reply-To: <3efc08b9-2e14-2b96-d00f-0b72524fb415@cisco.com> --Wx6uNWIjQ7hEOzj4ikUq9LvBkKKG1drpA Content-Type: multipart/mixed; boundary="------------CCF46CA29839F659E91246A6" Content-Language: en-GB This is a multi-part message in MIME format. --------------CCF46CA29839F659E91246A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/05/2018 04:52 PM, Eliot Lear wrote: > Hi Stephen, >=20 > Just a few comments on top of your comments: Same here. >=20 >=20 >=20 > On 05.01.18 17:10, Stephen Farrell wrote: >> >> SF review of draft-irtf-t2trg-iot-seccons-09 >> 20180105 >> >> (Note that I suggest referring to rfc 8240 and the LPWAN >> overview draft and am an editor for both of those. I do >> think they'd be good additions, but didn't want you to think >> I'm sneakily trying to up my h-index:-) >> >> - 50 pages, sheesh >=20 > A few of us are considering writing a book on this subject.=C3=82=C2=A0= The > challenge will be keeping it under 600 pages.=C3=82=C2=A0 Of course, pi= cking the > RIGHT 50 pages for this work is a different story. Fair point. > Totally agree with your top point that the audience and intended use ha= s > to be crystal clear up front. Right. Some audiences might only need 10 pages with good references. Others might need that book but that'd not be a good RFC. >=20 >> >> - p1: crap code is surely the biggest security challlenge >> here, if this doc is to be useful it'll need to recognise >> that. >=20 > Yes, but it has to mesh with your top point. >> >> - p3: I don't see the point of sales-speak such as "The >> things that are part of the Internet of Things are no >> longer unresponsive and have transformed into computing >> devices that understand and react to the environment they >> reside in." >=20 > If you think THAT's sales speak...=C3=82=C2=A0 Emm... we're talking abo= ut massive > swathes of devices that have nothing whatsoever in common except for th= e > idea that they have a transceiver, and are all classed IoT.=C3=82=C2=A0= The spin > started a long time ago. Sure. Doesn't mean an RG draft needs to contribute more to that pile though. (For at least this reader, such text is very off-putting.) >> >> - p4, the lifecycle doesn't start when a tangible device is >> manufactured but rather when the oldest bit of code the >> ends up in the device was written. That's a significant >> point, esp for smaller vendors who often re-use unpatched >> old builds that "work" but may be wildly insecure. >=20 > There are actually two points: old code and unpatched code.=C3=82=C2=A0= Old code > isn't necessarily bad if there are no known vulnerabilities with it.=C3= =82=20 Fair enough. I guess it'd have been more accurate to say "old packages" or some such. I do think the versioning of e.g. the linux kernel used tends to tell a lot. > Let's face it: there aren't too many reports of problems with /bin/true= =2E Well, I thought [1] was interesting. But sure. [1] https://lists.gnu.org/archive/html/coreutils/2017-12/msg00045.html= >=20 >> >> - p4, I'd argue that the lifecycle could include some >> recognition of OSS, but I'm not sure how to properly >> include that. >> >> - p4, the lifecycle could also include an on-the-shelf phase >> and a phase where a device is re-badged by some vendor who >> wasn't the actual original manuf. Such phases can >> significantly complicate s/w update and bootstrapping. >=20 > Different devices need to handle this differently, and this is a > fundamental challenge to keeping such a doc smaller.=C3=82=C2=A0 For in= stance, > Internet Barbie probably needs different capabilities in this regard > than, say, building lighting and management, which has different > requirements from, say, a car, which has different requirements from, > say, a manufacturer floor robot.=C3=82=C2=A0 The best I think one can d= o is > establish a bit of a matrix. True. Text based on your paragraph above though could be a good addition. >=20 >> >> - p4, there are two other end-states that probably ought be >> part of the lifecycle - where a vendor end-of-life's a >> device type that's still in use and where a device is simply >> forgotten but keeps on trucking.=20 >> >> - p6, Security for these devices is not more important than >> for other (sub)systems. The reason security for these >> devices deserves additional effort is that to-date, vendors >> have done a terrible job. The situation today with these >> devices resembles PC security about 20+ years ago. >=20 > There's SOME of that but I would take care not to lay all of that on Io= T > vendors.=C3=82=C2=A0 Shining security successes of any form are hard to= come by.=C3=82=C2=A0 > To me the key is that "IP on everything" has become a bit more of a > reality, and when one gets beyond general purpose computing with its > well known business model and environmental constraints, there's some > fresh thinking needed to look a problems we either thought solved or > didn't care about.=C3=82=C2=A0 And you've hit on some of that above.=C3= =82=C2=A0 How long does > a device remain active?=C3=82=C2=A0 What are the crypto implications fo= r that?=C3=82=C2=A0 > What about planning updates, not to mention memory (which really hits > COGS)?=C3=82=C2=A0 How long to do that for?=C3=82=C2=A0 Those were rela= tively easy questions > when 4 years is the average lifetime of a laptop with oodles of memory.= =C3=82=C2=A0 > Harder when we're talking 15. I don't think the duration creates any real new issues. Memory, power etc constraints do. But I guess I would defend the proposition that yes, vendors have done a bad job to date, just as was the case with PCs in the '90s. We're in a better place with PCs now, and will also be with smaller devices in a shorter timeframe (I expect) but IMO a lot of the security/privacy issues in this context are down to commercial decisions about pricing and time to market and aren't that much to do with technical constraints. (But we're digressing, I am not suggesting the draft ought try to allocate blame for the current situation.) >=20 >> >> - p7, section 2.2 seems pointless if it's not used later in >> the document - you may as well delete this. FWIW, I don't >> find figure 3 useful. >> >> - p9, the list seems to me to be very for-profit-vendor >> oriented. I wonder would a non-profit or device-using >> organisation write a different list? I think they would, >> e.g. they might include "crap s/w" and "attempted capture >> via proprietary APIs/data formats/cloudy services" as >> threats. >> >> - p11, I would argue that privacy deserves much more >> attention in this document than this, and that this >> document isn't much use without that. For example, it's >> important to include the scenario where a static sensor >> emits a packet due to the presence/absence of people - in >> that scenario anyone who can see that packet can potentially >> invade the privacy of the people involved. You do include >> more in section 5, but see my comment below about how that >> section is(n't:-) organised. >> >> - p12, Mirai shows that sets of crap devices can create a >> DDoS vector - that deserves a mention here. (And you note >> it in 4.3.) >> >> - p20, "the fact is that many IoT devices and systems have >> very limited security." It seems a bit late to say this on >> page 20:-) >> >> - p21, I'm not sure an RFC is a good place to wonder about >> potential future regulation, unless that's to be done in a >> more thorough manner. I'd say deleting the last two >> paragraphs of section 4.3 and replacing those with a single >> sentence that "redional regulations aren't unlikely" might >> be better.=20 >=20 > It depends on the goal and audience. >=20 >> >> - p22, I don't agree with the crypto points made (IMO, only >> devices that can verify an occasional signature ought be >> exposed to the Internet) - but even so the references here >> aren't good - curve 25519 ought be the main ECC reference >> relating to lessened CPU requirements. It's also a surprise >> to not see a mention of chacha. >> >> - p12, "Thus, ensuring a proper level of security in an IoT >> system at any point of time is challenging. To address >> this challenge, a process for secure product creation is >> required to ensure that an IoT system is secure and no >> security risks are present." That's just silly - aiming for >> a perfect system ("no security risks") is pointless as those >> do not exist. > Agree.=C3=82=C2=A0 Suggest, "to minimize risks at a reasonable cost, an= d to > mitigate vulnerabilities as and when they are discovered."=C3=82=C2=A0 = Or some such. >> >> - p12, a PIA ought also consider the kind of inferences that >> an observer of the system can make and re-identification >> and is not only about handling PII >> >> - p13, 4.1 should have some mention of LPWANs and indeed >> those deserve more text in general as the set of usable >> security mechanisms and challenges differ in those parts of >> networks. You do mention LPWAN in 5.1.4 - which confused me >> as that text probably should be here in 4.x. You might also >> wanna reference the LPWAN overview draft, currently in IETF >> LC.=20 >> >> - p16 and elsewhere - the state-of-the-art text should >> really try to indicate which things are or more, or less, >> importanct. That can be tricky, but e.g. presenting HIP as >> being of equal importance to (D)TLS here isn't useful, nor >> particularly credible. I also wonder if OSCOAP is as mature >> and important as the text implies. >> >> - p21, I don't get the logic behind the organisation of >> section 5, it seems to be a just-so list if things >> described at fairly different levels of detail, e.g. 5.1 vs >> 5.2. I'd say a bit of thought as to how to organise this >> section could lead to a better organised text. I'm not sure >> how that'd be best done myself, but perhaps some discussion >> within the RG would help there. >> >> - p21, one of the significant challenges here is vendor >> lock-in. IMO, that encourages short-term thinking (e.g. >> "it'll be more secure since it only talks to our >> cloud-server") but at the possible longer term cost of not >> getting security and multi-vendor interop. which is what the >> buyers of devices presumably would prefer. >=20 > I am not sure I understand your point.=C3=82=C2=A0 multi-vendor interop= is itself a > threat vector, from an epidemiological perspective.=C3=82=C2=A0 That is= - > interoperability comes at a cost, but one people often think is worth > paying.=C3=82=C2=A0 My favorite example of this was the Morris worm, no= t because of > how widely it spread, but because it didn't go father due to processor > differences.=C3=82=C2=A0 But it also goes to Geer at al and monoculture= s.=C3=82=C2=A0 I don't > know if I would address that in this work, other than perhaps to point > out that a convergence in IoT approaches will have the usual pluses and= > minuses, just as has happened elsewhere (e.g, SNMP or even the processo= r > fiasco). =46rom the POV of someone deploying I think vendor lock-in is a fairly clear threat in this context. Esp when one thinks about services that are suddenly EOL'd by the vendor. I agree that multi-vendor interop doesn't in itself mean "more secure" but it does at least tend to force use of explicit well-defined security mechanisms that can (appear to be) unnecessary in a single-vendor environment. And yes, sometimes when forced to define such mechanisms, it becomes clear that nobody would use the resulting system for various reasons. (E.g. if the answer were "use whatever flavour of IPsec you prefer":-) So I'm not saying multi-vendor interop is always "right" but dealing security without vendor lock-in is a challenge worth a mention I reckon. Cheers, S. >=20 > Eliot >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------CCF46CA29839F659E91246A6 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------CCF46CA29839F659E91246A6-- --Wx6uNWIjQ7hEOzj4ikUq9LvBkKKG1drpA-- --QDCCcocgmluIvG7M3HJr2nrqAB9sc1nz4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaT7YCAAoJEFqy+vF7FyvqNJ4P/A6BOQHlSiVHOdB2Dq2NbKP9 KkhzVue1hBvAHQ9KWWrhzoWNpV6UxmbAyVoUWa/H7XHL4p2qfMTUkeUSTsNkoWo/ Aem5/X8WP3w2JVKin7Aiwc5S4hIRXfYH+Y34mq81sMmhyiV7UYWZPx6JJQqw/xeq RSKHJ9D41N4Ygce+yZi3l1Mqfra2L2eUBB4Dbyihzj3BfmhtoPh1ozcCvfERzpjU W8li3lCe7zgG0A1Tp0qIrAdBjvFj5vRc9prkXkKTQQnCJWU75770gHV6BFQ59W7r SOqe9ZDgyzu/XuSnDns0nhxJyJvft33+wUvWFSiFtOfrx6kvdaiVzD/e8+qq1Bkq u8fm0pckeE+/xg6BllLqav6kv/fqnJtGYbrLL0cRQhfOQjuOwdJ08UYXtr3S3f3J R9aH/XWn+Vbz6oItsLXyQAYJ/bJ5ZyVOt7xohdfcHv39Mvvxb2y8NjgI6FTrDs4g Y6uG3N+U9KFsGZq7C1RiiHqysaBKE1LNEUlYXXNnd96+/OkvdoaamDABfHnH+riH WwEG90dOAE6edNmKiPY7af3Jvv4qM8JyZ7vnDWzZyx20T3oX54pZKL4Z/dgSHcyf XfuCggWEWCfTjs3GojPjA+NBcSAzN00k0m7norNPca+WljgSOw+dJCSY52CZZ31M y/8rVMX7eaZMgv0qnAHT =aqfE -----END PGP SIGNATURE----- --QDCCcocgmluIvG7M3HJr2nrqAB9sc1nz4-- From nobody Mon Jan 8 03:19:35 2018 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 2BE9D1273E2 for ; Mon, 8 Jan 2018 03:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_bab7Ob7G-D for ; Mon, 8 Jan 2018 03:19:32 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7411243FE for ; Mon, 8 Jan 2018 03:19:31 -0800 (PST) X-AuditID: c1b4fb2d-b4dff70000007932-67-5a5353c0d146 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DE.74.31026.0C3535A5; Mon, 8 Jan 2018 12:19:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Mon, 8 Jan 2018 12:19:28 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "T2TRG@irtf.org" Thread-Topic: Next WISHI hackathon continuation call (January 8th, 2018) Thread-Index: AQHTeQtKurBHzhK+CU2DnWM8gBRpGqNp4j0A Date: Mon, 8 Jan 2018 11:19:28 +0000 Message-ID: <7A0C1833-7FC4-4EC4-BC0D-2126F8D7E9CD@ericsson.com> 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="utf-8" Content-ID: <57214978DD8DE447B9D652CC642C6653@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7n+7B4OAogzuHOCzeP+hhcWD0mLzx MFsAYxSXTUpqTmZZapG+XQJXxtEL19kL5nBUzFm5kbmBsYGji5GTQ0LAROLOj+tsXYxcHEIC hxklDm/qhXIWM0p0/7vBAlLFJmAr8aR1H2sXIweHiICqxLXn8SBhYQF3iU1bjzOB2CICHhJX JmxihrCNJGasfccIUs4ioCLxeXUFSJhXwF7i/s05YBOFgOzuv9PAbE4BB4md36YwgtiMAmIS 30+tARvJLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJWklh0+zMTyCpmAU2J9bv0IVqtJb4f O8oKYStKTOl+yA5xgqDEyZlPWCYwis5CsmEWQvcsJN2zkHTPQtK9gJF1FaNocWpxcW66kbFe alFmcnFxfp5eXmrJJkZglBzc8lt3B+Pq146HGAU4GJV4eBOdgqOEWBPLiitzDzFKcDArifD+ 8QEK8aYkVlalFuXHF5XmpBYfYpTmYFES5z3pyRslJJCeWJKanZpakFoEk2Xi4JRqYOzm87j1 1zS0RGX78TeBQvN2lPczudVu3xsnYJaUveOl+qXtN+W2ntZgKPn1UfRxhlFt3Pq3PeFTZ0rE aYdv02x/16KSt6ZLfdo8w30He3iuCHY2aiiLe0u3MIWcZ3hucEe6pcJt0qsGDQe/1Y8yhL9m vXKqO1C4PHeP8KOlq1yOiUwqdmCvVGIpzkg01GIuKk4EAJoB/vGOAgAA Archived-At: Subject: Re: [T2TRG] Next WISHI hackathon continuation call (January 8th, 2018) X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 11:19:34 -0000 UmVtaW5kZXI6IHRoZSBuZXh0IFdJU0hJIGNhbGwgaXMgdG9kYXkuIFVwZGF0ZWQgYWdlbmRhIGlu IHRoZSB3aWtpOg0KaHR0cHM6Ly9naXRodWIuY29tL3QydHJnL3dpc2hpL3dpa2kvQWdlbmRhLWl0 ZW1zDQoNCg0KQ2hlZXJzLA0KQXJpDQoNCj4gT24gMTkgRGVjIDIwMTcsIGF0IDIyLjUyLCBBcmkg S2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBhbGws DQo+IA0KPiBCYXNlZCBvbiB0aGUgKHJlKXNjaGVkdWxpbmcgRG9vZGxlIGFuZCBkaXNjdXNzaW9u cyBpbiB0aGUgcHJldmlvdXMgV0lTSEkgY2FsbCwgdGhlIGJlc3QgdGltZSB0byBjb250aW51ZSB0 aGUgV0lTSEkgaGFja2F0aG9uIGRpc2N1c3Npb25zIHNlZW1zIHRvIGJlIEphbnVhcnkgOHRoIDc6 MDAtODozMCBBTSBQU1QgKDE2OjAwLTE3OjMwIENFU1QpLg0KPiANCj4gRHJhZnQgYWdlbmRhIGlz IGF2YWlsYWJsZSBpbiB0aGUgV0lTSEkgd2lraToNCj4gaHR0cHM6Ly9naXRodWIuY29tL3QydHJn L3dpc2hpL3dpa2kvQWdlbmRhLWl0ZW1zDQo+IA0KPiBKb2luIHRoZSBjYWxsIGhlcmU6IGh0dHBz Oi8vaml0c2kudG9vbHMuaWV0Zi5vcmcvdDJ0cmctd2lzaGkNCj4gDQo+IFJhdyBub3RlcyBmcm9t IHRoZSBwcmV2aW91cyBjYWxsIGFyZSBhdmFpbGFibGUgaW4gRXRoZXJwYWQ6DQo+IGh0dHBzOi8v ZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9ub3Rlcy10MnRyZy13aXNoaS0yMDE3MTIxOA0KPiAN Cj4gDQo+IENoZWVycywNCj4gQXJpDQoNCg== From nobody Tue Jan 16 00:48:50 2018 Return-Path: X-Original-To: t2trg@irtf.org Delivered-To: t2trg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7177612FAF4; Tue, 16 Jan 2018 00:48:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cabo@tzi.org, t2trg@irtf.org, irtf-chair@irtf.org, t2trg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151609252745.11729.5441506777887500501.idtracker@ietfa.amsl.com> Date: Tue, 16 Jan 2018 00:48:47 -0800 Archived-At: Subject: [T2TRG] t2trg - New Meeting Session Request for IETF 101 X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 08:48:47 -0000 A new meeting session request has just been submitted by Carsten Bormann, a Chair of the t2trg working group. --------------------------------------------------------- Working Group Name: Thing-to-Thing Area Name: IRTF Session Requester: Carsten Bormann Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: cbor httpbis core ace lpwan 6lo roll ice suit anima i2nsf Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm artarea teep Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg intarea People who must be present: Carsten Bormann Ari Keranen Resources Requested: Special Requests: Early in the week (Monday/Tuesday) would help so participants can join that then need to move on to the OCF meeting in Prague. Please also avoid any IoT related BOFs that might come up. --------------------------------------------------------- From nobody Tue Jan 16 03:17:05 2018 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 B4D06131479 for ; Tue, 16 Jan 2018 03:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM-5UfAiJzpl for ; Tue, 16 Jan 2018 03:16:59 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCB713144A for ; Tue, 16 Jan 2018 03:15:50 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-67-5a5ddee332e3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 10.08.31026.3EEDD5A5; Tue, 16 Jan 2018 12:15:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Tue, 16 Jan 2018 12:15:47 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "T2TRG@irtf.org" Thread-Topic: Next WISHI virtual meeting (January 22nd, 2018) Thread-Index: AQHTjrtbZBzcLYGG706EW+h3L7lWHA== Date: Tue, 16 Jan 2018 11:15:47 +0000 Message-ID: <439BA5FC-29F7-44D5-BA1C-53C42A77B7DD@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2K7uu6Te7FRBtd7eCzeP+hhcWD0mLzx MFsAYxSXTUpqTmZZapG+XQJXxtxb59gKrrBUXFh0krmB8SlzFyMnh4SAicSz2zdYuxi5OIQE DjNKrN86jxnCWcIosWpVKxNIFZuAvcTkNR8ZQWwRAVWJ5ikbWEFsYQELif/3D7NCxG0lPtw4 ClWjJ/Flxj8wmwWo/temVWA2L9CcQw9Xg9mMAmIS30+tAZvPLCAucevJfCaIiwQkluw5D3Wd qMTLx/9YIWwlibWHt7NA1OtJ3Jg6hQ3Ctpb4tPkW1BxtiWULXzND7BKUODnzCcsERuFZSFbM QtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGPwHt/zW3cG4+rXj IUYBDkYlHt7ft2OjhFgTy4orcw8xSnAwK4nwNgbHRAnxpiRWVqUW5ccXleakFh9ilOZgURLn PenJGyUkkJ5YkpqdmlqQWgSTZeLglGpgTNjE+SRjyqSb/Za3fPaWqpZ/d5BqYWNxY9k9T2np +WRz69LVDDHVEzbvU9n1Q/F/5EbDLdqMr9R3nbnArrrN70Gk2uXzvl+ZV61/sNhKq1M3Xkyp RXHFCjdlu0ZJoySXjOgj5Vmiv3P3Wqhk8c2N3yySwRYqdf3nM4fX86ZJrX0zZ/e/yrrDSizF GYmGWsxFxYkAKFAK7noCAAA= Archived-At: Subject: [T2TRG] Next WISHI virtual meeting (January 22nd, 2018) X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 11:17:04 -0000 Hi all, The next WISHI virtual meeting will be on Monday, January 22nd 7:00-8:30 AM= PST (16:00-17:30 CEST). See the latest draft agenda and previous meeting minutes in the WISHI wiki: https://github.com/t2trg/wishi/wiki/Agenda-items Join the call here: https://jitsi.tools.ietf.org/t2trg-wishi In this call we will discuss all the WISHI activities, ongoing and planned,= and in the latter half focus on the WISHI hackathon continuation. We welcome proposals for agenda items and also volunteers to drive the disc= ussion on the existing items. Thanks, Ari & Carsten= From nobody Fri Jan 19 06:05:38 2018 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 A1B4B12D93E for ; Fri, 19 Jan 2018 06:05:36 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOkjrwYqys98 for ; Fri, 19 Jan 2018 06:05:34 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A841201FA for ; Fri, 19 Jan 2018 06:05:33 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-19-5a61fb2bac77 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.EC.14322.B2BF16A5; Fri, 19 Jan 2018 15:05:31 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Fri, 19 Jan 2018 15:05:31 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "T2TRG@irtf.org" Thread-Topic: [T2TRG] Next WISHI virtual meeting (January 22nd, 2018) Thread-Index: AQHTjrtbJC4xE3weQUmlvmoMUWDg/qN7LuYA Date: Fri, 19 Jan 2018 14:05:30 +0000 Message-ID: References: <439BA5FC-29F7-44D5-BA1C-53C42A77B7DD@ericsson.com> In-Reply-To: <439BA5FC-29F7-44D5-BA1C-53C42A77B7DD@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7iK7278Qog2PbzC3eP+hhcWD0mLzx MFsAYxSXTUpqTmZZapG+XQJXxqHFWxgLHnBWrDs3ma2B8QBnFyMnh4SAicS547cZuxi5OIQE DjNK7HrwkxkkISSwhFGi8zw3iM0mYCvxpHUfK4gtIqAq0TxlA5DNwSEs4CJxeAILRNhVYtuj 3YwgYREBI4mbb41BwixA1b1PF7CBhHkF7CW2PguBGG4vsfbUPzYQm1PAQWLh64VgNqOAmMT3 U2uYQGxmAXGJW0/mM0FcKSCxZM95ZghbVOLl43+sELaSxNrD21lAxjMLaEqs36UPYVpLrJ8l ATFFUWJK90N2EJtXQFDi5MwnLBMYRWchWTALoXkWQvMsJM2zkDQvYGRdxShanFpcnJtuZKSX WpSZXFycn6eXl1qyiREYHQe3/LbawXjwueMhRgEORiUe3tSPiVFCrIllxZW5hxglOJiVRHhT rwOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zqlWUQJCaQnlqRmp6YWpBbBZJk4OKUaGD1Ykk6v kL90pp6BtfMXr7md5O0GoX3sf95qzRThjO363+/2TV7p271u863T5FmVj4UXy+hV8W2o28qQ f+Oq/Ft9mx2ZPNu+ny5Zs1HxtMrsm1P4pgfmvDwwXdZ4/frXS/ddej575Z0QV8tJKvc7Eqxn Pbzz/2mV7lMutsdrI31+7EtNCiiWLlNiKc5INNRiLipOBACnKkfKigIAAA== Archived-At: Subject: Re: [T2TRG] Next WISHI virtual meeting (January 22nd, 2018) X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 14:05:37 -0000 UmVtaW5kZXI6IHRoZSBuZXh0IFdJU0hJIGNhbGwgaXMgY29taW5nIG5leHQgTW9uZGF5Lg0KDQoN CkNoZWVycywNCkFyaQ0KDQo+IE9uIDE2IEphbiAyMDE4LCBhdCAxMy4xNSwgQXJpIEtlcsOkbmVu IDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGkgYWxsLA0KPiANCj4g VGhlIG5leHQgV0lTSEkgdmlydHVhbCBtZWV0aW5nIHdpbGwgYmUgb24gTW9uZGF5LCBKYW51YXJ5 IDIybmQgNzowMC04OjMwIEFNIFBTVCAoMTY6MDAtMTc6MzAgQ0VTVCkuDQo+IA0KPiBTZWUgdGhl IGxhdGVzdCBkcmFmdCBhZ2VuZGEgYW5kIHByZXZpb3VzIG1lZXRpbmcgbWludXRlcyBpbiB0aGUg V0lTSEkgd2lraToNCj4gaHR0cHM6Ly9naXRodWIuY29tL3QydHJnL3dpc2hpL3dpa2kvQWdlbmRh LWl0ZW1zDQo+IA0KPiBKb2luIHRoZSBjYWxsIGhlcmU6IGh0dHBzOi8vaml0c2kudG9vbHMuaWV0 Zi5vcmcvdDJ0cmctd2lzaGkNCj4gDQo+IEluIHRoaXMgY2FsbCB3ZSB3aWxsIGRpc2N1c3MgYWxs IHRoZSBXSVNISSBhY3Rpdml0aWVzLCBvbmdvaW5nIGFuZCBwbGFubmVkLCBhbmQgaW4gdGhlIGxh dHRlciBoYWxmIGZvY3VzIG9uIHRoZSBXSVNISSBoYWNrYXRob24gY29udGludWF0aW9uLg0KPiAN Cj4gV2Ugd2VsY29tZSBwcm9wb3NhbHMgZm9yIGFnZW5kYSBpdGVtcyBhbmQgYWxzbyB2b2x1bnRl ZXJzIHRvIGRyaXZlIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBleGlzdGluZyBpdGVtcy4NCj4gDQo+ IA0KPiBUaGFua3MsDQo+IEFyaSAmIENhcnN0ZW4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gVDJUUkcgbWFpbGluZyBsaXN0DQo+IFQyVFJHQGly dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vdDJ0cmcNCg0K From nobody Thu Jan 25 07:30:41 2018 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 D819512E878 for ; Thu, 25 Jan 2018 07:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdhxELSVNqEu for ; Thu, 25 Jan 2018 07:30:33 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCBE12DA40 for ; Thu, 25 Jan 2018 07:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0PFUU4u008296 for ; Thu, 25 Jan 2018 16:30:30 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zS5Zs6YqPzDXBv; Thu, 25 Jan 2018 16:30:29 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 538587027.754673-5231f2f56254a60cd392f8b1fc5dbeab Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 25 Jan 2018 16:30:29 +0100 Message-Id: To: t2trg@irtf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [T2TRG] T2TRG-OCF joint session on ACE X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 15:30:40 -0000 I have set up a repository for the call that will take place in two = hours: https://github.com/t2trg/2018-01-ocf Find there the agenda, call (WebEx) details, as well as first slides. If you have more slides, please send them to me (or in a Github pull = request). Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jan 27 08:34:09 2018 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 221AD1201F2; Sat, 27 Jan 2018 08:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxJRCjD8Qq0f; Sat, 27 Jan 2018 08:34:05 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82C31242F5; Sat, 27 Jan 2018 08:34:04 -0800 (PST) Received: by mail.in.tum.de (Postfix, from userid 107) id E104E1C2A43; Sat, 27 Jan 2018 17:34:01 +0100 (CET) Received: (Authenticated sender: ding) by mail.in.tum.de (Postfix) with ESMTPSA id CD1E51C2A3D; Sat, 27 Jan 2018 17:33:59 +0100 (CET) (Extended-Queue-bit tech_qsdvk@fff.in.tum.de) User-Agent: Microsoft-MacOutlook/10.8.0.171210 Date: Sat, 27 Jan 2018 17:34:02 +0100 From: Aaron Yi DING To: , "T2TRG@irtf.org" Message-ID: <349533C1-2BF5-4C0B-A472-52361B2E2BCF@tum.de> Thread-Topic: EdgeSys with ICN/T2T/Fog in Munich Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [T2TRG] EdgeSys with ICN/T2T/Fog in Munich X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 16:34:07 -0000 One relevant occasion for both RG colleagues: ACM MobiSys Workshop on Edge Systems, Analytics and Networking (EdgeSys 201= 8)=20 https://edgesys18.cm.in.tum.de/ Cheers, Aaron=EF=BB=BF From nobody Sun Jan 28 06:16:03 2018 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 D076112EA7C for ; Sun, 28 Jan 2018 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nextworks-it.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 vKZmkQp4ew3h for ; Sun, 28 Jan 2018 06:15:59 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525F4126FDC for ; Sun, 28 Jan 2018 06:15:59 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id v31so4411610wrc.11 for ; Sun, 28 Jan 2018 06:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nextworks-it.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2wkUiDfAsdWZJuyeMNlNj1TMoL8OTrTCKl2cjd/F78Y=; b=D3we7SlOvQWJOxLsChGvUVhCTDpR04rwZ4Apy5WKhLs+6HpwTc/IEpPyrqFJR4RLc1 kvo58DzDerIX3oiCIM/mcleNZC2koyybOxMb1iTfzAaSTflw8JIAvCiDf7MF1p/K41uU hSvvuHaDpNJrhJMAu+/2MBe/oMOjDgYn6ymz43XjPOKh7ZtM7JN1YOxaMxglskPKfnTs 4bu8IOEALyBcZR1JpJnTx5A4plVaAiQgJnIPr3DQT+tNIMPmcOCnnJ3bWg4tT9HCL19n br51AQwyCP6+MsZSsw76TXTyGhqJzb5r99HbmOLJhswAK9BhY8XHpSXIaCrqmfngEknL rMBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2wkUiDfAsdWZJuyeMNlNj1TMoL8OTrTCKl2cjd/F78Y=; b=T5cRzQBrwU49zH3KUeDEV9AsR/IX5oOqnRQ9ffQxzcraCbKSUuxRGXF3W05PJNrRM4 LavjoZ8cD0c9dFNkNqnDBRlCFZvG0+NcmkhyHXv6fPCtSW/7L+LPk6ATjoXKxp/6Dk3e xPrOfAwk7QU8xNlU0uA7VCznxNfxlkirP6nKBT46MTrT9JNMU9X3/pieTm7F9diIXSfk Whhp2K+WG6cpqYVz1jGWWfpjyCY2Z1CJEUsOkDlFnUsAuVDb15Fzyi1jZCzXQUeVf88B mHK3dtU/qCh96c76trCtn61UBwAT6/3ikS7bABWea4pokh3ihy2VmaUSngUcdvXe2ckI xl5Q== X-Gm-Message-State: AKwxytfJ2wTOVEeMR770tNQG8BhuitDwVO6AuPPZJmEU3IzmcPwsRsts 618x6ZVZGFnOWahvTkQg6X4JDob/1lWERQ8sJj4lCxdB X-Google-Smtp-Source: AH8x2269+ecm1ZIvyCAFtirGd1crY/tZPWvukfg1E2Kj9hUlwOUMT+wZmQz4HIKL8h5QaoQrl63kT8ozutEfo1jFfvA= X-Received: by 10.223.209.6 with SMTP id a6mr1916305wri.169.1517148956851; Sun, 28 Jan 2018 06:15:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.171.209 with HTTP; Sun, 28 Jan 2018 06:15:56 -0800 (PST) From: Gino Carrozzo Date: Sun, 28 Jan 2018 15:15:56 +0100 Message-ID: To: t2trg@irtf.org Content-Type: multipart/alternative; boundary="f4f5e80a10e4a515ba0563d6c471" Archived-At: Subject: [T2TRG] 3rd Workshop on Interoperability and Open-Source Solutions for the Internet of Things (InterOSS-IoT 2018): Call For Papers X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 14:16:03 -0000 --f4f5e80a10e4a515ba0563d6c471 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Apologies if you got multiple copies of this email. This CfP might be of interest for many in t2trg group] 3rd Workshop on Interoperability and Open-Source Solutions for the Internet of Things (InterOSS-IoT 2018) in conjunction with Global IoT Summit 2018 06-09 June, Bilbao, Spain OVERVIEW -------- Internet of Things Interoperability resides on the principle of connecting a large number of devices to a global infrastructure to offer added value features and global services across IoT platforms. In the past years we have witnessed the consolidation of communication protocols connecting various devices and the advent of open source frameworks for IoT interoperability. Standardization initiatives, industry alliances, and collaborative research projects have developed solutions to address the challenge of IoT interoperability. Sensor, actuator, and =E2=80=9Cthing=E2= =80=9D description formats as well as communication protocols and APIs have been designed to build advanced cross-domain IoT solutions and entire ecosystems based on interoperable IoT platform technologies. The challenges ahead are to advance interoperable IoT technologies for handling complex tasks and global interconnected systems in trendy verticals with high impact on the society, e.g. smart cities and ports, healthcare, automated manufacturing lines, connected robots, or autonomous vehicles. Open source interoperability solutions and open standards remain a viable option to automate the collaboration between otherwise closed IoT platforms with key challenges related to semantics, uniform APIs, security, privacy and trust issues, as well as technology uptake with increasing deployments. Following the success of the previous two editions, the =E2=80=9C3rd Worksh= op on Interoperability and Open-Source Solutions for the Internet of Things (InterOSS-IoT)=E2=80=9D focuses on exploring the potential of interoperable= IoT platform technology to facilitate and enhance the creation of complex systems and associated open source technology and open protocols. The workshop addresses current challenges in the IoT domain and promotes uptake by the industry from emerging open source solutions and best practices from IoT deployment experiences. Organized as a scientific event, workshop=E2=80=99s objective is to foster the exchange of practical experie= nces within the IoT community as well as contribute to create new ideas around open issues and gaps on Internet of Things platforms interoperability, architectural principles, standardization efforts, and deployment experiences. We invite authors to submit scientific papers reporting advance in the state of the art and practical experiences on interoperable IoT solutions, solutions relying on open-source software as well as emerging concepts and visionary papers. Topics of interest include (not limited to): IoT Principles, Design and Technology - Interoperability solutions for IoT systems and platforms - Standardisation efforts related to IoT solutions and Applications - Key concepts for interoperable IoT architectures - Semantic models for the IoT Platforms Data Exchange - Security, privacy and trust for IoT Devices and Platforms - IoT device Data Mash-Ups and platforms Orchestration - Solutions for IoT platform federations and interworking - Distributed ledger technology for interoperable IoT ecosystems IoT Experiments, Practice and Applications - IoT applications and real life deployments, e.g., in Smart Cities, Healthcare, Industrial IoT, Robotics, Autonomous Vehicles - Experiences from real industrial IoT deployments - Recent advances in open source IoT platforms and tools - Experimentally-driven Internet of Things experience - Business perspectives on IoT ecosystem creation - Business models and marketplaces InterOSS (http://www.inteross.org/) is bi-annual workshop organized to promotes open discussions for scientific progress, industrial standards evaluation and showcase practical experiences on interoperable IoT applications promoting open-source solutions. The workshop is organized by H2020 projects symbIoTe ( https://www.symbiote-h2020.eu) and BIG IoT (http://big-iot.eu/), which are part of the European Platforms Initiative (IoT-EPI, http://iot-epi.eu/). ORGANIZING COMMITTEE -------------------- Workshop General Chairs: - Ivana Podnar =C5=BDarko (University of Zagreb Faculty of Electrical Engineering and Computing, Croatia) - Martin Serrano (INSIGHT, National University of Ireland Galway, Ireland) - Arne Broering (Siemens, Germany) - Sergios Soursos, Intracom Telecom, Greece Important Dates -------------------------- Paper submission deadline: February 28, 2018 Acceptance Notification: March 31, 2018 Camera-Ready Paper Submission: April 30, 2018 SUBMISSION GUIDELINES --------------------------- Original research papers can be submitted via EDAS at link: https://edas.info/newPaper.php?c=3D24130&track=3D89110. Papers shall be written in English with a maximum paper length of six (6) printed pages and US letter page format. Papers will be fully peer reviewed. Accepted and presented papers will be published in the conference proceedings and submitted to IEEE Xplore as well as other Abstracting and Indexing (A&I) databases. All papers must conform, at time of submission, to the IEEE Formatting Guidelines. Please use either Word Template ( http://wfiot2016.ieee-wf-iot.org/files/2016/03/2014_04_msw_usltr_format-WF_= IoT-2015.doc) or LaTeX package ( http://wfiot2016.ieee-wf-iot.org/files/2016/03/IEEELaTeX_Letter_2Col.zip). IEEE takes the protection of intellectual property seriously. Accordingly, all submissions will be screened for plagiarism using CrossCheck. By submitting your work you agree to allow IEEE to screen your work. For more information please visit: http://www.crossref.org/crosscheck/index.html IEEE reserves the right to exclude a paper from distribution after the conference, including IEEE Xplore=C2=AE Digital Library, if the paper is no= t presented by the author at the conference. --f4f5e80a10e4a515ba0563d6c471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Apologies if you= got multiple copies of this email. This CfP might be of interest for many = in t2trg group]

3rd Workshop on Interop= erability and Open-Source Solutions for the Internet of Things (InterOSS-Io= T 2018)
in conjunction= with Global IoT Summit 2018=C2=A0
06-09 June, Bilbao, Spain

= OVERVIEW
--------
Internet of Things Interop= erability resides on the principle of connecting a large number of devices = to a global infrastructure to offer
added value features and global services across IoT platforms= . In the past years we have witnessed the consolidation of communication pr= otocols connecting various devices and the advent of open source frameworks= for IoT interoperability. Standardization initiatives, industry alliances,= and collaborative research projects have developed solutions to address th= e challenge of IoT interoperability. Sensor, actuator, and =E2=80=9Cthing= =E2=80=9D description formats as well as communication protocols and APIs h= ave been designed to build advanced cross-domain IoT solutions and entire e= cosystems based on interoperable IoT platform technologies.
The challenges ahead are to advance i= nteroperable IoT technologies for handling complex tasks and global interco= nnected systems in trendy verticals with high impact on the society, e.g. s= mart cities and ports, healthcare, automated manufacturing lines, connected= robots, or autonomous vehicles. Open source interoperability solutions and= open standards remain a viable option to automate the collaboration betwee= n otherwise closed IoT platforms with key challenges related to semantics, = uniform APIs, security, privacy and trust issues, as well as technology upt= ake with increasing deployments.
Following the success of the previous two editions, the =E2=80= =9C3rd Workshop on Interoperability and Open-Source Solutions for the Inter= net of Things (InterOSS-IoT)=E2=80=9D focuses on exploring the potential of= interoperable IoT platform technology to facilitate and enhance the creati= on of complex systems and associated open source technology and open protoc= ols.
The workshop addr= esses current challenges in the IoT domain and promotes uptake by the indus= try from emerging open source solutions and best practices from IoT deploym= ent experiences. Organized as a scientific event, workshop=E2=80=99s object= ive is to foster the exchange of practical experiences within the IoT commu= nity as well as contribute to create new ideas around open issues and gaps = on Internet of Things platforms interoperability, architectural principles,= standardization efforts, and deployment experiences.=C2=A0
We invite authors to submit scientifi= c papers reporting advance in the state of the art and practical experience= s on interoperable IoT solutions, solutions relying on open-source software= as well as emerging concepts and visionary papers.
Topics of interest include (not limited to):<= /font>

= IoT Principles, Design and Technology
- Interoperability solu= tions for IoT systems and platforms
- Standardisation efforts related to IoT solutions and Applic= ations
- Key concepts = for interoperable IoT architectures
- Semantic models for the IoT Platforms Data Exchange<= /div>
- Security, privacy and trust= for IoT Devices and Platforms
- IoT device Data Mash-Ups and platforms Orchestration=C2=A0
- Solutions for IoT platfor= m federations and interworking
- Distributed ledger technology for interoperable IoT ecosystems

<= font face=3D"monospace, monospace">IoT Experiments, Practice and Applicatio= ns
- IoT applications = and real life deployments, e.g., in Smart Cities, Healthcare, Industrial Io= T, Robotics, Autonomous Vehicles
- Experiences from real industrial IoT deployments=C2=A0<= /div>
- Recent advances in open sou= rce IoT platforms and tools
- Experimentally-driven Internet of Things experience
- Business perspectives on IoT ecosys= tem creation
- Busines= s models and marketplaces


InterOSS (http://www.inteross.org/) is bi-annual workshop organi= zed to promotes open discussions for scientific progress, industrial standa= rds evaluation and showcase practical experiences on interoperable IoT appl= ications promoting open-source solutions.
The workshop is organized by H2020 projects symbIoTe (<= a href=3D"https://www.symbiote-h2020.eu">https://www.symbiote-h2020.eu)= and BIG IoT (http://big-iot.eu/), which= are part of the European Platforms Initiative (IoT-EPI, http://iot-epi.eu/).

<= br>

<= div>ORGANIZING COMMITTEE
--------------------
Workshop General Chairs:=
- Ivana Podnar =C5=BDarko (Univers= ity of Zagreb Faculty of Electrical Engineering and Computing, Croatia)
- Martin Serrano (INSIGHT= , National University of Ireland Galway, Ireland)
- Arne Broering (Siemens, Germany)
=
- Sergios Soursos, Intracom Teleco= m, Greece

<= /div>

Important Dates
--------------------------
Paper submission deadline: February 28, 2018
Acceptance Notification:= March 31, 2018
Camera= -Ready Paper Submission: April 30, 2018


SUBMISSION GUIDE= LINES
----------------= -----------
Original r= esearch papers can be submitted via EDAS at link: https://edas.info/newPaper.ph= p?c=3D24130&track=3D89110.

Pape= rs shall be written in English with a maximum paper length of six (6) print= ed pages and US letter page format.

Pap= ers will be fully peer reviewed. Accepted and presented papers will be publ= ished in the conference proceedings and submitted to IEEE Xplore as well as= other Abstracting and Indexing (A&I) databases.
=C2=A0
All papers must conform, at time of submission, to the IEEE= Formatting Guidelines. Please use either Word Template (http://wfiot2016.ieee-wf-iot.org/files/2016/03/2014_04_msw_usltr_for= mat-WF_IoT-2015.doc) or LaTeX

For more information please v= isit: http://www.= crossref.org/crosscheck/index.html

= IEEE reserves the right to exclude a paper from distribution after the conf= erence, including IEEE Xplore=C2=AE Digital Library, if the paper is not pr= esented by the author at the conference.

--f4f5e80a10e4a515ba0563d6c471-- From nobody Tue Jan 30 09:17:03 2018 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 22D7112E889 for ; Tue, 30 Jan 2018 09:17:01 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLkaR4BnwESA for ; Tue, 30 Jan 2018 09:16:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AB312EC75 for ; Tue, 30 Jan 2018 09:16:36 -0800 (PST) X-AuditID: c1b4fb30-d49ff70000006bc7-16-5a70a872f47e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.04.27591.278A07A5; Tue, 30 Jan 2018 18:16:35 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Tue, 30 Jan 2018 18:16:34 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "T2TRG@irtf.org" Thread-Topic: Next WISHI virtual meeting (February 5th, 2018) Thread-Index: AQHTme4TqFx++AJXyEmGv5Nn3bvFMg== Date: Tue, 30 Jan 2018 17:16:33 +0000 Message-ID: <5275643D-26F2-44E6-AA55-9C274FA17354@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <893EF047C82D324192A0277585B162B6@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2J7iG7xioIog0832SzeP+hhcWD0mLzx MFsAYxSXTUpqTmZZapG+XQJXRvf5FcwFx5kqll97zdjA2MvUxcjJISFgIrHt0XzmLkYuDiGB w4wSp6+vZINwljBKzG6bxgxSxSZgLzF5zUdGEFtEQFWiecoGVhBbWMBC4uiDl6wQcVuJo8ee sEDYehKHDu0Hi7MA1f+9+p0dxOYFmnNi5mwwm1FATOL7qTVgVzALiEvcejIf6iIBiSV7zjND 2KISLx//Y4WwlSQalzxhhajXk7gxdQobhG0t8fdLEyOErS2xbOFrZohdghInZz5hmcAoPAvJ illI2mchaZ+FpH0WkvYFjKyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQKD/+CW3wY7GF8+ dzzEKMDBqMTDqzS3IEqINbGsuDL3EKMEB7OSCK/I6vwoId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYxr73xN//p1brmKrqehaL0Aqw/7vMPf/9QfaBNZ eMf94pSJG3unpsQ7vPYtfGvTGPkte/sqy5y9YdnPVYSXLJpYrsjB5/Pi9dF8lb5bea8TmGVb Ew0LJ6cmqi+c0Dejkjf+wvsAp2r1o9+cDgse+mgvV9UTqPDDXyWi/BmXwILT7HcCX5TtOKbE UpyRaKjFXFScCAABIHJGegIAAA== Archived-At: Subject: [T2TRG] Next WISHI virtual meeting (February 5th, 2018) X-BeenThere: t2trg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IRTF Thing-to-Thing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 17:17:01 -0000 Hi all, The next WISHI virtual meeting will be on Monday, February 5th 7:00-8:30 AM= PST (16:00-17:30 CEST). See the latest draft agenda and previous meeting minutes in the WISHI wiki: https://github.com/t2trg/wishi/wiki/Agenda-items Join the call here: https://jitsi.tools.ietf.org/t2trg-wishi Cheers, Ari=