Re: [6lowapp] Updated BOF proposal/draft charter

David Ryan <oobles@gmail.com> Sat, 10 October 2009 00:05 UTC

Return-Path: <oobles@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 2D64D3A6997 for <6lowapp@core3.amsl.com>; Fri, 9 Oct 2009 17:05:58 -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=[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 dmz2xnAcnby3 for <6lowapp@core3.amsl.com>; Fri, 9 Oct 2009 17:05:56 -0700 (PDT)
Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id DB6E53A6991 for <6lowapp@ietf.org>; Fri, 9 Oct 2009 17:05:55 -0700 (PDT)
Received: by ewy4 with SMTP id 4so1090502ewy.37 for <6lowapp@ietf.org>; Fri, 09 Oct 2009 17:07:39 -0700 (PDT)
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=WmbdpasoEsheCkZZGBAjCS0soyemuDzOpHnTNCXwQoA=; b=Qv3TFTxVvq5F84CSix9qJPH5cQJ+9Oogw73ML3wNFDPJI47/T4O0E1p2RQB8jk7GMm bmYc3Vz36O9NmCjeIOwksc3KYfCU/Jfd/xQ25mt2aP8uqU9YdwufHht+qpi/NpcyXMd7 H0Z5UDg4iWu+GFXjelSgrO4XCYTyHgvT5cOYg=
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=yAvJS2CYSFcRfGnGvmk5vMtZohHISv+dHwG+ih6NxGSlLiht1HTOaiZkcZ17qQpHKy mYOTCh3hmY+Z0H4Sy5dNDsD/TFGEIdApV7idH3qLxjL0xWPFT2w4nocol0hER6YzfX6w ZuWmNsqrQAJ19E2qDGPJCez9ZGt2MrW/ge0Qw=
MIME-Version: 1.0
Received: by 10.211.153.14 with SMTP id f14mr3881961ebo.36.1255133259030; Fri, 09 Oct 2009 17:07:39 -0700 (PDT)
In-Reply-To: <FCBE22FB-C228-4760-9F16-03C4B19F5BEB@tzi.org>
References: <9A0D2E81-653E-41EA-A339-DE6680CDA631@tzi.org> <FCBE22FB-C228-4760-9F16-03C4B19F5BEB@tzi.org>
Date: Sat, 10 Oct 2009 11:07:38 +1100
Message-ID: <7f996c490910091707vd270f11h15874c4058fdec21@mail.gmail.com>
From: David Ryan <oobles@gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/mixed; boundary=00504502d3350ce2ea0475897c94
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Updated BOF proposal/draft charter
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: Sat, 10 Oct 2009 00:05:58 -0000

Hi Carsten,

In each revision of the 6lowapp-bof-proposal the goal for the group
has narrowed.  In effect, a solution has been chosen without
consideration of the output from Work Item 1 (capture the problem
statement and state of the art).  I'm not sure that the "web of
things" is actually appropriate for memory constrained devices and
don't believe this can be selected without reviewing the output from
Work Item 1.  I can understand that elements of the REST architectural
style has some advantages, however, the current goal now states that
"proxying with HTTP, WS-Management and SNMP must be straightforward".
There is now the new addition of WS-Management.  This is a very detail
solution which has been chosen without consideration of the problem
statement.  The solution also selects "support for URLs, media types(
content types) and encodings."  I also note that "Proxying with IP
service discovery protocols such as SLP, SSDP, DNS-SD, or WS-Discovery
as provided by DPWS must be straightforward."  Once again without
reviewing and understanding the problem to be solved the working group
chairs have chosen a solution.

The proposal also states that "Data formats will be considered in the
working group as general requirements and considerations in the other
technical work, but no new standardization is needed."  This is also
premature and without review of the "state of the art, problems to be
solved and relevant requirements from target industries and
organisations".  As text based data formats have already been ruled
out, the the current proposal only allows the options of EXI and
possibly one or two others.  It has yet to be proven how small these
data formats can be reduced in packet length and code size.  As the
mission of the IETF is based on "Rough consensus and running code", I
think it is fair to review the ability of these formats to fit memory
constrained devices before making hasty decisions.

I am not against the REST architectural style or the "web of things".
However, the group has changed its tune to a large extent following
the initial proposal posted here
(http://www.ietf.org/mail-archive/web/6lowapp/current/msg00006.html).

The goals have also dropped what I believe is a fundamental
requirement for these devices; a reusable transport layer.  From the
initial proposal:

b -- Transport (section 3).
  TCP is often considered relatively heavyweight while UDP lacks the
necessary reliability and ordering services. Results of
  6LowApp-related activities might include a "profiling" of TCP that
just includes the necessary elements without losing compatibility,
  and/or a set of "building blocks" that could be used in a specific
application protocol to enhance UDP by just the functions actually
  required.

Is this work being taken up by others?  If this were to be rolled into
a REST protocol I think it would be a big mistake.  There should be a
distinction
between transport protocol and transfer protocol.

I also note that the Goals and Milsestones have been updated:

01/2010  Milestone: Working group document for the Application
Protocol Specification.

03/2010  Submit 6lowapp Problem Statement and Objectives to IESG for
consideration of publication as Informational.

This states that the specification will be documented before the
problem statement and objectives have been considered and before the
"state of the art" has been reviewed.  This does not follow basic
engineering principles.

I have edited the proposal and submit for consideration an updated
proposal that removes premature decisions without review of Work Item
1.

Regards,
David.



On Sat, Oct 10, 2009 at 2:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
> Attached please find another update to the BOF proposal/draft charter.
> We believe we have picked up the relevant comments from the list, while
> trying to keep the focus sharp.
>
> If we have missed something, or you see an opportunity to further sharpen
> the focus, please tell us.
> Everything that we can fix now doesn't contribute to the load in the BOF
> meeting in Hiroshima.
>
> Gruesse, Carsten
>
>
>
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>