Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

Kerry Lynn <kerlyn2001@gmail.com> Thu, 05 November 2009 16:03 UTC

Return-Path: <kerlyn2001@gmail.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 40DCC3A6AD5 for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 TWuntxZj1pyd for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:03:19 -0800 (PST)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 2D9D03A66B4 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 08:03:19 -0800 (PST)
Received: by bwz23 with SMTP id 23so134896bwz.29 for <6lowapp@ietf.org>; Thu, 05 Nov 2009 08:03:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=a5Jaafn9UQaetcStIQezjcdBInNe8t/dSRZBpOEiXCY=; b=qGOBNGMRhBN5qghfMJyGezpP2EveQlNpSoPWGYNHDvyet223/pyfS7nAO5Oh6yfpEk 2C1bnRqnGpXaGFpvr9XV8SMG3F32k4YF1szoPGZBHUrtttt0LvueJ8V8X8JUW/oNg9PI MuyiH0N9Istyzk4dCKUU2eVWt6Hf7OZSWCM+Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=abTZBcdn9E7P7CPjbYjVnGF6pPTUEHtN8eBO2OkSkgElAfCV1PJ3v2KODLboy2cIDu dn33KXv3WVmf5g+R8mO9FYd/qKgb3SJhjtm0yzp6HhFKVFawpVPU0N5J9AjdvXwC83OM zBvFHrXZFMl5a0C08uivwPtWuTlvvlobeN8hU=
MIME-Version: 1.0
Received: by 10.204.154.150 with SMTP id o22mr3202304bkw.154.1257437014536; Thu, 05 Nov 2009 08:03:34 -0800 (PST)
In-Reply-To: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org>
References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org>
Date: Thu, 5 Nov 2009 11:03:34 -0500
Message-ID: <3fe58b590911050803l352fc5e1idbd554ba10823868@mail.gmail.com>
From: Kerry Lynn <kerlyn2001@gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net
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: Thu, 05 Nov 2009 16:03:24 -0000

I plan to finish reading through all the email archives before the
6lowapp meeting, so this is the last time I'll apologize for not having
complete context.

There seems to be a wide divergence of opinion on the meaning of
"constrained", from full-on WS* to unable to contain any strings.  I would
offer a working definition, borrowed from Einstein, that CoNodes should
be "as simple as possible, but no simpler."

I believe that by moving as much functionality as possible from the
CoNodes into the CoGII nodes, we end up with a lower total system cost
and, ultimately, greater ubiquity. The definition of CoNode should admit
wired (e.g. power line connected) as well as wireless Devices.

As a general approach to foster consensus, I'd suggest the WG might
add to its "objectives and architecture" document a specification of
which services must be present in a CoNode and which must be
present in the CoGII node (and how the CoGII node differs from a
ROLL node; e.g. where does header de/compression reside?)

I support the viewpoint that a collection of CoNodes should be able to
implement some non-trivial applications without requiring a CoGII
node (e.g. the "one light, one switch" scenario).  Others may disagree
with this (perhaps even strongly) but I believe statements of this sort
will help focus the debate and lead to the the ultimate meaning of
"constrained".

I personally find it easier in the early stages to think in terms of abstract
services rather than specific protocols.  For example, "BACnet relies on
the ability to enumerate all the devices on the network and to query the
value of objects within a device."  The first is accomplished using the
"Who-is" or "Who-has" services (indeed, one might argue that having
two such mechanisms runs counter to interoperability) while the second
is accomplished using the "ReadProperty" service.  If we can reach
consensus on which services we need then mapping to specific
implementations might be easier.

Lastly, might I suggest using in the charter "CoNet" in place of "CNN"?

Respectfully submitted, Kerry Lynn


On Thu, Nov 5, 2009 at 5:06 AM, Carsten Bormann <cabo@tzi.org> wrote:
> I have put a new version of the WG charter proposal on the wiki page at
> http://6lowapp.net
> =
> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
> (charter text is at the end of the page).
>
> Obviously, I could not pick up every comment that was on the list (they were
> partially going in conflicting directions), but please do comment on the new
> version.
>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>