From fred@cisco.com Thu Apr 7 00:38:32 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DC83A68C2; Thu, 7 Apr 2011 00:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVSTzmUMtdTt; Thu, 7 Apr 2011 00:38:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7229E3A687A; Thu, 7 Apr 2011 00:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=322; q=dns/txt; s=iport; t=1302162016; x=1303371616; h=date:from:message-id:to:subject; bh=IFAO+TpgrwcpjnYifdsZ588Lfpse/WxHjdbNAJJjp0Q=; b=eU9+Q1ad1RU/KWlaLIZ+o7HrQ5NENvLYUOMOQxCKAvnb+NUlOAQr3yje 0LQroCR6IlBvBF9xcJ+pdZzHaxNW2+7i1dfoWFaGaSpqS+XufFTIl1cKL iOdJsKjFyTAmXM6rNyn6m3t+YpMYG/6reh3cV7Qg3D/xtYGeJBYSdQP2p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADtpnU2rRDoG/2dsb2JhbACYcwGNDXemAZxthW0EhVA X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="291077979" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 07:40:15 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p377eFfS024090; Thu, 7 Apr 2011 07:40:15 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id p377eFRC029958; Thu, 7 Apr 2011 00:40:15 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id p377eFDr029926; Thu, 7 Apr 2011 00:40:15 -0700 (PDT) Date: Thu, 7 Apr 2011 00:40:15 -0700 (PDT) From: Fred Baker Message-Id: <201104070740.p377eFDr029926@irp-view13.cisco.com> To: smartpower-interest@ietf.org, smartpowerdir@ietf.org Subject: [smartpowerdir] NIST/SGIP Discussion X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:38:32 -0000 Interesting ppt ftp://ftpeng.cisco.com/fred/SmartPower/NIST-SGIP_JWG.pptx This is a joint presentation from NIST/SGIP to ETSI proposing and negotiating a joint working group between the US and Europe. Nothing confidential that I see, but a pretty clear discussion of the issues NIST/SGIP think are on the table. From alexandru.petrescu@gmail.com Sun Apr 3 07:54:24 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D2E3A6813; Sun, 3 Apr 2011 07:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIwnifwBbIo3; Sun, 3 Apr 2011 07:54:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 101713A682B; Sun, 3 Apr 2011 07:54:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A456994030E; Sun, 3 Apr 2011 16:55:54 +0200 (CEST) Message-ID: <4D988A77.5040809@gmail.com> Date: Sun, 03 Apr 2011 16:55:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Fred Baker References: <7B550DC8-16A1-4DBD-BEDF-2C7B99703C9C@tzi.org> <558D2682-5137-4FB7-8D83-CA84495F3100@cisco.com> In-Reply-To: <558D2682-5137-4FB7-8D83-CA84495F3100@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110403-0, 03/04/2011), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Thu, 07 Apr 2011 00:53:45 -0700 Cc: core-chairs@tools.ietf.org, eman-chairs@tools.ietf.org, iot-workshop-prep@lists.i1b.org, IAB IAB , 6lowpan-chairs@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org, Carsten Bormann , smartpower-interest@ietf.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] IoT term (was: Report on the Smart Grid work in the IETF) X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 14:54:24 -0000 Le 30/03/2011 07:48, Fred Baker a écrit : > Thanks. > > Yes, I think of "IoT" as a marketing term, which is to say something > someone came up with to find out how people would define it. I agree, IoT has a marketing aura to it. IoT term is new, albeit its significance, taken literally, is not new - Internet is made of Routers Hosts since long. IoT is a strong keyword in EU administration when defining projects related to Internet. IoT has some roots in some manufacturers' vision of tracking goods on the Internet with an RFID and Electronic Product Code. IoT and IPv6 is an interesting mix. One may need the other. But only one is defined. IoT lives in the same space as M2M, and smart objects. Alex > > :-) > > On Mar 30, 2011, at 7:35 AM, Carsten Bormann wrote: > >> On Mar 30, 2011, at 07:20, Fred Baker wrote: >> >>> >>> http://www.ietf.org/rfc/rfc5548.txt 5548 Routing Requirements for >>> Urban Low-Power and Lossy Networks. M. Dohler, Ed., T. Watteyne, >>> Ed., T. Winter, Ed., D. Barthel, Ed.. May 2009. (Format: >>> TXT=47759 bytes) (Status: INFORMATIONAL) >>> >>> The first was generated by 6lowpan, >> >> Actually, that is a ROLL document. (The entire set of ROLL >> requirements RFCs is a great body of reference, by the way.) >> >> Note also that the full title of last week's IAB workshop is >> "Interconnecting Smart Objects with the Internet" (this is >> noteworthy as there is some debate around the term "Internet of >> Things"). >> >> JFYI. >> >> Gruesse, Carsten >> > > _______________________________________________ smartpower-interest > mailing list smartpower-interest@ietf.org > https://www.ietf.org/mailman/listinfo/smartpower-interest > From fredbakersba@gmail.com Tue Mar 29 05:41:55 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82D23A67DB; Tue, 29 Mar 2011 05:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVx0LNAYZnZT; Tue, 29 Mar 2011 05:41:54 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B6BF23A63CA; Tue, 29 Mar 2011 05:41:53 -0700 (PDT) Received: by wyb29 with SMTP id 29so118948wyb.31 for ; Tue, 29 Mar 2011 05:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=6Sq8xKT/z2FA1FRAh5r2LePxz/HA9GDKfUsrbfYGTqo=; b=T2vQMZ7gVFp7CKFLnSjZr4u3aRT7w8Wv5Oz1H9NDDWZ1x8vd7pElgFffFZoCYn0IOq BNaYMLyPTxRqxLnE4w1DvZr131FGXeKcHFs+14kH0sVccY7IUntZj/fwRtmEpbNW0pVq APyy05FtMADPtLcKSfk5Z7sTpmLnpKvgyNSqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=KWVbvd3aua7wUMcW38kd5rPIL8/IjdckYGLvKOuGjeQdJW51BslCpnMKnywpte1y9C nyTuaIidNSwM99oz2rfPA6cdb13km0QORn9OUTtvf5Mmk1R78ALzzdNi6KEkL78mQct8 hltAuynl3DwuqxNRK/+nv0rLhPVaoXI9TfAxc= Received: by 10.216.141.206 with SMTP id g56mr4990510wej.5.1301402611004; Tue, 29 Mar 2011 05:43:31 -0700 (PDT) Received: from [127.0.0.1] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id r80sm1912624wei.15.2011.03.29.05.43.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 05:43:29 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 14:43:19 +0200 Message-Id: To: SGIPGB-MEMBERS@SMARTGRIDLISTSERV.ORG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 07 Apr 2011 00:54:31 -0700 Cc: chair@ietf.org, chair@iab.org, IETF SmartPower Directorate Subject: [smartpowerdir] A view on Zigbee Security Energy Profile 1.x X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:41:55 -0000 I want to be very careful in identifying myself in sending this; I have = not vetted this statement with anyone, so I can't say "this is the = IETF's viewpoint". That said, I speak from an IETF perspective, and = would be very surprised if anyone in the IETF significantly disagreed. I = am the chairman of the IETF's Smart Power Directorate, and the IETF's = liaison to the SGIP. = http://en.wikipedia.org/wiki/Fred_Baker_(IETF_chair) The IETF has spent the past 25 years building protocols that numerous = operators have used to build a global network that interoperates very = effectively. The result has been a significant benefit to business and = to national GDP, and has spawned numerous businesses that can add = interesting capabilities to a world-wide market. The principles on which = the Internet Architecture and its protocols are based include openness = of specification, interoperable implementation among multiple vendors, = support of competitive business, and an absence of market capture. To give an idea of how we implement that, let me mention the development = of OSPF, a routing protocol commonly used in the Internet. We had = leadership from a small group of developers, but a relatively large = community that interacted with them to ensure that it met their needs. = It considered the needs of government networks, service provider = networks, and networks on the Internet edge. The documentation that was = presented before it was approved included a publicly readable protocol = specification (RFC 1247, which has since been updated), an analysis of = its capabilities (RFC 1245), a publicly documented interoperability test = that included 23 independent implementations of the complete protocol = (RFC 1246), and the capabilities required to manage the protocol (RFC = 1253). It is an example of what we consider a well documented open = specification. In addition, while we specified mutual cryptographic authentication = between neighboring routers, we didn't specify the company from which = certificates had to be obtained, or the type of cryptography involved. = There were two reasons: we wanted to avoid market capture by a single = organization, with the abuses attendant in such a thing, and we wanted = to provide for technological change, which is one of the few constants = in the Internet. Security is specified in terms of what is done, not in = terms of whose technology is used. Should an issue arise, such as has = happened in Stuxnet, it is possible to update operationally without = changing the specifics of the protocol. In reviewing any protocol or protocol suite, the IETF would similarly = look at how it is specified, its scalability (for which reason we = strongly recommend the use of IP generally, and more specifically IPv6), = the publicly available documentation of its testing, security issues, = and the business impacts. The IETF would generally recommend that the = protocol suite used in the Smart Grid similarly promote an openly = specified, widely and interoperable implemented, secure, and scalable = network that is designed for business and technological growth and = adaptation in time. =46rom what is publicly known about SEP 1.x, I don't believe that it = meets these concerns. Fred Baker http://www.ietf.org/rfc/rfc1245.txt 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT=3D26160, PS=3D33546, PDF=3D31723 bytes) (Also RFC1247, RFC1246) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc1246.txt 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: TXT=3D70441, PS=3D141924, PDF=3D84633 bytes) (Also RFC1247, = RFC1245) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc1247.txt 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT=3D433332, PS=3D989724, PDF=3D490300 bytes) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status: = DRAFT STANDARD) http://www.ietf.org/rfc/rfc1253.txt 1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT=3D74453 bytes) (Obsoletes RFC1252) = (Obsoleted by RFC1850) (Also RFC1247, RFC1245, RFC1246) (Status: PROPOSED STANDARD) From cabo@tzi.org Tue Mar 29 22:34:31 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B36C3A6AA0; Tue, 29 Mar 2011 22:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIPeSyet2NIG; Tue, 29 Mar 2011 22:34:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 786E53A6A35; Tue, 29 Mar 2011 22:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2U5Zl53022599; Wed, 30 Mar 2011 07:35:47 +0200 (CEST) Received: from [10.31.1.93] (unknown [212.4.138.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1A0233B7; Wed, 30 Mar 2011 07:35:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 30 Mar 2011 07:35:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B550DC8-16A1-4DBD-BEDF-2C7B99703C9C@tzi.org> References: To: Fred Baker X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 07 Apr 2011 00:54:31 -0700 Cc: core-chairs@tools.ietf.org, eman-chairs@tools.ietf.org, iot-workshop-prep@lists.i1b.org, IAB IAB , 6lowpan-chairs@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org, smartpower-interest@ietf.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] [Iot-workshop-prep] Report on the Smart Grid work in the IETF X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 05:34:31 -0000 On Mar 30, 2011, at 07:20, Fred Baker wrote: >=20 > http://www.ietf.org/rfc/rfc5548.txt > 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. > Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. = May > 2009. (Format: TXT=3D47759 bytes) (Status: INFORMATIONAL) >=20 > The first was generated by 6lowpan, Actually, that is a ROLL document. (The entire set of ROLL requirements = RFCs is a great body of reference, by the way.) Note also that the full title of last week's IAB workshop is = "Interconnecting Smart Objects with the Internet" (this is noteworthy as = there is some debate around the term "Internet of Things"). JFYI. Gruesse, Carsten From fred@cisco.com Tue Mar 29 22:47:15 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151F23A6AA0; Tue, 29 Mar 2011 22:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inLruXYMvwQ4; Tue, 29 Mar 2011 22:47:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7220B3A6A87; Tue, 29 Mar 2011 22:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=962; q=dns/txt; s=iport; t=1301464113; x=1302673713; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=nKFAD3hsU4IcWra9fz5KBzbLt4+E4KebIMEYbAwlfj4=; b=AefpkGrs/FZ6hLAj1AcKHcD+G+r4Ml2bihTPhBE3L8H4FMneA0eDuXz8 BrCkFVmrnBXv0hKp8ci36iKzPdrxEj8QVsO1h1SHtTELlS2F4gdHOSNAK PWOeBwWAfAImG00BsTmh2h8fCvjmP/9hJdcEzNe8BLthDUJCCRg0VfQhF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAHvDkk2Q/khLgWdsb2JhbAClUhQBARYmJYh5ljycVIVqBI0Fg1U X-IronPort-AV: E=Sophos;i="4.63,266,1299456000"; d="scan'208";a="23728607" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2011 05:48:28 +0000 Received: from dhcp-4213.meeting.ietf.org (dhcp-10-55-83-145.cisco.com [10.55.83.145]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2U5mMPB001067; Wed, 30 Mar 2011 05:48:27 GMT Received: from [127.0.0.1] by dhcp-4213.meeting.ietf.org (PGP Universal service); Wed, 30 Mar 2011 07:48:27 +0200 X-PGP-Universal: processed; by dhcp-4213.meeting.ietf.org on Wed, 30 Mar 2011 07:48:28 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <7B550DC8-16A1-4DBD-BEDF-2C7B99703C9C@tzi.org> Date: Wed, 30 Mar 2011 07:48:12 +0200 Message-Id: <558D2682-5137-4FB7-8D83-CA84495F3100@cisco.com> References: <7B550DC8-16A1-4DBD-BEDF-2C7B99703C9C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Apr 2011 00:54:31 -0700 Cc: core-chairs@tools.ietf.org, eman-chairs@tools.ietf.org, iot-workshop-prep@lists.i1b.org, IAB IAB , 6lowpan-chairs@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org, smartpower-interest@ietf.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] [Iot-workshop-prep] Report on the Smart Grid work in the IETF X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 05:47:15 -0000 Thanks. Yes, I think of "IoT" as a marketing term, which is to say something = someone came up with to find out how people would define it. :-) On Mar 30, 2011, at 7:35 AM, Carsten Bormann wrote: > On Mar 30, 2011, at 07:20, Fred Baker wrote: >=20 >>=20 >> http://www.ietf.org/rfc/rfc5548.txt >> 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. >> Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. = May >> 2009. (Format: TXT=3D47759 bytes) (Status: INFORMATIONAL) >>=20 >> The first was generated by 6lowpan, >=20 > Actually, that is a ROLL document. (The entire set of ROLL = requirements RFCs is a great body of reference, by the way.) >=20 > Note also that the full title of last week's IAB workshop is = "Interconnecting Smart Objects with the Internet" (this is noteworthy as = there is some debate around the term "Internet of Things"). >=20 > JFYI. >=20 > Gruesse, Carsten >=20 From mehmet.ersue@nsn.com Wed Mar 30 02:07:23 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B233A6B29; Wed, 30 Mar 2011 02:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkSJbMgJpLsB; Wed, 30 Mar 2011 02:07:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 968C23A6B34; Wed, 30 Mar 2011 02:07:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2U98tER024466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 11:08:55 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2U98hJF021711; Wed, 30 Mar 2011 11:08:52 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 11:08:49 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 11:08:48 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401DDB0DE@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [smartpower-interest] Report on the Smart Grid work in the IETF Thread-Index: Acvumk1IE50bP2qsSGW/Avv6tkVP5AAHurHA References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Fred Baker" , "IAB IAB" X-OriginalArrivalTime: 30 Mar 2011 09:08:49.0451 (UTC) FILETIME=[150A37B0:01CBEEBA] X-Mailman-Approved-At: Thu, 07 Apr 2011 00:54:31 -0700 Cc: core-chairs@tools.ietf.org, eman-chairs@tools.ietf.org, iot-workshop-prep@lists.i1b.org, 6lowpan-chairs@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org, smartpower-interest@ietf.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] [smartpower-interest] Report on the Smart Grid work in the IETF X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 09:07:23 -0000 May be we should add 'draft-ietf-opsawg-management-stds' to the list,=20 which has been mainly triggered by NIST SGIP and aims to complement=20 draft-baker-ietf-core. The draft is going to be discussed in SGIP IP Suite (IPSWG) and=20 Cyber Security (CSWG) Working Groups. Cheers,=20 Mehmet =20 > -----Original Message----- > From: smartpower-interest-bounces@ietf.org [mailto:smartpower-interest- > bounces@ietf.org] On Behalf Of ext Fred Baker > Sent: Wednesday, March 30, 2011 7:21 AM > To: IAB IAB > Cc: core-chairs@tools.ietf.org; eman-chairs@tools.ietf.org; iot- > workshop-prep@lists.i1b.org; 6lowpan-chairs@tools.ietf.org; The IESG; > roll-chairs@tools.ietf.org; smartpower-interest@ietf.org; IETF > SmartPower Directorate > Subject: [smartpower-interest] Report on the Smart Grid work in the > IETF >=20 > Ross asked me to put together a report on Smart Grid-related work in > the IETF. >=20 > In short, we have two RFCs and 18 Internet Drafts at this moment that > explicitly mention the Smart Grid. The two RFCs are: >=20 > http://www.ietf.org/rfc/rfc5548.txt > 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. > Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. > May > 2009. (Format: TXT=3D47759 bytes) (Status: INFORMATIONAL) >=20 > http://www.ietf.org/rfc/rfc6142.txt > 6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP. A. Moise, > J. Brodkin. March 2011. (Format: TXT=3D58320 bytes) (Status: > INFORMATIONAL) >=20 > The first was generated by 6lowpan, I believe, and tells us something > about what ROLL should produce; the second was an individual submission > by one of the co-authors of ANSI C12.22, which is a specification for > the protocols by which one reads an electrical meter. >=20 > The internet drafts include: >=20 > - draft-arkko-ipv6-transition-guidelines, which mentions the grid in > passing, and is on the RFC Editor's queue. > - draft-baker-ietf-core, which was requested by NIST/SGIP, and is in > discussion with the IESG and waiting for text regarding PKIX, Kerberos, > and SSH per a "discuss" from Tim Polk > - draft-campagna-suitee, which describes a cryptographic suite of > algorithms intended for constrained embedded systems. > - several drafts in EMAN, which is looking at measuring energy usage > in Internet equipment. > - draft-ietf-roll-terminology, which is a terminology draft in ROLL. > - draft-lee-iot-problem-statement, which identifies the Smart Grid as > containing a class of embedded systems. > - draft-mrw-nat66, which mentions it in passing. > - draft-oflynn-core-bootstrapping and draft-sarikaya-core- > sbootstrappingfs, which reference NIST 7628, which is a security > analysis of the US power grid and by extension a requirements document > for security solutions in the Smart Grid. > - draft-oreirdan-mody-bot-remediation, which mentions "smart home" and > "smart grid" devices in passing. >=20 > More generally, work in the IETF is primarily concentrated in 6LowPAN, > ROLL, CORE, and EMAN, with the odd supporting effort such as a 6man > discussion related to the RPL protocol. As you know, 6lowpan has > developed a compression algorithm and compressed IPv6 header for IEEE > 802.15.4 networks, which is being looked at by the IEEE for possible > use in power-line communications. Roll has developed a routing protocol > called RPL for 802.15.4 networks, for which the usual analysis, > interoperability testing reports, and management base remain > unavailable, which raises questions about the protocol. Core is working > on a transport for RESTful HTTP, which is proposed as one way for > embedded systems to communicate (although I will note that published > specifications for intersystem communications, such as ANSI C12 and IEC > 14908, use much simpler data formats designed for system-to-system > communication rather than system-to-human display of data content, and > TCP has been shown to be viable i > n an 802.15.4 environment in the Zigbee work). Eman is working on MIBs > and related technology for measurement of energy use in various places. >=20 > Note that, while sensor networks and embedded systems in general are > probably a more appropriate report, I haven't done the analysis to > identify that body of work. I would expect it is a superset of the > above. >=20 > The IAB held a workshop in Prague last week on the "Internet of > Things", which is probably better described as being about the > evolution of Internet Technology in a machine-to-machine embedded > system context. The web pages for that are at > http://www.iab.org/about/workshops/smartobjects/ >=20 > The workshop did in fact occur, and the organizers will eventually > generate a report. It was essentially a research discussion and a set > of tutorials on specific technologies that are relevant. > _______________________________________________ > smartpower-interest mailing list > smartpower-interest@ietf.org > https://www.ietf.org/mailman/listinfo/smartpower-interest From vint@google.com Thu Apr 7 02:55:15 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116A128C0F8 for ; Thu, 7 Apr 2011 02:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFydSoPonUwa for ; Thu, 7 Apr 2011 02:55:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 68B7B3A69C0 for ; Thu, 7 Apr 2011 02:55:13 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p379uvv5015223 for ; Thu, 7 Apr 2011 02:56:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302170217; bh=k9TdA6lX8zqowj756JzwdCKy5PQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ydLaLx53WNFjyWQnCS11DrtRVtLX3HusLPLltcj1JRZ8hheXf18qw4ZpFYbq7eood hAiNPa3l+yy1UvMsPBm2g== Received: from qwc23 (qwc23.prod.google.com [10.241.193.151]) by hpaq5.eem.corp.google.com with ESMTP id p379uJ72021688 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Apr 2011 02:56:56 -0700 Received: by qwc23 with SMTP id 23so1319672qwc.3 for ; Thu, 07 Apr 2011 02:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y9B+0eb4POzDCMptWDhE1+Shj5eK80LVFzm9Kt/8bU8=; b=EgaE1Vw8jY1M+f/hDIu1woIq2IS3kbOF9ejiJbDpZaTtTr2vU49iViUfrXvkTNBpQE PhXVqjHSUZqbfIfKTI2g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hq609MhMVlC1zuXd2KMKYSIkoGeC5ffbjm9pEDiLLPmPVI0PbbkoHTuXuJ8LLs9HEK LXnsfUEiOci8uzjojf2g== MIME-Version: 1.0 Received: by 10.229.101.36 with SMTP id a36mr447874qco.74.1302170215519; Thu, 07 Apr 2011 02:56:55 -0700 (PDT) Received: by 10.229.253.7 with HTTP; Thu, 7 Apr 2011 02:56:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2011 05:56:55 -0400 Message-ID: From: Vint Cerf To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: chair@ietf.org, SGIPGB-MEMBERS@smartgridlistserv.org, chair@iab.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] A view on Zigbee Security Energy Profile 1.x X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 09:55:15 -0000 Fred, I think this is a fair statement. However, if this is intended as an argument against public documentation of SEP 1.x, I would like to observe that the IETF or at least the Internet Architecture Board, has sanctioned publication of other than IETF standards simply for purposes of having that documentation readily available for vendors, users and operators faced with interacting with equipment that is not standard. IETF is careful to mark such documents as NOT IETF approved standards. SEP 1.x might fall into that category. If I were a vendor faced with making things interwork with other products in the Smart Grid area, I would want, not only to be compatible with the SGIP sanctioned standards but would be interested in the possibility of making equipment that could gateway to the non-standard equipment as a bridge towards normalization. I support your conclusions that SEP 1.x does not appear to meet the conventional requirements of IETF-sanctioned standards and ought not to be treated as SGIP-sanctioned either. But, properly "fenced off", might be documented, for reference purposes only, in, e.g., the catalog of "standards". Does this make any sense to you? vint On Tue, Mar 29, 2011 at 8:43 AM, Fred Baker wrote: > I want to be very careful in identifying myself in sending this; I have n= ot vetted this statement with anyone, so I can't say "this is the IETF's vi= ewpoint". That said, I speak from an IETF perspective, and would be very su= rprised if anyone in the IETF significantly disagreed. I am the chairman of= the IETF's Smart Power Directorate, and the IETF's liaison to the SGIP. ht= tp://en.wikipedia.org/wiki/Fred_Baker_(IETF_chair) > > The IETF has spent the past 25 years building protocols that numerous ope= rators have used to build a global network that interoperates very effectiv= ely. The result has been a significant benefit to business and to national = GDP, and has spawned numerous businesses that can add interesting capabilit= ies to a world-wide market. The principles on which the Internet Architectu= re and its protocols are based include openness of specification, interoper= able implementation among multiple vendors, support of competitive business= , and an absence of market capture. > > To give an idea of how we implement that, let me mention the development = of OSPF, a routing protocol commonly used in the Internet. We had leadershi= p from a small group of developers, but a relatively large community that i= nteracted with them to ensure that it met their needs. It considered the ne= eds of government networks, service provider networks, and networks on the = Internet edge. The documentation that was presented before it was approved = included a publicly readable protocol specification (RFC 1247, which has si= nce been updated), an analysis of its capabilities (RFC 1245), a publicly d= ocumented interoperability test that included 23 independent implementation= s of the complete protocol (RFC 1246), and the capabilities required to man= age the protocol (RFC 1253). It is an example of what we consider a well do= cumented open specification. > > In addition, while we specified mutual cryptographic authentication betwe= en neighboring routers, we didn't specify the company from which certificat= es had to be obtained, or the type of cryptography involved. There were two= reasons: we wanted to avoid market capture by a single organization, with = the abuses attendant in such a thing, and we wanted to provide for technolo= gical change, which is one of the few constants in the Internet. Security i= s specified in terms of what is done, not in terms of whose technology is u= sed. Should an issue arise, such as has happened in Stuxnet, it is possible= to update operationally without changing the specifics of the protocol. > > In reviewing any protocol or protocol suite, the IETF would similarly loo= k at how it is specified, its scalability (for which reason we strongly rec= ommend the use of IP generally, and more specifically IPv6), the publicly a= vailable documentation of its testing, security issues, and the business im= pacts. The IETF would generally recommend that the protocol suite used in t= he Smart Grid similarly promote an openly specified, widely and interoperab= le implemented, secure, and scalable network that is designed for business = and technological growth and adaptation in time. > > From what is publicly known about SEP 1.x, I don't believe that it meets = these concerns. > > Fred Baker > > http://www.ietf.org/rfc/rfc1245.txt > 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT=3D26160, > =A0 =A0 PS=3D33546, PDF=3D31723 bytes) (Also RFC1247, RFC1246) (Status: > =A0 =A0 INFORMATIONAL) > > http://www.ietf.org/rfc/rfc1246.txt > 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: > =A0 =A0 TXT=3D70441, PS=3D141924, PDF=3D84633 bytes) (Also RFC1247, RFC12= 45) > =A0 =A0 (Status: INFORMATIONAL) > > http://www.ietf.org/rfc/rfc1247.txt > 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT=3D433332, > =A0 =A0 PS=3D989724, PDF=3D490300 bytes) (Obsoletes RFC1131) (Obsoleted b= y > =A0 =A0 RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status: DR= AFT > =A0 =A0 STANDARD) > > http://www.ietf.org/rfc/rfc1253.txt > 1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. > =A0 =A0 August 1991. (Format: TXT=3D74453 bytes) (Obsoletes RFC1252) (Obs= oleted > =A0 =A0 by RFC1850) (Also RFC1247, RFC1245, RFC1246) (Status: PROPOSED > =A0 =A0 STANDARD) > > From fred@cisco.com Thu Apr 7 11:54:05 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258943A6A1D; Thu, 7 Apr 2011 11:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOou2AxUGbFA; Thu, 7 Apr 2011 11:54:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 48C533A6A14; Thu, 7 Apr 2011 11:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1122; q=dns/txt; s=iport; t=1302202548; x=1303412148; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ZCrMV8ApjocywW1H/8o8wi7pt/hIVn4aiwwVCOR3HdA=; b=KN70pMXI61gIfEQAjCCI/ga7fLVGIiTXie1t5qTiMw8vpJWpQv8ybKwE Xkdt2tGCyQ/Pi1bppcfoQmazp5DKbV9BH4Fw1JAc+yAw74S+7WmUWfvpI XZWHQWvOJIKql1tAQ0jRdwC3Mt/a+PFKMbOrtoV+DgESQjrpaDxVYAcep s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsAAGUInk2Q/khLgWdsb2JhbACYNo1SFAEBFiYliHmcRpxahW0EjUWDaA X-IronPort-AV: E=Sophos;i="4.63,317,1299456000"; d="scan'208";a="82668011" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2011 18:55:47 +0000 Received: from ip212-238-54-97.hotspotsvankpn.com (ams3-vpn-dhcp6414.cisco.com [10.61.89.13]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37ItgWf019871; Thu, 7 Apr 2011 18:55:47 GMT Received: from [127.0.0.1] by ip212-238-54-97.hotspotsvankpn.com (PGP Universal service); Thu, 07 Apr 2011 20:55:47 +0200 X-PGP-Universal: processed; by ip212-238-54-97.hotspotsvankpn.com on Thu, 07 Apr 2011 20:55:47 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <00bc01cbf52f$fb8d7190$f2a854b0$@yegin@yegin.org> Date: Thu, 7 Apr 2011 20:55:32 +0200 Message-Id: <15F9FE0C-54F4-443E-83CF-C9CDA9CC2D9B@cisco.com> References: <201104070740.p377eFDr029926@irp-view13.cisco.com> <00bc01cbf52f$fb8d7190$f2a854b0$@yegin@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: smartpower-interest@ietf.org, smartpowerdir@ietf.org Subject: Re: [smartpowerdir] [smartpower-interest] NIST/SGIP Discussion X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:54:05 -0000 It was a presentation *to* ETSI. On Apr 7, 2011, at 4:27 PM, Alper Yegin wrote: > Hi Fred, > > I didn't see ETSI mentioned in this PPT. > Is there a document that refers to the type of joint work being considered? > > Thank you. > > Alper > > > > > >> -----Original Message----- >> From: smartpower-interest-bounces@ietf.org [mailto:smartpower-interest- >> bounces@ietf.org] On Behalf Of Fred Baker >> Sent: Thursday, April 07, 2011 10:40 AM >> To: smartpower-interest@ietf.org; smartpowerdir@ietf.org >> Subject: [smartpower-interest] NIST/SGIP Discussion >> >> Interesting ppt >> ftp://ftpeng.cisco.com/fred/SmartPower/NIST-SGIP_JWG.pptx >> This is a joint presentation from NIST/SGIP to ETSI proposing and >> negotiating a joint working group between the US and Europe. Nothing >> confidential that I see, but a pretty clear discussion of the issues >> NIST/SGIP think are on the table. >> _______________________________________________ >> smartpower-interest mailing list >> smartpower-interest@ietf.org >> https://www.ietf.org/mailman/listinfo/smartpower-interest > From vint@google.com Thu Apr 7 02:42:00 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316C928C0E7 for ; Thu, 7 Apr 2011 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-Vz3pDv24r7 for ; Thu, 7 Apr 2011 02:41:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 49EFB3A69B7 for ; Thu, 7 Apr 2011 02:41:59 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p379hghH009167 for ; Thu, 7 Apr 2011 02:43:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302169422; bh=TNhxdsA8HEiGQSTtbis0Zc1EkK8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xPvAKlN0TpbyLvzZM8UfEMTLbRHpeccVJhXLuu/vlGXkRMJybtmEKFsU09ISUxxM5 FwQkRvx6DaZB3ZxCSAR0w== Received: from qwj8 (qwj8.prod.google.com [10.241.195.72]) by wpaz37.hot.corp.google.com with ESMTP id p379hfZv027899 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Apr 2011 02:43:41 -0700 Received: by qwj8 with SMTP id 8so1625931qwj.4 for ; Thu, 07 Apr 2011 02:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y1uRWi/68KFeUyD3f6QxjJ5H+jNM19qF+m11gAYf6XE=; b=MnfoVY5MwpOcwSCgmyWcwB5unsp9btqwgx1QLuP64cU5qzfhNlpt5vXSqT8e4O5Gd6 fzgKeOzYiJM59SkA9cJA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XtmUZaWEsijvsLv8oIKtqkHm6ax7KMdO5IUT/VfoZJ9PpOwfA+uK2KctEA+IgcBjXM +caKRiDUq1QWmL2N3fxA== MIME-Version: 1.0 Received: by 10.229.229.206 with SMTP id jj14mr438920qcb.112.1302169420815; Thu, 07 Apr 2011 02:43:40 -0700 (PDT) Received: by 10.229.253.7 with HTTP; Thu, 7 Apr 2011 02:43:40 -0700 (PDT) In-Reply-To: <558D2682-5137-4FB7-8D83-CA84495F3100@cisco.com> References: <7B550DC8-16A1-4DBD-BEDF-2C7B99703C9C@tzi.org> <558D2682-5137-4FB7-8D83-CA84495F3100@cisco.com> Date: Thu, 7 Apr 2011 05:43:40 -0400 Message-ID: From: Vint Cerf To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Tue, 12 Apr 2011 09:52:01 -0700 Cc: core-chairs@tools.ietf.org, eman-chairs@tools.ietf.org, iot-workshop-prep@lists.i1b.org, IAB IAB , 6lowpan-chairs@tools.ietf.org, The IESG , roll-chairs@tools.ietf.org, Carsten Bormann , smartpower-interest@ietf.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] [Iot-workshop-prep] Report on the Smart Grid work in the IETF X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 09:42:00 -0000 i have been using that term (IoT) for a while simply to make the point that every day appliances can become part of the communicating and manageable devices on the Internet, in the billions (including sensor systems). v On Wed, Mar 30, 2011 at 1:48 AM, Fred Baker wrote: > Thanks. > > Yes, I think of "IoT" as a marketing term, which is to say something some= one came up with to find out how people would define it. > > :-) > > On Mar 30, 2011, at 7:35 AM, Carsten Bormann wrote: > >> On Mar 30, 2011, at 07:20, Fred Baker wrote: >> >>> >>> http://www.ietf.org/rfc/rfc5548.txt >>> 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. >>> =A0 =A0Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. = May >>> =A0 =A02009. (Format: TXT=3D47759 bytes) (Status: INFORMATIONAL) >>> >>> The first was generated by 6lowpan, >> >> Actually, that is a ROLL document. =A0(The entire set of ROLL requiremen= ts RFCs is a great body of reference, by the way.) >> >> Note also that the full title of last week's IAB workshop is "Interconne= cting Smart Objects with the Internet" (this is noteworthy as there is some= debate around the term "Internet of Things"). >> >> JFYI. >> >> Gruesse, Carsten >> > > From fredbakersba@gmail.com Thu Apr 7 04:07:41 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E113A68EF; Thu, 7 Apr 2011 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Oq+IdDb-j9Y; Thu, 7 Apr 2011 04:07:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4F1B73A68A7; Thu, 7 Apr 2011 04:07:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so2318185wyb.31 for ; Thu, 07 Apr 2011 04:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Vzc4/nRRL3SjGqgeUiHIYeHIcB3hJDQ5o6NeSOi+guU=; b=NjfUCmJI8Wyyq+AFgQ2i3EsThJjzPHXnGMfY+0JgI0ay/wgRYWgokimgIwaJQ616Cx 75xkjjukbqDmynOfIO7uLX/Pv890qvRzvb9FuQYanL5l1SvjrHKKnScOGmjj5sl7idsU uU1hD8IfE8TLD2zg8qFMKl7PdwUp8ny1m//eY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=OmMg4B3rV7AXhWlUm68uKSC6hk0K/H+rWMrAc5cOaUXi/gZIYs2L8iFGBpz8KH9S4y HdYIZaTyGKIIbPCQyUpQWbJb5siekZkdbgEctPvY0sldn+3P+PVr8iRzFbo6hKKuTLNg hK+LzNLGyFoGIQBme99N9uwE7xJlZe+e/gbOo= Received: by 10.216.143.96 with SMTP id k74mr707266wej.100.1302174564361; Thu, 07 Apr 2011 04:09:24 -0700 (PDT) Received: from [127.0.0.1] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id d6sm763195wer.2.2011.04.07.04.09.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 04:09:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Thu, 7 Apr 2011 13:09:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vint Cerf X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 12 Apr 2011 09:52:01 -0700 Cc: chair@ietf.org, SGIPGB-MEMBERS@smartgridlistserv.org, chair@iab.org, IETF SmartPower Directorate Subject: Re: [smartpowerdir] A view on Zigbee Security Energy Profile 1.x X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 11:07:41 -0000 On Apr 7, 2011, at 11:56 AM, Vint Cerf wrote: > I support your conclusions that SEP 1.x does not appear to meet the = conventional requirements of IETF-sanctioned standards and ought not to = be treated as SGIP-sanctioned either. But, properly "fenced off", might = be documented, for reference purposes only, in, e.g., the catalog of = "standards". Does this make any sense to you? Yes and no. The question I would raise is essentially the "I have an RFC = number; it's obviously a standard" problem. What the Texas PUC and the = government of the UK are asking for might be compared to an RFC number = in that context. Given one, they can specify and sell product. The = Internet community has over 6000 RFCs, of which quite a number are best = described as "white papers" or "documentation of what turned out to be a = bad idea"; only 2441, less than half, are standards of any category, and = only 1997, less than 1/3, are current.=20 My personal opinion goes along with the governing board's action; the = best thing that the SGIP can do is figure out a reasonable = coexistence/transition model so that deployed equipment can be used = without serious reinvestment, but not encourage future deployment. I'd = like to believe that Zigbee will help with that.= From alper.yegin@yegin.org Thu Apr 7 07:26:11 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9731228C122; Thu, 7 Apr 2011 07:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol7zG8NlXWlv; Thu, 7 Apr 2011 07:26:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A89C328C105; Thu, 7 Apr 2011 07:26:10 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LpKCT-1PSkbo1EtJ-00fPVD; Thu, 07 Apr 2011 10:27:53 -0400 From: "Alper Yegin" To: "'Fred Baker'" , , References: <201104070740.p377eFDr029926@irp-view13.cisco.com> In-Reply-To: <201104070740.p377eFDr029926@irp-view13.cisco.com> Date: Thu, 7 Apr 2011 17:27:46 +0300 Message-ID: <00bc01cbf52f$fb8d7190$f2a854b0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv09wsRvtsGgEtGRuKnvwJ9vD5q0wAOLuDQ Content-Language: en-us X-Provags-ID: V02:K0:1FXv+ikMf/lhpDthEGWq2W5LUx7NtPFb/3lCg80Kvwf 7F5flT/2oxFh+cZNJn0EMbO/R5cc2ps2rXmC4Pbh0kYahwxeqj wy1WVMt0tBGeFoLWCdZUECOQBL2y9s4BG86G9gpFl965083w1j 5LZTyBPnoMoLAu234/x51gyGqwCz5H05I3Rm2HI1jTC+xjRicC Rfmzu13oFHZ4pYeWd7vnY0W03o2oZcGawF/MMLhEBY= X-Mailman-Approved-At: Tue, 12 Apr 2011 09:52:01 -0700 Subject: Re: [smartpowerdir] [smartpower-interest] NIST/SGIP Discussion X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 14:26:11 -0000 Hi Fred, I didn't see ETSI mentioned in this PPT. Is there a document that refers to the type of joint work being considered? Thank you. Alper > -----Original Message----- > From: smartpower-interest-bounces@ietf.org [mailto:smartpower-interest- > bounces@ietf.org] On Behalf Of Fred Baker > Sent: Thursday, April 07, 2011 10:40 AM > To: smartpower-interest@ietf.org; smartpowerdir@ietf.org > Subject: [smartpower-interest] NIST/SGIP Discussion > > Interesting ppt > ftp://ftpeng.cisco.com/fred/SmartPower/NIST-SGIP_JWG.pptx > This is a joint presentation from NIST/SGIP to ETSI proposing and > negotiating a joint working group between the US and Europe. Nothing > confidential that I see, but a pretty clear discussion of the issues > NIST/SGIP think are on the table. > _______________________________________________ > smartpower-interest mailing list > smartpower-interest@ietf.org > https://www.ietf.org/mailman/listinfo/smartpower-interest From juergen.heiles@nsn.com Thu Apr 7 08:05:10 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4606828C10C; Thu, 7 Apr 2011 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF+2IvqiVBMO; Thu, 7 Apr 2011 08:05:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 23A5228C0E1; Thu, 7 Apr 2011 08:05:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p37F6bex029551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2011 17:06:39 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p37F6atL014926; Thu, 7 Apr 2011 17:06:37 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 17:06:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 17:06:24 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326403A25EEF@DEMUEXC014.nsn-intra.net> In-Reply-To: <00bc01cbf52f$fb8d7190$f2a854b0$@yegin@yegin.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [smartpower-interest] NIST/SGIP Discussion Thread-Index: Acv09wsRvtsGgEtGRuKnvwJ9vD5q0wAOLuDQAAFLHPA= References: <201104070740.p377eFDr029926@irp-view13.cisco.com> <00bc01cbf52f$fb8d7190$f2a854b0$@yegin@yegin.org> From: "Heiles, Juergen (NSN - DE/Munich)" To: "ext Alper Yegin" , "Fred Baker" , , X-OriginalArrivalTime: 07 Apr 2011 15:06:25.0731 (UTC) FILETIME=[5D48B930:01CBF535] X-Mailman-Approved-At: Tue, 12 Apr 2011 09:52:01 -0700 Subject: Re: [smartpowerdir] [smartpower-interest] NIST/SGIP Discussion X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:05:10 -0000 NIST/SGIP and the CEN/CENELEC/ETSI JWG Smart Grid have a discussion today about possible cooperation. Regards Juergen > -----Original Message----- > From: smartpower-interest-bounces@ietf.org [mailto:smartpower-interest- > bounces@ietf.org] On Behalf Of ext Alper Yegin > Sent: Thursday, April 07, 2011 4:28 PM > To: 'Fred Baker'; smartpower-interest@ietf.org; smartpowerdir@ietf.org > Subject: Re: [smartpower-interest] NIST/SGIP Discussion >=20 > Hi Fred, >=20 > I didn't see ETSI mentioned in this PPT. > Is there a document that refers to the type of joint work being > considered? >=20 > Thank you. >=20 > Alper >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: smartpower-interest-bounces@ietf.org [mailto:smartpower- > interest- > > bounces@ietf.org] On Behalf Of Fred Baker > > Sent: Thursday, April 07, 2011 10:40 AM > > To: smartpower-interest@ietf.org; smartpowerdir@ietf.org > > Subject: [smartpower-interest] NIST/SGIP Discussion > > > > Interesting ppt > > ftp://ftpeng.cisco.com/fred/SmartPower/NIST-SGIP_JWG.pptx > > This is a joint presentation from NIST/SGIP to ETSI proposing and > > negotiating a joint working group between the US and Europe. Nothing > > confidential that I see, but a pretty clear discussion of the issues > > NIST/SGIP think are on the table. > > _______________________________________________ > > smartpower-interest mailing list > > smartpower-interest@ietf.org > > https://www.ietf.org/mailman/listinfo/smartpower-interest >=20 > _______________________________________________ > smartpower-interest mailing list > smartpower-interest@ietf.org > https://www.ietf.org/mailman/listinfo/smartpower-interest From richard@shockey.us Thu Apr 7 09:51:11 2011 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922C328C15F for ; Thu, 7 Apr 2011 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33S83t2Edn97 for ; Thu, 7 Apr 2011 09:51:10 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id DD74F28C15E for ; Thu, 7 Apr 2011 09:51:09 -0700 (PDT) Received: (qmail 19902 invoked by uid 0); 7 Apr 2011 16:52:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 7 Apr 2011 16:52:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=CNVwCyjP9bzCUl16WExsgSWk93flvqN7eLnN5fZoT0J32bD4xfQdGyHFFswC4176nVz5uEeiuC1TZmDPEvma0vr5JY5JPCnT2dFppgBDY6xvucDeHonQQqETVeYqLqQf; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q7sRy-0003Sq-3w; Thu, 07 Apr 2011 10:52:54 -0600 From: "Richard Shockey" To: "'Heiles, Juergen \(NSN - DE/Munich\)'" , "'ext Alper Yegin'" , "'Fred Baker'" , , References: <201104070740.p377eFDr029926@irp-view13.cisco.com> <00bc01cbf52f$fb8d7190$f2a854b0$@yegin@yegin.org> <077E41CFFD002C4CAB7DFA4386A5326403A25EEF@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326403A25EEF@DEMUEXC014.nsn-intra.net> Date: Thu, 7 Apr 2011 12:52:53 -0400 Message-ID: <00c501cbf544$3d6e6f60$b84b4e20$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv09wsRvtsGgEtGRuKnvwJ9vD5q0wAOLuDQAAFLHPAAA7kg0A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} X-Mailman-Approved-At: Tue, 12 Apr 2011 09:52:01 -0700 Subject: Re: [smartpowerdir] [smartpower-interest] NIST/SGIP Discussion X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:51:11 -0000 What about IEC? I assume IEC 61850 is a core component here. -----Original Message----- From: smartpower-interest-bounces@ietf.org [mailto:smartpower-interest-bounces@ietf.org] On Behalf Of Heiles, Juergen (NSN - DE/Munich) Sent: Thursday, April 07, 2011 11:06 AM To: ext Alper Yegin; Fred Baker; smartpower-interest@ietf.org; smartpowerdir@ietf.org Subject: Re: [smartpower-interest] NIST/SGIP Discussion NIST/SGIP and the CEN/CENELEC/ETSI JWG Smart Grid have a discussion today about possible cooperation. Regards Juergen > -----Original Message----- > From: smartpower-interest-bounces@ietf.org [mailto:smartpower-interest- > bounces@ietf.org] On Behalf Of ext Alper Yegin > Sent: Thursday, April 07, 2011 4:28 PM > To: 'Fred Baker'; smartpower-interest@ietf.org; smartpowerdir@ietf.org > Subject: Re: [smartpower-interest] NIST/SGIP Discussion > > Hi Fred, > > I didn't see ETSI mentioned in this PPT. > Is there a document that refers to the type of joint work being > considered? > > Thank you. > > Alper > > > > > > > -----Original Message----- > > From: smartpower-interest-bounces@ietf.org [mailto:smartpower- > interest- > > bounces@ietf.org] On Behalf Of Fred Baker > > Sent: Thursday, April 07, 2011 10:40 AM > > To: smartpower-interest@ietf.org; smartpowerdir@ietf.org > > Subject: [smartpower-interest] NIST/SGIP Discussion > > > > Interesting ppt > > ftp://ftpeng.cisco.com/fred/SmartPower/NIST-SGIP_JWG.pptx > > This is a joint presentation from NIST/SGIP to ETSI proposing and > > negotiating a joint working group between the US and Europe. Nothing > > confidential that I see, but a pretty clear discussion of the issues > > NIST/SGIP think are on the table. > > _______________________________________________ > > smartpower-interest mailing list > > smartpower-interest@ietf.org > > https://www.ietf.org/mailman/listinfo/smartpower-interest > > _______________________________________________ > smartpower-interest mailing list > smartpower-interest@ietf.org > https://www.ietf.org/mailman/listinfo/smartpower-interest _______________________________________________ smartpower-interest mailing list smartpower-interest@ietf.org https://www.ietf.org/mailman/listinfo/smartpower-interest From jari.arkko@piuha.net Wed Apr 20 14:00:22 2011 Return-Path: X-Original-To: smartpowerdir@ietfc.amsl.com Delivered-To: smartpowerdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 430B0E0737; Wed, 20 Apr 2011 14:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqk2JpgJs-+y; Wed, 20 Apr 2011 14:00:22 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfc.amsl.com (Postfix) with ESMTP id A8003E0735; Wed, 20 Apr 2011 14:00:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 40C252CC4D; Thu, 21 Apr 2011 00:00:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYRhTof6L3ka; Thu, 21 Apr 2011 00:00:17 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 52A242CC2F; Thu, 21 Apr 2011 00:00:17 +0300 (EEST) Message-ID: <4DAF495F.40906@piuha.net> Date: Thu, 21 Apr 2011 00:00:15 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Hannes Tschofenig References: <4D51DEC0.6050905@piuha.net> In-Reply-To: <4D51DEC0.6050905@piuha.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IESG , IAB , IETF SmartPower Directorate Subject: [smartpowerdir] report on the EC IOT experts group meeting in April X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 21:00:22 -0000 I was in my second EC IOT experts group meeting in April. As you may remember, this is a small group of experts and stakeholders who should guide EU's role in promoting IOT technology and setting governance directions. Zach Shelby and me alternate as the IETF representative in this group. The rest of the participants come from diverse backgrounds: Internet Governance people, industry group representatives, academia, etc.

