From nobody Wed Aug 27 11:48:04 2014 Return-Path: X-Original-To: smartobjectdir@ietfa.amsl.com Delivered-To: smartobjectdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2BA1A6EF2; Wed, 27 Aug 2014 11:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 103hbET-zX6i; Wed, 27 Aug 2014 11:18:37 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id E679B1A0B00; Wed, 27 Aug 2014 11:18:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 355131E45BE; Wed, 27 Aug 2014 11:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZqIdAP0jXw6; Wed, 27 Aug 2014 11:18:08 -0700 (PDT) Received: from [192.168.2.108] (pool-96-255-70-16.washdc.fios.verizon.net [96.255.70.16]) by c8a.amsl.com (Postfix) with ESMTPSA id C3A121E45B8; Wed, 27 Aug 2014 11:18:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: IAB Chair Date: Wed, 27 Aug 2014 14:18:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: To: IETF Announce X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/_dhUKRzPBe74LQkbWQGsr1CM0ZQ X-Mailman-Approved-At: Wed, 27 Aug 2014 11:48:03 -0700 Cc: IETF SmartObjectDir , IETF Subject: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" X-BeenThere: smartobjectdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: IAB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:18:41 -0000 This is a call for review of "Architectural Considerations in Smart = Object Networking" prior to potential approval as an IAB stream RFC. The document is available for inspection here: = https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/ The Call for Review will last until 24 September 2014. Please send = comments to iab@iab.org. On behalf of the IAB, Russ Housley IAB Chair From nobody Thu Aug 28 08:18:25 2014 Return-Path: X-Original-To: smartobjectdir@ietfa.amsl.com Delivered-To: smartobjectdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D104A1A0111; Wed, 27 Aug 2014 12:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.466 X-Spam-Level: * X-Spam-Status: No, score=1.466 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehhv6sUd4o68; Wed, 27 Aug 2014 12:55:29 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3A1A0067; Wed, 27 Aug 2014 12:55:28 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,413,1406606400"; d="scan'208";a="477817885" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 27 Aug 2014 15:54:31 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 27 Aug 2014 15:55:27 -0400 From: "George, Wes" To: IAB , IAB Chair Date: Wed, 27 Aug 2014 15:55:28 -0400 Thread-Topic: Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" Thread-Index: Ac/CMNk7OmnowKcvT3qBqPoVa7OoHg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/4kD2AP5cZ4v1e9RByRKSBl-SkOI X-Mailman-Approved-At: Thu, 28 Aug 2014 08:18:22 -0700 Cc: IETF SmartObjectDir , IETF Subject: Re: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" X-BeenThere: smartobjectdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:55:31 -0000 SSBtYWRlIHRoZSBmb2xsb3dpbmcgY29tbWVudCAoaW4gcGFydCkgb24gLTAzLiBJJ20gbWFraW5n IGl0IGFnYWluLA0KYmVjYXVzZSBpdCBzdGlsbCBhcHBsaWVzIHRvIC0wNC4NCg0KIkl0IHNlZW1z IG9kZCB0byBtZSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc2lsZW50IG9uIHRoZSBhcmNoaXRlY3R1 cmFsDQpjb25zaWRlcmF0aW9ucyB0aGF0IElQdjQgZXhoYXVzdGlvbiBtYXkgaGF2ZSBvbiBTbWFy dCBPYmplY3QgbmV0d29ya2luZy4NClJGQyA2MjcyIGRpc2N1c3NlcyBzdXBwb3J0IGZvciBib3Ro IHByb3RvY29scywgYnV0IHBhcnRpYWxseSBiZWNhdXNlIGl0DQp3YXMgd3JpdHRlbiBpbiAyMDEx LCBpdCB0cmVhdHMgdGhlbSBlcXVhbGx5IChubyByZWNvbW1lbmRhdGlvbiB0byBzdXBwb3J0DQpv bmUgcHJvdG9jb2wgb3ZlciBhbm90aGVyKS4gSSB0aGluayB3ZeKAmXJlIGRvaW5nIHNtYXJ0IG9i amVjdCBpbXBsZW1lbnRlcnMNCmEgZGlzc2VydmljZSBieSBub3QgZGlzY3Vzc2luZyB0aGUgaW5j cmVhc2luZyBsaWtlbGlob29kIHRoYXQgYWNjZXNzIHRvDQpJUHY0IGFkZHJlc3NlcyB3aWxsIGJl IGNoYWxsZW5naW5nIGFuZCBjb3N0bHksIGVzcGVjaWFsbHkgZm9yIHNvbWV0aGluZyBhdA0KdGhl IHNjYWxlIG9mIFNtYXJ0IE9iamVjdCBuZXR3b3JraW5nLiINCg0KDQpBdCB0aGUgdGltZSwgdGhl IGZlZWRiYWNrIGZyb20gSGFubmVzIHdhcyB0aGF0IGRpc2N1c3NpbmcgYSBzcGVjaWZpYw0KcHJv dG9jb2wgd2FzIHRvbyBsb3ctbGV2ZWwgZm9yIHRoaXMgZG9jdW1lbnQsIGJ1dCBJIGFyZ3VlZCB0 aGF0IHRoZSBsYWNrDQpvZiBJUHY0IGFkZHJlc3MgYXZhaWxhYmlsaXR5LCB0aGUgcG90ZW50aWFs IG9yZGVyIG9mIG1hZ25pdHVkZSBvZiB0aGUNCmRlcGxveW1lbnQgb2YgZGV2aWNlcyBpbiBhcHBs aWNhdGlvbnMgbGlrZSB0aGlzLCBhbmQgdGhlaXIgbGltaXRhdGlvbnMNCihwb3dlciwgZXRjKSBt YWtlIElQdjQgdnMgSVB2NiB2ZXJ5IG11Y2ggYW4gaW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0 aW9uDQphbmQgYW4gYXJjaGl0ZWN0dXJhbCBjb25zaWRlcmF0aW9uLiBJZiB5b3VyIGFyY2hpdGVj dHVyZSBkb2Vzbid0IHRha2UgaW50bw0KYWNjb3VudCB0aGUgZmFjdCB0aGF0IHdlJ3JlIG91dCBv ZiBJUHY0IGFkZHJlc3NlcywgdGhlbiBpdCdzIG5vdCBtdWNoIG9mDQphbiBhcmNoaXRlY3R1cmUu IEFkZGluZyBhIGRpc2N1c3Npb24gYWJvdXQgSVB2NCdzIGxpbWl0YXRpb25zIGFuZCBhDQpyZWNv bW1lbmRhdGlvbiBmb3IgSVB2NiBpc24ndCBhIGRpc2N1c3Npb24gb2YgYSBwcm90b2NvbCBmb3Ig dGhlIHNha2Ugb2YNCmNvbXBhcmUgYW5kIGNvbnRyYXN0LCBhcyBtdWNoIGFzIGl0IGlzIGFja25v d2xlZGdpbmcgdGhlIHJlYWxpdHkgb2YgdGhlDQpzaXR1YXRpb24uDQpJIGRvbid0IGJlbGlldmUg dGhhdCBzbWFydCBvYmplY3QgbmV0d29ya2luZyBpcyB2aWFibGUgYXQgYW55IHJlYWwgc2NhbGUN CndpdGhvdXQgSVB2Ni4gVGhlcmUgc2ltcGx5IGFyZW4ndCBlbm91Z2ggYWRkcmVzc2VzLCBldmVu IHRha2luZyBpbnRvDQphY2NvdW50IFJGQzE5MTguIEkgc2VlIHRoaXMgKnRvZGF5KiBpbiBteSBv d24gbmV0d29yayB3aXRoIGRlcGxveW1lbnRzDQpsaWtlIGxhcmdlLXNjYWxlIFdpRmkgYW5kIGNl bGwgdG93ZXIgZGVwbG95bWVudCwgc2V0LXRvcC1ib3hlcywgZXRjLiBJDQp0aGluayB0aGF0J3Mg dGhlIHJpZ2h0IHNvcnQgb2Ygc2NhbGUgdG8gb2JzZXJ2ZSBhcyBhbiBhbmFsb2cgZm9yIHNtYXJ0 DQpvYmplY3QgbmV0d29ya3MgLS0gdGhleSBjb3VsZCBwb3RlbnRpYWxseSBiZSBvcmRlcnMgb2Yg bWFnbml0dWRlIGJpZ2dlci4NClRoZSBtb3JlIGNsZWFybHkgd2Ugc2F5IHRoYXQgc21hcnQgb2Jq ZWN0IG5ldHdvcmtzIGFuZCB0aGVpciBzdXBwb3J0aW5nDQpzeXN0ZW1zIHNob3VsZCBhc3N1bWUg SVB2NiwgYW5kIHBvc3NpYmx5IElQdjYtb25seSBiZWNhdXNlIG9mIElQdjQncw0KaW5oZXJlbnQg c2NhbGluZyBsaW1pdGF0aW9uLCB0aGUgYmV0dGVyIG9mZiB3ZSdyZSBnb2luZyB0byBiZS4NCg0K U28gaW4gdGVybXMgb2Ygc21hcnQgb2JqZWN0cywgZXNwZWNpYWxseSB0aG9zZSB0aGF0IGFyZSBz ZXZlcmVseSByZXNvdXJjZQ0KY29uc3RyYWluZWQsIEkgdGhpbmsgdGhlIHJlY29tbWVuZGF0aW9u cyBhcmUtIEZpcnN0IHN1cHBvcnQgSVB2Niwgd2hldGhlcg0KaXQncyBmdWxsIElQdjYsIG9yIHNv bWV0aGluZyBsaWtlIDZMb1BBTi4gQW55IGludGVyd29ya2luZyBvciBvdGhlciBpc3N1ZXMNCnRo YXQgYXJpc2UgZnJvbSB0aGF0IGNob2ljZSBjYW4gYmUgYWRkcmVzc2VkIG9uIHRoZSBmYXIgc2lk ZSB3aGVyZSB0aGVyZQ0KaXNuJ3Qgc3VjaCBhIHJlc291cmNlIGNvbnN0cmFpbnQgb3Igc2NhbGlu ZyBpc3N1ZSwgZWcgcGxhY2luZyBhbiBBTEcgb3INCk5BVDY0IGluIGZyb250IG9mIHRoZSBJUHY2 LW9ubHkgZGV2aWNlcyB0byBtYWtlIHRoZW0gcmVhY2hhYmxlIGJ5IGxlZ2FjeQ0KSVB2NCBjbGll bnRzIGFuZCBtYW5hZ2VtZW50IHN5c3RlbXMuDQpFdmVuIGlmIHlvdSBhc3N1bWUgdGhhdCBzbWFy dCBvYmplY3QgZGVwbG95bWVudHMgYXJlbid0IGdvaW5nIHRvIGJlDQpsYXJnZWx5IGdyZWVuZmll bGQgKHdoaWNoIGluIGEgbG90IG9mIGNhc2VzIHRoZXkgYXJlLCBiZWNhdXNlIHRoZQ0KaW5mcmFz dHJ1Y3R1cmUgZG9lc24ndCBleGlzdCB0b2RheSksIGl0J3MgYWxtb3N0IGFsd2F5cyBnb2luZyB0 byBiZSBlYXNpZXINCnRvIG1ha2UgY2hhbmdlcyB0byB0aGUgbmV0d29yayBhbmQgb3RoZXIgc3lz dGVtcyB0byBnZXQgdGhvc2UgdG8gc3VwcG9ydA0KSVB2NiB0aGFuIGl0IGlzIHRvIGFkZCB0cmFu c2l0aW9uIHRlY2hub2xvZ2llcywgc3VwcG9ydCBkdWFsLXN0YWNrLCBvcg0KcmV0cm9maXQgc21h cnQgb2JqZWN0IG5ldHdvcmtzIGZyb20gSVB2NCB0byBJUHY2IGxhdGVyLiBUaGlzIGlzIGR1ZSB0 byB0aGUNCnNjYWxlIG9mIGRlcGxveW1lbnQgYW5kIHRoZSByZXNvdXJjZSBjb25zdHJhaW50cyBv ZiB0aGUgZGV2aWNlIGNsYXNzLg0KVGhhdCdzIGFuIGFyY2hpdGVjdHVyYWwgY29uc2lkZXJhdGlv biB0aGF0IGRyaXZlcyB0b3dhcmQgYSByZWNvbW1lbmRhdGlvbg0Kb2Ygc2luZ2xlLXN0YWNrIHdo ZW5ldmVyIHBvc3NpYmxlLg0KDQoNCg0KU2V2ZXJhbCBJQUIgZm9sa3MsIGluY2x1ZGluZyB0d28g b2YgdGhlIGF1dGhvcnMgYWdyZWVkIHRoYXQgdGhpcyBpcw0Kc29tZXRoaW5nIHRoYXQgc2hvdWxk IGJlIGFkZGVkLCBidXQgaXQgaGFzIG5vdCBiZWVuIGFkZHJlc3NlZCBpbiB0aGlzDQp2ZXJzaW9u LiBJbiBmYWN0LCBzZWN0aW9uIDIuMSBwcmVzZW50cyBJUCB2ZXJzaW9uIGFzIGlmIGl0IGlzIHN0 aWxsIG9wZW4NCmZvciBkaXNjdXNzaW9uIG9uIGVhY2ggZGVzaWduLCBhbmQgdGhlIG90aGVyIG1l bnRpb24gb2Ygc2luZ2xlIHN0YWNrIHZzDQpkdWFsIHN0YWNrIGluIHNlY3Rpb24gNC4yIGFwcGVh cnMgdG8gaGF2ZSBiZWVuIHJlbW92ZWQuIEknbSBob3BpbmcgdGhhdA0KdGhpcyB3YXMgbWVyZWx5 IGFuIG92ZXJzaWdodCByYXRoZXIgdGhhbiBhIGNvbnNjaW91cyBkZWNpc2lvbi4NCg0KDQpUaGFu a3MsDQoNCldlcyBHZW9yZ2UNCg0KDQoNCk9uIDgvMjcvMTQsIDI6MTggUE0sICJJQUIgQ2hhaXIi IDxpYWItY2hhaXJAaWFiLm9yZz4gd3JvdGU6DQoNCj5UaGlzIGlzIGEgY2FsbCBmb3IgcmV2aWV3 IG9mICJBcmNoaXRlY3R1cmFsIENvbnNpZGVyYXRpb25zIGluIFNtYXJ0DQo+T2JqZWN0IE5ldHdv cmtpbmciIHByaW9yIHRvIHBvdGVudGlhbCBhcHByb3ZhbCBhcyBhbiBJQUIgc3RyZWFtIFJGQy4N Cj4NCj5UaGUgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGZvciBpbnNwZWN0aW9uIGhlcmU6DQo+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWFiLXNtYXJ0LW9iamVjdC1hcmNo aXRlY3R1cmUvDQo+DQo+VGhlIENhbGwgZm9yIFJldmlldyB3aWxsIGxhc3QgdW50aWwgMjQgU2Vw dGVtYmVyIDIwMTQuICBQbGVhc2Ugc2VuZA0KPmNvbW1lbnRzIHRvIGlhYkBpYWIub3JnLg0KPg0K Pk9uIGJlaGFsZiBvZiB0aGUgSUFCLA0KPiAgIFJ1c3MgSG91c2xleQ0KPiAgIElBQiBDaGFpcg0K Pg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2 aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0 byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWws IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50 cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5l bnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQg YW55IHByaW50b3V0Lg0K From nobody Fri Aug 29 04:08:05 2014 Return-Path: X-Original-To: smartobjectdir@ietfa.amsl.com Delivered-To: smartobjectdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014331A00E1; Fri, 29 Aug 2014 04:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX0VNwYIcbId; Fri, 29 Aug 2014 04:07:58 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A151A00BA; Fri, 29 Aug 2014 04:07:58 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id m5so1985919qaj.14 for ; Fri, 29 Aug 2014 04:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4O73DcisL7VBmQY0BsOMNxr8y/REZvRwPw0hhttEKSc=; b=NLqtdntQz58tnRcTn4WDY+s7e3VDlpe69PvNS37ZP56vhh9GkUQujLaSxEUtSwedMx NgPblq54cCbFstsDHjnxL/ILp/zTxBzoxpGbpP9nKc4fuvWWGULK2GqziSJeLKk3yaDD Y+H8EiA2Y+v6xNd1cbbJDaTIn/4jfOIzo35T5eVfxP4fqmAcwcHW38FKMWkp3TkSQiK2 /Pp7ka2COfMRcvxkh85q/OjvkXKo4wTp+C1vRidFP4kIOZu47eRik0SKodyp3fGPGujL YQBXQsLBCpfbOqPNaQmn0qIVBsFNMhDBOhFuAUQHTf35YxJg16JideKKljgW7VL8dQ/j OhBw== X-Received: by 10.224.129.1 with SMTP id m1mr16782060qas.0.1409310477525; Fri, 29 Aug 2014 04:07:57 -0700 (PDT) Received: from rtp-rdroms-89112.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id v111sm9985713qge.7.2014.08.29.04.07.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 04:07:56 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Fri, 29 Aug 2014 07:07:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <24F02C3F-0538-4DDD-9434-37A360E53131@gmail.com> References: To: IAB X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/3sy2hdNKfAsGFroHFbCxxT7IBFE Cc: IAB Chair , IETF SmartObjectDir , IETF , "George, Wes" Subject: Re: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" X-BeenThere: smartobjectdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 11:08:01 -0000 I agree 100% with the observations Wes makes and his recommendation that = text be added to the document to the effect that IPv6 is strongly = recommended for use in Smart Objects - Ralph On Aug 27, 2014, at 3:55 PM 8/27/14, George, Wes = wrote: > I made the following comment (in part) on -03. I'm making it again, > because it still applies to -04. >=20 > "It seems odd to me that this document is silent on the architectural > considerations that IPv4 exhaustion may have on Smart Object = networking. > RFC 6272 discusses support for both protocols, but partially because = it > was written in 2011, it treats them equally (no recommendation to = support > one protocol over another). I think we=92re doing smart object = implementers > a disservice by not discussing the increasing likelihood that access = to > IPv4 addresses will be challenging and costly, especially for = something at > the scale of Smart Object networking." >=20 >=20 > At the time, the feedback from Hannes was that discussing a specific > protocol was too low-level for this document, but I argued that the = lack > of IPv4 address availability, the potential order of magnitude of the > deployment of devices in applications like this, and their limitations > (power, etc) make IPv4 vs IPv6 very much an interoperability = consideration > and an architectural consideration. If your architecture doesn't take = into > account the fact that we're out of IPv4 addresses, then it's not much = of > an architecture. Adding a discussion about IPv4's limitations and a > recommendation for IPv6 isn't a discussion of a protocol for the sake = of > compare and contrast, as much as it is acknowledging the reality of = the > situation. > I don't believe that smart object networking is viable at any real = scale > without IPv6. There simply aren't enough addresses, even taking into > account RFC1918. I see this *today* in my own network with deployments > like large-scale WiFi and cell tower deployment, set-top-boxes, etc. I > think that's the right sort of scale to observe as an analog for smart > object networks -- they could potentially be orders of magnitude = bigger. > The more clearly we say that smart object networks and their = supporting > systems should assume IPv6, and possibly IPv6-only because of IPv4's > inherent scaling limitation, the better off we're going to be. >=20 > So in terms of smart objects, especially those that are severely = resource > constrained, I think the recommendations are- First support IPv6, = whether > it's full IPv6, or something like 6LoPAN. Any interworking or other = issues > that arise from that choice can be addressed on the far side where = there > isn't such a resource constraint or scaling issue, eg placing an ALG = or > NAT64 in front of the IPv6-only devices to make them reachable by = legacy > IPv4 clients and management systems. > Even if you assume that smart object deployments aren't going to be > largely greenfield (which in a lot of cases they are, because the > infrastructure doesn't exist today), it's almost always going to be = easier > to make changes to the network and other systems to get those to = support > IPv6 than it is to add transition technologies, support dual-stack, or > retrofit smart object networks from IPv4 to IPv6 later. This is due to = the > scale of deployment and the resource constraints of the device class. > That's an architectural consideration that drives toward a = recommendation > of single-stack whenever possible. >=20 >=20 >=20 > Several IAB folks, including two of the authors agreed that this is > something that should be added, but it has not been addressed in this > version. In fact, section 2.1 presents IP version as if it is still = open > for discussion on each design, and the other mention of single stack = vs > dual stack in section 4.2 appears to have been removed. I'm hoping = that > this was merely an oversight rather than a conscious decision. >=20 >=20 > Thanks, >=20 > Wes George >=20 >=20 >=20 > On 8/27/14, 2:18 PM, "IAB Chair" wrote: >=20 >> This is a call for review of "Architectural Considerations in Smart >> Object Networking" prior to potential approval as an IAB stream RFC. >>=20 >> The document is available for inspection here: >> https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/ >>=20 >> The Call for Review will last until 24 September 2014. Please send >> comments to iab@iab.org. >>=20 >> On behalf of the IAB, >> Russ Housley >> IAB Chair >>=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From nobody Fri Aug 29 04:12:54 2014 Return-Path: X-Original-To: smartobjectdir@ietfa.amsl.com Delivered-To: smartobjectdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9A1A00E1; Fri, 29 Aug 2014 04:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXUis5ts9bP3; Fri, 29 Aug 2014 04:12:47 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E971A00B7; Fri, 29 Aug 2014 04:12:47 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so2130456qcx.7 for ; Fri, 29 Aug 2014 04:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XOcnkT/2il77y3uqZOdFJjEtppnhvn4S+VocyS1O5Zg=; b=ntaDr4thFBHlb7Ief08FZZGtqBvEPE0ffj0PNljUopvUO2qLGH+Z1S/sP9gcJFWuFd 27UUPgdAVll0GTkJTymkefHjTQJxf5tGbF+1m6gBhQwHc+JiQVyN1Lw8GOiVC/gSPQUW FbQh3D52tEaOTEd4AkhXLOYxusK1vhDUICbQb5TY17k4+7gcgtGwbYFp964h2goiJ8ig Coh+Bnu07BHIKoiswPC89y4Brz5bCOM+YacnNKOskS1zMTm5sUiAshR2Rq3YoJqa1Tuv zvaGoVIZnVH53hpLFckCkQsoyDAYYQxyroQWn4Z8ifZL7MPwpu+d8OS4oP0806jnAqYV Wh8w== X-Received: by 10.229.229.135 with SMTP id ji7mr16293616qcb.15.1409310766873; Fri, 29 Aug 2014 04:12:46 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:21b0:fbe9:76b4:a1cc? ([2001:420:2481:20:21b0:fbe9:76b4:a1cc]) by mx.google.com with ESMTPSA id x6sm21275296qas.27.2014.08.29.04.12.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 04:12:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Fri, 29 Aug 2014 07:12:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49EFDAD1-D7A3-4A6D-A2E3-AF603671B1CF@gmail.com> References: To: IAB X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/IH3c69MAkDaLT9jmHVULWMfw5qQ Cc: IETF SmartObjectDir , IETF , IETF Announce Subject: Re: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" X-BeenThere: smartobjectdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 11:12:50 -0000 The security section is especially handwavey ... especially considering = security is probably more important for smart objects while there are = fewer resources available for implementing security in smart objects = than elsewhere. Here's a useful take on the security issue that might provide some = guidance for additional tet in the security section: = http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions If the IAB is not prepared to undertake recommendations on security at = this time, in my opinion security should be tagged as a topic for future = work in addition to the pointers to earlier work. - Ralph On Aug 27, 2014, at 2:18 PM 8/27/14, IAB Chair = wrote: > This is a call for review of "Architectural Considerations in Smart = Object Networking" prior to potential approval as an IAB stream RFC. >=20 > The document is available for inspection here: = https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/ >=20 > The Call for Review will last until 24 September 2014. Please send = comments to iab@iab.org. >=20 > On behalf of the IAB, > Russ Housley > IAB Chair >=20 From nobody Fri Aug 29 08:04:51 2014 Return-Path: X-Original-To: smartobjectdir@ietfa.amsl.com Delivered-To: smartobjectdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962A81A0141 for ; Thu, 28 Aug 2014 16:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM0Y4BgBJPIg for ; Thu, 28 Aug 2014 16:31:05 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132261A013B for ; Thu, 28 Aug 2014 16:31:05 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so953657ykp.20 for ; Thu, 28 Aug 2014 16:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q7dTSbWsYXxlu2UuYQeC3sXQKP7n6Gyqbi1NcnTxII8=; b=w0hgjzuVlUM/hgmN2ZBtZ9mUROdO9OPqL65GUtBmH3NJZvZAcPOA5hHdeienMhxNT6 E0umgxZ2w10mzz1a85sQdx/LjwPhXGWbJDLSI/lFPShLaZcsNoc/GqNHAz3C3wfqyJgV /kebLA/J+xjNzygCW+Lehw5Sqc+UDHRgiA3Gra9q9nVakdMtp4GS1HsJncauHhy6sz2L zVdQwUOJbeP0ZReSvzuq3T5fWniMBsgBLb4QLTFQ8cJuFnJ3HuUdQr6Omdij9VJWNMxc Y9WWwD2xX/HwgM0u4MitVD1nOs48byFGxYmjFJMNfdpL2S6dj0CsOSgHvnLXd5jjBG4L NxfQ== MIME-Version: 1.0 X-Received: by 10.236.135.212 with SMTP id u60mr9767966yhi.118.1409268664273; Thu, 28 Aug 2014 16:31:04 -0700 (PDT) Received: by 10.170.44.216 with HTTP; Thu, 28 Aug 2014 16:31:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Aug 2014 01:31:04 +0200 Message-ID: From: Abdussalam Baryun To: "George, Wes" Content-Type: multipart/alternative; boundary=20cf301af8672094cb0501b8eecc Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/zFDZOdC6i0s8bux3mOMosQhV47s X-Mailman-Approved-At: Fri, 29 Aug 2014 08:04:49 -0700 Cc: IAB Chair , IETF SmartObjectDir , IAB Subject: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" X-BeenThere: smartobjectdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:31:08 -0000 --20cf301af8672094cb0501b8eecc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with George which shows one important point missing, while IMHO there may be more missing important points. However, I just read the title and abstract and I see that this document is not specifying its objectives, just it is general information. I don't see clear points of the importance of this document while considering IParchitecture. I don't think its structure fulfilling its title's aim. ------ OLD Title ----- Architectural Considerations in Smart Object Networking. ------ NEW Title ----- Architectural Design Considerations for networking Smart Objects within the Internet of Things. ------ OLD Abstract ----- Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice. This document offers guidance to engineers designing Internet connected smart objects. ------ NEW Abstract ---- Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice. That can be done by considering architectural issues and design guidance. This document offers recommendations of designing Internet connected smart objects. Best Regards, AB On Wednesday, August 27, 2014, George, Wes wrote: > I made the following comment (in part) on -03. I'm making it again, > because it still applies to -04. > > "It seems odd to me that this document is silent on the architectural > considerations that IPv4 exhaustion may have on Smart Object networking. > RFC 6272 discusses support for both protocols, but partially because it > was written in 2011, it treats them equally (no recommendation to support > one protocol over another). I think we=E2=80=99re doing smart object impl= ementers > a disservice by not discussing the increasing likelihood that access to > IPv4 addresses will be challenging and costly, especially for something a= t > the scale of Smart Object networking." > > > At the time, the feedback from Hannes was that discussing a specific > protocol was too low-level for this document, but I argued that the lack > of IPv4 address availability, the potential order of magnitude of the > deployment of devices in applications like this, and their limitations > (power, etc) make IPv4 vs IPv6 very much an interoperability consideratio= n > and an architectural consideration. If your architecture doesn't take int= o > account the fact that we're out of IPv4 addresses, then it's not much of > an architecture. Adding a discussion about IPv4's limitations and a > recommendation for IPv6 isn't a discussion of a protocol for the sake of > compare and contrast, as much as it is acknowledging the reality of the > situation. > I don't believe that smart object networking is viable at any real scale > without IPv6. There simply aren't enough addresses, even taking into > account RFC1918. I see this *today* in my own network with deployments > like large-scale WiFi and cell tower deployment, set-top-boxes, etc. I > think that's the right sort of scale to observe as an analog for smart > object networks -- they could potentially be orders of magnitude bigger. > The more clearly we say that smart object networks and their supporting > systems should assume IPv6, and possibly IPv6-only because of IPv4's > inherent scaling limitation, the better off we're going to be. > > So in terms of smart objects, especially those that are severely resource > constrained, I think the recommendations are- First support IPv6, whether > it's full IPv6, or something like 6LoPAN. Any interworking or other issue= s > that arise from that choice can be addressed on the far side where there > isn't such a resource constraint or scaling issue, eg placing an ALG or > NAT64 in front of the IPv6-only devices to make them reachable by legacy > IPv4 clients and management systems. > Even if you assume that smart object deployments aren't going to be > largely greenfield (which in a lot of cases they are, because the > infrastructure doesn't exist today), it's almost always going to be easie= r > to make changes to the network and other systems to get those to support > IPv6 than it is to add transition technologies, support dual-stack, or > retrofit smart object networks from IPv4 to IPv6 later. This is due to th= e > scale of deployment and the resource constraints of the device class. > That's an architectural consideration that drives toward a recommendation > of single-stack whenever possible. > > > > Several IAB folks, including two of the authors agreed that this is > something that should be added, but it has not been addressed in this > version. In fact, section 2.1 presents IP version as if it is still open > for discussion on each design, and the other mention of single stack vs > dual stack in section 4.2 appears to have been removed. I'm hoping that > this was merely an oversight rather than a conscious decision. > > > Thanks, > > Wes George > > > > On 8/27/14, 2:18 PM, "IAB Chair" wrote: > > >This is a call for review of "Architectural Considerations in Smart > >Object Networking" prior to potential approval as an IAB stream RFC. > > > >The document is available for inspection here: > >https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/ > > > >The Call for Review will last until 24 September 2014. Please send > >comments to iab@iab.org. > > > >On behalf of the IAB, > > Russ Housley > > IAB Chair > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > --20cf301af8672094cb0501b8eecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with George which shows one important point missing, while IMHO=C2= =A0there may be more missing important=C2=A0points. However, I just read th= e title and abstract and I see that this document is not specifying its obj= ectives, just it is general information. I don't see clear points of=C2= =A0the importance of this document while considering IParchite= cture. I don't think its structure fulfilling its title's aim.=C2= =A0

------=C2=A0OLD Title -----
=09 =09 =09 
Architectural Considerations in Smart Object Networking.=20

------ NEW Title -----
=
=09 =09 =09 
Architectural Design Considerations for networking Smart Objects within=
 the Internet of Things.=20

------=C2=A0OLD Abstract=C2=A0-----

=09 =09 =09 
Following the theme "Everything that can be connected will be conn=
ected", engineers and researchers designing smart object networks need=
 to decide how to achieve this in practice.=C2=A0
This document offer=
s guidance to engineers designing Internet connected smart objects.
------ NEW = Abstract=C2=A0----

Following the = theme "Everything that can be connected will be connected", <= /span>engineers and researchers designing smart object networks need t= o decide how to achieve this in practice. That can be done by considering a= rchitectural issues and design guidance. 
This document offers recommendations of desi=
gning Internet co=
nnected smart objects.

Best Regards,

AB

On Wednesday, August 27, 2014, George, Wes wrote:
I made the following comment (in part) on -03. I'm making it again,
because it still applies to -04.

"It seems odd to me that this document is silent on the architectural<= br> considerations that IPv4 exhaustion may have on Smart Object networking. RFC 6272 discusses support for both protocols, but partially because it
was written in 2011, it treats them equally (no recommendation to support one protocol over another). I think we=E2=80=99re doing smart object implem= enters
a disservice by not discussing the increasing likelihood that access to
IPv4 addresses will be challenging and costly, especially for something at<= br> the scale of Smart Object networking."


At the time, the feedback from Hannes was that discussing a specific
protocol was too low-level for this document, but I argued that the lack of IPv4 address availability, the potential order of magnitude of the
deployment of devices in applications like this, and their limitations
(power, etc) make IPv4 vs IPv6 very much an interoperability consideration<= br> and an architectural consideration. If your architecture doesn't take i= nto
account the fact that we're out of IPv4 addresses, then it's not mu= ch of
an architecture. Adding a discussion about IPv4's limitations and a
recommendation for IPv6 isn't a discussion of a protocol for the sake o= f
compare and contrast, as much as it is acknowledging the reality of the
situation.
I don't believe that smart object networking is viable at any real scal= e
without IPv6. There simply aren't enough addresses, even taking into account RFC1918. I see this *today* in my own network with deployments
like large-scale WiFi and cell tower deployment, set-top-boxes, etc. I
think that's the right sort of scale to observe as an analog for smart<= br> object networks -- they could potentially be orders of magnitude bigger. The more clearly we say that smart object networks and their supporting
systems should assume IPv6, and possibly IPv6-only because of IPv4's inherent scaling limitation, the better off we're going to be.

So in terms of smart objects, especially those that are severely resource constrained, I think the recommendations are- First support IPv6, whether it's full IPv6, or something like 6LoPAN. Any interworking or other iss= ues
that arise from that choice can be addressed on the far side where there isn't such a resource constraint or scaling issue, eg placing an ALG or=
NAT64 in front of the IPv6-only devices to make them reachable by legacy IPv4 clients and management systems.
Even if you assume that smart object deployments aren't going to be
largely greenfield (which in a lot of cases they are, because the
infrastructure doesn't exist today), it's almost always going to be= easier
to make changes to the network and other systems to get those to support IPv6 than it is to add transition technologies, support dual-stack, or
retrofit smart object networks from IPv4 to IPv6 later. This is due to the<= br> scale of deployment and the resource constraints of the device class.
That's an architectural consideration that drives toward a recommendati= on
of single-stack whenever possible.



Several IAB folks, including two of the authors agreed that this is
something that should be added, but it has not been addressed in this
version. In fact, section 2.1 presents IP version as if it is still open for discussion on each design, and the other mention of single stack vs
dual stack in section 4.2 appears to have been removed. I'm hoping that=
this was merely an oversight rather than a conscious decision.


Thanks,

Wes George



On 8/27/14, 2:18 PM, "IAB Chair" <iab-chair@iab.org>= wrote:

>This is a call for review of "Architectural Considerations in Smar= t
>Object Networking" prior to potential approval as an IAB stream RF= C.
>
>The document is available for inspection here:
>https://datatracker.ietf.org/doc/draft-iab-sma= rt-object-architecture/
>
>The Call for Review will last until 24 September 2014.=C2=A0 Please sen= d
>comments to iab@iab.org.
>
>On behalf of the IAB,
>=C2=A0 =C2=A0Russ Housley
>=C2=A0 =C2=A0IAB Chair
>


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
--20cf301af8672094cb0501b8eecc-- From nobody Fri Aug 29 08:05:00 2014 Return-Path: X-Original-To: smartobjectdir@ietfa.amsl.com Delivered-To: smartobjectdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1563B1A0110; Fri, 29 Aug 2014 04:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waxlKXTu1L6W; Fri, 29 Aug 2014 04:33:00 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id A8F871A0011; Fri, 29 Aug 2014 04:32:59 -0700 (PDT) Received: from dummy.name; Fri, 29 Aug 2014 11:32:59 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_2D5DB18E-9977-4EBE-A027-AE4097538322" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Steve Crocker In-Reply-To: <49EFDAD1-D7A3-4A6D-A2E3-AF603671B1CF@gmail.com> Date: Fri, 29 Aug 2014 07:27:55 -0400 Message-Id: <081C75F2-2034-47D8-A5AE-5B86F0F795B1@shinkuro.com> References: <49EFDAD1-D7A3-4A6D-A2E3-AF603671B1CF@gmail.com> To: Ralph Droms , IAB , IETF SmartObjectDir X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smartobjectdir/DVV86DQoIWPS7BV0p7U6IWKEfwE X-Mailman-Approved-At: Fri, 29 Aug 2014 08:04:49 -0700 Cc: "Stephen D. Crocker" , IETF , IETF Announce Subject: Re: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking" X-BeenThere: smartobjectdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 11:33:01 -0000 --Apple-Mail=_2D5DB18E-9977-4EBE-A027-AE4097538322 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Another =93security=94 dimension that=92s increasingly relevant is = whether the design, configuration or operation might lead to unintended = storms. For a recent example of such a problem, see: = http://www.washingtonpost.com/blogs/capital-weather-gang/wp/2014/08/26/nat= ional-weather-service-website-taken-down-by-overzealous-android-app/ In February this year, the US National Science Foundation sponsored a = workshop on Interdisciplinary Pathways towards a More Secure Internet. = The report included several recommendation, two of which seem relevant = here. Create a Framework for Managing Software Updates The Internet of Things will challenge our current channels for = distributing security updates. An environment must be developed for = distributing security patches that scales to a world where almost = everything is connected to the Internet and many =93things=94 are = largely unattended. Enhance the Security of the Internet of Things by Identifying Enclaves The security challenges posed by the emerging Internet of Things should = be addressed now, to prepare before it is fully upon us. By identifying = specific use segments, or =93enclaves,=94 Internet of Things = infrastructure stakeholders can address the security requirements and = devise event remediations for that enclave. Steve On Aug 29, 2014, at 7:12 AM, Ralph Droms wrote: > The security section is especially handwavey ... especially = considering security is probably more important for smart objects while = there are fewer resources available for implementing security in smart = objects than elsewhere. >=20 > Here's a useful take on the security issue that might provide some = guidance for additional tet in the security section: = http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions >=20 > If the IAB is not prepared to undertake recommendations on security at = this time, in my opinion security should be tagged as a topic for future = work in addition to the pointers to earlier work. >=20 > - Ralph >=20 > On Aug 27, 2014, at 2:18 PM 8/27/14, IAB Chair = wrote: >=20 >> This is a call for review of "Architectural Considerations in Smart = Object Networking" prior to potential approval as an IAB stream RFC. >>=20 >> The document is available for inspection here: = https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/ >>=20 >> The Call for Review will last until 24 September 2014. Please send = comments to iab@iab.org. >>=20 >> On behalf of the IAB, >> Russ Housley >> IAB Chair >>=20 >=20 --Apple-Mail=_2D5DB18E-9977-4EBE-A027-AE4097538322 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Another =93security=94 dimension = that=92s increasingly relevant is whether the design, configuration or = operation might lead to unintended storms.  For a recent = example of such a problem, see:

http://w= ww.washingtonpost.com/blogs/capital-weather-gang/wp/2014/08/26/national-we= ather-service-website-taken-down-by-overzealous-android-app/

In= February this year, the US National Science Foundation sponsored a = workshop on Interdisciplinary Pathways towards = a More Secure Internet.  The report included several = recommendation, two of which seem relevant here.

  • Create a = Framework for Managing Software Updates

    The = Internet of Things will challenge our current channels for = distributing security updates. An environment must be = developed for distributing security patches that scales to a world = where almost everything is connected to the Internet and many = =93things=94 are largely unattended.


  • Enhance the = Security of the Internet of Things by = Identifying Enclaves

    The security challenges posed by the = emerging Internet of Things should be addressed now, to prepare = before it is fully upon us. By identifying specific use = segments, or =93enclaves,=94 Internet of Things = infrastructure stakeholders can address the security = requirements and devise event remediations for = that enclave.
Steve



On = Aug 29, 2014, at 7:12 AM, Ralph Droms <rdroms.ietf@gmail.com> = wrote:

The security section is = especially handwavey ... especially considering security is probably = more important for smart objects while there are fewer resources = available for implementing security in smart objects than = elsewhere.

Here's a useful take on the security issue that might = provide some guidance for additional tet in the security = section: http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions
If the IAB is not prepared to undertake recommendations on security at = this time, in my opinion security should be tagged as a topic for = future work in addition to the pointers to earlier work.

- = Ralph

On Aug 27, 2014, at 2:18 PM 8/27/14, IAB Chair = <iab-chair@iab.org> wrote:

This = is a call for review of "Architectural Considerations in Smart Object = Networking" prior to potential approval as an IAB stream RFC.

The = document is available for inspection here: = https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/
<= br>The Call for Review will last until 24 September 2014.  Please = send comments to iab@iab.org.

On behalf of the IAB,
 Russ = Housley
 IAB = Chair



= --Apple-Mail=_2D5DB18E-9977-4EBE-A027-AE4097538322--