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

Jonathan Hui <jhui@archrock.com> Wed, 04 November 2009 15:54 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 C91A63A67D9 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:54:13 -0800 (PST)
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 wK0-GDYPD01m for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:54:13 -0800 (PST)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D5D863A67D4 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 07:54:12 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7FBACAF92E; Wed, 4 Nov 2009 07:54:34 -0800 (PST)
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 U31oQdzSSRVm; Wed, 4 Nov 2009 07:54:29 -0800 (PST)
Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 445CCAF92C; Wed, 4 Nov 2009 07:54:29 -0800 (PST)
Message-Id: <F78A8E6C-7523-4C62-A2CE-D94ABAA26C2B@archrock.com>
From: Jonathan Hui <jhui@archrock.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
In-Reply-To: <20091104143600.GA8772@elstar.local>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 4 Nov 2009 07:54:27 -0800
References: <OF164C5409.51429B82-ONC1257663.007E96BE-C1257663.008109C1@schneider-electric.com> <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> <20091104143600.GA8772@elstar.local>
X-Mailer: Apple Mail (2.936)
Cc: "6lowapp@ietf.org" <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: Wed, 04 Nov 2009 15:54:13 -0000

On Nov 4, 2009, at 6:36 AM, Juergen Schoenwaelder wrote:

> On Wed, Nov 04, 2009 at 10:04:01AM +0100, Zach Shelby wrote:
>
> I have been following this discussion silently and it seems there are
> pretty diverging opinions of the applications targeted by CoAP. Some
> people apparently just want to read simple meters from lots of truely
> resource constrained (thus cheap) devices and do very limited control
> actions.  Others seem to see a need for a rather complex^Hcomplete
> middleware instrastructure to be developed, including new transports
> to support it (and not much discussion of the necessary security
> infrastructure needed to support it has yet been seen here). Some
> poeple might believe there is a magic silver bullet to support all
> application scenarios equally well - I personally have some doubts
> about the existance of it or that it can be found quickly. This goes
> to the expectation that all the new protocols will be worked out and
> standardized fast enough to meet aggressive industry consortia
> deadlines of "tomorrow".
>
> In my experience, the IETF is working best by breaking things down in
> manageable pieces and assigning priorities to them. I believe this
> needs to be done sooner rather than later here as well. Building a
> long wishlist of things CoAP is expected to nicely interface with
> seems like moving into the wrong direction (except you take a rather
> liberal interpretation of "interfacing nicely" - the hard stuff is
> often in the detailed semantics and their mismatches).


Exactly!  I have been advocating this and I'm glad others are bumping  
into the same problem.  If we want to make quick forward progress, we  
need to explicitly call out target applications (and probably use  
cases) in the charter.

SE 2 and Building Management applications seems like a good starting  
list and I would be satisfied if we only focused on those two for the  
time being.

--
Jonathan Hui