This time their meeting focused on cellular networks and their role in the Internet of Things, the group continued the work on their governance paper, and we a presentation about ETSI's machine-to-machine standardization work.

Liberalization of mobile networks number spaces for IOT

Rudolf van den Berg from OECD argued that we need market liberalization (number spaces, SIM cards, etc) so that the "one million device users" (utility companies etc) can unlock themselves from providers. Currently, a utility company that acquires cellular network service from a particular operator gets SIM cards, phone numbers, IMSI, etc. from that operator, and changing the operator currently involves having to change those million SIM cards in the devices that in the field. This is limiting the growth of some IOT applications, particularly when a very large number of devices has to stay in use for a decade or longer. As a practical example, government organizations have a legal obligation to allow their service contracts opened up in periodic competitive bidding process, which basically forces them to plan for an eventual operator change in their IOT-based applications. In general, the requirements from these new types of users are the following:

- switch operator without switching SIM cards
- employ national roaming to avoid dark spots
- allow the user to negotiate roaming prices in different countries
- guarantees on life time of networks

There are technical solutions (network-reprogrammable SIM cards and so on) but they have not been standardized and they may not be flexible enough (I'm personally not sure that's true). Rudolf proposes opening up the IMSI space for non-operators, so that a large user could have their own number space, own SIM cards, and simply contract on a yearly basis with operators for running the authentication infrastructure and roaming.

