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 > >
- [6lowapp] 6lowapp BOF scheduled for Mon, Nov 9, 1… Carsten Bormann
- [6lowapp] Updated BOF proposal/draft charter Carsten Bormann
- Re: [6lowapp] Updated BOF proposal/draft charter David Ryan
- Re: [6lowapp] Updated BOF proposal/draft charter Carsten Bormann