Re: [6lowapp] Next steps

Zach Shelby <zach@sensinode.com> Wed, 11 November 2009 12:26 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918EA28C20E for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 04:26:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.367
X-Spam-Level:
X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 H5Zgzb7W5-xF for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 04:26:38 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0520F3A688D for <6lowapp@ietf.org>; Wed, 11 Nov 2009 04:26:37 -0800 (PST)
Received: from host-17-149.meeting.ietf.org (host-17-149.meeting.ietf.org [133.93.17.149]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nABCQrTA022137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Nov 2009 14:26:57 +0200
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <019f01ca6259$625528c0$26ff7a40$@sturek@att.net>
Date: Wed, 11 Nov 2009 21:26:54 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <2704E79A-634B-4677-A28A-3F9841CEE737@sensinode.com>
References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <BCFFD6A3-8B4F-49CF-A657-DE34485134E1@tzi.org> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> <019f01ca6259$625528c0$26ff7a40$@sturek@att.net>
To: d.sturek@att.net
X-Mailer: Apple Mail (2.1076)
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next steps
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2009 12:26:39 -0000

(again off the 6lowpan list, thread re-named)

Hi from Hiroshima,

I totally agree with Don below. There is a clear need for what CoRE is  
aiming to achieve, which was confirmed here at the IETF as well. For  
those of you that can and want to use HTTP, then please go ahead and  
do that.  CoRE is just augmenting the REST model with a different  
realization.

We had a really successful BOF here at the IETF, with helpful input to  
update the charter and move forward. Please give us a chance here to  
report back to the mailing list, and let you know what the next steps  
are. Be sure we will take the feedback on the CoRE charter into  
account from the mailing list as well.

Thanks,
Zach

On Nov 11, 2009, at 7:58 , Don Sturek wrote:

> Hi Kris,
>
> Prior to all of the wireless work I have done in the past 10 years,  
> I worked
> at a specialty edge router company.  We worked in large data centers
> migrating serial protocols (bisync, X.25, etc.) to IP.  This work did
> actually require new IETF protocols and extensions (MPLS, reliable
> multicast, etc).
>
> I think for 6LowPAN to proliferate, we need to partially do what you  
> suggest
> (limit where possible creating new protocols) but augment existing  
> IETF
> standards as well.  I really see the CoRE work aligning with that  
> vision
> since we are mapping it to a RESTfull HTTP deployment which has  
> precedence
> in current web services.  Having CoRE re-use existing transports and
> security is critical
>
> There was one thing missing from your note on new hardware:  cost.
> Lowering the bar on cost with CoRE will allow the technology to be  
> deployed
> in places where new ARM processors with 192K flash/etc are too  
> expensive.
>
> Don
>
>
> -----Original Message-----
> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On  
> Behalf
> Of Kris Pister
> Sent: Tuesday, November 10, 2009 11:13 AM
> To: Richard Kelsey
> Cc: 6lowpan@ietf.org; 6lowapp@ietf.org
> Subject: Re: [6lowpan] hardware trends, new vs. existing protocols  
> [Re: 4861
> usage in LLNs]
>
> Richard -
> I think that today's things are being designed with wonderful chips  
> like
> your Ember EM351 and EM357
> which have 128kB and 192kB of flash and lots of RAM; like the Jennic
> JN5148, the Freescale MC13224, the Dust DN2510.
> They can run IP, they will run IP, and in many cases they do run  
> IP.  We
> all agree on that, and we're all excited about that.
> The debate centers on how many new protocols we need to invent, vs.  
> how
> many we can adopt or adapt, with the existing hardware, and with an  
> eye
> toward where technology trends are taking us.  My concern, like yours,
> is over the rate of adoption.  If the fastest path to broad adoption  
> is
> to create new protocols for routing, ND, transport, and applications,
> then by all means let's do that.  I'm concerned, however, that this  
> has
> not been a uniformly successful approach for wireless sensor  
> networks in
> the past. :)
> Many of us believe that we will see the fastest adoption by minimizing
> the number of new protocols.  We might be wrong, and that's the  
> debate.
>
> ksjp
>
> Richard Kelsey wrote:
>>   Date: Mon, 09 Nov 2009 22:12:03 -0800
>>   From: Kris Pister <pister@eecs.berkeley.edu>
>>
>>> Abandoning the installed base just goes to reinforce the idea
>>> that IP isn't an appropriate technology for things.
>>
>>   Michael - I think that we have the same goal, but I disagree with  
>> that
>>   statement.  I think that re-writing every protocol from discovery
>>   through transport to applications, from scratch, is what  
>> reinforces the
>
>>   idea that IP isn't an appropriate technology for things.
>>
>>   I realize that there are pressures from an installed base, but at  
>> this
>>   point it's a tiny fraction of the overall potential.  If we let  
>> the 1%
>>   installed base dictate the path for the next 99%, we should do  
>> our best
>
>>   to ensure that it's the right path.
>>
>> Taking these two paragraphs together, you seem to be saying
>> that IP is an appropriate technology for tomorrow's things,
>> but not necessarily for today's.  While the hardware will
>> obviously improve over time, we still need to pick some
>> target platform.  The current 6lowpan charter gives 32K of
>> flash as an example and mentions 802.15.4 repeatedly.  Are
>> you suggesting that we recharter?
>>
>> The increasing capabilities of the hardware does give us the
>> reassuring prospect that the longer we take the solve the
>> problems the easier it will be to so.
>>
>>                                -Richard Kelsey
>>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.