Rudolf also had a nice classification of IOT applications into mobile/fixed vs. concentrated/dispersed, and showed how different types of network solutions are appropriate for different applications. Traffic applications are dispersed and mobile, for instance, and cellular network solutions fit very well here. Whereas home networking may be best covered by wireless local area networks. There is no clear single winner, both types of technology are needed. The "just turn it on" model of cellular devices and their SIM cards is very appealing, however. There are limited examples of other deployment models where no user interaction is required but the system can still run in secure manner.

Governance aspects

The group is working on a paper that defines the governance directions regarding IOT for the EU. This paper is not making as much progress as they had initially hoped, and several more meeting rounds will be needed. The most interesting part of the governance discussion was about the level of required human control. EU might set some basic principles on what IOT systems must follow with regards to human safety, control, privacy, etc. These principles would be very similar to those that have been already specified for privacy in EU, for instance. In the question of human control, the group was divided about whether there could be situations where human involvement cannot be allowed. The example that started this discussion was smart grid control of your air conditioning, should you be allowed to turn air conditioning on, even at times of high load? This topic provokes a lot of opinions, mostly about having to leave consumers and users a choice. That being said, there are already systems such as ABS brakes in cars that run autonomously and cannot be disabled. So maybe the example application was bad. The group had lot of discussion about the principles, and the room generally seemed to think that there has to be a baseline set of rules and principles -- allowing (some) control, privacy, fair access to information, and so on.

