Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Jonathan Hui <jhui@archrock.com> Fri, 30 October 2009 15:08 UTC

Return-Path: <jhui@archrock.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 7D2973A6969 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 htS3Aip39k5F for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:08:49 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id BC5F33A692D for <6lowapp@ietf.org>; Fri, 30 Oct 2009 08:08:49 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2329DAF89E; Fri, 30 Oct 2009 08:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd0bZWZmauRm; Fri, 30 Oct 2009 08:09:02 -0700 (PDT)
Received: from [192.168.7.97] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 5A3A7AF849; Fri, 30 Oct 2009 08:09:02 -0700 (PDT)
Message-Id: <F6294845-9D2E-488F-B005-FF2345209F65@archrock.com>
From: Jonathan Hui <jhui@archrock.com>
To: <d.sturek@att.net>
In-Reply-To: <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 30 Oct 2009 08:09:00 -0700
References: <B27B00F8-1A4F-4258-86FC-C02E78778E45@cisco.com> <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <CE5B892A-3699-4CBF-8B6A-588F5A7DE99A@cisco.com> <EB735931-0D15-4017-94F1-3B10A0EC814D@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net>
X-Mailer: Apple Mail (2.936)
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF
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: Fri, 30 Oct 2009 15:08:50 -0000

Hi Don,

On Oct 30, 2009, at 6:25 AM, Don Sturek wrote:

> It would be good to avoid PEPs as much as possible.   These devices  
> are
> controversial in cost constrained deployments since they imply a  
> standalone
> box someplace (that the customer does not get benefit from  
> functionally) or
> some translation which eventually is outdated.

It seems that the desire to avoid the use of translation proxies/ 
gateways in SE 2 is driven by both business and technical reasons, is  
this accurate?  (Security may be another good reason to avoid the use  
of translation proxies/gateways).

Do you see value in a back-end service for SE 2 that can centrally  
buffer/store data from, accept and schedule requests to, and offer the  
data/node capabilities of large numbers of LLN devices in an  
aggregated and structured manner using one or more standard  
interfaces?  Such a service is not a proxy and also not really a  
gateway.  This is more of what I was envisioning that the PEP should  
really be, and the terms PEP and gateway do not capture that well.

--
Jonathan Hui