ETSI M2M

ETSI's work on M2M was presented. 70 organizations participate the work in ETSI M2M working group, mainly working on an architecture for M2M services. Their primary model is IP(v6) connectivity from sensors over some access network to a server platform that can serve the needs of multiple M2M applications. The work is primarily not about designing new protocols, existing protocols (HTTP etc) are reused where possible.

Given the wide interest to ETSI's work, there is a plan to move the work from a regional entity (ETSI) to a 3GPP-like partnership entity.

Other

The group also talked about privacy impact assessment (PIA) and got a presentation from a Dutch foundation Qiy and their unified view model into online resources. Next meetings are in June 30th, September 28-29th, and November 15-16th.

From fred@cisco.com Wed Apr 20 22:06:33 2011 Return-Path: X-Original-To: smartpowerdir@ietfc.amsl.com Delivered-To: smartpowerdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D672FE06AA; Wed, 20 Apr 2011 22:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.548 X-Spam-Level: X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWoSZZsCfpNB; Wed, 20 Apr 2011 22:06:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id F2561E067B; Wed, 20 Apr 2011 22:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=11622; q=dns/txt; s=iport; t=1303362392; x=1304571992; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=9MZSI06aFTaCxX2pMk58fa67j6H15+HvkVuSUBzUgXw=; b=as2Eql/zt27RI3I8RsEdYFLxLC3qIERJI80qvkwEFQ7VmbfS4FptLAs2 cWbWK8Kp6UvYBZkGxNPXLQMycD+Hzj7CisgIVPRiEdPfLDIh6rqUNIahO fjSeZmyvqtcAhYpv7oQ1GOan3VoGU12l7ItdCGT+8NDRnnlJa01nDfomJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFy6r02rRDoI/2dsb2JhbAClSneIb6B6nFiFdgSFdIgwg38 X-IronPort-AV: E=Sophos;i="4.64,249,1301875200"; d="scan'208,217";a="434004120" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2011 05:06:31 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3L56OhW016018; Thu, 21 Apr 2011 05:06:30 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 20 Apr 2011 22:06:30 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 20 Apr 2011 22:06:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DAF495F.40906@piuha.net> Date: Wed, 20 Apr 2011 22:06:30 -0700 Message-Id: References: <4D51DEC0.6050905@piuha.net> <4DAF495F.40906@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-422-785159573 Cc: Hannes Tschofenig , IESG , IAB , IETF SmartPower Directorate Subject: Re: [smartpowerdir] report on the EC IOT experts group meeting in April X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 05:06:34 -0000 --Apple-Mail-422-785159573 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks On Apr 20, 2011, at 2:00 PM, Jari Arkko wrote: > I was in my second EC IOT experts group meeting in April. As you may = remember, this is a small group of experts and stakeholders who should = guide EU's role in promoting IOT technology and setting governance = directions. Zach Shelby and me alternate as the IETF representative in = this group. The rest of the participants come from diverse backgrounds: = Internet Governance people, industry group representatives, academia, = etc. >=20 > This time their meeting focused on cellular networks and their role in = the Internet of Things, the group continued the work on their governance = paper, and we a presentation about ETSI's machine-to-machine = standardization work. >=20 > Liberalization of mobile networks number spaces for IOT >=20 > Rudolf van den Berg from OECD argued that we need market = liberalization (number spaces, SIM cards, etc) so that the "one million = device users" (utility companies etc) can unlock themselves from = providers. Currently, a utility company that acquires cellular network = service from a particular operator gets SIM cards, phone numbers, IMSI, = etc. from that operator, and changing the operator currently involves = having to change those million SIM cards in the devices that in the = field. This is limiting the growth of some IOT applications, = particularly when a very large number of devices has to stay in use for = a decade or longer. As a practical example, government organizations = have a legal obligation to allow their service contracts opened up in = periodic competitive bidding process, which basically forces them to = plan for an eventual operator change in their IOT-based applications. In = general, the requirements from these new types of users are the = following: >=20 > - switch operator without switching SIM cards > - employ national roaming to avoid dark spots > - allow the user to negotiate roaming prices in different countries > - guarantees on life time of networks >=20 > There are technical solutions (network-reprogrammable SIM cards and so = on) but they have not been standardized and they may not be flexible = enough (I'm personally not sure that's true). Rudolf proposes opening up = the IMSI space for non-operators, so that a large user could have their = own number space, own SIM cards, and simply contract on a yearly basis = with operators for running the authentication infrastructure and = roaming. >=20 > Rudolf also had a nice classification of IOT applications into = mobile/fixed vs. concentrated/dispersed, and showed how different types = of network solutions are appropriate for different applications. Traffic = applications are dispersed and mobile, for instance, and cellular = network solutions fit very well here. Whereas home networking may be = best covered by wireless local area networks. There is no clear single = winner, both types of technology are needed. The "just turn it on" model = of cellular devices and their SIM cards is very appealing, however. = There are limited examples of other deployment models where no user = interaction is required but the system can still run in secure manner. >=20 > Governance aspects >=20 > The group is working on a paper that defines the governance directions = regarding IOT for the EU. This paper is not making as much progress as = they had initially hoped, and several more meeting rounds will be = needed. The most interesting part of the governance discussion was about = the level of required human control. EU might set some basic principles = on what IOT systems must follow with regards to human safety, control, = privacy, etc. These principles would be very similar to those that have = been already specified for privacy in EU, for instance. In the question = of human control, the group was divided about whether there could be = situations where human involvement cannot be allowed. The example that = started this discussion was smart grid control of your air conditioning, = should you be allowed to turn air conditioning on, even at times of high = load? This topic provokes a lot of opinions, mostly about having to = leave consumers and users a choice. That being said, there are already = systems such as ABS brakes in cars that run autonomously and cannot be = disabled. So maybe the example application was bad. The group had lot of = discussion about the principles, and the room generally seemed to think = that there has to be a baseline set of rules and principles -- allowing = (some) control, privacy, fair access to information, and so on. >=20 > ETSI M2M >=20 > ETSI's work on M2M was presented. 70 organizations participate the = work in ETSI M2M working group, mainly working on an architecture for = M2M services. Their primary model is IP(v6) connectivity from sensors = over some access network to a server platform that can serve the needs = of multiple M2M applications. The work is primarily not about designing = new protocols, existing protocols (HTTP etc) are reused where possible.=20= >=20 > Given the wide interest to ETSI's work, there is a plan to move the = work from a regional entity (ETSI) to a 3GPP-like partnership entity. >=20 > Other >=20 > The group also talked about privacy impact assessment (PIA) and got a = presentation from a Dutch foundation Qiy and their unified view model = into online resources. Next meetings are in June 30th, September = 28-29th, and November 15-16th. >=20 --Apple-Mail-422-785159573 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks

On Apr 20, 2011, at 2:00 PM, Jari Arkko wrote:

I was in my second EC IOT experts group meeting in April. As you may remember, this is a small group of experts and stakeholders who should guide EU's role in promoting IOT technology and setting governance directions. Zach Shelby and me alternate as the IETF representative in this group. The rest of the participants come from diverse backgrounds: Internet Governance people, industry group representatives, academia, etc.

This time their meeting focused on cellular networks and their role in the Internet of Things, the group continued the work on their governance paper, and we a presentation about ETSI's machine-to-machine standardization work.

Liberalization of mobile networks number spaces for IOT

Rudolf van den Berg from OECD argued that we need market liberalization (number spaces, SIM cards, etc) so that the "one million device users" (utility companies etc) can unlock themselves from providers. Currently, a utility company that acquires cellular network service from a particular operator gets SIM cards, phone numbers, IMSI, etc. from that operator, and changing the operator currently involves having to change those million SIM cards in the devices that in the field. This is limiting the growth of some IOT applications, particularly when a very large number of devices has to stay in use for a decade or longer. As a practical example, government organizations have a legal obligation to allow their service contracts opened up in periodic competitive bidding process, which basically forces them to plan for an eventual operator change in their IOT-based applications. In general, the requirements from these new types of users are the following:

- switch operator without switching SIM cards
- employ national roaming to avoid dark spots
- allow the user to negotiate roaming prices in different countries
- guarantees on life time of networks

There are technical solutions (network-reprogrammable SIM cards and so on) but they have not been standardized and they may not be flexible enough (I'm personally not sure that's true). Rudolf proposes opening up the IMSI space for non-operators, so that a large user could have their own number space, own SIM cards, and simply contract on a yearly basis with operators for running the authentication infrastructure and roaming.

Rudolf also had a nice classification of IOT applications into mobile/fixed vs. concentrated/dispersed, and showed how different types of network solutions are appropriate for different applications. Traffic applications are dispersed and mobile, for instance, and cellular network solutions fit very well here. Whereas home networking may be best covered by wireless local area networks. There is no clear single winner, both types of technology are needed. The "just turn it on" model of cellular devices and their SIM cards is very appealing, however. There are limited examples of other deployment models where no user interaction is required but the system can still run in secure manner.

Governance aspects

The group is working on a paper that defines the governance directions regarding IOT for the EU. This paper is not making as much progress as they had initially hoped, and several more meeting rounds will be needed. The most interesting part of the governance discussion was about the level of required human control. EU might set some basic principles on what IOT systems must follow with regards to human safety, control, privacy, etc. These principles would be very similar to those that have been already specified for privacy in EU, for instance. In the question of human control, the group was divided about whether there could be situations where human involvement cannot be allowed. The example that started this discussion was smart grid control of your air conditioning, should you be allowed to turn air conditioning on, even at times of high load? This topic provokes a lot of opinions, mostly about having to leave consumers and users a choice. That being said, there are already systems such as ABS brakes in cars that run autonomously and cannot be disabled. So maybe the example application was bad. The group had lot of discussion about the principles, and the room generally seemed to think that there has to be a baseline set of rules and principles -- allowing (some) control, privacy, fair access to information, and so on.

ETSI M2M

ETSI's work on M2M was presented. 70 organizations participate the work in ETSI M2M working group, mainly working on an architecture for M2M services. Their primary model is IP(v6) connectivity from sensors over some access network to a server platform that can serve the needs of multiple M2M applications. The work is primarily not about designing new protocols, existing protocols (HTTP etc) are reused where possible.

Given the wide interest to ETSI's work, there is a plan to move the work from a regional entity (ETSI) to a 3GPP-like partnership entity.

Other

The group also talked about privacy impact assessment (PIA) and got a presentation from a Dutch foundation Qiy and their unified view model into online resources. Next meetings are in June 30th, September 28-29th, and November 15-16th.


--Apple-Mail-422-785159573--