From cabo@tzi.org Mon Oct 5 23:45:43 2009 Return-Path: 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 9C6F428C2FB for <6lowapp@core3.amsl.com>; Mon, 5 Oct 2009 23:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 4u6l0XYJRn77 for <6lowapp@core3.amsl.com>; Mon, 5 Oct 2009 23:45:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 7E66928C2F6 for <6lowapp@ietf.org>; Mon, 5 Oct 2009 23:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n966lBUe009814 for <6lowapp@ietf.org>; Tue, 6 Oct 2009 08:47:11 +0200 (CEST) Received: from [192.168.217.101] (p5489F0DD.dip.t-dialin.net [84.137.240.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 66E21B42B; Tue, 6 Oct 2009 08:47:11 +0200 (CEST) Message-Id: <9A0D2E81-653E-41EA-A339-DE6680CDA631@tzi.org> From: Carsten Bormann To: 6lowapp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 08:47:09 +0200 X-Mailer: Apple Mail (2.936) Subject: [6lowapp] 6lowapp BOF scheduled for Mon, Nov 9, 13-15 (date and time TENTATIVE) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 06:45:43 -0000 The first draft of the Hiroshima IETF 76 schedule is out: https://datatracker.ietf.org/meeting/76/agenda.html and the 6lowapp BOF has been scheduled for Mon, Nov 9, 13-15. Note that the meeting schedule is a DRAFT -- scheduling conflicts are often only detected when the actual schedule has been laid out, and corrective action may mean that sessions are moved around. Don't book a non-refundable airline ticket on the assumption the session will stay exactly there. An updated draft charter reflecting on the comments received will go out today. Gruesse, Carsten From shidan@gmail.com Tue Oct 6 13:42:42 2009 Return-Path: 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 4EF373A68D9 for <6lowapp@core3.amsl.com>; Tue, 6 Oct 2009 13:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 p9hFTtWpibJT for <6lowapp@core3.amsl.com>; Tue, 6 Oct 2009 13:42:41 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 1E4E83A67BE for <6lowapp@ietf.org>; Tue, 6 Oct 2009 13:42:40 -0700 (PDT) Received: by ewy10 with SMTP id 10so4648811ewy.9 for <6lowapp@ietf.org>; Tue, 06 Oct 2009 13:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7nVxY8am6AQF+9l5DV/n5HYckpV2NBIP/0c5zcmAKEM=; b=RCO3lldb78RXvlBKYDJS5QpMqpseIvixeN/GSYYGClbI6x2d+AoF3ta0py+c1zaW54 o/fd3lx33ZQdJ/xIob734oNpcjASYsFK676sKXc2iwEAPlq2U/yvY8racO8H9QAGUYGX ds/h3Unm/lKihp+Qf6D63R2ZjAYfXlGueD48w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ESSAZrzT4OjSoZC1gOWb5yOLrhVglFrnE/s5Ln3cpJVbDv+fTSBAckHoWjTz6n2UH4 5zj1xywsgqwJ60VlMcFmOFEq3SaO1Elkpw+IHJ2R9rpV+jCOVPlE9weYomH+CzisDcw4 tMy6mCiOiFN5R+zXA/b22ZnHztZFFsFdos6z8= MIME-Version: 1.0 Received: by 10.216.88.212 with SMTP id a62mr417083wef.72.1254861855613; Tue, 06 Oct 2009 13:44:15 -0700 (PDT) Date: Tue, 6 Oct 2009 16:44:15 -0400 Message-ID: <429b380e0910061344x6484e950h6bc7bf0dda634c2c@mail.gmail.com> From: Shidan To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=0016e6d6455925654a04754a4b10 Subject: [6lowapp] SIP as a Base Application Protocol 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:43:33 -0000 --0016e6d6455925654a04754a4b10 Content-Type: text/plain; charset=ISO-8859-1 Hello, I'm representing a group who is interested in implementing SIP over 6LoWPAN. What is the state of service discovery for 6LoWAPP.. If anyone is interested in being involved in our group discussions please let me know. Best, Shidan Gouran --0016e6d6455925654a04754a4b10 Content-Type: text/html; charset=ISO-8859-1 Hello, I'm representing a group who is interested in implementing SIP over 6LoWPAN. What is the state of service discovery for 6LoWAPP.. If anyone is interested in being involved in our group discussions please let me know.

Best,
Shidan Gouran
--0016e6d6455925654a04754a4b10-- From cabo@tzi.org Fri Oct 9 08:46:17 2009 Return-Path: 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 3280728C0F1 for <6lowapp@core3.amsl.com>; Fri, 9 Oct 2009 08:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 YhGWeTPWNqCt for <6lowapp@core3.amsl.com>; Fri, 9 Oct 2009 08:46:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 516B63A68E9 for <6lowapp@ietf.org>; Fri, 9 Oct 2009 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n99FlpdP029071 for <6lowapp@ietf.org>; Fri, 9 Oct 2009 17:47:51 +0200 (CEST) Received: from [192.168.217.101] (p5489ED07.dip.t-dialin.net [84.137.237.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 7445EB13C; Fri, 9 Oct 2009 17:47:50 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowapp@ietf.org In-Reply-To: <9A0D2E81-653E-41EA-A339-DE6680CDA631@tzi.org> Content-Type: multipart/mixed; boundary=Apple-Mail-41--229321283 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 17:47:49 +0200 References: <9A0D2E81-653E-41EA-A339-DE6680CDA631@tzi.org> X-Mailer: Apple Mail (2.936) Subject: [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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 15:46:17 -0000 --Apple-Mail-41--229321283 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 --Apple-Mail-41--229321283 Content-Disposition: attachment; filename=6lowapp-bof-proposal.txt Content-Type: text/plain; x-unix-mode=0644; name="6lowapp-bof-proposal.txt" Content-Transfer-Encoding: 7bit BOF request for IETF 76 (Hiroshima) $Revision: 324 $ BOF Name: 6lowapp -- Application protocols for resource-constrained devices and networks Area: APP Conflicts: -- must avoid: 6LoWPAN, ROLL, APPAREA, OPSAREA -- Avoid if possible: TSVAREA, SAAG -- (others???) Expected attendance: ~100 (see below) Timeslot: 120 minutes BOF Chairs: Carsten Bormann, TBD Mailing list: 6lowapp@ietf.org Description: ------------ 6lowapp -- Application protocols for resource-constrained devices and networks The 6LoWPAN and ROLL WGs are laying the groundwork to make the wireless Internet of Things a reality, but what application protocols will we use? Request-response protocols like HTTP may be a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the current web header (e.g. HTTP) and payload (e.g. XML) formats are too chatty for the 50-60 byte payloads possible in LoWPANs and require too much code for the 8-bit and 16-bit processors dominating embedded devices. Finally, the autoconfiguration of application protocols is a must in the embedded domain -- embedded devices often do not even have a user interface for manual configuration. Although in PC and cellphone processors memory size and processing speed have increased rapidly, simple embedded processors still find their place in a wide variety of applications where there are extreme limits on price and power consumption. Cost considerations often pin these chips on the trailing end of the fabrication process cycle, effectively disabling or at least considerably slowing Moore's law. The same trend can be seen from low-power wireless communications, where power consumption, robustness and price have kept e.g. the IEEE 802.15.4 standard at very modest data rates (10-100 kbit/s at the application layer) and payload sizes. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. The goal of 6lowapp is to produce application protocol and application commissioning solutions suitable for providing us the web for resource constrained devices suitable for use also over very constrained networks such as 6LoWPAN (the "embedded web"). In the 6lowapp Bar BOF discussion at IETF 75 in Stockholm, five areas of work were identified: Application protocols, service discovery, data formats, security and transport. Two areas are being proposed as the basis for a new working group called 6lowapp: application protocol and application commissioning work (the latter is more focused than general service discovery). Work on transport and security issues requires longer time frames and may fan out to different IETF areas. 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. There is a clear indication from industry and other standardization bodies that the solutions which this working group would provide are needed, and that the IETF is the most suitable place to do it. In particular the Smart Energy v2.0 (collaboration of NIST, UCA international, ZigBee/HomePlug and the IEC) is in urgent need of both application protocol and application commissioning solutions. The goal of the BOF is to confirm consensus for a WG charter proposal for a 6lowapp working group in the APP area. This BOF proposal contains an outline of that charter; the full charter proposal is being developed on the 6lowapp mailing list, and will be completed and circulated there before Hiroshima. 6lowapp WG Charter Draft: ------------------------- Description of Working Group: * The working group will produce documents in three areas: -- The general problem statement and requirements will be documented for an informational RFC. -- An application protocol for low-power embedded transfer will be developed and published with the goal of enabling the "embedded web" as the engine of the Internet of Things. -- Finally, a suitable technique for discovering and configuring application protocols for resource-constrained embedded devices and networks will be developed (application commissioning). * The main requirements for the working group will be taken from three industries: smart energy, building automation and machine-to-machine telemetry. * This working group will not standardize new content formats or encodings, instead the work items aim at supporting a wide variety of payloads through a suitable subset of media type (MIME type) and encoding identifiers. The working group will not work on the compression, tokenization or adaptation of HTTP, instead it will produce an efficient protocol implementing a defined core of REST functionality. * Apart from the pertinent APP area working groups, 6lowapp will work closely with the IPv6 over low-power WPAN (6lowpan) and Routing over low power and lossy networks (roll) working groups. * 6lowapp will cooperate with external organizations on work item requirements and standards interoperability. These include the W3C on data formats, OASIS on device web-services, the IEC and UCA OpenSG on Smart Energy, ETSI M2M TC on machine-to-machine architecture requirements, ZigBee/HomePlug, and the IPSO alliance. Work Items: ----------- 1. Problem Statement and Objectives: -- Captures the current state of the art, problems to be solved and relevant requirements from target industries and organizations. -- This activity is performed in parallel to solution work. 2. Application protocol: -- The development of a low-power embedded transfer protocol with a compact binary format requiring minimal code to implement. -- Features will include e.g. support for URLs, media types (content types) and encodings, sleeping nodes, several interaction models (pull, push, events, peer-to-peer), basic REST methods, both UDP and TCP transports, simple cachability, and statelessness. -- Proxying with HTTP, WS-Management and SNMP must be straightforward. -- This work item may produce one or more documents. 3. Application commissioning: -- The development of a technique enabling the application layer of a resource-constrained embedded device on an limited network to configure its application protocols. -- Support for sleeping nodes and NBMA links such as in 6lowpan. -- Simple, compact binary format requiring minimal code to implement. -- Proxying with IP service discovery protocols such as SLP, SSDP, DNS-SD, or WS-Discovery as provided by DPWS must be straightforward. Goals and Milestones: --------------------- 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. 03/2010 Milestone: Working group document for the Application Commissioning Specification. 09/2010 Submit Application Protocol Specification document(s) to IESG for consideration of publication as Proposed Standard. 11/2010 Submit Application Commissioning Specification document to IESG for consideration of publication as Proposed Standard. Agenda (2 hours): 5 min Agenda bashing Chairs 10 min Goal and purpose of the BOF Chairs 10 min Description of the problem/problem space Carsten 20 min 6lowapp WG charter proposal: part 1 Zach 20 min Contributions so far TBC Several drafts are in the pipeline for submission before the Hiroshima initial I-D deadline, 2009-10-19. It would be premature to make an exact list, but subjects will include: -- Requirements input (Building automation, Smart energy) -- Input from relevant large projects (e.g., SENSEI) -- Current solution drafts 10 min 6lowapp WG charter proposal: part 2 Zach 30 min Open Discussion All 10 min Calling the questions ADs Further Reading: -- 6lowapp Wiki http://6lowapp.net -- 6lowapp Problem Statement http://tools.ietf.org/html/6lowapp-problem Expected Audience: The 6lowapp mailing list has 85 members, many of which were attendees of the Stockholm Bar BOF. Other potential attendees include ROLL and 6LoWPAN attendees, plus other interested APP area attendees. (Influence of the meeting location in both directions, very hard to estimate.) --Apple-Mail-41--229321283 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-41--229321283-- From oobles@gmail.com Fri Oct 9 17:05:58 2009 Return-Path: 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: References: <9A0D2E81-653E-41EA-A339-DE6680CDA631@tzi.org> Date: Sat, 10 Oct 2009 11:07:38 +1100 Message-ID: <7f996c490910091707vd270f11h15874c4058fdec21@mail.gmail.com> From: David Ryan To: Carsten Bormann 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 00:05:58 -0000 --00504502d3350ce2ea0475897c94 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --00504502d3350ce2ea0475897c94 Content-Type: text/plain; charset=US-ASCII; name="6lowapp-bof-proposal-revised.txt" Content-Disposition: attachment; filename="6lowapp-bof-proposal-revised.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g0llu8471 Qk9GIHJlcXVlc3QgZm9yIElFVEYgNzYgKEhpcm9zaGltYSkKJFJldmlzaW9uOiAzMjQgJAoKQk9G IE5hbWU6IDZsb3dhcHAgLS0gQXBwbGljYXRpb24gcHJvdG9jb2xzIGZvciByZXNvdXJjZS1jb25z dHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3JrcwpBcmVhOiBBUFAKQ29uZmxpY3RzOgotLSBtdXN0 IGF2b2lkOiA2TG9XUEFOLCBST0xMLCBBUFBBUkVBLCBPUFNBUkVBCi0tIEF2b2lkIGlmIHBvc3Np YmxlOiBUU1ZBUkVBLCBTQUFHCi0tIChvdGhlcnM/Pz8pCkV4cGVjdGVkIGF0dGVuZGFuY2U6IH4x MDAgKHNlZSBiZWxvdykKVGltZXNsb3Q6IDEyMCBtaW51dGVzCgpCT0YgQ2hhaXJzOiBDYXJzdGVu IEJvcm1hbm4sIFRCRApNYWlsaW5nIGxpc3Q6IDZsb3dhcHBAaWV0Zi5vcmcKCkRlc2NyaXB0aW9u OgotLS0tLS0tLS0tLS0KCjZsb3dhcHAgLS0gQXBwbGljYXRpb24gcHJvdG9jb2xzIGZvciByZXNv dXJjZS1jb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3JrcwoKVGhlIDZMb1dQQU4gYW5kIFJP TEwgV0dzIGFyZSBsYXlpbmcgdGhlIGdyb3VuZHdvcmsgdG8gbWFrZSB0aGUKd2lyZWxlc3MgSW50 ZXJuZXQgb2YgVGhpbmdzIGEgcmVhbGl0eSwgYnV0IHdoYXQgYXBwbGljYXRpb24gcHJvdG9jb2xz CndpbGwgd2UgdXNlPyBSZXF1ZXN0LXJlc3BvbnNlIHByb3RvY29scyBsaWtlIEhUVFAgbWF5IGJl IGEgcG9vciBmaXQgdG8KYSBjb21tdW5pY2F0aW9uIG1vZGVsIHdpdGggYmF0dGVyeS1vcGVyYXRl ZCwgbW9zdGx5IHNsZWVwaW5nIG5vZGVzLiBJbgphZGRpdGlvbiwgdGhlIGN1cnJlbnQgd2ViIGhl YWRlciAoZS5nLiBIVFRQKSBhbmQgcGF5bG9hZCAoZS5nLiBYTUwpCmZvcm1hdHMgYXJlIHRvbyBj aGF0dHkgZm9yIHRoZSA1MC02MCBieXRlIHBheWxvYWRzIHBvc3NpYmxlIGluIExvV1BBTnMKYW5k IHJlcXVpcmUgdG9vIG11Y2ggY29kZSBmb3IgdGhlIDgtYml0IGFuZCAxNi1iaXQgcHJvY2Vzc29y cwpkb21pbmF0aW5nIGVtYmVkZGVkIGRldmljZXMuIEZpbmFsbHksIHRoZSBhdXRvY29uZmlndXJh dGlvbiBvZgphcHBsaWNhdGlvbiBwcm90b2NvbHMgaXMgYSBtdXN0IGluIHRoZSBlbWJlZGRlZCBk b21haW4gLS0gZW1iZWRkZWQKZGV2aWNlcyBvZnRlbiBkbyBub3QgZXZlbiBoYXZlIGEgdXNlciBp bnRlcmZhY2UgZm9yIG1hbnVhbApjb25maWd1cmF0aW9uLiBBbHRob3VnaCBpbiBQQyBhbmQgY2Vs bHBob25lIHByb2Nlc3NvcnMgbWVtb3J5IHNpemUgYW5kCnByb2Nlc3Npbmcgc3BlZWQgaGF2ZSBp bmNyZWFzZWQgcmFwaWRseSwgc2ltcGxlIGVtYmVkZGVkIHByb2Nlc3NvcnMKc3RpbGwgZmluZCB0 aGVpciBwbGFjZSBpbiBhIHdpZGUgdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMgd2hlcmUgdGhlcmUK YXJlIGV4dHJlbWUgbGltaXRzIG9uIHByaWNlIGFuZCBwb3dlciBjb25zdW1wdGlvbi4gQ29zdCBj b25zaWRlcmF0aW9ucwpvZnRlbiBwaW4gdGhlc2UgY2hpcHMgb24gdGhlIHRyYWlsaW5nIGVuZCBv ZiB0aGUgZmFicmljYXRpb24gcHJvY2VzcwpjeWNsZSwgZWZmZWN0aXZlbHkgZGlzYWJsaW5nIG9y IGF0IGxlYXN0IGNvbnNpZGVyYWJseSBzbG93aW5nIE1vb3JlJ3MKbGF3LiBUaGUgc2FtZSB0cmVu ZCBjYW4gYmUgc2VlbiBmcm9tIGxvdy1wb3dlciB3aXJlbGVzcwpjb21tdW5pY2F0aW9ucywgd2hl cmUgcG93ZXIgY29uc3VtcHRpb24sIHJvYnVzdG5lc3MgYW5kIHByaWNlIGhhdmUKa2VwdCBlLmcu IHRoZSBJRUVFIDgwMi4xNS40IHN0YW5kYXJkIGF0IHZlcnkgbW9kZXN0IGRhdGEgcmF0ZXMgKDEw LTEwMAprYml0L3MgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyKSBhbmQgcGF5bG9hZCBzaXplcy4K ClRoZSBnb2FsIG9mIDZsb3dhcHAgaXMgdG8gcHJvZHVjZSBhcHBsaWNhdGlvbiBwcm90b2NvbCBh bmQKYXBwbGljYXRpb24gY29tbWlzc2lvbmluZyBzb2x1dGlvbnMgc3VpdGFibGUgZm9yIHJlc291 cmNlIGNvbnN0cmFpbmVkIApkZXZpY2VzIHN1aXRhYmxlIGZvciB1c2Ugb3ZlciB2ZXJ5IGNvbnN0 cmFpbmVkIG5ldHdvcmtzIHN1Y2ggYXMgNkxvV1BBTi4KCkluIHRoZSA2bG93YXBwIEJhciBCT0Yg ZGlzY3Vzc2lvbiBhdCBJRVRGIDc1IGluIFN0b2NraG9sbSwgZml2ZSBhcmVhcwpvZiB3b3JrIHdl cmUgaWRlbnRpZmllZDogQXBwbGljYXRpb24gcHJvdG9jb2xzLCBzZXJ2aWNlIGRpc2NvdmVyeSwK ZGF0YSBmb3JtYXRzLCBzZWN1cml0eSBhbmQgdHJhbnNwb3J0LgoKVHdvIGFyZWFzIGFyZSBiZWlu ZyBwcm9wb3NlZCBhcyB0aGUgYmFzaXMgZm9yIGEgbmV3IHdvcmtpbmcgZ3JvdXAKY2FsbGVkIDZs b3dhcHA6IGFwcGxpY2F0aW9uIHByb3RvY29sIGFuZCBhcHBsaWNhdGlvbiBjb21taXNzaW9uaW5n CndvcmsgKHRoZSBsYXR0ZXIgaXMgbW9yZSBmb2N1c2VkIHRoYW4gZ2VuZXJhbCBzZXJ2aWNlIGRp c2NvdmVyeSkuCldvcmsgb24gdHJhbnNwb3J0IGFuZCBzZWN1cml0eSBpc3N1ZXMgcmVxdWlyZXMg bG9uZ2VyIHRpbWUgZnJhbWVzIGFuZAptYXkgZmFuIG91dCB0byBkaWZmZXJlbnQgSUVURiBhcmVh cy4gIERhdGEgZm9ybWF0cyB3aWxsIGJlIGNvbnNpZGVyZWQKaW4gdGhlIHdvcmtpbmcgZ3JvdXAg YXMgZ2VuZXJhbCByZXF1aXJlbWVudHMgYW5kIGNvbnNpZGVyYXRpb25zIGluIHRoZQpvdGhlciB0 ZWNobmljYWwgd29yay4KClRoZXJlIGlzIGEgY2xlYXIgaW5kaWNhdGlvbiBmcm9tIGluZHVzdHJ5 IGFuZCBvdGhlciBzdGFuZGFyZGl6YXRpb24KYm9kaWVzIHRoYXQgdGhlIHNvbHV0aW9ucyB3aGlj aCB0aGlzIHdvcmtpbmcgZ3JvdXAgd291bGQgcHJvdmlkZSBhcmUKbmVlZGVkLCBhbmQgdGhhdCB0 aGUgSUVURiBpcyB0aGUgbW9zdCBzdWl0YWJsZSBwbGFjZSB0byBkbyBpdC4gSW4KcGFydGljdWxh ciB0aGUgU21hcnQgRW5lcmd5IHYyLjAgKGNvbGxhYm9yYXRpb24gb2YgTklTVCwgVUNBCmludGVy bmF0aW9uYWwsIFppZ0JlZS9Ib21lUGx1ZyBhbmQgdGhlIElFQykgaXMgaW4gdXJnZW50IG5lZWQg b2YgYm90aAphcHBsaWNhdGlvbiBwcm90b2NvbCBhbmQgYXBwbGljYXRpb24gY29tbWlzc2lvbmlu ZyBzb2x1dGlvbnMuCgpUaGUgZ29hbCBvZiB0aGUgQk9GIGlzIHRvIGNvbmZpcm0gY29uc2Vuc3Vz IGZvciBhIFdHIGNoYXJ0ZXIgcHJvcG9zYWwKZm9yIGEgNmxvd2FwcCB3b3JraW5nIGdyb3VwIGlu IHRoZSBBUFAgYXJlYS4gVGhpcyBCT0YgcHJvcG9zYWwKY29udGFpbnMgYW4gb3V0bGluZSBvZiB0 aGF0IGNoYXJ0ZXI7IHRoZSBmdWxsIGNoYXJ0ZXIgcHJvcG9zYWwgaXMKYmVpbmcgZGV2ZWxvcGVk IG9uIHRoZSA2bG93YXBwIG1haWxpbmcgbGlzdCwgYW5kIHdpbGwgYmUgY29tcGxldGVkCmFuZCBj aXJjdWxhdGVkIHRoZXJlIGJlZm9yZSBIaXJvc2hpbWEuCgo2bG93YXBwIFdHIENoYXJ0ZXIgRHJh ZnQ6Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3Jv dXA6CgoqIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgcHJvZHVjZSBkb2N1bWVudHMgaW4gdGhyZWUg YXJlYXM6CiAgLS0gVGhlIGdlbmVyYWwgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50 cyB3aWxsIGJlIGRvY3VtZW50ZWQKICAgICBmb3IgYW4gaW5mb3JtYXRpb25hbCBSRkMuCiAgLS0g QW4gYXBwbGljYXRpb24gcHJvdG9jb2wgZm9yIGxvdy1wb3dlciBlbWJlZGRlZCB0cmFuc2ZlciB3 aWxsIGJlCiAgICAgZGV2ZWxvcGVkIGFuZCBwdWJsaXNoZWQgd2l0aCB0aGUgZ29hbCBvZiBlbmFi bGluZyB0aGUgSW50ZXJuZXQgb2YgVGhpbmdzLgogIC0tIEZpbmFsbHksIGEgc3VpdGFibGUgdGVj aG5pcXVlIGZvciBkaXNjb3ZlcmluZyBhbmQgY29uZmlndXJpbmcKICAgICBhcHBsaWNhdGlvbiBw cm90b2NvbHMgZm9yIHJlc291cmNlLWNvbnN0cmFpbmVkIGVtYmVkZGVkIGRldmljZXMKICAgICBh bmQgbmV0d29ya3Mgd2lsbCBiZSBkZXZlbG9wZWQgKGFwcGxpY2F0aW9uIGNvbW1pc3Npb25pbmcp LgoKKiBUaGUgbWFpbiByZXF1aXJlbWVudHMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYmUg dGFrZW4gZnJvbSB0aHJlZQogIGluZHVzdHJpZXM6IHNtYXJ0IGVuZXJneSwgYnVpbGRpbmcgYXV0 b21hdGlvbiBhbmQgbWFjaGluZS10by1tYWNoaW5lCiAgdGVsZW1ldHJ5LgoKKiBBcGFydCBmcm9t IHRoZSBwZXJ0aW5lbnQgQVBQIGFyZWEgd29ya2luZyBncm91cHMsIDZsb3dhcHAgd2lsbCB3b3Jr CiAgY2xvc2VseSB3aXRoIHRoZSBJUHY2IG92ZXIgbG93LXBvd2VyIFdQQU4gKDZsb3dwYW4pIGFu ZCBSb3V0aW5nIG92ZXIKICBsb3cgcG93ZXIgYW5kIGxvc3N5IG5ldHdvcmtzIChyb2xsKSB3b3Jr aW5nIGdyb3Vwcy4KCiogNmxvd2FwcCB3aWxsIGNvb3BlcmF0ZSB3aXRoIGV4dGVybmFsIG9yZ2Fu aXphdGlvbnMgb24gd29yayBpdGVtCiAgcmVxdWlyZW1lbnRzIGFuZCBzdGFuZGFyZHMgaW50ZXJv cGVyYWJpbGl0eS4gVGhlc2UgaW5jbHVkZSB0aGUgCiAgSUVDIGFuZCBVQ0EgT3BlblNHIG9uIFNt YXJ0IEVuZXJneSwgRVRTSSBNMk0gVEMgb24gbWFjaGluZS10by1tYWNoaW5lCiAgYXJjaGl0ZWN0 dXJlIHJlcXVpcmVtZW50cywgWmlnQmVlL0hvbWVQbHVnLCBhbmQgdGhlIElQU08gYWxsaWFuY2Uu CgoKV29yayBJdGVtczoKLS0tLS0tLS0tLS0KCjEuIFByb2JsZW0gU3RhdGVtZW50IGFuZCBPYmpl Y3RpdmVzOgogIC0tIENhcHR1cmVzIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBhcnQsIHByb2Js ZW1zIHRvIGJlIHNvbHZlZCBhbmQKICAgICByZWxldmFudCByZXF1aXJlbWVudHMgZnJvbSB0YXJn ZXQgaW5kdXN0cmllcyBhbmQgb3JnYW5pemF0aW9ucy4KICAtLSBUaGlzIGFjdGl2aXR5IGlzIHBl cmZvcm1lZCBpbiBwYXJhbGxlbCB0byBzb2x1dGlvbiB3b3JrLCBob3dldmVyLAogICAgIGEgcHJv YmxlbSBzdGF0ZW1lbnQgYW5kIG9iamVjdGl2ZXMgd2lsbCBiZSBwdWJsaXNoZWQgcHJpb3IgdG8K ICAgICBhbnkgc3BlY2lmaWNhdGlvbi4KCjIuIFRyYW5zcG9ydCBwcm90b2NvbDoKICAtLSBUQ1Ag aXMgb2Z0ZW4gY29uc2lkZXJlZCByZWxhdGl2ZWx5IGhlYXZ5d2VpZ2h0IHdoaWxlIFVEUCBsYWNr cyAKICAgICB0aGUgbmVjZXNzYXJ5IHJlbGlhYmlsaXR5IGFuZCBvcmRlcmluZyBzZXJ2aWNlcy4g UmVzdWx0cyBvZgogICAgIDZMb3dBcHAtcmVsYXRlZCBhY3Rpdml0aWVzIGluY2x1ZGUgYSAicHJv ZmlsaW5nIiBvZiBUQ1AgdGhhdCBqdXN0IAogICAgIGluY2x1ZGVzIHRoZSBuZWNlc3NhcnkgZWxl bWVudHMgd2l0aG91dCBsb3NpbmcgY29tcGF0aWJpbGl0eSwKICAgICBhbmQvb3IgYSBzZXQgb2Yg ImJ1aWxkaW5nIGJsb2NrcyIgdGhhdCBjb3VsZCBiZSB1c2VkIGluIGEgc3BlY2lmaWMgCiAgICAg YXBwbGljYXRpb24gcHJvdG9jb2wgdG8gZW5oYW5jZSBVRFAgYnkganVzdCB0aGUgZnVuY3Rpb25z IGFjdHVhbGx5CiAgICAgcmVxdWlyZWQuCgozLiBBcHBsaWNhdGlvbiBwcm90b2NvbDoKICAtLSBU aGUgZGV2ZWxvcG1lbnQgb2YgYSBsb3ctcG93ZXIgZW1iZWRkZWQgdHJhbnNmZXIgcHJvdG9jb2wg d2l0aCBhCiAgICAgY29tcGFjdCBiaW5hcnkgZm9ybWF0IHJlcXVpcmluZyBtaW5pbWFsIGNvZGUg dG8gaW1wbGVtZW50LgogIC0tIEZlYXR1cmVzIHdpbGwgbWF5IGluY2x1ZGUgc3VwcG9ydCBmb3Ig ZW5jb2RpbmdzLCBzbGVlcGluZyBub2RlcywgCiAgICAgc2V2ZXJhbCBpbnRlcmFjdGlvbiBtb2Rl bHMgKHB1bGwsIHB1c2gsIGV2ZW50cywgcGVlci10by1wZWVyKSwgCiAgICAgdGhlIFJFU1QgYXJj aGl0ZWN0dXJhbCBzdHlsZSwgYm90aCBVRFAgYW5kIFRDUCB0cmFuc3BvcnRzLgogICAgIFRoZSBl eGFjdCByZXF1aXJlbWVudHMgdG8gY29tZSBmcm9tIHdvcmsgaXRlbSAxLgogIC0tIFRoaXMgd29y ayBpdGVtIG1heSBwcm9kdWNlIG9uZSBvciBtb3JlIGRvY3VtZW50cy4KCjQuIEFwcGxpY2F0aW9u IGNvbW1pc3Npb25pbmc6CiAgLS0gVGhlIGRldmVsb3BtZW50IG9mIGEgdGVjaG5pcXVlIGVuYWJs aW5nIHRoZSBhcHBsaWNhdGlvbiBsYXllciBvZgogICAgIGEgcmVzb3VyY2UtY29uc3RyYWluZWQg ZW1iZWRkZWQgZGV2aWNlIG9uIGFuIGxpbWl0ZWQgbmV0d29yayB0bwogICAgIGNvbmZpZ3VyZSBp dHMgYXBwbGljYXRpb24gcHJvdG9jb2xzLgogIC0tIFN1cHBvcnQgZm9yIHNsZWVwaW5nIG5vZGVz IGFuZCBOQk1BIGxpbmtzIHN1Y2ggYXMgaW4gNmxvd3Bhbi4KICAtLSBTaW1wbGUsIGNvbXBhY3Qg YmluYXJ5IGZvcm1hdCByZXF1aXJpbmcgbWluaW1hbCBjb2RlIHRvIGltcGxlbWVudC4KCkdvYWxz IGFuZCBNaWxlc3RvbmVzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0KCjAxLzIwMTAgIFN1Ym1pdCA2 bG93YXBwIFByb2JsZW0gU3RhdGVtZW50IGFuZCBPYmplY3RpdmVzIHRvIElFU0cgZm9yCiAgICAg ICAgIGNvbnNpZGVyYXRpb24gb2YgcHVibGljYXRpb24gYXMgSW5mb3JtYXRpb25hbC4KCjAzLzIw MTAgIE1pbGVzdG9uZTogV29ya2luZyBncm91cCBkb2N1bWVudCBmb3IgdGhlIEFwcGxpY2F0aW9u IFByb3RvY29sCiAgICAgICAgIFNwZWNpZmljYXRpb24uCgowMy8yMDEwICBNaWxlc3RvbmU6IFdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQgZm9yIHRoZSBBcHBsaWNhdGlvbgogICAgICAgICBDb21taXNz aW9uaW5nIFNwZWNpZmljYXRpb24uCgowOS8yMDEwICBTdWJtaXQgQXBwbGljYXRpb24gUHJvdG9j b2wgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKSB0byBJRVNHCiAgICAgICAgIGZvciBjb25zaWRl cmF0aW9uIG9mIHB1YmxpY2F0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkLgoKMTEvMjAxMCAgU3Vi bWl0IEFwcGxpY2F0aW9uIENvbW1pc3Npb25pbmcgU3BlY2lmaWNhdGlvbiBkb2N1bWVudCB0bwog ICAgICAgICBJRVNHIGZvciBjb25zaWRlcmF0aW9uIG9mIHB1YmxpY2F0aW9uIGFzIFByb3Bvc2Vk IFN0YW5kYXJkLgoKCkFnZW5kYSAoMiBob3Vycyk6Cgo1IG1pbiAgIEFnZW5kYSBiYXNoaW5nICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGFpcnMKMTAgbWluICBHb2FsIGFuZCBwdXJw b3NlIG9mIHRoZSBCT0YgICAgICAgICAgICAgICAgICAgQ2hhaXJzCjEwIG1pbiAgRGVzY3JpcHRp b24gb2YgdGhlIHByb2JsZW0vcHJvYmxlbSBzcGFjZSAgICAgIENhcnN0ZW4KMjAgbWluICA2bG93 YXBwIFdHIGNoYXJ0ZXIgcHJvcG9zYWw6IHBhcnQgMSAgICAgICAgICAgWmFjaAoyMCBtaW4gIENv bnRyaWJ1dGlvbnMgc28gZmFyICAgICAgICAgICAgICAgICAgICAgICAgICBUQkMKICAgICAgICBT ZXZlcmFsIGRyYWZ0cyBhcmUgaW4gdGhlIHBpcGVsaW5lIGZvciBzdWJtaXNzaW9uIGJlZm9yZSB0 aGUKICAgICAgICBIaXJvc2hpbWEgaW5pdGlhbCBJLUQgZGVhZGxpbmUsIDIwMDktMTAtMTkuICBJ dCB3b3VsZCBiZQogICAgICAgIHByZW1hdHVyZSB0byBtYWtlIGFuIGV4YWN0IGxpc3QsIGJ1dCBz dWJqZWN0cyB3aWxsIGluY2x1ZGU6CiAgICAgICAgLS0gUmVxdWlyZW1lbnRzIGlucHV0IChCdWls ZGluZyBhdXRvbWF0aW9uLCBTbWFydCBlbmVyZ3kpCiAgICAgICAgLS0gSW5wdXQgZnJvbSByZWxl dmFudCBsYXJnZSBwcm9qZWN0cyAoZS5nLiwgU0VOU0VJKQogICAgICAgIC0tIEN1cnJlbnQgc29s dXRpb24gZHJhZnRzCjEwIG1pbiAgNmxvd2FwcCBXRyBjaGFydGVyIHByb3Bvc2FsOiBwYXJ0IDIg ICAgICAgICAgIFphY2gKMzAgbWluICBPcGVuIERpc2N1c3Npb24gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQWxsCjEwIG1pbiAgQ2FsbGluZyB0aGUgcXVlc3Rpb25zICAgICAgICAgICAg ICAgICAgICAgICAgIEFEcwoKRnVydGhlciBSZWFkaW5nOgotLSA2bG93YXBwIFdpa2kgICAgICAg ICAgICAgICAgICBodHRwOi8vNmxvd2FwcC5uZXQKLS0gNmxvd2FwcCBQcm9ibGVtIFN0YXRlbWVu dCAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvNmxvd2FwcC1wcm9ibGVtCgpFeHBlY3Rl ZCBBdWRpZW5jZToKClRoZSA2bG93YXBwIG1haWxpbmcgbGlzdCBoYXMgODUgbWVtYmVycywgbWFu eSBvZiB3aGljaCB3ZXJlIGF0dGVuZGVlcwpvZiB0aGUgU3RvY2tob2xtIEJhciBCT0YuICBPdGhl ciBwb3RlbnRpYWwgYXR0ZW5kZWVzIGluY2x1ZGUgUk9MTCBhbmQKNkxvV1BBTiBhdHRlbmRlZXMs IHBsdXMgb3RoZXIgaW50ZXJlc3RlZCBBUFAgYXJlYSBhdHRlbmRlZXMuCihJbmZsdWVuY2Ugb2Yg dGhlIG1lZXRpbmcgbG9jYXRpb24gaW4gYm90aCBkaXJlY3Rpb25zLCB2ZXJ5IGhhcmQgdG8KZXN0 aW1hdGUuKQo= --00504502d3350ce2ea0475897c94-- From cabo@tzi.org Sat Oct 10 00:54:58 2009 Return-Path: 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 F3D3E3A680B for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 flW8xGugmPyn for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 00:54:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AE75E3A68E6 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 00:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9A7uYSg011387; Sat, 10 Oct 2009 09:56:34 +0200 (CEST) Received: from [192.168.217.101] (p5489F553.dip.t-dialin.net [84.137.245.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 48F00B1AC; Sat, 10 Oct 2009 09:56:34 +0200 (CEST) From: Carsten Bormann To: David Ryan In-Reply-To: <7f996c490910091707vd270f11h15874c4058fdec21@mail.gmail.com> References: <9A0D2E81-653E-41EA-A339-DE6680CDA631@tzi.org> <7f996c490910091707vd270f11h15874c4058fdec21@mail.gmail.com> Message-Id: <1382865A-77BC-4AF6-A5AF-71D96FBCFD1B@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 09:56:32 +0200 X-Mailer: Apple Mail (2.936) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 07:54:58 -0000 David, before I go into your more technical points, let me try to clear up a process issue: On Oct 10, 2009, at 02:07, David Ryan wrote: > 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. This sequence may indeed be confusing if you are not familiar with the IETF WG process. What the milestones are trying to say is that we want to reach the early "WG document" milestone for the application protocol before we reach the "Submit to IESG" milestone for the objectives document. The "Submit" milestone for the application protocol is: 09/2010 Submit Application Protocol Specification document(s) to IESG for consideration of publication as Proposed Standard. Let me put this in a little figure: Objectives |-----------------------------------| Protocol Spec |============*1---------------------------| *1 is the "reach WG document status" milestone; before that, we are likely to work on one or more individually submitted Internet-Drafts (as depicted by the double line to the left of the *1). (We haven't defined such a milestone for the objectives document, which may add to the confusion; we just didn't see that much potential for competing objectives documents going through a selection/adoption process.) Experience tells us that we will need some finishing on the problem statement/objectives document before we can submit that -- this does not mean that we can't start working from objectives that may not have achieved perfect editorial clarity. On a practical level, what we definitely don't want to do is the classical "standardization requirements engineering", i.e. each proponent of a solution arguing endlessly to coax a solution-specific "mandatory requirement" into some document that is then used to throw out the other candidate protocols. We don't have time for that game; this is one of the reasons the document is called "objectives" and not "requirements". More philosophically speaking, I'd say we aren't likely to "engineer" a protocol (create it from well-understood non- conflicting requirements, as you would engineer a bridge) as much as "design" it (evolve the engineering in parallel with the objectives, as the latter are influenced by the former about as much as vice versa), but the timeline takes somewhat of a middle ground here, acknowledging that there is something to be gained by focusing on collecting objectives first and that there will be a more engineering- like phase at the end during which the design (and thus the objectives) already are stable. Gruesse, Carsten From shidan@gmail.com Sat Oct 10 10:28:21 2009 Return-Path: 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 1DB003A6860 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 5X1ayD-BqkDn for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 10:28:20 -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 B65CF3A68E9 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 10:28:19 -0700 (PDT) Received: by ewy4 with SMTP id 4so1456536ewy.37 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 10:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=dB8i3YyjJnufq0TO+GmFsolYamiEqa/nYTANKLny2Pc=; b=nxvXcKZjKV13DmLU4iktq31trD6GTTroRrLC9lvnB7rQfYEn3SN1ODNafrVrYo7R2a RD6vXt6sJ1MwGevsUq/4+RuEnurE1nR9vDA/oJZlaFbAgyZz45r/gfo0lMtn0mdXyaAV hf925Nzcr/H3p63unB9EqFKda6ovfVR9nqaX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XtnYFZYBYbE0fyKu7VXKOKZGa/We9H6pU0GeFUmDDJYTCeKpsV4sMEGt9esINZIw7r 4UxtJggGAiABkU81D1dTONMo4vuX7ZdGWuJoiURDyIzhUSLwHtoyIb1H22OWDs/HhTNm XMBzr9yYoJvL/MOyoO7FTro5m1gAVV4wGCG1k= MIME-Version: 1.0 Received: by 10.216.86.195 with SMTP id w45mr1289991wee.82.1255195804120; Sat, 10 Oct 2009 10:30:04 -0700 (PDT) Date: Sat, 10 Oct 2009 13:30:04 -0400 Message-ID: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> From: Shidan To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7e06c0738e00475980c80 Subject: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 17:28:21 -0000 --0016e6d7e06c0738e00475980c80 Content-Type: text/plain; charset=ISO-8859-1 I'm going through the 6LoWAPP problem statement: "request-response protocols like HTTP may require battery-operated, mostly sleeping nodes to be listening for requests much more frequently than their application processing requirements alone would need them to wake up." "In addition, some of the applications may require optimizations in terms of bandwidth usage; for example, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs. Their interpretation and generation may require too much code for the 8-bit and 16-bit processors dominating LoWPAN nodes." None of these points seem evident to me. We are in co-operation with two multinationals and faculty at Columbia University implementing, unadulterated SIP for smart meter PLC communications and I'm personally trying to steer the group to do a proof of concept of running our sub 40K stack over 6 LoWPAN on Contiki. Going back to the problem statement, definitely the second point is only valid if considering XML . For the first point, if we are assuming there is a gateway present that isn't constrained by power requirements then the ways to tackle this issue become wider. My bias is not towards SIP, some sort of adulterated HTTP or anything else, but I think anyone in this space should consider the fact that a SIP based architecture will be the defacto standard for mobile networks, which is already the most ubiquitos system out there. Thats why I'm interested in both SIP for this space. Its one thing standardizing how to implement application layers over 6LoWPAN but standardizing around specific REST architecures, SIP architectures, desription logics or anything else at this point without understanding requirements is quite unreasonable. --0016e6d7e06c0738e00475980c80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm going through=A0the 6LoWAPP=A0problem statement:
=A0
"request-response protocols like HTTP may require battery-operate= d, mostly sleeping nodes to be listening for requests much more frequently = than their application processing requirements alone would need them to wak= e up."
=A0
"In addition, some of the applications may require optimization= s in terms of bandwidth usage; for example, the usual data formats (both he= aders and body) are perceived to be too chatty for the 50-60 byte payloads = possible in LoWPANs.=A0 Their interpretation and generation may require too= much code for the 8-bit and 16-bit processors dominating LoWPAN nodes.&quo= t;
=A0
=A0
None of these points seem evident to me. We are in co-operation with t= wo multinationals and faculty at Columbia University implementing, unadulte= rated SIP for smart meter PLC communications and I'm personally=A0tryin= g to steer=A0the group to do a proof of concept of running our sub 40K=A0st= ack=A0over 6 LoWPAN=A0on Contiki.
=A0
Going back to the problem statement,=A0definitely the second point is = only valid if considering XML=A0.
=A0
For the first point, if we are assuming there is a gateway present tha= t isn't constrained by power requirements then the ways to tackle this = issue become wider.
=A0
My bias is not towards SIP, some sort of=A0adulterated HTTP=A0or anyth= ing else, but I think anyone in this space should consider the fact that a = SIP based architecture will be the defacto standard for mobile networks, wh= ich is already the most ubiquitos system out there. Thats why I'm inter= ested in both SIP=A0for this space.
=A0
Its one thing standardizing how to implement application layers over 6= LoWPAN but standardizing around specific=A0REST architecures, SIP architect= ures, desription logics=A0or anything else=A0at this point without understa= nding requirements is quite unreasonable.
--0016e6d7e06c0738e00475980c80-- From cabo@tzi.org Sat Oct 10 11:12:21 2009 Return-Path: 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 EA59828C0E6 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 11:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 wM3HZc8Vpcu3 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 11:12:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id BA18F3A6778 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 11:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9AIDuvp028150; Sat, 10 Oct 2009 20:13:56 +0200 (CEST) Received: from [192.168.217.101] (p5489F553.dip.t-dialin.net [84.137.245.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 8BB59B1F9; Sat, 10 Oct 2009 20:13:56 +0200 (CEST) From: Carsten Bormann To: Shidan In-Reply-To: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 20:13:55 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 18:12:22 -0000 On Oct 10, 2009, at 19:30, Shidan wrote: > SIP for smart meter PLC communications As I told everyone who is bringing some technology to the table, I'd suggest you write an Internet-Draft. In this case, it should at least cover what problem SIP solves and what data protocols you expect to initiate/transport with it. I would like to take the opportunity to remind everyone that the deadline for new Internet-Drafts for Hiroshima is October 19 (24:00 UTC), please see http://www.ietf.org/meeting/cutoff-dates.html#76 Gruesse, Carsten From adam@sics.se Sat Oct 10 15:06:47 2009 Return-Path: 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 403DF3A694F for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 15:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 gOBkwBN5z9Ns for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 15:06:46 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 1E4253A6946 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 15:06:45 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id 879464001C; Sun, 11 Oct 2009 00:08:32 +0200 (CEST) Message-ID: <4AD105DC.3070407@sics.se> Date: Sun, 11 Oct 2009 00:08:28 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shidan References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> In-Reply-To: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 22:06:47 -0000 Shidan wrote: > "request-response protocols like HTTP may require battery-operated, > mostly sleeping nodes to be listening for requests much more frequently > than their application processing requirements alone would need them to > wake up." > > "In addition, some of the applications may require optimizations in > terms of bandwidth usage; for example, the usual data formats (both > headers and body) are perceived to be too chatty for the 50-60 byte > payloads possible in LoWPANs. Their interpretation and generation may > require too much code for the 8-bit and 16-bit processors dominating > LoWPAN nodes." > > None of these points seem evident to me. I very much agree with this. By so quickly dismissing the opportunities with existing protocols such as HTTP and SIP, this group may miss reaching widespread adoption of its protocols. Both these arguments were frequently used in the past against IP for resource-constrained systems, yet today we take IP for granted for these systems despite the overheads of IP. We need to a pay price for interoperability and flexibility, but we think it is worth it. FWIW, we've recently been working with REST web services (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio protocol (X-MAC) for Contiki. The implementation of the application layers (REST/HTTP) has roughly a 5kb code footprint. The performance is not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML format is completed in roughly 0.5 seconds over a one-hop radio link and in less than 2 seconds over a four-hop radio network: http://www.sics.se/~adam/yazar09efficient.pdf Note that this is without any optimizations at the REST/HTTP/TCP/IP layers. Full HTTP headers are sent from the curl client, reducing the overall performance. Full XML is sent from the sensors. Thus there is plenty of opportunity to improve this without moving away from the HTTP/TCP/IP framework. For example, as we show in the above paper, there are significant savings in using conditional HTTP GETs when data have not changed between subsequent requests. Like Shidan, I am not saying that we necessarily must use full-fledged REST/HTTP/TCP/IP or SIP for everything in our resource-constrained networks. But we mustn't so quickly rule out existing mechanisms just because of their perceived overhead. Interoperability and flexibility are very important properties, often more important than bit-level optimizations. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From d.sturek@att.net Sat Oct 10 17:55:07 2009 Return-Path: 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 72E603A6907 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 17:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] 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 qLtHpt44OzCy for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 17:55:06 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 7889D3A68BB for <6lowapp@ietf.org>; Sat, 10 Oct 2009 17:55:06 -0700 (PDT) Received: (qmail 77294 invoked from network); 11 Oct 2009 00:56:52 -0000 Received: from (d.sturek@202.130.198.3 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 10 Oct 2009 17:56:51 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: M4pzGFoVM1n2HMDu6Rzxef0kGdK8XnNUDYzb6PBGrY2Oz2zvc0UTlqPvKT_WQHfBoV8aK4gyE_shlY9xiA7AVC5QGjj_Y_i2fcEe6qRwvssNUsClBFOSNyIbOV078kc102GlvH9RGozUBGBSjxN2o6KDLES.lV8NYQQMLRt1Ih8SWS0wafreF7NH9pnSB22NhlObDb0TajCrXnph.Y.uXxG64p6inZKRbT61PF39dcn4gnT4cJmWQ8kCHXnxvpdR.XmcPMVq_BBPI8tCoArcELaqVOq4fP.KudOaVqukgdnWTGJeKTk- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Adam Dunkels'" , "'Shidan'" References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> In-Reply-To: <4AD105DC.3070407@sics.se> Date: Sat, 10 Oct 2009 17:56:43 -0700 Message-ID: <001701ca4a0d$b6416610$22c43230$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpJ9jctpABh1S4eRtCYTsS5ybj9CgAFxeaA Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 00:55:07 -0000 Hi Adam. .5 seconds for one hop and 2 seconds for 4 hops are really not acceptable for many applications. We should of course investigate using existing protocols. However it does not seem likely that full HTTP and XML deployed over devices like IEEE 802.15.4 with very small packet sizes will scale very well (certainly, for any application expecting to do home or building controls, those latencies don't work). Ideally, we should find something that allows for full HTTP/etc. while enabling constrained devices to operate with a solution that can be expanded/compressed. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Adam Dunkels Sent: Saturday, October 10, 2009 3:08 PM To: Shidan Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP Shidan wrote: > "request-response protocols like HTTP may require battery-operated, > mostly sleeping nodes to be listening for requests much more frequently > than their application processing requirements alone would need them to > wake up." > > "In addition, some of the applications may require optimizations in > terms of bandwidth usage; for example, the usual data formats (both > headers and body) are perceived to be too chatty for the 50-60 byte > payloads possible in LoWPANs. Their interpretation and generation may > require too much code for the 8-bit and 16-bit processors dominating > LoWPAN nodes." > > None of these points seem evident to me. I very much agree with this. By so quickly dismissing the opportunities with existing protocols such as HTTP and SIP, this group may miss reaching widespread adoption of its protocols. Both these arguments were frequently used in the past against IP for resource-constrained systems, yet today we take IP for granted for these systems despite the overheads of IP. We need to a pay price for interoperability and flexibility, but we think it is worth it. FWIW, we've recently been working with REST web services (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio protocol (X-MAC) for Contiki. The implementation of the application layers (REST/HTTP) has roughly a 5kb code footprint. The performance is not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML format is completed in roughly 0.5 seconds over a one-hop radio link and in less than 2 seconds over a four-hop radio network: http://www.sics.se/~adam/yazar09efficient.pdf Note that this is without any optimizations at the REST/HTTP/TCP/IP layers. Full HTTP headers are sent from the curl client, reducing the overall performance. Full XML is sent from the sensors. Thus there is plenty of opportunity to improve this without moving away from the HTTP/TCP/IP framework. For example, as we show in the above paper, there are significant savings in using conditional HTTP GETs when data have not changed between subsequent requests. Like Shidan, I am not saying that we necessarily must use full-fledged REST/HTTP/TCP/IP or SIP for everything in our resource-constrained networks. But we mustn't so quickly rule out existing mechanisms just because of their perceived overhead. Interoperability and flexibility are very important properties, often more important than bit-level optimizations. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From shidan@gmail.com Sat Oct 10 18:38:57 2009 Return-Path: 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 A80E03A68D5 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 18:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LzjK1IC1ikK5 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 18:38:56 -0700 (PDT) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 856863A6861 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 18:38:55 -0700 (PDT) Received: by ewy18 with SMTP id 18so2016617ewy.43 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 18:40:41 -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=MvDg72WmegVIIjzyOxYBJFsGCaXnG6idAyY1LQB/fiE=; b=BCdP33t60FsQJ9kJSqZSsy/YPencJV2tf2HwDk5/civTqTLkEazQmz/jPAOCboyFIu eV0DxWSm1BtMxak7NM2gw67qgNHQaphPjMx6el65hU5lm+AtmkO6PyU8uBOv32mD8Fw7 qNG/AIMBWM13h0MoCQebDgeFtpQ1/yG4OHuGg= 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=X7geLngnpvmYpRGlQ76oH00eMxmkOAKV4ofxs6VAMUNNaYmKjnk7K34GHT9J8V4mqs OdRDt0tIV5j9Pj2UftkViwXN2uJx+gW/B/yYL690jrcTuxiCOo7NwqOJZeOgd+j1U6fD 52Qth9NGTr1oVRQnBPKPwE5Aupf5W5lHlHvs8= MIME-Version: 1.0 Received: by 10.216.87.81 with SMTP id x59mr1434047wee.147.1255225241402; Sat, 10 Oct 2009 18:40:41 -0700 (PDT) In-Reply-To: <-3576688268114842355@unknownmsgid> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> Date: Sat, 10 Oct 2009 21:40:41 -0400 Message-ID: <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> From: Shidan To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0016e6dab082a07da704759ee6a7 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 01:38:57 -0000 --0016e6dab082a07da704759ee6a7 Content-Type: text/plain; charset=ISO-8859-1 Hi Don, I certainly don't disagree with you that we need better latency and I'm pretty sure Adam doesn't either as he said this is without ANY optimizations. Given that fact, his statement is quite impressive. The key here is to actually back up any ideas and opinions with real results and this is what we are in the process of doing. Right now for our purposes, in the Smart Grid domain, we can run SIP, with some minor changes beyond stack size optimizations, over networks with as little bandwidth as 80kbps and highly constrained devices. We also acknowledge for our use cases, latency is not really an issue. I'm pretty convinced that with the RIGHT sort of optimizations, any latency issues can be handled without having to dictating general architectural standards like using REST, SNMP, SIP, etc. which can stifle innovation and lead to building everything with a hammer. Having said that Carsten's note is encouraging and I'm pretty convinced this committee has in mind creating a base that will evolve without stifling innovation and take real results and proof of concepts of use cases as main deciding factors. We will definitely be submitting an ID for Hiroshima. -- Shidan Gouran On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek wrote: > Hi Adam. > .5 seconds for one hop and 2 seconds for 4 hops are really not acceptable > for many applications. > > We should of course investigate using existing protocols. However it does > not seem likely that full HTTP and XML deployed over devices like IEEE > 802.15.4 with very small packet sizes will scale very well (certainly, for > any application expecting to do home or building controls, those latencies > don't work). Ideally, we should find something that allows for full > HTTP/etc. while enabling constrained devices to operate with a solution > that > can be expanded/compressed. > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf > Of Adam Dunkels > Sent: Saturday, October 10, 2009 3:08 PM > To: Shidan > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] HTTP and SIP > > Shidan wrote: > > "request-response protocols like HTTP may require battery-operated, > > mostly sleeping nodes to be listening for requests much more frequently > > than their application processing requirements alone would need them to > > wake up." > > > > "In addition, some of the applications may require optimizations in > > terms of bandwidth usage; for example, the usual data formats (both > > headers and body) are perceived to be too chatty for the 50-60 byte > > payloads possible in LoWPANs. Their interpretation and generation may > > require too much code for the 8-bit and 16-bit processors dominating > > LoWPAN nodes." > > > > None of these points seem evident to me. > > I very much agree with this. By so quickly dismissing the opportunities > with existing protocols such as HTTP and SIP, this group may miss > reaching widespread adoption of its protocols. > > Both these arguments were frequently used in the past against IP for > resource-constrained systems, yet today we take IP for granted for these > systems despite the overheads of IP. We need to a pay price for > interoperability and flexibility, but we think it is worth it. > > FWIW, we've recently been working with REST web services > (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio > protocol (X-MAC) for Contiki. The implementation of the application > layers (REST/HTTP) has roughly a 5kb code footprint. The performance is > not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML > format is completed in roughly 0.5 seconds over a one-hop radio link and > in less than 2 seconds over a four-hop radio network: > > http://www.sics.se/~adam/yazar09efficient.pdf > > Note that this is without any optimizations at the REST/HTTP/TCP/IP > layers. Full HTTP headers are sent from the curl client, reducing the > overall performance. Full XML is sent from the sensors. Thus there is > plenty of opportunity to improve this without moving away from the > HTTP/TCP/IP framework. For example, as we show in the above paper, there > are significant savings in using conditional HTTP GETs when data have > not changed between subsequent requests. > > Like Shidan, I am not saying that we necessarily must use full-fledged > REST/HTTP/TCP/IP or SIP for everything in our resource-constrained > networks. But we mustn't so quickly rule out existing mechanisms just > because of their perceived overhead. Interoperability and flexibility > are very important properties, often more important than bit-level > optimizations. > > /adam > -- > Adam Dunkels , +46707731614 > http://twitter.com/adunk | http://www.sics.se/~adam/ > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > --0016e6dab082a07da704759ee6a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Don, I certainly don't disagree with you that we need better latency= and I'm pretty sure Adam doesn't either as he said this is without= ANY optimizations. Given that fact, his statement is quite impressive.
The key here is to actually back up any ideas and opinions w= ith real results and this is what we are in the process of doing.

Right now for our=A0purposes, in the Smart Grid d= omain, we can run SIP, with some minor changes beyond stack size optimizati= ons, over networks with as little bandwidth as 80kbps and highly constraine= d devices. We also acknowledge for our use cases, latency is not really an = issue.=A0

I'm pretty convinced that with the RIGHT sort of op= timizations, any latency issues can be handled without having to dictating = general architectural standards like using REST, SNMP, SIP, etc. which can = stifle innovation and lead to building everything with a hammer.=A0

Having said that Carsten's note is encouraging and = I'm pretty convinced this committee has in mind creating a base that wi= ll evolve without=A0stifling=A0innovation and take real results and proof o= f concepts of use cases as main deciding factors. We will definitely be sub= mitting an ID for Hiroshima.

--
Shidan Gouran

On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek <d.stur= ek@att.net> wrote:
Hi Adam.
.5 seconds for one hop and 2 seconds for 4 hops are really not acceptable for many applications.

We should of course investigate using existing protocols. =A0 However it do= es
not seem likely that full HTTP and XML deployed over devices like IEEE
802.15.4 with very small packet sizes will scale very well =A0(certainly, f= or
any application expecting to do home or building controls, those latencies<= br> don't work). =A0Ideally, we should find something that allows for full<= br> HTTP/etc. while enabling constrained devices to operate with a solution tha= t
can be expanded/compressed.

Don


-----Original Message-----
From: 6lowapp= -bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Adam Dunkels
Sent: Saturday, October 10, 2009 3:08 PM
To: Shidan
Cc: 6lowapp@ietf.org<= /a>
Subject: Re: [6lowapp] HTTP and SIP

Shidan wrote:
> "request-response protocols like HTTP may require battery-operate= d,
> mostly sleeping nodes to be listening for requests much more frequentl= y
> than their application processing requirements alone would need them t= o
> wake up."
>
> "In addition, some of the applications may require optimizations = in
> terms of bandwidth usage; for example, the usual data formats (both > headers and body) are perceived to be too chatty for the 50-60 byte > payloads possible in LoWPANs. =A0Their interpretation and generation m= ay
> require too much code for the 8-bit and 16-bit processors dominating > LoWPAN nodes."
>
> None of these points seem evident to me.

I very much agree with this. By so quickly dismissing the opportunities
with existing protocols such as HTTP and SIP, this group may miss
reaching widespread adoption of its protocols.

Both these arguments were frequently used in the past against IP for
resource-constrained systems, yet today we take IP for granted for these systems despite the overheads of IP. We need to a pay price for
interoperability and flexibility, but we think it is worth it.

FWIW, we've recently been working with REST web services
(REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio
protocol (X-MAC) for Contiki. The implementation of the application
layers (REST/HTTP) has roughly a 5kb code footprint. The performance is
not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML
format is completed in roughly 0.5 seconds over a one-hop radio link and in less than 2 seconds over a four-hop radio network:

http://www.sics.se/~adam/yazar09efficient.pdf

Note that this is without any optimizations at the REST/HTTP/TCP/IP
layers. Full HTTP headers are sent from the curl client, reducing the
overall performance. Full XML is sent from the sensors. Thus there is
plenty of opportunity to improve this without moving away from the
HTTP/TCP/IP framework. For example, as we show in the above paper, there are significant savings in using conditional HTTP GETs when data have
not changed between subsequent requests.

Like Shidan, I am not saying that we necessarily must use full-fledged
REST/HTTP/TCP/IP or SIP for everything in our resource-constrained
networks. But we mustn't so quickly rule out existing mechanisms just because of their perceived overhead. Interoperability and flexibility
are very important properties, often more important than bit-level
optimizations.

/adam
--
Adam Dunkels <adam@sic= s.se>, +46707731614
http://twitter.com/a= dunk | http://w= ww.sics.se/~adam/
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp


--0016e6dab082a07da704759ee6a7-- From jhui@archrock.com Sat Oct 10 19:38:15 2009 Return-Path: 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 81DA33A6800 for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 19:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 7nlWx+9-gYUE for <6lowapp@core3.amsl.com>; Sat, 10 Oct 2009 19:38:14 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id AAEE03A67B4 for <6lowapp@ietf.org>; Sat, 10 Oct 2009 19:38:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F2BB2AF9CB; Sat, 10 Oct 2009 19:40:02 -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 py48D9sfYiTu; Sat, 10 Oct 2009 19:39:59 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-110-10.dsl.pltn13.pacbell.net [71.142.110.10]) by mail.sf.archrock.com (Postfix) with ESMTP id C4FAEAF9C1; Sat, 10 Oct 2009 19:39:58 -0700 (PDT) Message-Id: <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> From: Jonathan Hui To: Adam Dunkels In-Reply-To: <4AD105DC.3070407@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 19:39:57 -0700 References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 02:38:15 -0000 On Oct 10, 2009, at 3:08 PM, Adam Dunkels wrote: > Shidan wrote: >> "request-response protocols like HTTP may require battery-operated, >> mostly sleeping nodes to be listening for requests much more >> frequently than their application processing requirements alone >> would need them to wake up." >> "In addition, some of the applications may require optimizations in >> terms of bandwidth usage; for example, the usual data formats (both >> headers and body) are perceived to be too chatty for the 50-60 byte >> payloads possible in LoWPANs. Their interpretation and generation >> may require too much code for the 8-bit and 16-bit processors >> dominating LoWPAN nodes." >> None of these points seem evident to me. > > I very much agree with this. By so quickly dismissing the > opportunities with existing protocols such as HTTP and SIP, this > group may miss reaching widespread adoption of its protocols. I also agree that we should not be so quick to come to conclusions without presentation of real empirical evidence. > Both these arguments were frequently used in the past against IP for > resource-constrained systems, yet today we take IP for granted for > these systems despite the overheads of IP. We need to a pay price > for interoperability and flexibility, but we think it is worth it. I'd be careful carrying the interoperability argument towards the upper layers. IP was designed to be the narrow waist. Today, that has evolved to UDP and TCP being the narrow waist [1]. We have far more flexibility and opportunity at the application layer than we do with TCP/UDP/IP and we should not be afraid to exploit that. I do support the argument for evaluating existing protocols/architectures, but more because they are established, vetted, and widely understood, less so because we actually want to utilize the existing technical infrastructure that surrounds it. [1] http://tools.ietf.org/html/draft-rosenberg-internet-waist-hourglass -- Jonathan Hui From zach@sensinode.com Sun Oct 11 04:57:18 2009 Return-Path: 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 DE8223A6866 for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 04:57:18 -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 oi7DsszJ5k-u for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 04:57:18 -0700 (PDT) Received: from smtp-68.nebula.fi (smtp-68.nebula.fi [83.145.220.68]) by core3.amsl.com (Postfix) with ESMTP id EFAE93A67F8 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 04:57:17 -0700 (PDT) Received: from webmail3.nebula.fi (webmail3.nebula.fi [83.145.246.137]) by smtp-68.nebula.fi (Postfix) with ESMTP id A4D9843F0735; Sun, 11 Oct 2009 14:59:04 +0300 (EEST) MIME-Version: 1.0 Date: Sun, 11 Oct 2009 14:59:04 +0300 From: "zach@sensinode.com" To: Jonathan Hui In-Reply-To: <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> Message-ID: <84fafc9f623d81c6821e739fa1f94fcb@mailserver13.nebula.fi> X-Sender: zach@sensinode.com User-Agent: Nebula Webmail Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 11:57:19 -0000 On Sat, 10 Oct 2009 19:39:57 -0700, Jonathan Hui wrote: > I'd be careful carrying the interoperability argument towards the > upper layers. IP was designed to be the narrow waist. Today, that > has evolved to UDP and TCP being the narrow waist [1]. We have far > more flexibility and opportunity at the application layer than we do > with TCP/UDP/IP and we should not be afraid to exploit that. I do > support the argument for evaluating existing protocols/architectures, > but more because they are established, vetted, and widely understood, > less so because we actually want to utilize the existing technical > infrastructure that surrounds it. > > [1] http://tools.ietf.org/html/draft-rosenberg-internet-waist-hourglass I totally agree. - Zach > -- > Jonathan Hui > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From zach@sensinode.com Sun Oct 11 05:15:19 2009 Return-Path: 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 44A833A67D7 for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 05:15:19 -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 hP5Ozi228Rfl for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 05:15:18 -0700 (PDT) Received: from smtp-68.nebula.fi (smtp-68.nebula.fi [83.145.220.68]) by core3.amsl.com (Postfix) with ESMTP id 9CC453A67AF for <6lowapp@ietf.org>; Sun, 11 Oct 2009 05:15:17 -0700 (PDT) Received: from webmail3.nebula.fi (webmail3.nebula.fi [83.145.246.137]) by smtp-68.nebula.fi (Postfix) with ESMTP id 600C443F07BE; Sun, 11 Oct 2009 15:17:05 +0300 (EEST) MIME-Version: 1.0 Date: Sun, 11 Oct 2009 15:17:05 +0300 From: "zach@sensinode.com" To: Shidan In-Reply-To: <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> Message-ID: <51a935134ec43c777faff0894070d2a9@mailserver13.nebula.fi> X-Sender: zach@sensinode.com User-Agent: Nebula Webmail Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 12:15:19 -0000 On Sat, 10 Oct 2009 21:40:41 -0400, Shidan wrote: > I'm pretty convinced that with the RIGHT sort of optimizations, any latency > issues can be handled without having to dictating general architectural > standards like using REST, SNMP, SIP, etc. which can stifle innovation and > lead to building everything with a hammer. I think there is confusion about the word REST in the charter. This is only meant to mean that if you want to proxy with HTTP and support the design of web-services reusing existing techniques - then we need to support GET, PUT, POST, DELETE methods. Maybe it is better to remove the word REST if that implies anything more than that to people? The purpose of the application protocol work item description was exactly to say that we are not limiting ourselves to one single paradigm. Instead we need to integrate features from suitable protocols that allows us to innovate yet at the same time easily proxy into HTTP, SIP and SNMP. My view is: - For applications where full HTTP, SIP, SNMP etc. can be used - then you are lucky - and you don't necessarily need this working group. If you just need to optimize one of the above, then there are appropriate working groups for that already. - There are definitely applications, devices and networks for which current solutions are not suitable. 60 byte payloads, real problems with TCP over wireless and mobile networks and very limited bandwidth over multiple wireless hops in e.g. a LoWPAN are very real problems. The goal of 6lowapp should be to provide an application protocol totally suitable to this domain - not just a band-aid. What I would like to see is that the solution we aim at in 6lowapp is able to easily be proxied into protocols that dominate applications in energy, building automation and M2M. Today this is mainly HTTP, but we see some SIP and SNMP as well. For this reason the work item features include both features from HTTP (Req-Res, REST methods) as well as from e.g. SIP (eventing) and e.g. peer-to-peer which is key for OASIS and building automation in general. The support of URIs and content-types are common to all. > Having said that Carsten's note is encouraging and I'm pretty convinced > this > committee has in mind creating a base that will evolve > without stifling innovation and take real results and proof of concepts of > use cases as main deciding factors. We will definitely be submitting an ID > for Hiroshima. Great - and any more feedback on improving the charter text would be welcome too! Zach > -- > Shidan Gouran > > On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek wrote: > >> Hi Adam. >> .5 seconds for one hop and 2 seconds for 4 hops are really not acceptable >> for many applications. >> >> We should of course investigate using existing protocols. However it >> does >> not seem likely that full HTTP and XML deployed over devices like IEEE >> 802.15.4 with very small packet sizes will scale very well (certainly, >> for >> any application expecting to do home or building controls, those >> latencies >> don't work). Ideally, we should find something that allows for full >> HTTP/etc. while enabling constrained devices to operate with a solution >> that >> can be expanded/compressed. >> >> Don >> >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf >> Of Adam Dunkels >> Sent: Saturday, October 10, 2009 3:08 PM >> To: Shidan >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] HTTP and SIP >> >> Shidan wrote: >> > "request-response protocols like HTTP may require battery-operated, >> > mostly sleeping nodes to be listening for requests much more frequently >> > than their application processing requirements alone would need them to >> > wake up." >> > >> > "In addition, some of the applications may require optimizations in >> > terms of bandwidth usage; for example, the usual data formats (both >> > headers and body) are perceived to be too chatty for the 50-60 byte >> > payloads possible in LoWPANs. Their interpretation and generation may >> > require too much code for the 8-bit and 16-bit processors dominating >> > LoWPAN nodes." >> > >> > None of these points seem evident to me. >> >> I very much agree with this. By so quickly dismissing the opportunities >> with existing protocols such as HTTP and SIP, this group may miss >> reaching widespread adoption of its protocols. >> >> Both these arguments were frequently used in the past against IP for >> resource-constrained systems, yet today we take IP for granted for these >> systems despite the overheads of IP. We need to a pay price for >> interoperability and flexibility, but we think it is worth it. >> >> FWIW, we've recently been working with REST web services >> (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio >> protocol (X-MAC) for Contiki. The implementation of the application >> layers (REST/HTTP) has roughly a 5kb code footprint. The performance is >> not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML >> format is completed in roughly 0.5 seconds over a one-hop radio link and >> in less than 2 seconds over a four-hop radio network: >> >> http://www.sics.se/~adam/yazar09efficient.pdf >> >> Note that this is without any optimizations at the REST/HTTP/TCP/IP >> layers. Full HTTP headers are sent from the curl client, reducing the >> overall performance. Full XML is sent from the sensors. Thus there is >> plenty of opportunity to improve this without moving away from the >> HTTP/TCP/IP framework. For example, as we show in the above paper, there >> are significant savings in using conditional HTTP GETs when data have >> not changed between subsequent requests. >> >> Like Shidan, I am not saying that we necessarily must use full-fledged >> REST/HTTP/TCP/IP or SIP for everything in our resource-constrained >> networks. But we mustn't so quickly rule out existing mechanisms just >> because of their perceived overhead. Interoperability and flexibility >> are very important properties, often more important than bit-level >> optimizations. >> >> /adam >> -- >> Adam Dunkels , +46707731614 >> http://twitter.com/adunk | http://www.sics.se/~adam/ >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> From brian.tridium@gmail.com Sun Oct 11 06:28:00 2009 Return-Path: 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 CE4413A68EE for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 06:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 wUueg7cA9rrn for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 06:28:00 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id D91793A687F for <6lowapp@ietf.org>; Sun, 11 Oct 2009 06:27:59 -0700 (PDT) Received: by fxm28 with SMTP id 28so7004710fxm.42 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 06:29:45 -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=vfI+BQgHFcyQipa6Jz+uz8o4Rj/N4/7LUfo3es+NuNM=; b=vu52EHhjf74NaSE5sI5BFsOKiKYZCC2wg08RTA3wWW1XzkwVCH/ThDJF9uEcfWrxPA lyUdtvrTKAWpw3s3ba5hcMa8tMf5S3z8ypl2cFexKCXJnlF2N4JNh7XAKxxGBUr/aZMe uBhHJVJi5iT4s7yzCkKCGlbluROyAAkoc4aww= 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=LbQK9n9nV2IyWZtyG3OnbScOtSNiIx/9nTCb/6nJbQDUUjD+sE9x+zrdbnOmHoWzwR xXHUNP5OAyOsZBkN6VZE1LBWXdBM+LB8vUJkbJAkWJtFFLT5lGaJ+syDScplFUg1LN+K C6NXP4kXVY1KheMU00yFai/xkoP0EjMxZ7EUU= MIME-Version: 1.0 Received: by 10.204.26.147 with SMTP id e19mr4025796bkc.149.1255267785211; Sun, 11 Oct 2009 06:29:45 -0700 (PDT) In-Reply-To: <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> Date: Sun, 11 Oct 2009 09:29:45 -0400 Message-ID: <7b191a110910110629r6e45825cr4e69c0636ea99c16@mail.gmail.com> From: Brian Frank To: Jonathan Hui Content-Type: multipart/alternative; boundary=000325557d266f81520475a8ceab Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 13:28:00 -0000 --000325557d266f81520475a8ceab Content-Type: text/plain; charset=ISO-8859-1 > I also agree that we should not be so quick to come to conclusions without > presentation of real empirical evidence. > I agree. One of the first things we need to do is justify that a new protocol is required using real empirical data that shows TCP and text based HTTP do not work for the problem domain. For example, how does HTTP over TCP stack up against binary UDP protocols with regard to latency, bandwidth, and power consumption of battery powered sensors? --000325557d266f81520475a8ceab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also agree that we should not be so quick to come to conclu= sions without presentation of real empirical evidence.


I agree.=A0 One of the first things we need= to do is justify that a new protocol is required using real empirical data= that shows TCP and text based HTTP do not work for the problem domain.=A0 = For example, how does HTTP over TCP stack up against binary UDP protocols w= ith regard to latency, bandwidth, and power consumption of battery powered = sensors?

--000325557d266f81520475a8ceab-- From d.sturek@att.net Sun Oct 11 15:18:58 2009 Return-Path: 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 2DAB23A66B4 for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 15:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] 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 dLkxrlJF7Bvn for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 15:18:48 -0700 (PDT) Received: from smtp102.sbc.mail.gq1.yahoo.com (smtp102.sbc.mail.gq1.yahoo.com [67.195.15.61]) by core3.amsl.com (Postfix) with SMTP id 8A9123A6848 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 15:18:45 -0700 (PDT) Received: (qmail 56895 invoked from network); 11 Oct 2009 22:18:43 -0000 Received: from (d.sturek@202.130.198.3 with login) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 11 Oct 2009 15:18:43 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: i3y5ycYVM1n4ameQChpFoBcD8vkxfQYo81xTwCzKg.bMPNVAQKUXhstdF39jDGMbONbBSndhYqORlL7i7ssnQU9VY_3rOaWrxEckT.FkSACpGpKeYUGDQEeoO_36GBR5e9sdvr4J5deLNBYvSdmyS62VJbdcUHfF.wAy4nJLuoO75IUCtO6LjbZDHhmKj7CMp0goGql6GnnadQGWlWyX96ek0id3WVv3EQYVcQpW9ICTnr6bjDCxqIQ5Ghkq65mZPb2LI0EnBFpbTQZJ7T1h3m4jLB__pSO2ZRlz.Fsm4nJrOujK6g-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Shidan'" References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> In-Reply-To: <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> Date: Sun, 11 Oct 2009 15:18:35 -0700 Message-ID: <004001ca4ac0$c91e68b0$5b5b3a10$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CA4A86.1CBF90B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpKE9feu4czlODhR1C+gxR2SayxYwAq9TQQ Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 22:18:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0041_01CA4A86.1CBF90B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Shidan, One more issue: We have existing smart energy messaging using a proprietary binary protocol. We then created an XML structure for these messages then used W3C EXI to tokenize. Here is what we ended up with: Binary Protocol Message Size: 6 Bytes XML Message Size: 376 Bytes W3C EXI Tokenized XML Message Size: 12 Bytes. The issue you run into is this: If you have a data collector model where many messages are forwarded from leaf nodes up to a central node (like the ROLL DAG root for example), then you find that the nodes close to the root have dramatically lower throughput due to congestion from packet forwarding from the leaf nodes towards the popular data collector device. We have many deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turns into 9Kpbs as you forward towards the data collector. These deployments are using a binary protocol where nearly all messages fit into a single packet. Now, consider what happens where each and every message turns into MANY packet exchanges. You will quickly see this does not work.. I agree with what Zach wrote in a later note. I don't want to dissuade anyone who finds HTTP or SIP working over IEEE 802.15.4 from using it. However, I think the problem statement in 6LowAPP stands at least for the smart energy application I am familiar with. Don From: Shidan [mailto:shidan@gmail.com] Sent: Saturday, October 10, 2009 6:41 PM To: d.sturek@att.net Cc: Adam Dunkels; 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP Hi Don, I certainly don't disagree with you that we need better latency and I'm pretty sure Adam doesn't either as he said this is without ANY optimizations. Given that fact, his statement is quite impressive. The key here is to actually back up any ideas and opinions with real results and this is what we are in the process of doing. Right now for our purposes, in the Smart Grid domain, we can run SIP, with some minor changes beyond stack size optimizations, over networks with as little bandwidth as 80kbps and highly constrained devices. We also acknowledge for our use cases, latency is not really an issue. I'm pretty convinced that with the RIGHT sort of optimizations, any latency issues can be handled without having to dictating general architectural standards like using REST, SNMP, SIP, etc. which can stifle innovation and lead to building everything with a hammer. Having said that Carsten's note is encouraging and I'm pretty convinced this committee has in mind creating a base that will evolve without stifling innovation and take real results and proof of concepts of use cases as main deciding factors. We will definitely be submitting an ID for Hiroshima. -- Shidan Gouran On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek wrote: Hi Adam. .5 seconds for one hop and 2 seconds for 4 hops are really not acceptable for many applications. We should of course investigate using existing protocols. However it does not seem likely that full HTTP and XML deployed over devices like IEEE 802.15.4 with very small packet sizes will scale very well (certainly, for any application expecting to do home or building controls, those latencies don't work). Ideally, we should find something that allows for full HTTP/etc. while enabling constrained devices to operate with a solution that can be expanded/compressed. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Adam Dunkels Sent: Saturday, October 10, 2009 3:08 PM To: Shidan Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP Shidan wrote: > "request-response protocols like HTTP may require battery-operated, > mostly sleeping nodes to be listening for requests much more frequently > than their application processing requirements alone would need them to > wake up." > > "In addition, some of the applications may require optimizations in > terms of bandwidth usage; for example, the usual data formats (both > headers and body) are perceived to be too chatty for the 50-60 byte > payloads possible in LoWPANs. Their interpretation and generation may > require too much code for the 8-bit and 16-bit processors dominating > LoWPAN nodes." > > None of these points seem evident to me. I very much agree with this. By so quickly dismissing the opportunities with existing protocols such as HTTP and SIP, this group may miss reaching widespread adoption of its protocols. Both these arguments were frequently used in the past against IP for resource-constrained systems, yet today we take IP for granted for these systems despite the overheads of IP. We need to a pay price for interoperability and flexibility, but we think it is worth it. FWIW, we've recently been working with REST web services (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio protocol (X-MAC) for Contiki. The implementation of the application layers (REST/HTTP) has roughly a 5kb code footprint. The performance is not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML format is completed in roughly 0.5 seconds over a one-hop radio link and in less than 2 seconds over a four-hop radio network: http://www.sics.se/~adam/yazar09efficient.pdf Note that this is without any optimizations at the REST/HTTP/TCP/IP layers. Full HTTP headers are sent from the curl client, reducing the overall performance. Full XML is sent from the sensors. Thus there is plenty of opportunity to improve this without moving away from the HTTP/TCP/IP framework. For example, as we show in the above paper, there are significant savings in using conditional HTTP GETs when data have not changed between subsequent requests. Like Shidan, I am not saying that we necessarily must use full-fledged REST/HTTP/TCP/IP or SIP for everything in our resource-constrained networks. But we mustn't so quickly rule out existing mechanisms just because of their perceived overhead. Interoperability and flexibility are very important properties, often more important than bit-level optimizations. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp ------=_NextPart_000_0041_01CA4A86.1CBF90B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shidan,

 

One more issue:     We have existing = smart energy messaging using a proprietary binary protocol.  We then = created an XML structure for these messages then used W3C EXI to tokenize.  = Here is what we ended up with:

Binary Protocol Message Size:    6 = Bytes

XML Message Size:  376 Bytes

W3C EXI Tokenized XML Message Size:  12 = Bytes.

 

The issue you run into is this:  If you have a data collector model where many messages are forwarded from leaf nodes up to = a central node (like the ROLL DAG root for example), then you find that the nodes = close to the root have dramatically lower throughput due to congestion from = packet forwarding from the leaf nodes towards the popular data collector = device.  We have many deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turns into 9Kpbs as you forward towards the data = collector.  These deployments are using a binary protocol where nearly all messages fit = into a single packet.  Now, consider what happens where each and every = message turns into MANY packet exchanges.  You will quickly see this does = not work……

 

I agree with what Zach wrote in a later = note.    I don’t want to dissuade anyone who finds HTTP or SIP working over = IEEE 802.15.4 from using it.  However, I think the problem statement in = 6LowAPP stands at least for the smart energy application I am familiar = with.

 

Don

 

 

From:= Shidan [mailto:shidan@gmail.com]
Sent: Saturday, October 10, 2009 6:41 PM
To: d.sturek@att.net
Cc: Adam Dunkels; 6lowapp@ietf.org
Subject: Re: [6lowapp] HTTP and SIP

 

Hi Don, I certainly don't disagree with you that we = need better latency and I'm pretty sure Adam doesn't either as he said this = is without ANY optimizations. Given that fact, his statement is quite = impressive.

 

The key here is to actually back up any ideas and = opinions with real results and this is what we are in the process of = doing.

 

Right now for our purposes, in the Smart Grid = domain, we can run SIP, with some minor changes beyond stack size optimizations, = over networks with as little bandwidth as 80kbps and highly constrained = devices. We also acknowledge for our use cases, latency is not really an = issue. 

 

I'm pretty convinced that with the RIGHT sort of optimizations, any latency issues can be handled without having to = dictating general architectural standards like using REST, SNMP, SIP, etc. which = can stifle innovation and lead to building everything with a = hammer. 

 

Having said that Carsten's note is encouraging and = I'm pretty convinced this committee has in mind creating a base that will = evolve without stifling innovation and take real results and proof of concepts of use cases as main deciding factors. We will definitely be submitting an ID for Hiroshima.

 

--

Shidan Gouran

 

On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek <d.sturek@att.net> wrote:

Hi Adam.
.5 seconds for one hop and 2 seconds for 4 hops are really not = acceptable
for many applications.

We should of course investigate using existing protocols.   However = it does
not seem likely that full HTTP and XML deployed over devices like = IEEE
802.15.4 with very small packet sizes will scale very well =  (certainly, for
any application expecting to do home or building controls, those = latencies
don't work).  Ideally, we should find something that allows for = full
HTTP/etc. while enabling constrained devices to operate with a solution = that
can be expanded/compressed.

Don



-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Adam Dunkels
Sent: Saturday, October 10, 2009 3:08 PM
To: Shidan
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] HTTP and SIP

Shidan wrote:
> "request-response protocols like HTTP may require = battery-operated,
> mostly sleeping nodes to be listening for requests much more = frequently
> than their application processing requirements alone would need = them to
> wake up."
>
> "In addition, some of the applications may require = optimizations in
> terms of bandwidth usage; for example, the usual data formats = (both
> headers and body) are perceived to be too chatty for the 50-60 = byte
> payloads possible in LoWPANs.  Their interpretation and = generation may
> require too much code for the 8-bit and 16-bit processors = dominating
> LoWPAN nodes."
>
> None of these points seem evident to me.

I very much agree with this. By so quickly dismissing the = opportunities
with existing protocols such as HTTP and SIP, this group may miss
reaching widespread adoption of its protocols.

Both these arguments were frequently used in the past against IP for
resource-constrained systems, yet today we take IP for granted for = these
systems despite the overheads of IP. We need to a pay price for
interoperability and flexibility, but we think it is worth it.

FWIW, we've recently been working with REST web services
(REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio
protocol (X-MAC) for Contiki. The implementation of the application
layers (REST/HTTP) has roughly a 5kb code footprint. The performance = is
not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML
format is completed in roughly 0.5 seconds over a one-hop radio link = and
in less than 2 seconds over a four-hop radio network:

http://www.sics.se/~adam/yazar09efficient.pdf

Note that this is without any optimizations at the REST/HTTP/TCP/IP
layers. Full HTTP headers are sent from the curl client, reducing = the
overall performance. Full XML is sent from the sensors. Thus there = is
plenty of opportunity to improve this without moving away from the
HTTP/TCP/IP framework. For example, as we show in the above paper, = there
are significant savings in using conditional HTTP GETs when data = have
not changed between subsequent requests.

Like Shidan, I am not saying that we necessarily must use = full-fledged
REST/HTTP/TCP/IP or SIP for everything in our resource-constrained
networks. But we mustn't so quickly rule out existing mechanisms = just
because of their perceived overhead. Interoperability and = flexibility
are very important properties, often more important than bit-level
optimizations.

/adam
--
Adam Dunkels <adam@sics.se>, +46707731614
http://twitter.com/adunk | http://www.sics.se/~adam/

__________________________________________= _____
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<= /o:p>

 

------=_NextPart_000_0041_01CA4A86.1CBF90B0-- From shidan@gmail.com Sun Oct 11 16:18:55 2009 Return-Path: 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 3A1A43A67EB for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 16:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 roGvoWJ40ukB for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 16:18:53 -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 51C8B3A67A8 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 16:18:51 -0700 (PDT) Received: by ewy4 with SMTP id 4so2071306ewy.37 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 16:18:49 -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=kOVJLJBKDJ3f+r/bTaipMGyD8/1I6Z1A5KDF25jqjrY=; b=qIm0mXePOtgfEDM6viyFufBsmrRfFbJzo1AlsJDz9Nj3IvGPvZb1ZKtA44KxVX0XS0 pH7A9j+NVE2SAKR6LYpwmAS7mFh/9qP3Yne1sv4KlDlePaK+UiVADIlD/Km0onUtXT3A u5tcKmVIcZYlQL9lciCehFvcFuZrhXNBXaxLc= 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=TfYI+04Gvb9Zfv4VmNle52sSP3w/mEN9GE7gtvQrDBaVvmQCYCswF+0XoFn8cedDaf oYXkF4iNXK5zXlDL8etWaJfrBfxPCqCHvOuxcY8mEtf116Mj62hUB/R6wrQPhvc1dh8P QQbsbAelKOTdBcrazSbk4wosiUuRYoyd244MU= MIME-Version: 1.0 Received: by 10.216.87.131 with SMTP id y3mr1668160wee.9.1255303129303; Sun, 11 Oct 2009 16:18:49 -0700 (PDT) In-Reply-To: <438002485272261273@unknownmsgid> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> <438002485272261273@unknownmsgid> Date: Sun, 11 Oct 2009 19:18:49 -0400 Message-ID: <429b380e0910111618v44d98962gbb2e43906426c79c@mail.gmail.com> From: Shidan To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0016e6d77e5e1b894f0475b10999 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 23:18:55 -0000 --0016e6d77e5e1b894f0475b10999 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for this detailed explanation Don and your figures with regards to XML is very sound here. However for the purposes of the project I'm involved with, we've looked at the other side of the meter and the sessions we are defining with SIP are C12.19 sessions and very simple SIP messaging. The great thing is we can meld the control of meters with advanced communications infrastructure and take "unified communications", the concept of device mobility, security and accountability to another level. One of our partner companies has written a= n informative whitepaper on this architecture and if we get their permission we will send a link to the list if you are interested. Now going back to the home, and this is just my personal opinion, I don't believe standards like ZigBee are the right choice because they do indeed lock one to a particular layer 2 technology. However, I think they've done some great work on the application side and the application objects, profiles and such they have defined would take care of the issue you had without having to necessarily modify SIP or HTTP. Again, I'm not saying that a need for a whole new application protocol is warranted or not warranted as a fact, I'm just saying this is not evident t= o me and isn't a trivial assumption or something that can be reasoned without empirical evidence and considering some clear use cases. Lets change/modify what really needs to be changed based on the empirical evidence. Also unrelated, In response to Zach's note, we will be more than happy to lend a hand in helping define a standard that can map cleanly to SIP which might be useful for interfacing with even other applications such as XMPP which some leading demand reponse companies like Enernoc are using on the industrial side already. I will be engaging people in our group early next week and I'm sure they will be interested in working on this as well. On Sun, Oct 11, 2009 at 6:18 PM, Don Sturek wrote: > Hi Shidan, > > > > One more issue: We have existing smart energy messaging using a > proprietary binary protocol. We then created an XML structure for these > messages then used W3C EXI to tokenize. Here is what we ended up with: > > Binary Protocol Message Size: 6 Bytes > > XML Message Size: 376 Bytes > > W3C EXI Tokenized XML Message Size: 12 Bytes. > > > > The issue you run into is this: If you have a data collector model where > many messages are forwarded from leaf nodes up to a central node (like th= e > ROLL DAG root for example), then you find that the nodes close to the roo= t > have dramatically lower throughput due to congestion from packet forwardi= ng > from the leaf nodes towards the popular data collector device. We have m= any > deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turns > into 9Kpbs as you forward towards the data collector. These deployments = are > using a binary protocol where nearly all messages fit into a single packe= t. > Now, consider what happens where each and every message turns into MANY > packet exchanges. You will quickly see this does not work=85=85 > > > > I agree with what Zach wrote in a later note. I don=92t want to dissua= de > anyone who finds HTTP or SIP working over IEEE 802.15.4 from using it. > However, I think the problem statement in 6LowAPP stands at least for the > smart energy application I am familiar with. > > > > Don > > > > > > *From:* Shidan [mailto:shidan@gmail.com] > *Sent:* Saturday, October 10, 2009 6:41 PM > *To:* d.sturek@att.net > *Cc:* Adam Dunkels; 6lowapp@ietf.org > > *Subject:* Re: [6lowapp] HTTP and SIP > > > > Hi Don, I certainly don't disagree with you that we need better latency a= nd > I'm pretty sure Adam doesn't either as he said this is without ANY > optimizations. Given that fact, his statement is quite impressive. > > > > The key here is to actually back up any ideas and opinions with real > results and this is what we are in the process of doing. > > > > Right now for our purposes, in the Smart Grid domain, we can run SIP, wit= h > some minor changes beyond stack size optimizations, over networks with as > little bandwidth as 80kbps and highly constrained devices. We also > acknowledge for our use cases, latency is not really an issue. > > > > I'm pretty convinced that with the RIGHT sort of optimizations, any laten= cy > issues can be handled without having to dictating general architectural > standards like using REST, SNMP, SIP, etc. which can stifle innovation an= d > lead to building everything with a hammer. > > > > Having said that Carsten's note is encouraging and I'm pretty convinced > this committee has in mind creating a base that will evolve > without stifling innovation and take real results and proof of concepts o= f > use cases as main deciding factors. We will definitely be submitting an I= D > for Hiroshima. > > > > -- > > Shidan Gouran > > > > On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek wrote: > > Hi Adam. > .5 seconds for one hop and 2 seconds for 4 hops are really not acceptable > for many applications. > > We should of course investigate using existing protocols. However it do= es > not seem likely that full HTTP and XML deployed over devices like IEEE > 802.15.4 with very small packet sizes will scale very well (certainly, f= or > any application expecting to do home or building controls, those latencie= s > don't work). Ideally, we should find something that allows for full > HTTP/etc. while enabling constrained devices to operate with a solution > that > can be expanded/compressed. > > Don > > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behal= f > Of Adam Dunkels > Sent: Saturday, October 10, 2009 3:08 PM > To: Shidan > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] HTTP and SIP > > Shidan wrote: > > "request-response protocols like HTTP may require battery-operated, > > mostly sleeping nodes to be listening for requests much more frequently > > than their application processing requirements alone would need them to > > wake up." > > > > "In addition, some of the applications may require optimizations in > > terms of bandwidth usage; for example, the usual data formats (both > > headers and body) are perceived to be too chatty for the 50-60 byte > > payloads possible in LoWPANs. Their interpretation and generation may > > require too much code for the 8-bit and 16-bit processors dominating > > LoWPAN nodes." > > > > None of these points seem evident to me. > > I very much agree with this. By so quickly dismissing the opportunities > with existing protocols such as HTTP and SIP, this group may miss > reaching widespread adoption of its protocols. > > Both these arguments were frequently used in the past against IP for > resource-constrained systems, yet today we take IP for granted for these > systems despite the overheads of IP. We need to a pay price for > interoperability and flexibility, but we think it is worth it. > > FWIW, we've recently been working with REST web services > (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio > protocol (X-MAC) for Contiki. The implementation of the application > layers (REST/HTTP) has roughly a 5kb code footprint. The performance is > not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML > format is completed in roughly 0.5 seconds over a one-hop radio link and > in less than 2 seconds over a four-hop radio network: > > http://www.sics.se/~adam/yazar09efficient.pdf > > Note that this is without any optimizations at the REST/HTTP/TCP/IP > layers. Full HTTP headers are sent from the curl client, reducing the > overall performance. Full XML is sent from the sensors. Thus there is > plenty of opportunity to improve this without moving away from the > HTTP/TCP/IP framework. For example, as we show in the above paper, there > are significant savings in using conditional HTTP GETs when data have > not changed between subsequent requests. > > Like Shidan, I am not saying that we necessarily must use full-fledged > REST/HTTP/TCP/IP or SIP for everything in our resource-constrained > networks. But we mustn't so quickly rule out existing mechanisms just > because of their perceived overhead. Interoperability and flexibility > are very important properties, often more important than bit-level > optimizations. > > /adam > -- > Adam Dunkels , +46707731614 > http://twitter.com/adunk | http://www.sics.se/~adam/ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > > --0016e6d77e5e1b894f0475b10999 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for this detailed explanation Don and your figures with regards to X= ML is very sound here.

However for the purposes of the p= roject I'm involved with, we've looked at the other side of the met= er and the sessions we are defining with SIP are C12.19 sessions and very s= imple SIP messaging. The great thing is we can meld the control of meters w= ith advanced communications infrastructure and take "unified communica= tions", the concept of device mobility, security and accountability to= another level. One of our partner companies has written an informative whi= tepaper on this architecture and if we get their permission we will send a = link to the list if you are interested.

Now going back to the home, and this is just my personal opi= nion, I don't believe standards like ZigBee are the right choice becaus= e they do indeed lock one to a particular layer 2 technology. However, I th= ink they've done some great work on the application side and the applic= ation objects, profiles and such they have defined would take care of the i= ssue you had without having to necessarily modify SIP or HTTP.

Again, I'm not saying that a need for a whole new a= pplication protocol is warranted or not=A0warranted=A0as a fact, I'm ju= st saying this is not evident to me and isn't a trivial assumption or s= omething that can be reasoned without empirical evidence and considering so= me clear use cases. Lets change/modify what really needs to be changed base= d on the empirical evidence.

Also unrelated, In response to Zach's note, we will= be more than happy to lend a hand in helping define a standard that can ma= p cleanly to SIP which might be useful for interfacing with even other appl= ications such as XMPP which some leading demand reponse companies like Ener= noc are using on the industrial side already. I will be engaging people in = our group early next week and I'm sure they will be interested in worki= ng on this as well.


On Sun, Oct 11, 2009 at 6:18 PM, Don Stu= rek <d.sturek@att.net> wrote:

Hi Sh= idan,

=A0

One m= ore issue:=A0=A0=A0=A0 We have existing smart energy messaging using a proprietary binary protocol.=A0 We then created an XML structure for these messages then used W3C EXI to tokenize.=A0 Here is = what we ended up with:

Binar= y Protocol Message Size:=A0=A0=A0 6 Bytes

XML M= essage Size:=A0 376 Bytes

W3C E= XI Tokenized XML Message Size:=A0 12 Bytes.

=A0

The i= ssue you run into is this:=A0 If you have a data collector model where many messages are forwarded from leaf nodes up to a c= entral node (like the ROLL DAG root for example), then you find that the nodes clo= se to the root have dramatically lower throughput due to congestion from packe= t forwarding from the leaf nodes towards the popular data collector device.= =A0 We have many deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turns into 9Kpbs as you forward towards the data collector.=A0 Thes= e deployments are using a binary protocol where nearly all messages fit into = a single packet.=A0 Now, consider what happens where each and every message turns into MANY packet exchanges.=A0 You will quickly see this does not wor= k=85=85

=A0

I agr= ee with what Zach wrote in a later note.=A0=A0=A0 I don=92t want to dissuade anyone who finds HTTP or SIP working over IEEE 802.15.4 from using it.=A0 However, I think the problem statement in 6LowAP= P stands at least for the smart energy application I am familiar with.=

=A0

Don

=A0

=A0

From:= Shidan [mailto:shidan@gmail.= com]
Sent: Saturday, October 10, 2009 6:41 PM
To: d.sturek@a= tt.net
Cc: Adam Dunkels; 6lowapp@ietf.org


Subject: Re: [6lowapp] HTTP and SIP

=A0

Hi Don, I certainly don't disagree with you that= we need better latency and I'm pretty sure Adam doesn't either as he said t= his is without ANY optimizations. Given that fact, his statement is quite impressi= ve.

=A0

The key here is to actually back up any ideas and op= inions with real results and this is what we are in the process of doing.

=A0

Right now for our=A0purposes, in the Smart Grid doma= in, we can run SIP, with some minor changes beyond stack size optimizations, ov= er networks with as little bandwidth as 80kbps and highly constrained devices.= We also acknowledge for our use cases, latency is not really an issue.=A0

=A0

I'm pretty convinced that with the RIGHT sort of optimizations, any latency issues can be handled without having to dictatin= g general architectural standards like using REST, SNMP, SIP, etc. which can stifle innovation and lead to building everything with a hammer.=A0

=A0

Having said that Carsten's note is encouraging a= nd I'm pretty convinced this committee has in mind creating a base that will evolv= e without=A0stifling=A0innovation and take real results and proof of concepts of use cases as main deciding factors. We will definitely be submitting an ID for Hiroshima.

=A0

--

Shidan Gouran

=A0

On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek <d.sturek@att.net> = wrote:

Hi Adam.
.5 seconds for one hop and 2 seconds for 4 hops are really not acceptable for many applications.

We should of course investigate using existing protocols. =A0 However it does
not seem likely that full HTTP and XML deployed over devices like IEEE
802.15.4 with very small packet sizes will scale very well =A0(certainly, for
any application expecting to do home or building controls, those latencies<= br> don't work). =A0Ideally, we should find something that allows for full<= br> HTTP/etc. while enabling constrained devices to operate with a solution tha= t
can be expanded/compressed.

Don



-----Original Message-----
From: 6lowapp= -bounces@ietf.org [mailto:6lowa= pp-bounces@ietf.org] On Behalf
Of Adam Dunkels
Sent: Saturday, October 10, 2009 3:08 PM
To: Shidan
Cc: 6lowapp@ietf.org<= /a>
Subject: Re: [6lowapp] HTTP and SIP

Shidan wrote:
> "request-response protocols like HTTP may require battery-operate= d,
> mostly sleeping nodes to be listening for requests much more frequentl= y
> than their application processing requirements alone would need them t= o
> wake up."
>
> "In addition, some of the applications may require optimizations = in
> terms of bandwidth usage; for example, the usual data formats (both > headers and body) are perceived to be too chatty for the 50-60 byte > payloads possible in LoWPANs. =A0Their interpretation and generation may
> require too much code for the 8-bit and 16-bit processors dominating > LoWPAN nodes."
>
> None of these points seem evident to me.

I very much agree with this. By so quickly dismissing the opportunities
with existing protocols such as HTTP and SIP, this group may miss
reaching widespread adoption of its protocols.

Both these arguments were frequently used in the past against IP for
resource-constrained systems, yet today we take IP for granted for these systems despite the overheads of IP. We need to a pay price for
interoperability and flexibility, but we think it is worth it.

FWIW, we've recently been working with REST web services
(REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio
protocol (X-MAC) for Contiki. The implementation of the application
layers (REST/HTTP) has roughly a 5kb code footprint. The performance is
not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML
format is completed in roughly 0.5 seconds over a one-hop radio link and in less than 2 seconds over a four-hop radio network:

http://www.sics.se/~adam/yazar09efficient.pdf

Note that this is without any optimizations at the REST/HTTP/TCP/IP
layers. Full HTTP headers are sent from the curl client, reducing the
overall performance. Full XML is sent from the sensors. Thus there is
plenty of opportunity to improve this without moving away from the
HTTP/TCP/IP framework. For example, as we show in the above paper, there are significant savings in using conditional HTTP GETs when data have
not changed between subsequent requests.

Like Shidan, I am not saying that we necessarily must use full-fledged
REST/HTTP/TCP/IP or SIP for everything in our resource-constrained
networks. But we mustn't so quickly rule out existing mechanisms just because of their perceived overhead. Interoperability and flexibility
are very important properties, often more important than bit-level
optimizations.

/adam
--
Adam Dunkels <adam@sic= s.se>, +46707731614
http://twitter.com/a= dunk | http://www.sics.s= e/~adam/

_____________________= __________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

=A0


--0016e6d77e5e1b894f0475b10999-- From shidan@gmail.com Sun Oct 11 17:58:55 2009 Return-Path: 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 4E8B23A67ED for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 17:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GbHB7l6IYMs9 for <6lowapp@core3.amsl.com>; Sun, 11 Oct 2009 17:58:53 -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 A3C463A67D2 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 17:58:52 -0700 (PDT) Received: by ewy4 with SMTP id 4so2102248ewy.37 for <6lowapp@ietf.org>; Sun, 11 Oct 2009 17:58:48 -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=9LP4r/659Dj2lZC9ZwaUDQXVTNhwv5HRrfjYKuazSGk=; b=d1fhnBLequmekaIUPefsGrGWUukoXqkbjnzsrFJ+aGps7oSqFFiXr3b5BPdJ4q4okN AgrvhTupQUjBaR/l8++MHkhu/j0jOymwzdcraY4N4eccFmE0+t7UPJHdr37LojN3lus3 /Bktkex2C3KgU/sL26eIAICroXFvMzlYOCWW4= 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=e2uMz7EAVtNGwdIPVAuLEu3xvi1RJElSTnO7DcYukxyQe2qTBVbQtGTptrcEJSrp/I FC5F0zqhi6KXuJVT2L62iu9j76gDxalLsx6X2dcmuCzcx7gF/3+tGwVj3Ml5GE1iqbT8 4WwCP8RB/jwyUSpjz22bFgMrMPmBIrodKUwCQ= MIME-Version: 1.0 Received: by 10.216.88.146 with SMTP id a18mr1749254wef.56.1255309128077; Sun, 11 Oct 2009 17:58:48 -0700 (PDT) In-Reply-To: <429b380e0910111618v44d98962gbb2e43906426c79c@mail.gmail.com> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> <438002485272261273@unknownmsgid> <429b380e0910111618v44d98962gbb2e43906426c79c@mail.gmail.com> Date: Sun, 11 Oct 2009 20:58:47 -0400 Message-ID: <429b380e0910111758s40058652xca04f348160d789e@mail.gmail.com> From: Shidan To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0016e6d99c4ba991fb0475b26e3c Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 00:58:55 -0000 --0016e6d99c4ba991fb0475b26e3c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable And just to be specific, when I'm talking about ZigBee, I'm referring in specific to their defined data models and representations, not the whole application architecture. On Sun, Oct 11, 2009 at 7:18 PM, Shidan wrote: > Thanks for this detailed explanation Don and your figures with regards to > XML is very sound here. > However for the purposes of the project I'm involved with, we've looked a= t > the other side of the meter and the sessions we are defining with SIP are > C12.19 sessions and very simple SIP messaging. The great thing is we can > meld the control of meters with advanced communications infrastructure an= d > take "unified communications", the concept of device mobility, security a= nd > accountability to another level. One of our partner companies has written= an > informative whitepaper on this architecture and if we get their permissio= n > we will send a link to the list if you are interested. > > Now going back to the home, and this is just my personal opinion, I don't > believe standards like ZigBee are the right choice because they do indeed > lock one to a particular layer 2 technology. However, I think they've don= e > some great work on the application side and the application objects, > profiles and such they have defined would take care of the issue you had > without having to necessarily modify SIP or HTTP. > > Again, I'm not saying that a need for a whole new application protocol is > warranted or not warranted as a fact, I'm just saying this is not evident= to > me and isn't a trivial assumption or something that can be reasoned witho= ut > empirical evidence and considering some clear use cases. Lets change/modi= fy > what really needs to be changed based on the empirical evidence. > > Also unrelated, In response to Zach's note, we will be more than happy to > lend a hand in helping define a standard that can map cleanly to SIP whic= h > might be useful for interfacing with even other applications such as XMPP > which some leading demand reponse companies like Enernoc are using on the > industrial side already. I will be engaging people in our group early nex= t > week and I'm sure they will be interested in working on this as well. > > > On Sun, Oct 11, 2009 at 6:18 PM, Don Sturek wrote: > >> Hi Shidan, >> >> >> >> One more issue: We have existing smart energy messaging using a >> proprietary binary protocol. We then created an XML structure for these >> messages then used W3C EXI to tokenize. Here is what we ended up with: >> >> Binary Protocol Message Size: 6 Bytes >> >> XML Message Size: 376 Bytes >> >> W3C EXI Tokenized XML Message Size: 12 Bytes. >> >> >> >> The issue you run into is this: If you have a data collector model wher= e >> many messages are forwarded from leaf nodes up to a central node (like t= he >> ROLL DAG root for example), then you find that the nodes close to the ro= ot >> have dramatically lower throughput due to congestion from packet forward= ing >> from the leaf nodes towards the popular data collector device. We have = many >> deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turn= s >> into 9Kpbs as you forward towards the data collector. These deployments= are >> using a binary protocol where nearly all messages fit into a single pack= et. >> Now, consider what happens where each and every message turns into MANY >> packet exchanges. You will quickly see this does not work=85=85 >> >> >> >> I agree with what Zach wrote in a later note. I don=92t want to dissu= ade >> anyone who finds HTTP or SIP working over IEEE 802.15.4 from using it. >> However, I think the problem statement in 6LowAPP stands at least for th= e >> smart energy application I am familiar with. >> >> >> >> Don >> >> >> >> >> >> *From:* Shidan [mailto:shidan@gmail.com] >> *Sent:* Saturday, October 10, 2009 6:41 PM >> *To:* d.sturek@att.net >> *Cc:* Adam Dunkels; 6lowapp@ietf.org >> >> *Subject:* Re: [6lowapp] HTTP and SIP >> >> >> >> Hi Don, I certainly don't disagree with you that we need better latency >> and I'm pretty sure Adam doesn't either as he said this is without ANY >> optimizations. Given that fact, his statement is quite impressive. >> >> >> >> The key here is to actually back up any ideas and opinions with real >> results and this is what we are in the process of doing. >> >> >> >> Right now for our purposes, in the Smart Grid domain, we can run SIP, wi= th >> some minor changes beyond stack size optimizations, over networks with a= s >> little bandwidth as 80kbps and highly constrained devices. We also >> acknowledge for our use cases, latency is not really an issue. >> >> >> >> I'm pretty convinced that with the RIGHT sort of optimizations, any >> latency issues can be handled without having to dictating general >> architectural standards like using REST, SNMP, SIP, etc. which can stifl= e >> innovation and lead to building everything with a hammer. >> >> >> >> Having said that Carsten's note is encouraging and I'm pretty convinced >> this committee has in mind creating a base that will evolve >> without stifling innovation and take real results and proof of concepts = of >> use cases as main deciding factors. We will definitely be submitting an = ID >> for Hiroshima. >> >> >> >> -- >> >> Shidan Gouran >> >> >> >> On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek wrote: >> >> Hi Adam. >> .5 seconds for one hop and 2 seconds for 4 hops are really not acceptabl= e >> for many applications. >> >> We should of course investigate using existing protocols. However it >> does >> not seem likely that full HTTP and XML deployed over devices like IEEE >> 802.15.4 with very small packet sizes will scale very well (certainly, >> for >> any application expecting to do home or building controls, those latenci= es >> don't work). Ideally, we should find something that allows for full >> HTTP/etc. while enabling constrained devices to operate with a solution >> that >> can be expanded/compressed. >> >> Don >> >> >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf >> Of Adam Dunkels >> Sent: Saturday, October 10, 2009 3:08 PM >> To: Shidan >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] HTTP and SIP >> >> Shidan wrote: >> > "request-response protocols like HTTP may require battery-operated, >> > mostly sleeping nodes to be listening for requests much more frequentl= y >> > than their application processing requirements alone would need them t= o >> > wake up." >> > >> > "In addition, some of the applications may require optimizations in >> > terms of bandwidth usage; for example, the usual data formats (both >> > headers and body) are perceived to be too chatty for the 50-60 byte >> > payloads possible in LoWPANs. Their interpretation and generation may >> > require too much code for the 8-bit and 16-bit processors dominating >> > LoWPAN nodes." >> > >> > None of these points seem evident to me. >> >> I very much agree with this. By so quickly dismissing the opportunities >> with existing protocols such as HTTP and SIP, this group may miss >> reaching widespread adoption of its protocols. >> >> Both these arguments were frequently used in the past against IP for >> resource-constrained systems, yet today we take IP for granted for these >> systems despite the overheads of IP. We need to a pay price for >> interoperability and flexibility, but we think it is worth it. >> >> FWIW, we've recently been working with REST web services >> (REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio >> protocol (X-MAC) for Contiki. The implementation of the application >> layers (REST/HTTP) has roughly a 5kb code footprint. The performance is >> not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML >> format is completed in roughly 0.5 seconds over a one-hop radio link and >> in less than 2 seconds over a four-hop radio network: >> >> http://www.sics.se/~adam/yazar09efficient.pdf >> >> Note that this is without any optimizations at the REST/HTTP/TCP/IP >> layers. Full HTTP headers are sent from the curl client, reducing the >> overall performance. Full XML is sent from the sensors. Thus there is >> plenty of opportunity to improve this without moving away from the >> HTTP/TCP/IP framework. For example, as we show in the above paper, there >> are significant savings in using conditional HTTP GETs when data have >> not changed between subsequent requests. >> >> Like Shidan, I am not saying that we necessarily must use full-fledged >> REST/HTTP/TCP/IP or SIP for everything in our resource-constrained >> networks. But we mustn't so quickly rule out existing mechanisms just >> because of their perceived overhead. Interoperability and flexibility >> are very important properties, often more important than bit-level >> optimizations. >> >> /adam >> -- >> Adam Dunkels , +46707731614 >> http://twitter.com/adunk | http://www.sics.se/~adam/ >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> >> > > --0016e6d99c4ba991fb0475b26e3c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable And just to be specific, when I'm talking about ZigBee, I'm referri= ng in specific to their defined data models and representations, not the wh= ole application architecture.

On Sun, Oct= 11, 2009 at 7:18 PM, Shidan <shidan@gmail.com> wrote:
Thanks for this detailed explanation Don an= d your figures with regards to XML is very sound here.

H= owever for the purposes of the project I'm involved with, we've loo= ked at the other side of the meter and the sessions we are defining with SI= P are C12.19 sessions and very simple SIP messaging. The great thing is we = can meld the control of meters with advanced communications infrastructure = and take "unified communications", the concept of device mobility= , security and accountability to another level. One of our partner companie= s has written an informative whitepaper on this architecture and if we get = their permission we will send a link to the list if you are interested.

Now going back to the home, and this is just my personal opi= nion, I don't believe standards like ZigBee are the right choice becaus= e they do indeed lock one to a particular layer 2 technology. However, I th= ink they've done some great work on the application side and the applic= ation objects, profiles and such they have defined would take care of the i= ssue you had without having to necessarily modify SIP or HTTP.

Again, I'm not saying that a need for a whole new a= pplication protocol is warranted or not=A0warranted=A0as a fact, I'm ju= st saying this is not evident to me and isn't a trivial assumption or s= omething that can be reasoned without empirical evidence and considering so= me clear use cases. Lets change/modify what really needs to be changed base= d on the empirical evidence.

Also unrelated, In response to Zach's note, we will= be more than happy to lend a hand in helping define a standard that can ma= p cleanly to SIP which might be useful for interfacing with even other appl= ications such as XMPP which some leading demand reponse companies like Ener= noc are using on the industrial side already. I will be engaging people in = our group early next week and I'm sure they will be interested in worki= ng on this as well.


On Sun, Oct 11, 2009 at 6:18 PM, Don Stu= rek <d.sturek@att.net> wrote:

Hi Sh= idan,

=A0

One m= ore issue:=A0=A0=A0=A0 We have existing smart energy messaging using a proprietary binary protocol.=A0 We then created an XML structure for these messages then used W3C EXI to tokenize.=A0 Here is = what we ended up with:

Binar= y Protocol Message Size:=A0=A0=A0 6 Bytes

XML M= essage Size:=A0 376 Bytes

W3C E= XI Tokenized XML Message Size:=A0 12 Bytes.

=A0

The i= ssue you run into is this:=A0 If you have a data collector model where many messages are forwarded from leaf nodes up to a c= entral node (like the ROLL DAG root for example), then you find that the nodes clo= se to the root have dramatically lower throughput due to congestion from packe= t forwarding from the leaf nodes towards the popular data collector device.= =A0 We have many deployments where the IEEE 802.15.4 effective throughput of 140Kpbs turns into 9Kpbs as you forward towards the data collector.=A0 Thes= e deployments are using a binary protocol where nearly all messages fit into = a single packet.=A0 Now, consider what happens where each and every message turns into MANY packet exchanges.=A0 You will quickly see this does not wor= k=85=85

=A0

I agr= ee with what Zach wrote in a later note.=A0=A0=A0 I don=92t want to dissuade anyone who finds HTTP or SIP working over IEEE 802.15.4 from using it.=A0 However, I think the problem statement in 6LowAP= P stands at least for the smart energy application I am familiar with.=

=A0

Don

=A0

=A0

From:= Shidan [mailto:shidan@gmail.= com]
Sent: Saturday, October 10, 2009 6:41 PM
To: d.sturek@a= tt.net
Cc: Adam Dunkels; 6lowapp@ietf.org


Subject: Re: [6lowapp] HTTP and SIP

=A0

Hi Don, I certainly don't disagree with you that= we need better latency and I'm pretty sure Adam doesn't either as he said t= his is without ANY optimizations. Given that fact, his statement is quite impressi= ve.

=A0

The key here is to actually back up any ideas and op= inions with real results and this is what we are in the process of doing.

=A0

Right now for our=A0purposes, in the Smart Grid doma= in, we can run SIP, with some minor changes beyond stack size optimizations, ov= er networks with as little bandwidth as 80kbps and highly constrained devices.= We also acknowledge for our use cases, latency is not really an issue.=A0

=A0

I'm pretty convinced that with the RIGHT sort of optimizations, any latency issues can be handled without having to dictatin= g general architectural standards like using REST, SNMP, SIP, etc. which can stifle innovation and lead to building everything with a hammer.=A0

=A0

Having said that Carsten's note is encouraging a= nd I'm pretty convinced this committee has in mind creating a base that will evolv= e without=A0stifling=A0innovation and take real results and proof of concepts of use cases as main deciding factors. We will definitely be submitting an ID for Hiroshima.

=A0

--

Shidan Gouran

=A0

On Sat, Oct 10, 2009 at 8:56 PM, Don Sturek <d.sturek@att.net> = wrote:

Hi Adam.
.5 seconds for one hop and 2 seconds for 4 hops are really not acceptable for many applications.

We should of course investigate using existing protocols. =A0 However it does
not seem likely that full HTTP and XML deployed over devices like IEEE
802.15.4 with very small packet sizes will scale very well =A0(certainly, for
any application expecting to do home or building controls, those latencies<= br> don't work). =A0Ideally, we should find something that allows for full<= br> HTTP/etc. while enabling constrained devices to operate with a solution tha= t
can be expanded/compressed.

Don



-----Original Message-----
From: 6lowapp= -bounces@ietf.org [mailto:6lowa= pp-bounces@ietf.org] On Behalf
Of Adam Dunkels
Sent: Saturday, October 10, 2009 3:08 PM
To: Shidan
Cc: 6lowapp@ietf.org<= /a>
Subject: Re: [6lowapp] HTTP and SIP

Shidan wrote:
> "request-response protocols like HTTP may require battery-operate= d,
> mostly sleeping nodes to be listening for requests much more frequentl= y
> than their application processing requirements alone would need them t= o
> wake up."
>
> "In addition, some of the applications may require optimizations = in
> terms of bandwidth usage; for example, the usual data formats (both > headers and body) are perceived to be too chatty for the 50-60 byte > payloads possible in LoWPANs. =A0Their interpretation and generation may
> require too much code for the 8-bit and 16-bit processors dominating > LoWPAN nodes."
>
> None of these points seem evident to me.

I very much agree with this. By so quickly dismissing the opportunities
with existing protocols such as HTTP and SIP, this group may miss
reaching widespread adoption of its protocols.

Both these arguments were frequently used in the past against IP for
resource-constrained systems, yet today we take IP for granted for these systems despite the overheads of IP. We need to a pay price for
interoperability and flexibility, but we think it is worth it.

FWIW, we've recently been working with REST web services
(REST/HTTP/TCP/IP) over 802.15.4 with a low-power duty-cycling radio
protocol (X-MAC) for Contiki. The implementation of the application
layers (REST/HTTP) has roughly a 5kb code footprint. The performance is
not bad: a full HTTP/TCP/IP REST transaction with sensor data in XML
format is completed in roughly 0.5 seconds over a one-hop radio link and in less than 2 seconds over a four-hop radio network:

http://www.sics.se/~adam/yazar09efficient.pdf

Note that this is without any optimizations at the REST/HTTP/TCP/IP
layers. Full HTTP headers are sent from the curl client, reducing the
overall performance. Full XML is sent from the sensors. Thus there is
plenty of opportunity to improve this without moving away from the
HTTP/TCP/IP framework. For example, as we show in the above paper, there are significant savings in using conditional HTTP GETs when data have
not changed between subsequent requests.

Like Shidan, I am not saying that we necessarily must use full-fledged
REST/HTTP/TCP/IP or SIP for everything in our resource-constrained
networks. But we mustn't so quickly rule out existing mechanisms just because of their perceived overhead. Interoperability and flexibility
are very important properties, often more important than bit-level
optimizations.

/adam
--
Adam Dunkels <adam@sic= s.se>, +46707731614
http://twitter.com/a= dunk | http://www.sics.s= e/~adam/

_____________________= __________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

=A0



--0016e6d99c4ba991fb0475b26e3c-- From adam@sics.se Mon Oct 12 04:14:31 2009 Return-Path: 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 8F67028C19E for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35] 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 zU69NYEFJ7SH for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:14:30 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 2056528C19C for <6lowapp@ietf.org>; Mon, 12 Oct 2009 04:14:30 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id BC2C440124; Mon, 12 Oct 2009 13:14:28 +0200 (CEST) Message-ID: <4AD30F8E.3090800@sics.se> Date: Mon, 12 Oct 2009 13:14:22 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "zach@sensinode.com" References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> <51a935134ec43c777faff0894070d2a9@mailserver13.nebula.fi> In-Reply-To: <51a935134ec43c777faff0894070d2a9@mailserver13.nebula.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:14:31 -0000 zach@sensinode.com wrote: > On Sat, 10 Oct 2009 21:40:41 -0400, Shidan wrote: >> I'm pretty convinced that with the RIGHT sort of optimizations, any > latency >> issues can be handled without having to dictating general architectural >> standards like using REST, SNMP, SIP, etc. which can stifle innovation > and >> lead to building everything with a hammer. > > I think there is confusion about the word REST in the charter. This > is only meant to mean that if you want to proxy with HTTP and support > the design of web-services reusing existing techniques - then we need to > support GET, PUT, POST, DELETE methods. Maybe it is better to > remove the word REST if that implies anything more than that to people? Using the acronym REST may be a little difficult because many strongly associate it with HTTP, even if the actual architectural principles do not necessarily have to be implemented over HTTP. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From adam@sics.se Mon Oct 12 04:18:48 2009 Return-Path: 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 3CDCA3A68D0 for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, HELO_EQ_SE=0.35] 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 48KINhKVnHMa for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:18:47 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 5B07328C154 for <6lowapp@ietf.org>; Mon, 12 Oct 2009 04:18:47 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id 35D7B40128; Mon, 12 Oct 2009 13:18:47 +0200 (CEST) Message-ID: <4AD31091.2050901@sics.se> Date: Mon, 12 Oct 2009 13:18:41 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Frank References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> <7b191a110910110629r6e45825cr4e69c0636ea99c16@mail.gmail.com> In-Reply-To: <7b191a110910110629r6e45825cr4e69c0636ea99c16@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:18:48 -0000 Brian Frank wrote: > > I also agree that we should not be so quick to come to conclusions > without presentation of real empirical evidence. > > > I agree. One of the first things we need to do is justify that a new > protocol is required using real empirical data that shows TCP and text > based HTTP do not work for the problem domain. For example, how does > HTTP over TCP stack up against binary UDP protocols with regard to > latency, bandwidth, and power consumption of battery powered sensors? HTTP/TCP is actually quite lean in terms of latency and bandwidth compared to a protocol with similar functionality run on top of UDP - at least if we remove most of the HTTP headers that modern HTTP clients and servers send. It is easy to view TCP as a complex beast and that something else would be more lightweight. But upon closer inspection, TCP isn't such a resource hog as it initially seems. That said, the HTTP and/or TCP interaction models may not be right for all applications in 6lowapp, but we should be wary of reinventing TCP over UDP for those cases where TCP-like functionality is needed. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From adam@sics.se Mon Oct 12 04:19:47 2009 Return-Path: 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 5388C3A68D0 for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_05=-1.11, HELO_EQ_SE=0.35] 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 7YqcpV-HGr2k for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:19:46 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 89A7728C19C for <6lowapp@ietf.org>; Mon, 12 Oct 2009 04:19:46 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id 6E28340124; Mon, 12 Oct 2009 13:19:46 +0200 (CEST) Message-ID: <4AD310CC.40808@sics.se> Date: Mon, 12 Oct 2009 13:19:40 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: d.sturek@att.net References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <001701ca4a0d$b6416610$22c43230$@sturek@att.net> In-Reply-To: <001701ca4a0d$b6416610$22c43230$@sturek@att.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:19:47 -0000 Don Sturek wrote: > .5 seconds for one hop and 2 seconds for 4 hops are really not acceptable > for many applications. > > We should of course investigate using existing protocols. However it does > not seem likely that full HTTP and XML deployed over devices like IEEE > 802.15.4 with very small packet sizes will scale very well (certainly, for > any application expecting to do home or building controls, those latencies > don't work). Ideally, we should find something that allows for full > HTTP/etc. while enabling constrained devices to operate with a solution that > can be expanded/compressed. I agree with this, and that's also why I think the 6lowapp initiative is important. As a sidenote, though: the 0.5 seconds and 2 seconds are not latencies, but completion time. Latency about 0.3s per hop in this case, which is due to the power-saving radio mechanism we use, which switches the radio off for 99% of the time, while waking up twice per second. So the HTTP/TCP does not incur the significant part of the latency in this case. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From adam@sics.se Mon Oct 12 04:22:38 2009 Return-Path: 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 12B2F28C1AF for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HELO_EQ_SE=0.35] 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 JbqqDlTTBdcw for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:22:37 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 18D5428C19C for <6lowapp@ietf.org>; Mon, 12 Oct 2009 04:22:37 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id ECA6C40124; Mon, 12 Oct 2009 13:22:36 +0200 (CEST) Message-ID: <4AD31176.1000104@sics.se> Date: Mon, 12 Oct 2009 13:22:30 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> In-Reply-To: <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:22:38 -0000 Jonathan Hui wrote: >> Both these arguments were frequently used in the past against IP for >> resource-constrained systems, yet today we take IP for granted for >> these systems despite the overheads of IP. We need to a pay price for >> interoperability and flexibility, but we think it is worth it. > > I'd be careful carrying the interoperability argument towards the upper > layers. IP was designed to be the narrow waist. Today, that has > evolved to UDP and TCP being the narrow waist [1]. We have far more > flexibility and opportunity at the application layer than we do with > TCP/UDP/IP and we should not be afraid to exploit that. I do support > the argument for evaluating existing protocols/architectures, but more > because they are established, vetted, and widely understood, less so > because we actually want to utilize the existing technical > infrastructure that surrounds it. > > [1] http://tools.ietf.org/html/draft-rosenberg-internet-waist-hourglass I fully agree with you in that these arguments are stronger than the interoperability argument, and the application layer is the place were we are free to do what we please, without being constrained from the network infrastructure, and that we should use that fact to our advantage. (Even though the waist nowadays sometimes is IP/TCP port 80 or even IP/TCP/HTTP port 80.) But we shouldn't overlook the interoperability aspects with existing application-layer infrastructure such as SNMP, for which there are numerous tools and systems available, and HTTP, that has both infrastructure (e.g. caching proxies) and deployed systems. I am not implying that we must necessarily use existing protocols for everything in 6lowapp. It is dangerous (and easy) to become too fixated with existing mechanisms, particularly in cases where they clearly are not applicable. But rejecting them prematurely based on perceived qualities and not empirical data is not good. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From cabo@tzi.org Mon Oct 12 04:22:39 2009 Return-Path: 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 61AAE28C1B6 for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 oGw+eLYtgyyT for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:22:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 5F08228C19C for <6lowapp@ietf.org>; Mon, 12 Oct 2009 04:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9CBMZqb004753; Mon, 12 Oct 2009 13:22:35 +0200 (CEST) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 167A9B4C1; Mon, 12 Oct 2009 13:22:35 +0200 (CEST) From: Carsten Bormann To: Adam Dunkels In-Reply-To: <4AD30F8E.3090800@sics.se> References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <-3576688268114842355@unknownmsgid> <429b380e0910101840r93129edmae938b4c20eba50f@mail.gmail.com> <51a935134ec43c777faff0894070d2a9@mailserver13.nebula.fi> <4AD30F8E.3090800@sics.se> Message-Id: <10698EC2-72B2-47F4-B277-11D62DEAE7EC@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 13:22:34 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:22:39 -0000 On Oct 12, 2009, at 13:14, Adam Dunkels wrote: > Using the acronym REST may be a little difficult because many > strongly associate it with HTTP, even if the actual architectural > principles do not necessarily have to be implemented over HTTP. I think that is indeed the interesting part, nicely isolated as such by Roy Fielding's dissertation. So, the $64000 question: What are the architectural principles of SIP, SNMP, XMPP, etc. that we are interested in for a constrained-node/-network transfer protocol? Gruesse, Carsten From zach@sensinode.com Mon Oct 12 04:28:53 2009 Return-Path: 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 D02E33A67D4 for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6R2V2NuJzq4c for <6lowapp@core3.amsl.com>; Mon, 12 Oct 2009 04:28:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8E3753A67A2 for <6lowapp@ietf.org>; Mon, 12 Oct 2009 04:28:52 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9CBSjrC009868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 14:28:46 +0300 Message-Id: From: Zach Shelby To: Adam Dunkels In-Reply-To: <4AD31091.2050901@sics.se> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 14:28:47 +0300 References: <429b380e0910101030q25f1ad7fge7157c2e04b5d530@mail.gmail.com> <4AD105DC.3070407@sics.se> <1DDEE359-AA0F-4D94-81BA-7ED03E3CC86A@archrock.com> <7b191a110910110629r6e45825cr4e69c0636ea99c16@mail.gmail.com> <4AD31091.2050901@sics.se> X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] HTTP and SIP 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:28:53 -0000 On Oct 12, 2009, at 14:18 , Adam Dunkels wrote: > That said, the HTTP and/or TCP interaction models may not be right =20 > for all applications in 6lowapp, but we should be wary of =20 > reinventing TCP over UDP for those cases where TCP-like =20 > functionality is needed. I totally agree. This is why we are aiming at support for both UDP and =20= TCP as transports for 6lowapp in the charter. There are interaction =20 models for embedded devices where UDP is great. For example for very =20 short transactions, multicast, or even where no response is needed. =20 There are also models where TCP is great, and situations where it =20 really works too. In the future this activity hopefully spins off a transport area =20 working group that can really make an improvement/alternative to TCP =20 for these types of applications and networks. We already identified =20 this in this first Bar BOF - but it was made clear that this is a long =20= term process and something to do in parallel. Zach > /adam > --=20 > Adam Dunkels , +46707731614 > http://twitter.com/adunk | http://www.sics.se/~adam/ > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Tue Oct 13 03:46:22 2009 Return-Path: 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 092523A68F0 for <6lowapp@core3.amsl.com>; Tue, 13 Oct 2009 03:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qDcvdk4JfiWe for <6lowapp@core3.amsl.com>; Tue, 13 Oct 2009 03:46:21 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E1A153A682D for <6lowapp@ietf.org>; Tue, 13 Oct 2009 03:46:20 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9DAkHXu026538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Tue, 13 Oct 2009 13:46:17 +0300 Message-Id: From: Zach Shelby To: 6lowapp@ietf.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 13:46:19 +0300 X-Mailer: Apple Mail (2.936) Subject: [6lowapp] Wiki page updated 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 10:46:22 -0000 Hi, I have updated the Wiki page: http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp This now explains the overall, long-term goal of the 6LowApp effort, =20 along with the current short-term goal of starting an Application area =20= working group on two of the identified interest areas. The BOF =20 timeslot, agenda and the latest charter text are all there. Should be =20= easier than always digging up links to mails. We will keep this up to =20= date whenever a new version is up. Any ideas for improving the Wiki are welcome! We should at least =20 expand the More Resources section... Cheers, Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From Adrian.Farrel@huawei.com Tue Oct 13 06:48:37 2009 Return-Path: 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 721EA28C1E1 for <6lowapp@core3.amsl.com>; Tue, 13 Oct 2009 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=1.076, 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 0UZA4KLpUBMm for <6lowapp@core3.amsl.com>; Tue, 13 Oct 2009 06:48:36 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 7949728C1AE for <6lowapp@ietf.org>; Tue, 13 Oct 2009 06:48:36 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRG00C1UH11A7@usaga01-in.huawei.com> for 6lowapp@ietf.org; Tue, 13 Oct 2009 06:48:37 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRG00747H0ZXE@usaga01-in.huawei.com> for 6lowapp@ietf.org; Tue, 13 Oct 2009 06:48:37 -0700 (PDT) Date: Tue, 13 Oct 2009 14:47:00 +0100 From: Adrian Farrel To: 6lowapp@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [6lowapp] Smart Grid Bar Bof at IETF 76 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:48:37 -0000 Please see the attached from Security AD (and NIST employee) Tim Polk. If this is something that would be of direct interest to you, please consider completing the Doodle poll. Thanks, Adrian ----- Original Message ----- From: "Polk, William T." To: "Fred Baker" ; "David R Oran" ; "Richard Shockey" ; "Russ Housley" ; "Leslie Daigle" ; "Sean Turner" ; "Paul Hoffman" ; "Henning Schulzrinne" ; "Phil Roberts" ; ; ; "Hiroshi Esaki" ; "Michael Dillon" ; "Brian E Carpenter" ; "Ralph Droms" ; "Michael Dillon" ; "IESG IESG" ; "IAB IAB" ; ; "Peny Yang" Cc: "St. Pierre, James A." ; "Dodson, Donna F." ; "Su, David H." ; "Golmie, Nada T." Sent: Tuesday, October 13, 2009 2:45 AM Subject: Doodle poll: Smart Grid Bar Bof at IETF 76 Folks, I would like to organize a BAR BOF at IETF 76 in Hiroshima to discuss the US Smart Grid effort. IETF protocols will be an important component of a successful and evolutionary Smart Grid, and NIST is looking to the IETF for leadership. To enable participation by NIST/ITL Management, I would like to hold the BAR BOF either Wednesday or Thursday night. NIST attendees will provide some background/history of the Smart Grid efforts but the primary goal of this session is to determine whether there is sufficient interest in the community to take on work in this area. If there is interest, scoping of appropriate IETF contributions, and strategies for organizing the response would also be fruitful topic areas. I am sending this email directly to any IETFers that have (to my knowledge) previously indicated interest in Smart Grid. I am also sending this message to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov email lists. Please feel free to forward this email to anyone else that you think I may have missed. If you are interested in attending the BOF, please indicate your preference using the following doodle poll: http://www.doodle.com/q5nusbhpqfnf75yh Thanks, Tim Polk From jvasseur@cisco.com Tue Oct 13 03:18:06 2009 Return-Path: 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 F3FAC3A6945; Tue, 13 Oct 2009 03:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.11 X-Spam-Level: X-Spam-Status: No, score=-8.11 tagged_above=-999 required=5 tests=[AWL=-1.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 EhyTlWDOnDvS; Tue, 13 Oct 2009 03:18:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A906B3A680C; Tue, 13 Oct 2009 03:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=10136; q=dns/txt; s=sjiport06001; t=1255429086; x=1256638686; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20F wd:=20[recipe]=20Doodle=20poll:=20Smart=20Grid=20Bar=20Bo f=20at=20IETF=2076|Date:=20Tue,=2013=20Oct=202009=2012:17 :51=20+0200|Message-Id:=20|To:=20IETF=20ROLL=20,=20 6lowpan=20<6lowpan@ietf.org>,=206lowapp@ietf.org|Cc:=20re cipe@ietf.org|Mime-Version:=201.0=20(Apple=20Message=20fr amework=20v936)|References:=20; bh=4zcA0TYmVcvWwkGS0XP+vFQYlZUG9xSvg90QHUDnLyQ=; b=nxkYlucTj3CZYyPXliLtslJ94LPQ+eUpborkemk+iNoVYrd0ScDrgB+4 39stIiSfOkFX7gwSICKnaXe/X2zpw5fU/TAH+dRVb5XnF82qgmQpL9VP3 gXlaowewPke7vnvpoEYTKI9TkX8UTSISD5g/ZAMusz9CZ5kslD5dwBKeF 0=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAHvw00qrR7Hu/2dsb2JhbACCJxUYu0iXbIQtBA X-IronPort-AV: E=Sophos;i="4.44,550,1249257600"; d="scan'208,217";a="408091713" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 10:18:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9DAI4sT026575; Tue, 13 Oct 2009 10:18:05 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:17:52 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:17:52 +0200 Message-Id: From: JP Vasseur To: IETF ROLL , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-156-96480763 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 12:17:51 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 10:17:52.0219 (UTC) FILETIME=[6C25B2B0:01CA4BEE] X-Mailman-Approved-At: Tue, 13 Oct 2009 08:09:17 -0700 Cc: recipe@ietf.org Subject: [6lowapp] Fwd: [recipe] Doodle poll: Smart Grid Bar Bof at IETF 76 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 10:18:06 -0000 --Apple-Mail-156-96480763 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit A BAR BOF many of you should be interested in. Thanks. JP. Begin forwarded message: > From: "Polk, William T." > Date: October 13, 2009 3:45:52 AM CEDT > To: Fred Baker , David R Oran , > Richard Shockey , Russ Housley >, Leslie Daigle , Sean Turner , > Paul Hoffman , Henning Schulzrinne >, Phil Roberts , "peter@peter-dambier.de" >, "dcrocker@bbiw.net" , Hiroshi Esaki >, Michael Dillon , Brian E Carpenter >, Ralph Droms , Michael Dillon >, IESG IESG , IAB IAB , > "recipe@ietf.org" , Peny Yang > > Cc: "St. Pierre, James A." , "Dodson, > Donna F." , "Su, David H." > , "Golmie, Nada T." > Subject: [recipe] Doodle poll: Smart Grid Bar Bof at IETF 76 > > > Folks, > > I would like to organize a BAR BOF at IETF 76 in Hiroshima to > discuss the US Smart Grid effort. IETF protocols will be an > important component of a successful and evolutionary Smart Grid, and > NIST is looking to the IETF for leadership. To enable participation > by NIST/ITL Management, I would like to hold the BAR BOF either > Wednesday or Thursday night. > > NIST attendees will provide some background/history of the Smart > Grid efforts but the primary goal of this session is to determine > whether there is sufficient interest in the community to take on > work in this area. If there is interest, scoping of appropriate IETF > contributions, and strategies for organizing the response would also > be fruitful topic areas. > > I am sending this email directly to any IETFers that have (to my > knowledge) previously indicated interest in Smart Grid. I am also > sending this message to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov > email lists. Please feel free to forward this email to anyone else > that you think I may have missed. > > If you are interested in attending the BOF, please indicate your > preference using the following doodle poll: > > http://www.doodle.com/q5nusbhpqfnf75yh > > Thanks, > > Tim Polk > _______________________________________________ > recipe mailing list > recipe@ietf.org > https://www.ietf.org/mailman/listinfo/recipe --Apple-Mail-156-96480763 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A BAR BOF many of you should be = interested = in.

Thanks.

JP.

Begin forwarded message:

From: = "Polk, William T." <william.polk@nist.gov>=
Date: October 13, 2009 3:45:52 AM = CEDT
To: Fred Baker <fred@cisco.com>, David R Oran = <oran@cisco.com>, Richard = Shockey <richard@shockey.us>, Russ = Housley <housley@vigilsec.com>, = Leslie Daigle <daigle@isoc.org>, Sean Turner = <turners@ieca.com>, Paul = Hoffman <paul.hoffman@vpnc.org>, = Henning Schulzrinne <hgs@cs.columbia.edu>, Phil = Roberts <roberts@isoc.org>, = "peter@peter-dambier.de" = <peter@peter-dambier.de>, = "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Hiroshi = Esaki <hiroshi@wide.ad.jp>, Michael = Dillon <wavetossed@googlemail.com>= ;, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ralph Droms <rdroms@cisco.com>, Michael = Dillon <wavetossed@googlemail.com>= ;, IESG IESG <iesg@ietf.org>, = IAB IAB <iab@iab.org>, "recipe@ietf.org" <recipe@ietf.org>, Peny Yang = <peng.yang.chn@gmail.com>
Cc: "St. Pierre, James A." <james.st.pierre@nist.gov>,= "Dodson, Donna F." <donna.dodson@nist.gov>, = "Su, David H." <david.su@nist.gov>, "Golmie, = Nada T." <nada.golmie@nist.gov>
Subject: [recipe] Doodle poll: Smart Grid Bar = Bof at IETF 76


Folks,

= I would like to = organize a BAR BOF at IETF 76 in Hiroshima to discuss the US Smart Grid = effort.  IETF protocols will be an important component of a = successful and evolutionary Smart Grid, and NIST is looking to the IETF = for leadership. To enable participation by NIST/ITL Management, I would = like to hold the BAR BOF either Wednesday or Thursday night.

= NIST attendees will provide some background/history of the Smart Grid = efforts but the primary goal of this session is to determine whether = there is sufficient interest in the community to take on work in this = area. If there is interest, scoping of appropriate IETF contributions, = and strategies for organizing the response would also be fruitful topic = areas.

= I am sending this = email directly to any IETFers that have (to my knowledge) previously = indicated interest in Smart Grid.  I am also sending this message = to the IESG, IAB, recipe@ietf.org, and = ipaction@nist.gov email lists. =  Please feel free to forward this email to anyone else that you = think I may have missed.

If you are interested in attending the = BOF, please indicate your preference using the following doodle = poll:

=       http://www.doodle.com/q5nu= sbhpqfnf75yh

= Thanks,

= Tim Polk
= _______________________________________________
recipe mailing = list
recipe@ietf.org
https://www.ietf.or= g/mailman/listinfo/recipe

= --Apple-Mail-156-96480763-- From schmitt@net.in.tum.de Thu Oct 15 00:27:58 2009 Return-Path: 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 293323A69C9 for <6lowapp@core3.amsl.com>; Thu, 15 Oct 2009 00:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 zUxcU9XYOo74 for <6lowapp@core3.amsl.com>; Thu, 15 Oct 2009 00:27:57 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 0B82A3A69C3 for <6lowapp@ietf.org>; Thu, 15 Oct 2009 00:27:56 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 3E79748646 for <6lowapp@ietf.org>; Thu, 15 Oct 2009 09:27:58 +0200 (CEST) Received: from [127.0.0.1] (ldap [131.159.14.1]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0CE6550A1 for <6lowapp@ietf.org>; Thu, 15 Oct 2009 09:27:58 +0200 (CEST) Message-ID: <4AD6CF03.9010809@net.in.tum.de> Date: Thu, 15 Oct 2009 09:28:03 +0200 From: Schmitt User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [6lowapp] Submission of draft-schmitt-6lowapp-ipfix-ws-00.txt 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 07:27:58 -0000 Morning, now we also joined the call for draft submissions for the upcoming working group 6lowapp. Our submission deals with IPFIX above 6LoWPAN for an efficient data transmission and can be found under http://www.ietf.org/id/draft-schmitt-6lowapp-ipfix-ws-00.txt Abstract: In this draft we want to introduce an idea to develop a protocol for efficient data transmission for Wireless Sensors using the ideas of IPFIX. We will call this protocol IPFIX-WS. Regards, Corinna -- Corinna Schmitt, Dipl.-Inf. (Bioinf.) Technische Universität München Chair for Network Architectures and Services (I8) Boltzmannstr. 3 85748 Garching b. München Germany Phone.: +49 (0)89 289 18005 Email: schmitt@net.in.tum.de http://www.net.in.tum.de/~schmitt/ From zach@sensinode.com Fri Oct 16 05:45:43 2009 Return-Path: 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 1C6BF28C210 for <6lowapp@core3.amsl.com>; Fri, 16 Oct 2009 05:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 kg4ENzs+9TYX for <6lowapp@core3.amsl.com>; Fri, 16 Oct 2009 05:45:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B317828C216 for <6lowapp@ietf.org>; Fri, 16 Oct 2009 05:45:41 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9GCjdH5024839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Fri, 16 Oct 2009 15:45:40 +0300 Message-Id: From: Zach Shelby To: 6lowapp@ietf.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 15:45:41 +0300 References: <20091016124006.8789128C1EE@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [6lowapp] Fwd: New Version Notification for draft-shelby-6lowapp-encoding-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 12:45:43 -0000 Hi, We have submitted a draft looking at efficient XML encodings, their =20 applicability to 6LowApp and what requirements there are for using =20 them over an application protocol. http://www.ietf.org/id/draft-shelby-6lowapp-encoding-00.txt This is just an initial spin, we look forward to expanding the =20 encodings and results still some more and adding input from others. =20 However, what is important to note is that the summary is pretty =20 universal for any encoding - provide a reasonable range of Internet =20 media types and a couple transfer encoding types and we're good to go. Cheers, Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 16, 2009 15:40:06 GMT+03:00 > To: zach@sensinode.com > Cc: Mika.Luimula@centria.fi,Daniel.Peintner.EXT@siemens.com > Subject: New Version Notification for draft-shelby-6lowapp-encoding-00 > > > A new version of I-D, draft-shelby-6lowapp-encoding-00.txt has been =20= > successfuly submitted by Zach Shelby and posted to the IETF =20 > repository. > > Filename: draft-shelby-6lowapp-encoding > Revision: 00 > Title: Efficient XML Encoding and 6LowApp > Creation_date: 2009-10-16 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > For the resource constrained devices and networks of 6LowApp it is > essential that the payload of messages are compact. The use of XML > to represent data in web applications has become almost universal. > The interoperability of 6LowApp with these applications will require > that XML can also be carried over the embedded web. This document > introduces and compares techniques for encoding or compressing XML > for use with 6LowApp including EXI, BXML and Fast Infoset. The > performance and requirements for using these encodings are analyzed > in the scope of 6LowApp. It is shown that these standard encodings > can represent XML in a compact form, with reasonable overhead, and > require only Internet media type and content transfer encoding > indication from the application protocol. > > > > The IETF Secretariat. > > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From richard.kelsey@ember.com Fri Oct 16 08:18:27 2009 Return-Path: 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 A5DE328C1BC for <6lowapp@core3.amsl.com>; Fri, 16 Oct 2009 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 s16G2-qcaDCu for <6lowapp@core3.amsl.com>; Fri, 16 Oct 2009 08:18:27 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id C8BB73A685B for <6lowapp@ietf.org>; Fri, 16 Oct 2009 08:18:26 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 11:19:39 -0400 Date: Fri, 16 Oct 2009 11:16:38 -0400 Message-Id: <874opz9xnt.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: (message from Zach Shelby on Fri, 16 Oct 2009 15:45:41 +0300) From: Richard Kelsey References: <20091016124006.8789128C1EE@core3.amsl.com> X-OriginalArrivalTime: 16 Oct 2009 15:19:39.0070 (UTC) FILETIME=[13E925E0:01CA4E74] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Fwd: New Version Notification for draft-shelby-6lowapp-encoding-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:18:27 -0000 From: Zach Shelby Date: Fri, 16 Oct 2009 15:45:41 +0300 We have submitted a draft looking at efficient XML encodings, their applicability to 6LowApp and what requirements there are for using them over an application protocol. http://www.ietf.org/id/draft-shelby-6lowapp-encoding-00.txt This is great. It should be a big help. I do have a question about MIME types. When using EXI in schema-informed mode it seems you have two choices: - include the schema, either directly or by reference - use the application/octet-stream type Is there much point in indicating that this is an EXI stream if the schema is not also provided? For messages as small as these even sending a reference to the schema will signifcantly increase the overhead. The W3C EXI Best Practices document has only placeholders for the sections on how to deal with schemas and out-of-band encoding knowledge. -Richard Kelsey From shidan@gmail.com Sat Oct 17 14:00:36 2009 Return-Path: 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 EEBAA3A6839 for <6lowapp@core3.amsl.com>; Sat, 17 Oct 2009 14:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 YaBgwYNyexPZ for <6lowapp@core3.amsl.com>; Sat, 17 Oct 2009 14:00:35 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 76BB93A6784 for <6lowapp@ietf.org>; Sat, 17 Oct 2009 14:00:35 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so747531eyd.51 for <6lowapp@ietf.org>; Sat, 17 Oct 2009 14:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=/jztCFF6v0mgM37QqD8ymD34oSUPBZ45HMf7m1eOKKk=; b=nJ9kUce7EO6BVutycaOy9DUk3gs0WO99aswOIhchV3Ec2nwXIc0SoqEEfINw9tsrQi LW04/QUf/aO8ry8aOR62gFYYUWNtQGESpmPTMODBHSKK1Zm4GA1cYmamGiSVORj8H0SN CfKyBghMLH1QA3djbIBgmobu0fodGxM/Trh7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i1npINjV/W7SP7IKK5eETfcaRcXpYWwfOW9TvygsTIXNdkTMduIPLdzYfW4DMSyoiP JUeLHEDWRwdSuIfquA35utq96iGtSB5egJ6Z6Z78k/0MPBO2ZxDd9eYDxManFF9/WbiP 4GGcjt9CQeiwTFqltPBH30ByWH6lHuUSKHtiw= MIME-Version: 1.0 Received: by 10.216.86.137 with SMTP id w9mr1136326wee.104.1255813236371; Sat, 17 Oct 2009 14:00:36 -0700 (PDT) Date: Sat, 17 Oct 2009 17:00:36 -0400 Message-ID: <429b380e0910171400g83a10e4r5aff1be8d3c22c0a@mail.gmail.com> From: Shidan To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7f07edbb048047627cd88 Subject: [6lowapp] SIP and 6LoWPAN & Some General Suggestions 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 21:00:37 -0000 --0016e6d7f07edbb048047627cd88 Content-Type: text/plain; charset=ISO-8859-1 I don't think I have sufficient time to write anything other than a very high level motivation I-D on the merits of SIP, as defined by RFC 3261 & 3625, for ubiquitos computing and building automation. I will start this tonight and submit it sometime on Monday for sure. * * Here are some recommendations I have for this working group in general: * * - With regards to the general 6LoWAPP problem statement, I suggest the WG adopt the use cases of OpenHan as criteria for evaluating any application protocol suitable for the 6LowAPP working group. Their use cases are the most extensive that I have seen. - I think before we consider any binary encoding, we must consider how binary compression of application level protocols is done in current bandwidth constrained communications networks like GSM. I certainly think we would benefit from learning/involving SIGCOMM in making this decision. Power contraint seems to me to be a much more unique issue this WG has to deal with than bandwidth constraint. Now going back to the concepts of a specific binary encoding for SIP as a base protocol here are some ideas: - Any method for binary compression of HTTP would work seamlessly with SIP, so for example everything in section 2 of the Chopan I-D could be applied to all SIP messages and follow the same request/response model. Also, referring to the Chopan I-D, SIP already addresses sections 3, 4 and a significant portion of 5. For these purposes, no new extensions or modifications to SIP need to be defined and it really becomes just a matter of defining the message encoding. One area that needs to be addressed with SIP is sleeping nodes and this is something we definitely need to think about more. - In addition, any type of binary encoding of XML, "ZigBee like" data representations or anything else that can or will be transported by a binary HTTP protocol, will also work with SIP as the mechanism is identical in both. - For security, relying solely on 802.15.4's AES is, in my opinion, not a good idea. for example both SIP and, as Schmidt et al outlined, IPFIX requires TLS and support of something like Tiny 3-TLS would also work well for us*.* - As I mentioned before, SIP as a base protocol can make gatewaying with XMPP and some "real-time web" REST based protocols such as FeedSync or ATOM Pub + PubHubSub, much more efficient. If we are defining all of this using HTTP you are going to be defining heavier payloads than needed. Describing this will take more time than I have for the motivational I-D, this is something in the coming months I would be happy to expand on fully if this WG considers it worthwhile. - As much as possible, the 6LowPAN framework should be abstracted to unify and fit commonalities in SNMP, SIP and "real time web" protocols. So the way we define eventing, for example, should be done in a way that lends to simple interfacing with systems that use any of the above. * *I would appreciate any comments or suggestions to this note before I start writing the motivational I-D later tonight EST. * * Shidan Gouran --0016e6d7f07edbb048047627cd88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think I have sufficient time to write anything other= than a very high level motivation I-D on the merits of SIP, as defined by = RFC 3261 & 3625, for ubiquitos computing and building automation. I wil= l start this tonight and submit it sometime on Monday for sure.

Here are some recommendations I have = for this working group in general:

  • With regards to the general 6LoWAPP prob= lem statement, I suggest the WG adopt the use cases of OpenHan as criteria = for evaluating any application protocol suitable for the 6LowAPP working gr= oup. Their use cases are the most extensive that I have seen.
  • I think before we consider any binary encoding, we must consid= er how binary compression of application level protocols is done in current= bandwidth constrained communications networks like GSM. I certainly think = we would benefit from learning/involving SIGCOMM in making this decision.= =A0Power contraint seems to me to be a much more unique issue this WG has t= o deal with than bandwidth constraint.
Now going back to the concepts of a specific binary encodin= g for SIP as a base protocol here are some ideas:
  • Any method for binary compression of HTTP would work = seamlessly with SIP, so for example everything in section 2 of the Chopan I= -D could be applied to all SIP messages and follow the same request/respons= e model.=A0Also, referring to the Chopan I-D, SIP already addresses section= s =A03, 4 and a significant portion of 5. For these purposes, no new extens= ions or modifications to SIP need to be defined and it really becomes just = a matter of defining the message encoding.=A0One area that needs to be addr= essed with SIP is sleeping nodes and this is something we definitely need t= o think about more.
  • In addition, any type of binary enc= oding of XML, "ZigBee like" data representations or anything else= that can or will be transported by a binary HTTP protocol, will also work = with SIP as the mechanism is identical in both.
  • For security, relying solely on 802= .15.4's AES is, in my opinion, not a good idea. for example both SIP an= d, as Schmidt et al outlined, IPFIX requires TLS and support of something l= ike Tiny 3-TLS would also work well for us.
  • As I mentioned before, SIP as a bas= e protocol can make gatewaying with XMPP and some "real-time web"= REST based protocols such as FeedSync or ATOM Pub + PubHubSub, much more e= fficient. If we are defining all of this using HTTP you are going to be=A0d= efining=A0heavier payloads than needed. Describing this will take more time= than I have for the motivational I-D, this is something in the coming mont= hs I would be happy to expand on fully if this WG considers it worthwhile.<= /li>
  • As much as possible, the 6LowPAN fr= amework should be abstracted to unify and fit commonalities in SNMP, SIP an= d "real time web" protocols. So the way we define eventing, for e= xample, should be done in a way that lends to simple interfacing with syste= ms that use any of the above.
=A0I would appreciate any comments or suggestions to this = note before I start writing the motivational I-D later tonight EST.

Shidan Gouran
--0016e6d7f07edbb048047627cd88-- From shidan@gmail.com Sat Oct 17 14:36:44 2009 Return-Path: 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 F3ED23A68B7 for <6lowapp@core3.amsl.com>; Sat, 17 Oct 2009 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 A+oEv2azQC8z for <6lowapp@core3.amsl.com>; Sat, 17 Oct 2009 14:36:42 -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 7A4853A67B6 for <6lowapp@ietf.org>; Sat, 17 Oct 2009 14:36:42 -0700 (PDT) Received: by ewy4 with SMTP id 4so418286ewy.37 for <6lowapp@ietf.org>; Sat, 17 Oct 2009 14:36:44 -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:content-type; bh=T+xr1UAcSPYPP+2QMEWjRNnQhdS4aHDwc3gy0zYz17I=; b=faktJdi6S5uPQ4UAo7pkhCQkRT0hTcQzG7BFm0la4l+W/Dk/Heh3745xO0b/3TeRUE ILSDQJuHUnB6gLihf7+iOWHtgfdUmXGW/DNiBHllN4MjxbA9YKe+zvMUcasjAXXtyhlI DGR4cwO5QQnDXAftwRzSbb/RCgiK3nHjpNnc0= 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 :content-type; b=GCb+5zRW1yC/bUyc4Wb7TYGrA/aesXyV1qn6b853qh40ah8O/XSjbAyMuVymDKQAm3 7XcNAxPSvVPvb0Gj9F6s6fU4HffdDEOpbKtDN8wRpciU4K/KbVq6V8Wf2JJL05LJbbfu RGd5nEUuHmlgzqwW2TgV81loOfi0H7Hmk9Efs= MIME-Version: 1.0 Received: by 10.216.87.7 with SMTP id x7mr1278607wee.53.1255815404101; Sat, 17 Oct 2009 14:36:44 -0700 (PDT) In-Reply-To: <429b380e0910171400g83a10e4r5aff1be8d3c22c0a@mail.gmail.com> References: <429b380e0910171400g83a10e4r5aff1be8d3c22c0a@mail.gmail.com> Date: Sat, 17 Oct 2009 17:36:44 -0400 Message-ID: <429b380e0910171436r18305389pe922731b566486ee@mail.gmail.com> From: Shidan To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=001636c5b1e210a29a0476284fa8 Subject: Re: [6lowapp] SIP and 6LoWPAN & Some General Suggestions 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 21:36:44 -0000 --001636c5b1e210a29a0476284fa8 Content-Type: text/plain; charset=ISO-8859-1 Sorry for the typo, I meant involve the WG responsible for SIGCOMP not the conference. --- Shidan Gouran On Sat, Oct 17, 2009 at 5:00 PM, Shidan wrote: > I don't think I have sufficient time to write anything other than a very > high level motivation I-D on the merits of SIP, as defined by RFC 3261 & > 3625, for ubiquitos computing and building automation. I will start this > tonight and submit it sometime on Monday for sure. * > * > Here are some recommendations I have for this working group in general: > * > * > > - With regards to the general 6LoWAPP problem statement, I suggest the > WG adopt the use cases of OpenHan as criteria for evaluating any application > protocol suitable for the 6LowAPP working group. Their use cases are the > most extensive that I have seen. > > > - I think before we consider any binary encoding, we must consider how > binary compression of application level protocols is done in current > bandwidth constrained communications networks like GSM. I certainly think we > would benefit from learning/involving SIGCOMM in making this decision. Power > contraint seems to me to be a much more unique issue this WG has to deal > with than bandwidth constraint. > > Now going back to the concepts of a specific binary encoding for SIP as a > base protocol here are some ideas: > > - Any method for binary compression of HTTP would work seamlessly with > SIP, so for example everything in section 2 of the Chopan I-D could be > applied to all SIP messages and follow the same request/response > model. Also, referring to the Chopan I-D, SIP already addresses sections 3, > 4 and a significant portion of 5. For these purposes, no new extensions or > modifications to SIP need to be defined and it really becomes just a matter > of defining the message encoding. One area that needs to be addressed with > SIP is sleeping nodes and this is something we definitely need to think > about more. > > > - In addition, any type of binary encoding of XML, "ZigBee like" data > representations or anything else that can or will be transported by a binary > HTTP protocol, will also work with SIP as the mechanism is identical in > both. > > > - For security, relying solely on 802.15.4's AES is, in my opinion, not > a good idea. for example both SIP and, as Schmidt et al outlined, IPFIX > requires TLS and support of something like Tiny 3-TLS would also work well > for us*.* > > > - As I mentioned before, SIP as a base protocol can make gatewaying > with XMPP and some "real-time web" REST based protocols such as FeedSync or > ATOM Pub + PubHubSub, much more efficient. If we are defining all of this > using HTTP you are going to be defining heavier payloads than needed. > Describing this will take more time than I have for the motivational I-D, > this is something in the coming months I would be happy to expand on fully > if this WG considers it worthwhile. > > > - As much as possible, the 6LowPAN framework should be abstracted to > unify and fit commonalities in SNMP, SIP and "real time web" protocols. So > the way we define eventing, for example, should be done in a way that lends > to simple interfacing with systems that use any of the above. > > * *I would appreciate any comments or suggestions to this note before I > start writing the motivational I-D later tonight EST. > * > * > Shidan Gouran > --001636c5b1e210a29a0476284fa8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for the typo, I meant involve the WG responsible for SIGCOMP not the = conference.

---
Shidan Gouran

On Sat, Oct 17, 2009 at 5:00 PM, Shidan <shidan@gmail.com> wr= ote:
I don't think I have suffici= ent time to write anything other than a very high level motivation I-D on t= he merits of SIP, as defined by RFC 3261 & 3625, for ubiquitos computin= g and building automation. I will start this tonight and submit it sometime= on Monday for sure.

Here are some recommendations I have = for this working group in general:

  • With regards to the general 6LoWAPP prob= lem statement, I suggest the WG adopt the use cases of OpenHan as criteria = for evaluating any application protocol suitable for the 6LowAPP working gr= oup. Their use cases are the most extensive that I have seen.
  • I think before we consider any binary encoding, we must consid= er how binary compression of application level protocols is done in current= bandwidth constrained communications networks like GSM. I certainly think = we would benefit from learning/involving SIGCOMM in making this decision.= =A0Power contraint seems to me to be a much more unique issue this WG has t= o deal with than bandwidth constraint.
Now going back to the concepts of a specific binary encodin= g for SIP as a base protocol here are some ideas:
  • Any method for binary compression of HTTP would work = seamlessly with SIP, so for example everything in section 2 of the Chopan I= -D could be applied to all SIP messages and follow the same request/respons= e model.=A0Also, referring to the Chopan I-D, SIP already addresses section= s =A03, 4 and a significant portion of 5. For these purposes, no new extens= ions or modifications to SIP need to be defined and it really becomes just = a matter of defining the message encoding.=A0One area that needs to be addr= essed with SIP is sleeping nodes and this is something we definitely need t= o think about more.
  • In addition, any type of binary enc= oding of XML, "ZigBee like" data representations or anything else= that can or will be transported by a binary HTTP protocol, will also work = with SIP as the mechanism is identical in both.
  • For security, relying solely on 802= .15.4's AES is, in my opinion, not a good idea. for example both SIP an= d, as Schmidt et al outlined, IPFIX requires TLS and support of something l= ike Tiny 3-TLS would also work well for us.
  • As I mentioned before, SIP as a bas= e protocol can make gatewaying with XMPP and some "real-time web"= REST based protocols such as FeedSync or ATOM Pub + PubHubSub, much more e= fficient. If we are defining all of this using HTTP you are going to be=A0d= efining=A0heavier payloads than needed. Describing this will take more time= than I have for the motivational I-D, this is something in the coming mont= hs I would be happy to expand on fully if this WG considers it worthwhile.<= /li>
  • As much as possible, the 6LowPAN fr= amework should be abstracted to unify and fit commonalities in SNMP, SIP an= d "real time web" protocols. So the way we define eventing, for e= xample, should be done in a way that lends to simple interfacing with syste= ms that use any of the above.
=A0I would appreciate any comments or suggestions to this = note before I start writing the motivational I-D later tonight EST.

Shidan Gouran
=

--001636c5b1e210a29a0476284fa8-- From cabo@tzi.org Sat Oct 17 15:07:11 2009 Return-Path: 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 17BD93A69A3 for <6lowapp@core3.amsl.com>; Sat, 17 Oct 2009 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 CFNHUD9RuKli for <6lowapp@core3.amsl.com>; Sat, 17 Oct 2009 15:07:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 142CB3A69A4 for <6lowapp@ietf.org>; Sat, 17 Oct 2009 15:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9HM75NW025342; Sun, 18 Oct 2009 00:07:05 +0200 (CEST) Received: from [192.168.217.101] (p5489B1CE.dip.t-dialin.net [84.137.177.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4D40FBA43; Sun, 18 Oct 2009 00:07:05 +0200 (CEST) From: Carsten Bormann To: Shidan In-Reply-To: <429b380e0910171436r18305389pe922731b566486ee@mail.gmail.com> References: <429b380e0910171400g83a10e4r5aff1be8d3c22c0a@mail.gmail.com> <429b380e0910171436r18305389pe922731b566486ee@mail.gmail.com> Message-Id: <52968AFD-40BC-42F0-ACC7-9D22FA1E3CF9@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Oct 2009 00:07:04 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] SIP and 6LoWPAN & Some General Suggestions 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 22:07:11 -0000 On Oct 17, 2009, at 23:36, Shidan wrote: > SIGCOMP SigComp (RFC 3320) is essentially a virtual machine for shipping decompression code to a peer. Constrained nodes (as in 8 MHz 10K RAM) won't be able to run such a virtual machine, I'd say. Actually, the whole idea of using complex encodings full of encoding alternatives (the fact that any of these are text-based is secondary to that) and then compressing them with a data compression algorithm is something that may be appropriate out of backwards compatibility, but not for a new design that emphasizes minimal code complexity. Apart from this little nit (sorry, I was involved in RFC 3320), I'm looking forward to your draft. BTW, right now the score is: 16 Oct 2009 draft-martocci-6lowapp-building-applications 16 Oct 2009 draft-shelby-6lowapp-encoding 14 Oct 2009 draft-schmitt-6lowapp-ipfix-ws 11 Sep 2009 draft-frank-6lowapp-chopan 13 Jul 2009 draft-bormann-6lowpan-6lowapp-problem 48 more hours to go... Gruesse, Carsten From d.sturek@att.net Sun Oct 18 13:27:52 2009 Return-Path: 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 B20583A6995 for <6lowapp@core3.amsl.com>; Sun, 18 Oct 2009 13:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] 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 1b6cKrmjGDYf for <6lowapp@core3.amsl.com>; Sun, 18 Oct 2009 13:27:51 -0700 (PDT) Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by core3.amsl.com (Postfix) with SMTP id BBE083A6953 for <6lowapp@ietf.org>; Sun, 18 Oct 2009 13:27:51 -0700 (PDT) Received: from [216.252.122.219] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 18 Oct 2009 20:27:58 -0000 Received: from [68.142.194.243] by t4.bullet.sp1.yahoo.com with NNFMP; 18 Oct 2009 20:27:58 -0000 Received: from [68.142.201.241] by t1.bullet.mud.yahoo.com with NNFMP; 18 Oct 2009 20:27:58 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 18 Oct 2009 20:27:58 -0000 X-Yahoo-Newman-Id: 207819.24735.bm@omp402.mail.mud.yahoo.com Received: (qmail 85354 invoked from network); 18 Oct 2009 20:27:57 -0000 Received: from unknown (HELO Studio) (d.sturek@69.108.48.55 with login) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 18 Oct 2009 20:27:57 -0000 X-YMail-OSG: ci.JaNcVM1n.swIhuusAxd6MAvBjfHcRlNKHN5ZvmkFMrxb5AgI_M6OXOL_mViXsSPz82YwM7FAAO9SQr4AR6nE_CJCsG_D0yczacPXXBJVtusOPpzCLi0sbmhdiqRP6T6i3tY0IPl2GVLrnozN0hsyNZb9sq2oEc_SAxwQYqhaRVU7EzYaWkZbGO77GhB9XfMmFJUWNyxnyF_2EYHN9LGhsSqlEG1lIm1bJyTSm1Siy2a1MOvvemBY9bUsPkOahtO7uL.rewywcyAD43gkOlfqaak6.gNUNWL6i7Yua7FlGP2jMGkU- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: <6lowapp@ietf.org> Date: Sun, 18 Oct 2009 13:27:49 -0700 Message-ID: <009701ca5031$762bc500$62834f00$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01CA4FF6.C9CCED00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpQMXW0DiNlXX3MT8a6yvIhWxACoQ== Content-Language: en-us Subject: [6lowapp] I-D for 6LowAPP Service Discovery X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 20:27:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01CA4FF6.C9CCED00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here is a new I-D submitted for 6LowAPP Service Discovery: https://datatracker.ietf.org/drafts/draft-sturek-6lowapp-servicediscovery/ Hopefully we can find time in Hiroshima to discuss... Don ------=_NextPart_000_0098_01CA4FF6.C9CCED00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is a new I-D submitted for 6LowAPP Service = Discovery:   https://datatracker.ietf.org/drafts/draft-sturek-6lowapp-servi= cediscovery/

 

Hopefully we can find time in Hiroshima to = discuss…….

 

Don

------=_NextPart_000_0098_01CA4FF6.C9CCED00-- From shidan@gmail.com Sun Oct 18 19:49:02 2009 Return-Path: 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 A52B73A677C for <6lowapp@core3.amsl.com>; Sun, 18 Oct 2009 19:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ZB3AEoafnAaT for <6lowapp@core3.amsl.com>; Sun, 18 Oct 2009 19:49:01 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 997B93A6861 for <6lowapp@ietf.org>; Sun, 18 Oct 2009 19:49:01 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so925126eyd.51 for <6lowapp@ietf.org>; Sun, 18 Oct 2009 19:49:05 -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=2QfiB9gSaHh4VncKU06Yt27Cdtzo+I4u0mEmrE3lfec=; b=Ucc0L5vjGW1D1W+MslwQah/Uls0/TU0wYS/vY8DOuP1nfvn+jRqX/leLfM5buKV5o+ V+AX2IWqLOK4ZJ9hJch7hDnpaa1EXej9ITeLgjDxzEIWWhy/+a/A5lmP6fL/GoDamwPQ ExmPH+DzZ/mctvWOEPdfueS9Tb1MzqIh0D7fk= 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=GDmMYP2hb9tnrrIXEZYErIa/Ysjo7KeNSJ6Dii3VfXYDvqmuvc/C78MrbiQHA7PQsC naetaklSxRYABAti9MRi0A4CvDonLd2jZxjn1PqqeFoI6Lt47fUPOzmU7A1OEse8htsI xcWkca3HKdWi4qw1KfIcU/22z8J/v6Whri+pc= MIME-Version: 1.0 Received: by 10.216.88.14 with SMTP id z14mr1549279wee.25.1255920545119; Sun, 18 Oct 2009 19:49:05 -0700 (PDT) In-Reply-To: <52968AFD-40BC-42F0-ACC7-9D22FA1E3CF9@tzi.org> References: <429b380e0910171400g83a10e4r5aff1be8d3c22c0a@mail.gmail.com> <429b380e0910171436r18305389pe922731b566486ee@mail.gmail.com> <52968AFD-40BC-42F0-ACC7-9D22FA1E3CF9@tzi.org> Date: Sun, 18 Oct 2009 22:49:05 -0400 Message-ID: <429b380e0910181949ub867c2dyfa3105176a07a395@mail.gmail.com> From: Shidan To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6d7e925f54001047640c94c Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] SIP and 6LoWPAN & Some General Suggestions 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 02:49:02 -0000 --0016e6d7e925f54001047640c94c Content-Type: text/plain; charset=ISO-8859-1 Thanks for the info Carsten, that makes sense. We have submitted the motivational I-D for SIP as a 6LoWAPP protocol and it can be found here: http://www.ietf.org/id/draft-roychowdhury-6lowappsip-00.txt --- Shidan Gouran On Sat, Oct 17, 2009 at 6:07 PM, Carsten Bormann wrote: > On Oct 17, 2009, at 23:36, Shidan wrote: > > SIGCOMP >> > > SigComp (RFC 3320) is essentially a virtual machine for shipping > decompression code to a peer. > Constrained nodes (as in 8 MHz 10K RAM) won't be able to run such a virtual > machine, I'd say. > > Actually, the whole idea of using complex encodings full of encoding > alternatives (the fact that any of these are text-based is secondary to > that) and then compressing them with a data compression algorithm is > something that may be appropriate out of backwards compatibility, but not > for a new design that emphasizes minimal code complexity. > > Apart from this little nit (sorry, I was involved in RFC 3320), I'm looking > forward to your draft. > > BTW, right now the score is: > > 16 Oct 2009 draft-martocci-6lowapp-building-applications > 16 Oct 2009 draft-shelby-6lowapp-encoding > 14 Oct 2009 draft-schmitt-6lowapp-ipfix-ws > 11 Sep 2009 draft-frank-6lowapp-chopan > 13 Jul 2009 draft-bormann-6lowpan-6lowapp-problem > > 48 more hours to go... > > Gruesse, Carsten > > --0016e6d7e925f54001047640c94c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the info Carsten, that makes sense.

We have s= ubmitted the motivational I-D for SIP as a 6LoWAPP protocol and it can be f= ound here:=A0http://www.ietf.org/id/draft-roychowdhury-6lowa= ppsip-00.txt

---
Shidan Gouran

<= div class=3D"gmail_quote">On Sat, Oct 17, 2009 at 6:07 PM, Carsten Bormann = <cab= o@tzi.org> wrote:
On Oct 17, 2009, at 23:36, Shidan wrote:

SIGCOMP

SigComp (RFC 3320) is essentially a virtual machine for shipping decompress= ion code to a peer.
Constrained nodes (as in 8 MHz 10K RAM) won't be able to run such a vir= tual machine, I'd say.

Actually, the whole idea of using complex encodings full of encoding altern= atives (the fact that any of these are text-based is secondary to that) and= then compressing them with a data compression algorithm is something that = may be appropriate out of backwards compatibility, but not for a new design= that emphasizes minimal code complexity.

Apart from this little nit (sorry, I was involved in RFC 3320), I'm loo= king forward to your draft.

BTW, right now the score is:

16 Oct 2009 =A0draft-martocci-6lowapp-building-applications
16 Oct 2009 =A0draft-shelby-6lowapp-encoding
14 Oct 2009 =A0draft-schmitt-6lowapp-ipfix-ws
11 Sep 2009 =A0draft-frank-6lowapp-chopan
13 Jul 2009 =A0draft-bormann-6lowpan-6lowapp-problem

48 more hours to go...

Gruesse, Carsten


--0016e6d7e925f54001047640c94c-- From zach@sensinode.com Mon Oct 19 06:06:39 2009 Return-Path: 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 A92373A69B5 for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 06:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 RIHyISz2BrON for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 06:06:38 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 523313A6967 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 06:06:38 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9JD6e5q028882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Mon, 19 Oct 2009 16:06:40 +0300 From: Zach Shelby Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 16:06:42 +0300 References: <20091019130350.D9D453A69A4@core3.amsl.com> To: 6lowapp@ietf.org Message-Id: <4A16D036-F76D-4244-9AF8-0E56AB0075F6@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) Subject: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:06:39 -0000 Hi, We have posted a 6lowapp draft summarizing Smart Energy 2.0 with =20 requirements identified for the new working group effort along with =20 possible future work. This is just a first draft, and will surely =20 still evolve during and after Hiroshima. http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt Zach (on behalf of Don) Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 19, 2009 16:03:50 GMT+03:00 > To: zach@sensinode.com > Cc: =20 > = d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.ash= ton@ember.com > Subject: New Version Notification for draft-sturek-6lowapp-=20 > smartenergy-00 > > > A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has =20 > been successfuly submitted by Zach Shelby and posted to the IETF =20 > repository. > > Filename: draft-sturek-6lowapp-smartenergy > Revision: 00 > Title: Smart Energy Requiements for 6LowApp > Creation_date: 2009-10-19 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- > to-end connectivity between energy providers, energy consumers, and > their respective equipment. This effort has been recognized as part > of the Smart Grid roadmap by the US National Institute of Standards > and Technology (NIST). Whereas SE 1 was based on a proprietary > ZigBee stack, SE 2 will is based on IPv6 with support for IEEE > 802.15.4, HomePlug and use across the Internet. The work in 6LowApp > on application protocols and commissioning is an important component > of SE 2. This document introduces SE 2 along with requirements > identified for 6LowApp and considerations for future work. > > > > The IETF Secretariat. > > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From oobles@gmail.com Mon Oct 19 06:59:38 2009 Return-Path: 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 D45CC28C18A for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 06:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 8uKH19kixRAN for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 06:59:34 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9BCB428C0E9 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 06:59:33 -0700 (PDT) Received: by ewy28 with SMTP id 28so4488233ewy.42 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 06:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=EyCDu+PWBUM5yyNF697oftGqPYL3rcPU+0o6qFkqxVM=; b=bWOe1Pi7Ct9ZK9i+VRCPW2GyxpNpsgA0uKupVvC3wO8snAyRBvmZoX40tCGmga+TJF rV/V7/kO/g45i1rYkaCkvVj5pZykQAzneSysbunoRJxcEV1WmUQCe6vpmqCGb5snknk6 8KCT5wgDPIi8rPyhmBVL3ptQcwQFB4Ctrsg7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gNVT1Ybt0Kcsqmce6kPfcMAogmFDeKn/h5bYSMJdCu+Xja/M7As4V6+EQGRY+AU4v1 r6k/GYOwaOhwEqnLI2Ymz+Bxq8wp7J33zt4slr6/2lNs9EA88zVTgSsScxSsvFLIVhG3 T/nWZB7bWCfU8YPBIOMH7nvVr7iKrnKSACWXQ= MIME-Version: 1.0 Received: by 10.211.129.8 with SMTP id g8mr5497185ebn.71.1255960776137; Mon, 19 Oct 2009 06:59:36 -0700 (PDT) Date: Tue, 20 Oct 2009 00:59:36 +1100 Message-ID: <7f996c490910190659s24a57747x56d73cd8ff2503d8@mail.gmail.com> From: David Ryan To: 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [6lowapp] draft-ryanpitt-6lowapp-xpl-00.txt 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:59:38 -0000 Hi, We have submitted draft-ryanpitt-6lowapp-xpl-00.txt for consideration of the 6lowapp working group. It can be found at: http://www.ietf.org/internet-drafts/draft-ryanpitt-6lowapp-xpl-00.txt Please note that we recently discovered other software using the name Extensible Presentation Language (XPL). This is not related to that work. This draft is currently implemented under the name Argot at www.einet.com.au. We are currently deciding what name might be more appropriate. Also in compliance with BCP79, some aspects of the XPL draft have patent pending in the USA and Australia. (United States Patent Application 20070130282) Regards, David. From richard.kelsey@ember.com Mon Oct 19 07:30:52 2009 Return-Path: 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 6C94928C102 for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 zE097DFunahV for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 07:30:51 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A911028C147 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 07:30:51 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:32:08 -0400 Date: Mon, 19 Oct 2009 10:28:55 -0400 Message-Id: <87ws2r8nko.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <52968AFD-40BC-42F0-ACC7-9D22FA1E3CF9@tzi.org> (message from Carsten Bormann on Sun, 18 Oct 2009 00:07:04 +0200) From: Richard Kelsey References: <429b380e0910171400g83a10e4r5aff1be8d3c22c0a@mail.gmail.com> <429b380e0910171436r18305389pe922731b566486ee@mail.gmail.com> <52968AFD-40BC-42F0-ACC7-9D22FA1E3CF9@tzi.org> X-OriginalArrivalTime: 19 Oct 2009 14:32:08.0916 (UTC) FILETIME=[F0536940:01CA50C8] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] SIP and 6LoWPAN & Some General Suggestions 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:30:52 -0000 From: Carsten Bormann Date: Sun, 18 Oct 2009 00:07:04 +0200 Actually, the whole idea of using complex encodings full of encoding alternatives (the fact that any of these are text-based is secondary to that) and then compressing them with a data compression algorithm is something that may be appropriate out of backwards compatibility, but not for a new design that emphasizes minimal code complexity. I agree with you. Would you say that this description includes using XML with EXI for compression? EXI in schema-informed mode is not exactly a data compression algorithm, but it isn't entirely unlike one either. -Richard Kelsey From jmani@comverge.com Mon Oct 19 11:38:22 2009 Return-Path: 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 326953A6827 for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 11:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.572 X-Spam-Level: * X-Spam-Status: No, score=1.572 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] 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 ft6984KW0QDK for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 11:38:21 -0700 (PDT) Received: from newman.comverge.com (unknown [72.1.84.67]) by core3.amsl.com (Postfix) with ESMTP id 5049228C0E6 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 11:38:18 -0700 (PDT) Received: from 24.6.83.145 ([24.6.83.145]) by NEWMAN.comverge.com ([192.168.1.5]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Oct 2009 18:38:28 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 19 Oct 2009 11:38:22 -0700 From: John Mani To: Zach Shelby , <6lowapp@ietf.org> Message-ID: Thread-Topic: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 Thread-Index: AcpQ61XFC/ebeNAhsUGcjtUChK1LFw== In-Reply-To: <4A16D036-F76D-4244-9AF8-0E56AB0075F6@sensinode.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:38:22 -0000 Re: requirement-1 in section 2.1, states that "end-2-end IPv6" is required across both back-end systems and embedded networks in Smart Energy. I'm curious if this requirement can be met for an AMI deployment over the public Internet (not all ISPs support v6 yet ..) -john On 10/19/09 6:06 AM, "Zach Shelby" wrote: > Hi, > > We have posted a 6lowapp draft summarizing Smart Energy 2.0 with > requirements identified for the new working group effort along with > possible future work. This is just a first draft, and will surely > still evolve during and after Hiroshima. > > http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt > > Zach (on behalf of Don) > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: October 19, 2009 16:03:50 GMT+03:00 >> To: zach@sensinode.com >> Cc: >> d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.ashton >> @ember.com >> Subject: New Version Notification for draft-sturek-6lowapp- >> smartenergy-00 >> >> >> A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has >> been successfuly submitted by Zach Shelby and posted to the IETF >> repository. >> >> Filename: draft-sturek-6lowapp-smartenergy >> Revision: 00 >> Title: Smart Energy Requiements for 6LowApp >> Creation_date: 2009-10-19 >> WG ID: Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- >> to-end connectivity between energy providers, energy consumers, and >> their respective equipment. This effort has been recognized as part >> of the Smart Grid roadmap by the US National Institute of Standards >> and Technology (NIST). Whereas SE 1 was based on a proprietary >> ZigBee stack, SE 2 will is based on IPv6 with support for IEEE >> 802.15.4, HomePlug and use across the Internet. The work in 6LowApp >> on application protocols and commissioning is an important component >> of SE 2. This document introduces SE 2 along with requirements >> identified for 6LowApp and considerations for future work. >> >> >> >> The IETF Secretariat. >> >> From d.sturek@att.net Mon Oct 19 11:44:18 2009 Return-Path: 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 3EACD28C10E for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 s1PD5liTq4BO for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 11:44:17 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 67BF928C0FC for <6lowapp@ietf.org>; Mon, 19 Oct 2009 11:44:17 -0700 (PDT) Received: (qmail 22591 invoked from network); 19 Oct 2009 18:44:24 -0000 Received: from unknown (HELO Studio) (d.sturek@65.42.208.133 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Oct 2009 18:44:24 -0000 X-YMail-OSG: dWqePTsVM1m2D.GCC5MdlfUPpAkxrJK4jf5HFKQOPCAqMG9l8796HSCx0eY4D_oP0gV0mJS.ZOgvg9kIZ6t60Q0bMRjm74MqgVJhXNNdZCF.xK2_Yw1afZfApY4WpVJ7uBl7u5aW7SjTCgB5DvvdSPEPw59BUyi460LTjvlJwFSAUHpBc7et88.FGPO7TAB_Wq6WX.dOpzOxEVL6.ehcPFrp152o9_cWzIngxj41xvKTU2yFZlLAokE3lMLWecRu_qD7h9xmiBzzZzBpagdwmPA4DvB74F4ix1au5UWgPy8ORv3C81y.J3ZlPzrtNX6XL7_BWyWNG2VEWTlkbr0E8wk.0PTOeYdMypYFIplmjR7rOdGCcg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'John Mani'" , "'Zach Shelby'" , <6lowapp@ietf.org> References: <4A16D036-F76D-4244-9AF8-0E56AB0075F6@sensinode.com> In-Reply-To: Date: Mon, 19 Oct 2009 11:44:19 -0700 Message-ID: <012101ca50ec$2b3380e0$819a82a0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpQ61XFC/ebeNAhsUGcjtUChK1LFwAAJp9w Content-Language: en-us Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:44:18 -0000 Hi John, I don't think we should make such a requirement for the access side of the meter. I agree with you that using public ISPs will likely mean using IPv4 in many cases. However, for the HAN we are expecting to use just IPv6 due to the critical limitation on IPv4 addresses and the desire to do direct addressing. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of John Mani Sent: Monday, October 19, 2009 11:38 AM To: Zach Shelby; 6lowapp@ietf.org Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 Re: requirement-1 in section 2.1, states that "end-2-end IPv6" is required across both back-end systems and embedded networks in Smart Energy. I'm curious if this requirement can be met for an AMI deployment over the public Internet (not all ISPs support v6 yet ..) -john On 10/19/09 6:06 AM, "Zach Shelby" wrote: > Hi, > > We have posted a 6lowapp draft summarizing Smart Energy 2.0 with > requirements identified for the new working group effort along with > possible future work. This is just a first draft, and will surely > still evolve during and after Hiroshima. > > http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt > > Zach (on behalf of Don) > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: October 19, 2009 16:03:50 GMT+03:00 >> To: zach@sensinode.com >> Cc: >> d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.ashto n >> @ember.com >> Subject: New Version Notification for draft-sturek-6lowapp- >> smartenergy-00 >> >> >> A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has >> been successfuly submitted by Zach Shelby and posted to the IETF >> repository. >> >> Filename: draft-sturek-6lowapp-smartenergy >> Revision: 00 >> Title: Smart Energy Requiements for 6LowApp >> Creation_date: 2009-10-19 >> WG ID: Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- >> to-end connectivity between energy providers, energy consumers, and >> their respective equipment. This effort has been recognized as part >> of the Smart Grid roadmap by the US National Institute of Standards >> and Technology (NIST). Whereas SE 1 was based on a proprietary >> ZigBee stack, SE 2 will is based on IPv6 with support for IEEE >> 802.15.4, HomePlug and use across the Internet. The work in 6LowApp >> on application protocols and commissioning is an important component >> of SE 2. This document introduces SE 2 along with requirements >> identified for 6LowApp and considerations for future work. >> >> >> >> The IETF Secretariat. >> >> _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From jmani@comverge.com Mon Oct 19 11:53:51 2009 Return-Path: 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 D6F423A68EF for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 11:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.572 X-Spam-Level: * X-Spam-Status: No, score=1.572 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] 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 nSQ1vuM5V+Th for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 11:53:51 -0700 (PDT) Received: from newman.comverge.com (unknown [72.1.84.67]) by core3.amsl.com (Postfix) with ESMTP id D9FA43A6857 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 11:53:47 -0700 (PDT) Received: from 24.6.83.145 ([24.6.83.145]) by NEWMAN.comverge.com ([192.168.1.5]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Oct 2009 18:53:57 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Mon, 19 Oct 2009 11:53:51 -0700 From: John Mani To: , <6lowapp@ietf.org> Message-ID: Thread-Topic: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 Thread-Index: AcpQ61XFC/ebeNAhsUGcjtUChK1LFwAAJp9wAABjz5Y= In-Reply-To: <012101ca50ec$2b3380e0$819a82a0$@sturek@att.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:53:51 -0000 Thanks Don. Would it be possible to address (and access) an ipv6 end-node over the Internet? Or is there some proxying/address-translation needed at the 'ESP'? I'm just not familiar with how this all can be achieved technically. The requirement - as stated currently, might be confusing? When it states "across both back-end systems and embedded networks", I take it to include the 'access side of the meter' as well ... -john On 10/19/09 11:44 AM, "Don Sturek" wrote: > Hi John, > > I don't think we should make such a requirement for the access side of the > meter. I agree with you that using public ISPs will likely mean using IPv4 > in many cases. > > However, for the HAN we are expecting to use just IPv6 due to the critical > limitation on IPv4 addresses and the desire to do direct addressing. > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf > Of John Mani > Sent: Monday, October 19, 2009 11:38 AM > To: Zach Shelby; 6lowapp@ietf.org > Subject: Re: [6lowapp] Fwd: New Version Notification for > draft-sturek-6lowapp-smartenergy-00 > > Re: requirement-1 in section 2.1, states that "end-2-end IPv6" is required > across both back-end systems and embedded networks in Smart Energy. > > I'm curious if this requirement can be met for an AMI deployment over the > public Internet (not all ISPs support v6 yet ..) > > -john > > > On 10/19/09 6:06 AM, "Zach Shelby" wrote: > >> Hi, >> >> We have posted a 6lowapp draft summarizing Smart Energy 2.0 with >> requirements identified for the new working group effort along with >> possible future work. This is just a first draft, and will surely >> still evolve during and after Hiroshima. >> >> http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt >> >> Zach (on behalf of Don) >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: October 19, 2009 16:03:50 GMT+03:00 >>> To: zach@sensinode.com >>> Cc: >>> > d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.ashto > n >>> @ember.com >>> Subject: New Version Notification for draft-sturek-6lowapp- >>> smartenergy-00 >>> >>> >>> A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has >>> been successfuly submitted by Zach Shelby and posted to the IETF >>> repository. >>> >>> Filename: draft-sturek-6lowapp-smartenergy >>> Revision: 00 >>> Title: Smart Energy Requiements for 6LowApp >>> Creation_date: 2009-10-19 >>> WG ID: Independent Submission >>> Number_of_pages: 12 >>> >>> Abstract: >>> The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- >>> to-end connectivity between energy providers, energy consumers, and >>> their respective equipment. This effort has been recognized as part >>> of the Smart Grid roadmap by the US National Institute of Standards >>> and Technology (NIST). Whereas SE 1 was based on a proprietary >>> ZigBee stack, SE 2 will is based on IPv6 with support for IEEE >>> 802.15.4, HomePlug and use across the Internet. The work in 6LowApp >>> on application protocols and commissioning is an important component >>> of SE 2. This document introduces SE 2 along with requirements >>> identified for 6LowApp and considerations for future work. >>> >>> >>> >>> The IETF Secretariat. >>> >>> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From zach@sensinode.com Mon Oct 19 13:01:25 2009 Return-Path: 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 2BBDB3A68BB for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 13:01:25 -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 G9tADwZlmBy8 for <6lowapp@core3.amsl.com>; Mon, 19 Oct 2009 13:01:24 -0700 (PDT) Received: from smtp-68.nebula.fi (smtp-68.nebula.fi [83.145.220.68]) by core3.amsl.com (Postfix) with ESMTP id A75153A6825 for <6lowapp@ietf.org>; Mon, 19 Oct 2009 13:00:48 -0700 (PDT) Received: from webmail3.nebula.fi (webmail3.nebula.fi [83.145.246.137]) by smtp-68.nebula.fi (Postfix) with ESMTP id ABAFE43F09AE; Mon, 19 Oct 2009 23:00:53 +0300 (EEST) MIME-Version: 1.0 Date: Mon, 19 Oct 2009 23:00:53 +0300 From: "zach@sensinode.com" To: John Mani In-Reply-To: References: Message-ID: <426cf1a24e6c6c226668bbda939e6ad9@mailserver13.nebula.fi> X-Sender: zach@sensinode.com User-Agent: Nebula Webmail Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 20:01:25 -0000 On Mon, 19 Oct 2009 11:53:51 -0700, John Mani wrote: > Thanks Don. > > Would it be possible to address (and access) an ipv6 end-node over the > Internet? Or is there some proxying/address-translation needed at the > 'ESP'? > I'm just not familiar with how this all can be achieved technically. Yes, all IPv6 nodes (also 6LoWPAN ones) can be addressed and accessed. I interpret this requirement to mean that you should tunnel IPv6-in-IPv4 over whatever IPv4-only parts of the Internet you come across. There are probably half a dozen other alternatives as well but that is the most straight-forward from my experience. > The requirement - as stated currently, might be confusing? When it states > "across both back-end systems and embedded networks", I take it to include > the 'access side of the meter' as well ... You are right, should be clearer. Zach > -john > > > On 10/19/09 11:44 AM, "Don Sturek" wrote: > >> Hi John, >> >> I don't think we should make such a requirement for the access side of >> the >> meter. I agree with you that using public ISPs will likely mean using >> IPv4 >> in many cases. >> >> However, for the HAN we are expecting to use just IPv6 due to the >> critical >> limitation on IPv4 addresses and the desire to do direct addressing. >> >> Don >> >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf >> Of John Mani >> Sent: Monday, October 19, 2009 11:38 AM >> To: Zach Shelby; 6lowapp@ietf.org >> Subject: Re: [6lowapp] Fwd: New Version Notification for >> draft-sturek-6lowapp-smartenergy-00 >> >> Re: requirement-1 in section 2.1, states that "end-2-end IPv6" is >> required >> across both back-end systems and embedded networks in Smart Energy. >> >> I'm curious if this requirement can be met for an AMI deployment over the >> public Internet (not all ISPs support v6 yet ..) >> >> -john >> >> >> On 10/19/09 6:06 AM, "Zach Shelby" wrote: >> >>> Hi, >>> >>> We have posted a 6lowapp draft summarizing Smart Energy 2.0 with >>> requirements identified for the new working group effort along with >>> possible future work. This is just a first draft, and will surely >>> still evolve during and after Hiroshima. >>> >>> http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt >>> >>> Zach (on behalf of Don) >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool >>>> Date: October 19, 2009 16:03:50 GMT+03:00 >>>> To: zach@sensinode.com >>>> Cc: >>>> >> d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.ashto >> n >>>> @ember.com >>>> Subject: New Version Notification for draft-sturek-6lowapp- >>>> smartenergy-00 >>>> >>>> >>>> A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has >>>> been successfuly submitted by Zach Shelby and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-sturek-6lowapp-smartenergy >>>> Revision: 00 >>>> Title: Smart Energy Requiements for 6LowApp >>>> Creation_date: 2009-10-19 >>>> WG ID: Independent Submission >>>> Number_of_pages: 12 >>>> >>>> Abstract: >>>> The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- >>>> to-end connectivity between energy providers, energy consumers, and >>>> their respective equipment. This effort has been recognized as part >>>> of the Smart Grid roadmap by the US National Institute of Standards >>>> and Technology (NIST). Whereas SE 1 was based on a proprietary >>>> ZigBee stack, SE 2 will is based on IPv6 with support for IEEE >>>> 802.15.4, HomePlug and use across the Internet. The work in 6LowApp >>>> on application protocols and commissioning is an important component >>>> of SE 2. This document introduces SE 2 along with requirements >>>> identified for 6LowApp and considerations for future work. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From richard.gold@ericsson.com Tue Oct 20 00:30:56 2009 Return-Path: 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 931C83A67FA for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 00:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 IGnl5fujncC0 for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 00:30:55 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BCF813A67E7 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 00:30:54 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-d5-4add6734c2b2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BE.64.04191.4376DDA4; Tue, 20 Oct 2009 09:31:00 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 09:30:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Oct 2009 09:30:57 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0144_01CA5168.07336DA0" Message-ID: <53CCFDD6E346CB43994852666C210E9108B0F952@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New draft on requirements from the SENSEI project Thread-Index: AcpRV0NI6E9plWcrQw+0sFtI+I1/6Q== From: "Richard Gold" To: <6lowapp@ietf.org> X-OriginalArrivalTime: 20 Oct 2009 07:30:57.0936 (UTC) FILETIME=[440FA100:01CA5157] X-Brightmail-Tracker: AAAAAA== Subject: [6lowapp] New draft on requirements from the SENSEI project 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 07:30:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0144_01CA5168.07336DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Zach & I (among others) have put together a draft of requirements which were inspired by an EU project we've been working on called SENSEI. The draft is available here: http://www.ietf.org/id/draft-gold-6lowapp-sensei-00.txt SENSEI is a large-scale EU project investigating frameworks for global-scale sensor network applications and it has a website here: http://www.sensei-project.eu/ See you in Hiroshima! Best regards, Richard Gold Ericsson AB Email: richard.gold@ericsson.com ------=_NextPart_000_0144_01CA5168.07336DA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQTzCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIELDCCAxSgAwIBAgIQEC4Sgk+8ASEcqT7U37xxbzANBgkqhkiG9w0BAQUFADA5 MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAx MB4XDTA4MDEyOTEwMTQxMVoXDTExMDEyOTEwMTQwOFowZjERMA8GA1UECgwIRXJpY3Nzb24xFTAT BgNVBAMMDFJpY2hhcmQgR29sZDEQMA4GA1UEBRMHZXJpY2dvbDEoMCYGCSqGSIb3DQEJARYZcmlj aGFyZC5nb2xkQGVyaWNzc29uLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAgNpISh7o yjD8ee3+2Xtf0h7R8ZrTi974o80rB9A+eDHH+/pz9ML+w+AFqTt0ZcVVssTSGDIljxHsmJ0/I+Yx +xjf9jlAS2qiOBfElFqNbn6IEEP/XuJmKeHtVF475wBxWogVuHG9ZyzXej9uzjCGe2QRsyAI86zC W+w9Xvf9LVkCAwEAAaOCAYUwggGBMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFw LnRydXN0LnRlbGlhLmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1F cmljc3Nvbj9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCQGA1UdEQQdMBuB GXJpY2hhcmQuZ29sZEBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEF BQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFFZokqxZ FGMgnc1ol8/odWIouYivMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB /wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEACqmlJZ7l7SUnVRsv8p+A24zGRZ9zTxBh2QM4kRz+ 0Wa9t2FFkUjlz3oaG237Ro4kvWTEZvwVVMA5awvERwpfAyoHvASR3WvZ7/WrjE39YUfZkWoWcWzu PstweByadx0GTHXmPDZCsCqKplEpw0Vz6kt7HL4JtfW0IEarMMlZZOm+2hIUMmEh7Y+FTZgxFiiG uC54FN5zRRYflracNu9nmhlNhiUhnoTYKKwNQRozljmiAwidMRN9/VhAyJXMa0GjIBRVfyI+Nqpz GYH5VvQJtPg3qUSM1zc2whHcMwmZH7M0RFVDrYYGe+AOFYe4EAF+nD+fq8MY23T7vQI+6To2OzCC BEUwggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwR VGVsaWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYx MB4XDTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAi BgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqI EyHv1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFS fhqTu3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNf HWMcCYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJ qzUbAz2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1Ud EwEB/wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBz Oi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8v bGRhcC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0El MjB2MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaA FEXb8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/Yn whXIv6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8H utzYFSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJB WZ67OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1 Xq3kMXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXY z+OYCMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEF BQAwOjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIw NDggVjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNv bmVyYSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lIC KF5DuVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHp N0pe1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1Qp QhF46H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liD BjghXYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMB AAGjggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvw j7gaYqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG 9w0FBgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7 BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5j b20wcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMv a2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5D UkwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgv hOUEkUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3Zwh MyDCfkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouM vM6bKuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/ OLHntP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHde VxPdOI5GtDYPMYICezCCAncCAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhAQLhKCT7wBIRypPtTfvHFvMAkGBSsOAwIaBQCgggGE MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTAyMDA3MzA1N1ow IwYJKoZIhvcNAQkEMRYEFHnMDdbB7qJR+lF6qNNhWUplR9jKMFwGCSsGAQQBgjcQBDFPME0wOTER MA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQ EC4Sgk+8ASEcqT7U37xxbzBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24x JDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQEC4Sgk+8ASEcqT7U37xxbzBn BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0B AQEFAASBgFLwvznC388ZwUM6URxkHvidUOgLb50w/8Z5ZyRODhomdl/1rt5Ot8fBboRjZNa5BWE5 ykV7HQCoWrabEtk8gIbX+2FqSecbQgeWdcZGgfKLAnb6oOl4DiqYkQ0ed2ZVd/gA3wg0VOcieI01 R1zA9EKrbgo8eV7CDgvSJDKmERicAAAAAAAA ------=_NextPart_000_0144_01CA5168.07336DA0-- From zach@sensinode.com Tue Oct 20 02:15:39 2009 Return-Path: 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 F18993A6A16 for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 02:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 LHmz1EyiKKYH for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 02:15:38 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 98AFB3A699A for <6lowapp@ietf.org>; Tue, 20 Oct 2009 02:15:37 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9K9Fe5Y014013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:15:41 +0300 From: Zach Shelby Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 12:15:42 +0300 Message-Id: <61FCF058-4745-48A6-B30D-14122727FBD1@sensinode.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) Subject: [6lowapp] Wiki updated, 11 drafts so far 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:15:39 -0000 Hi, We now have a total of 11 I-D submissions to 6LowApp, thanks everyone =20= for all the hard work up to last night's deadline! I updated the Wiki with links to all the drafts under "More =20 Resources". Hope this makes it easier to find them all. I tried to =20 loosely group them by Requirements, Protocol and Discovery themes. If =20= I missed something that should be listed just let us know. http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From jukka.manner@tkk.fi Tue Oct 20 02:57:18 2009 Return-Path: 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 DC3C43A6889 for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 02:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.763 X-Spam-Level: X-Spam-Status: No, score=-5.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XgXH7NdqohFU for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 02:57:18 -0700 (PDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id C437F3A67F8 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 02:57:17 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id n9K9vNnJ002603 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:57:23 +0300 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 10532-205-25 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:57:23 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id n9K9tIAP001736 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:55:19 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 928501E13F for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:55:18 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VPjfYT0pwge4 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:55:14 +0300 (EEST) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id ACD9F1E125 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:55:14 +0300 (EEST) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 9F5A1120050 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 12:55:14 +0300 (EEST) Message-ID: <4ADD8900.2010003@tkk.fi> Date: Tue, 20 Oct 2009 12:55:12 +0300 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6LowAPP <6lowapp@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Mailman-Approved-At: Tue, 20 Oct 2009 03:09:15 -0700 Subject: [6lowapp] Some high-level thoughts on service discovery (draft-manner-6lowapp-sdnd-00) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:57:18 -0000 Hi, I managed to put some of my own thoughts on service discovery into a draft and submitted that yesterday. The basic idea is to reuse the ND work and extend that to carry also service information (and add a lookup/reply functionality). More info in the draft. cheers, Jukka ------------------------------------- A new version of I-D, draft-manner-6lowapp-sdnd-00.txt has been successfuly submitted by Jukka Manner and posted to the IETF repository. Filename: draft-manner-6lowapp-sdnd Revision: 00 Title: Coupling of Service and Neighbor Discovery in 6LowPAN Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 7 Abstract: Finding out functionality, nodes or services, in general resources, in a network has a number of well-known solutions. A sensor network has inherent limitations and requires a solution that has a low footprint and follows the networking concepts defined within 6LoWPAN. This draft discusses two alternative solutions to service discovery in a sensor network. Both approaches are based on the 6LowPAN Neighbor Discovery. From cabo@tzi.org Tue Oct 20 08:05:10 2009 Return-Path: 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 7AB9F28C0DB for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 k96znuFaHm6u for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 08:05:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6B07528C0CF for <6lowapp@ietf.org>; Tue, 20 Oct 2009 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9KF573O023655; Tue, 20 Oct 2009 17:05:07 +0200 (CEST) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 52219B565; Tue, 20 Oct 2009 17:05:07 +0200 (CEST) From: Carsten Bormann To: 6lowapp@ietf.org In-Reply-To: <61FCF058-4745-48A6-B30D-14122727FBD1@sensinode.com> References: <61FCF058-4745-48A6-B30D-14122727FBD1@sensinode.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 17:05:06 +0200 X-Mailer: Apple Mail (2.936) Subject: Re: [6lowapp] Wiki updated, 11 drafts so far 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 15:05:10 -0000 > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp ... and one more about Security, which is still stuck in the Internet- Drafts processing, is now also linked from that Wiki. Gruesse, Carsten From jmani@comverge.com Tue Oct 20 16:10:26 2009 Return-Path: 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 B85133A681A for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 16:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.572 X-Spam-Level: * X-Spam-Status: No, score=1.572 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] 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 2sMbjYAa2qKR for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 16:10:25 -0700 (PDT) Received: from newman.comverge.com (unknown [72.1.84.67]) by core3.amsl.com (Postfix) with ESMTP id 8BD0C3A67B6 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 16:10:22 -0700 (PDT) Received: from 192.206.180.200 ([192.206.180.200]) by NEWMAN.comverge.com ([192.168.1.5]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Oct 2009 23:10:34 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 20 Oct 2009 16:10:28 -0700 From: John Mani To: "zach@sensinode.com" Message-ID: Thread-Topic: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 Thread-Index: AcpR2oM8aDU5Gg58kkeLygFcb30Wtw== In-Reply-To: <426cf1a24e6c6c226668bbda939e6ad9@mailserver13.nebula.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:10:26 -0000 Another requirement - not HAN specific, is support for a low-latency mechanism to send a message to a large number of HAN devices from a backend system. An example use case is a Load management system sending a 'load-shed' message to a large subset of its customers for immediate grid reliability needs. This implies some sort of efficient broadcast/multicast mechanism. Not sure if this requirement really belongs here, just wanted to bring this point up .. -john On 10/19/09 1:00 PM, "zach@sensinode.com" wrote: > On Mon, 19 Oct 2009 11:53:51 -0700, John Mani wrote: >> Thanks Don. >> >> Would it be possible to address (and access) an ipv6 end-node over the >> Internet? Or is there some proxying/address-translation needed at the >> 'ESP'? >> I'm just not familiar with how this all can be achieved technically. > > Yes, all IPv6 nodes (also 6LoWPAN ones) can be addressed and accessed. I > interpret this requirement to mean that you should tunnel IPv6-in-IPv4 over > > whatever IPv4-only parts of the Internet you come across. There are > probably > half a dozen other alternatives as well but that is the most > straight-forward > from my experience. > >> The requirement - as stated currently, might be confusing? When it states >> "across both back-end systems and embedded networks", I take it to > include >> the 'access side of the meter' as well ... > > You are right, should be clearer. > > Zach > >> -john >> >> >> On 10/19/09 11:44 AM, "Don Sturek" wrote: >> >>> Hi John, >>> >>> I don't think we should make such a requirement for the access side of >>> the >>> meter. I agree with you that using public ISPs will likely mean using >>> IPv4 >>> in many cases. >>> >>> However, for the HAN we are expecting to use just IPv6 due to the >>> critical >>> limitation on IPv4 addresses and the desire to do direct addressing. >>> >>> Don >>> >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >>> Behalf >>> Of John Mani >>> Sent: Monday, October 19, 2009 11:38 AM >>> To: Zach Shelby; 6lowapp@ietf.org >>> Subject: Re: [6lowapp] Fwd: New Version Notification for >>> draft-sturek-6lowapp-smartenergy-00 >>> >>> Re: requirement-1 in section 2.1, states that "end-2-end IPv6" is >>> required >>> across both back-end systems and embedded networks in Smart Energy. >>> >>> I'm curious if this requirement can be met for an AMI deployment over > the >>> public Internet (not all ISPs support v6 yet ..) >>> >>> -john >>> >>> >>> On 10/19/09 6:06 AM, "Zach Shelby" wrote: >>> >>>> Hi, >>>> >>>> We have posted a 6lowapp draft summarizing Smart Energy 2.0 with >>>> requirements identified for the new working group effort along with >>>> possible future work. This is just a first draft, and will surely >>>> still evolve during and after Hiroshima. >>>> >>>> http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt >>>> >>>> Zach (on behalf of Don) >>>> >>>> Begin forwarded message: >>>> >>>>> From: IETF I-D Submission Tool >>>>> Date: October 19, 2009 16:03:50 GMT+03:00 >>>>> To: zach@sensinode.com >>>>> Cc: >>>>> >>> > d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.ashto >>> n >>>>> @ember.com >>>>> Subject: New Version Notification for draft-sturek-6lowapp- >>>>> smartenergy-00 >>>>> >>>>> >>>>> A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has >>>>> been successfuly submitted by Zach Shelby and posted to the IETF >>>>> repository. >>>>> >>>>> Filename: draft-sturek-6lowapp-smartenergy >>>>> Revision: 00 >>>>> Title: Smart Energy Requiements for 6LowApp >>>>> Creation_date: 2009-10-19 >>>>> WG ID: Independent Submission >>>>> Number_of_pages: 12 >>>>> >>>>> Abstract: >>>>> The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- >>>>> to-end connectivity between energy providers, energy consumers, and >>>>> their respective equipment. This effort has been recognized as part >>>>> of the Smart Grid roadmap by the US National Institute of Standards >>>>> and Technology (NIST). Whereas SE 1 was based on a proprietary >>>>> ZigBee stack, SE 2 will is based on IPv6 with support for IEEE >>>>> 802.15.4, HomePlug and use across the Internet. The work in 6LowApp >>>>> on application protocols and commissioning is an important component >>>>> of SE 2. This document introduces SE 2 along with requirements >>>>> identified for 6LowApp and considerations for future work. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp From arjunrc@gmail.com Tue Oct 20 17:39:13 2009 Return-Path: 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 B6F4C3A68E3 for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 17:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 mGFQfjuupZip for <6lowapp@core3.amsl.com>; Tue, 20 Oct 2009 17:39:12 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id C42ED3A696C for <6lowapp@ietf.org>; Tue, 20 Oct 2009 17:39:12 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so821542qwb.31 for <6lowapp@ietf.org>; Tue, 20 Oct 2009 17:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=dKh00r3Q59HJGSoDIqY4i6D9hUP06RabTx/yXHUOB6E=; b=T9/Yu19FQrkwVKU+hYN8qxEhaCNB0N275sVKL1BgD16A5ul14DATS8BZrjSC2Xec92 nt/oAxviGsQ2VpQMjDUm8HUB8fmeb4b2GQ8zBU3LHXHGjXn9O1iQ+SgJ9Lp4W9qUyhG3 Yt7bDdAdb8No7Ariao2QWcrqtHcPAGkLgSg2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:from:date:x-google-sender-auth :message-id:subject:to:content-type; b=YCHX3916QBXPsnWFTKeJkUZsMu8sNg5HDDbWG4kXkRdRpZpFxPXBklwJtn6QGlmomm Fk+VyfkD0NRDrXx6D6MxGdjVAuJNs5R82YRs1ZbRItq2AJoGLxm6Wgiz8tAxjShAsKda Kyj5UNX4fJrYTS7xuK9ctp0+gaDWFo8sIXueQ= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.115.83 with SMTP id h19mr3496464qaq.351.1256085558180; Tue, 20 Oct 2009 17:39:18 -0700 (PDT) From: Arjun Roychowdhury Date: Tue, 20 Oct 2009 20:38:58 -0400 X-Google-Sender-Auth: bbf55bb295004810 Message-ID: To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=00148502ae8380be9804766735d4 Subject: [6lowapp] On selecting protocols: latency before flexibility or the other way around? X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 00:39:13 -0000 --00148502ae8380be9804766735d4 Content-Type: text/plain; charset=ISO-8859-1 Hi,my apologies if this discussion has been initiated before (I did not see it though, in the archives) I've been reading the past threads of discussions with a lot of interest and I notice that most discussions put latency and payload size ahead of discussing the features that could drive these devices. I just wonder if this group should consider switching the priorities around - first agree on what are the best features this network can benefit from and then address which protocols & formats meet these needs and what can be done to optimize them for the characteristics of the underlying network. It's an approach I think that 6lowpan itself took - isn't it? IPV6 was chosen due to its several advantages and then, RFC 4944 decided how to best optimize and/or compress it. In my mind, features and flexibility of the carrier protocols are more important than whether it supports millisecond response times "as it stands today" - just my past experience that when we make design choices based on size first, we make compromises on the best solution and ignore "adaptations" that could solve the latency and timing issues (if that were not the case, we would never have binary XML, JSON, SIGCOMPed SIP and even 6lowPAN which adapted popular protocols to various network conditions). So the short of it, I'd love to see a discussion on: a) What are the features we believe the current and next generation devices will bring in, if given a chance ? b) What are the control mechanisms that users would like if devices were able to offer more functionality? regds arjun -- Arjun Roychowdhury Hughes Systique Corp. --00148502ae8380be9804766735d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
my apologies if this discussion has been initiated before (I did no= t see it though, in the archives)

I've been re= ading the past threads of discussions with a lot of interest and I notice t= hat most discussions put latency and payload size ahead of discussing the f= eatures that could drive these devices. I just wonder if this group should = consider switching the priorities around - first agree on what are the best= features this network can benefit from and then address which protocols &a= mp; formats meet these needs and what can be done to optimize them for the = characteristics of the underlying network. It's an approach I think tha= t 6lowpan itself took - isn't it? IPV6 was chosen due to its several ad= vantages and then, RFC 4944 decided how to best optimize and/or compress it= . In my mind, features and flexibility of the carrier=A0protocols=A0are mor= e important than whether it supports millisecond response times "as it= stands today" - just my past experience that when we make design choi= ces based on size first, we make compromises on the best solution and ignor= e "adaptations" that could solve the latency and timing issues (i= f that were not the case, we would never have binary XML, JSON, SIGCOMPed S= IP and even 6lowPAN which adapted popular protocols to various network cond= itions).

So the short of it, I'd love to see a discussion on= :
a) What are the features we believe the current and next genera= tion devices will bring in, if given a chance ?
b) What are the c= ontrol mechanisms that users would like if devices were able to offer more = functionality?

regds
arjun


-= -
Arjun Roychowdhury
Hughes Systique Corp.

--00148502ae8380be9804766735d4-- From hamid.mukhtar@gmail.com Tue Oct 20 19:48:22 2009 Return-Path: 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 DCD383A69C2; Tue, 20 Oct 2009 19:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.526 X-Spam-Level: X-Spam-Status: No, score=-99.526 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] 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 yAu44Y1CA906; Tue, 20 Oct 2009 19:48:21 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9751F3A6937; Tue, 20 Oct 2009 19:48:21 -0700 (PDT) Received: by yxe30 with SMTP id 30so8276014yxe.29 for ; Tue, 20 Oct 2009 19:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=SAtyeKOifz7WKgchRVhgprbPY7d5gHYT+ZKJCc0NhQU=; b=ax/5PwuWjaOS26TTFxLHINQbv1SG12NaKEDVoxCjFQnuNHXGnBfNLo3vx5MESazwPq NkY/slwtTyoUpJXA1l63YYaaRuzYaM4rgwOskm8FcW+ilFeZMzrYlV9A8WeN45MEtucU MoLiwx6AarwWkLcdcRaCq8tso5r7G5NoOf/N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=q0UQNTGeYKtt94DvDelmgGe5d70z9trDEO1n98PS1hyrFlW2oiNerc+OUEdPQUkjPr EPRh0Myf5EjTHhCnsWF6wGhgDCItZzm/alaiURO9WIxey5e97h3jgccr90yeE2C18Jun JievxWik3FtNsDmeAZ/+winJfuGeL9CC26+bU= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.101.152.13 with SMTP id e13mr4435505ano.107.1256093307097; Tue, 20 Oct 2009 19:48:27 -0700 (PDT) In-Reply-To: <9F66D2FD931D42D0A3446E17C8A0FB5B@etri.info> References: <9F66D2FD931D42D0A3446E17C8A0FB5B@etri.info> From: Hamid Mukhtar Date: Wed, 21 Oct 2009 11:48:12 +0900 X-Google-Sender-Auth: 1eed07e7eae1d954 Message-ID: To: 6lowpan@ietf.org, 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=0016368e315a5fd27e04766903e0 Cc: =?UTF-8?B?7KO87ISx7Iic?= , =?UTF-8?B?S2ktSHl1bmcgS2ltICjquYDquLDtmJUp?= Subject: [6lowapp] Fwd: New Version Notification for draft-hamid-6lowpan-snmp-optimizations-02 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 02:48:22 -0000 --0016368e315a5fd27e04766903e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We have revised the I-D "SNMP Optimizations for 6LoWPAN" ( http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-02) based on the comments received in Stockholm. The new version covers the applicability of SNMP in 6LoWPANs with implementation and deployment considerations. Any reviews or comments are appreciated. Thanks, -----=EC=9B=90=EB=B3=B8 =EB=A9=94=EC=8B=9C=EC=A7=80----- *From:* "IETF I-D Submission Tool" *From Date:* 2009-10-21 =EC=98=A4=EC=A0=84 11:32:24 *To:* "hamid@etri.re.kr" *Cc:* "ssjoo@etri.re.kr" , " j.schoenwaelder@jacobs-university.de" , "kkim86@ajou.ac.kr" *Subject:* New Version Notification for draft-hamid-6lowpan-snmp-optimizations-02 A new version of I-D, draft-hamid-6lowpan-snmp-optimizations-02.txt has bee= n successfuly submitted by Hamid Mukhtar and posted to the IETF repository. Filename: draft-hamid-6lowpan-snmp-optimizations Revision: 02 Title: SNMP optimizations for 6LoWPAN Creation_date: 2009-10-21 WG ID: Independent Submission Number_of_pages: 17 Abstract: Simple Network Management Protocol (SNMP) is a widely deployed application protocol for network management and data retrieval. In this document we describe the applicability of SNMP for 6LoWPANs. We discuss the implementation considerations of SNMP Agent and SNMP Manager followed by the deployment considerations of the SNMP protocol. Our discussion also covers the applicability of MIB modules for 6LoWPAN devices. The IETF Secretariat. --0016368e315a5fd27e04766903e0 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Hi,
 
We have revised the I-D "SNMP Optimizations for 6LoWPAN"= ; (http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-= 02) based on the comments received in Stockholm. The new version c= overs the applicability of SNMP in 6LoWPANs with implementation and deploym= ent considerations.
 
Any reviews or comments are appreciated.
 
Thanks,
 


A new version of I-D, draft-hamid-6lowpan-snmp-optimiza= tions-02.txt has been successfuly submitted by Hamid Mukhtar and posted to = the IETF repository.

Filename:      &n= bsp; draft-hamid-6lowpan-snmp-optimizations
Revision:        02
Title:  &nbs= p;        SNMP optimizations for 6LoWPAN=
Creation_date:   2009-10-21
WG ID:     = ;      Independent Submission
Number_of_pages: = 17

Abstract:
Simple Network Management Protocol (SNMP) is a widel= y deployed
application protocol for network management and data retrieval.  Inthis document we describe the applicability of SNMP for 6LoWPANs.  We=
discuss the implementation considerations of SNMP Agent and SNMP
Man= ager followed by the deployment considerations of the SNMP
protocol.  Our discussion also covers the applicability of MIB
modu= les for 6LoWPAN devices.
        = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          

The IETF Secretariat.



--0016368e315a5fd27e04766903e0-- From hamid.mukhtar@gmail.com Thu Oct 22 22:26:30 2009 Return-Path: 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 8E1F23A6923 for <6lowapp@core3.amsl.com>; Thu, 22 Oct 2009 22:26:30 -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 TYb348q9nzwh for <6lowapp@core3.amsl.com>; Thu, 22 Oct 2009 22:26:29 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 4EA9C3A69B0 for <6lowapp@ietf.org>; Thu, 22 Oct 2009 22:26:26 -0700 (PDT) Received: by gxk28 with SMTP id 28so7676417gxk.9 for <6lowapp@ietf.org>; Thu, 22 Oct 2009 22:26:32 -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 :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=a2y2FL0sz2drmz8TcjCCv09zKVXr3kIeZWGh/ksG4aM=; b=pFrhL2oSJ00jLNx4I1ogfyFGYzTssc9ERp7IXmPX3twBAxlQC4SQJUs2FUmzsUp6kc 1n6TD6+s448jlDd3ghAOsQippmLekf+f+DFGWp+DwRQ8kt2iA/zXV3QPJjj2cC+Lo2NJ J2NEspwxpd4NDzHyLkPFxlhHmOYmsmdL6fKsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=vvOZllewA0B+6BU2XRSA+63KbONmlmrbTvOCazF79PvoHTPujiVhmN0oiCIOTTWKa7 AjkFHf/KSqfGRNNX9xhoFiEwva+HV9WXm1wikRkLn68iW9UXXY0Bwlg3PdhFyCKuKWGp uSFnXpm7lKSjQJiB/xFC3DQ/zT5q7B0NLPQ+U= MIME-Version: 1.0 Received: by 10.101.126.10 with SMTP id d10mr6556229ann.147.1256275592208; Thu, 22 Oct 2009 22:26:32 -0700 (PDT) In-Reply-To: <4A16D036-F76D-4244-9AF8-0E56AB0075F6@sensinode.com> References: <20091019130350.D9D453A69A4@core3.amsl.com> <4A16D036-F76D-4244-9AF8-0E56AB0075F6@sensinode.com> From: Hamid Mukhtar Date: Fri, 23 Oct 2009 14:26:17 +0900 Message-ID: To: 6lowapp@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [6lowapp] Fwd: New Version Notification for draft-sturek-6lowapp-smartenergy-00 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 05:26:30 -0000 > (12) SE 2 requires support of efficient network management in the > HAN. The SE 2 application protocol must support get and set > operations required for application and device management. It > is not expected that limited nodes support SNMP, but instead > may use the same application protocol also for management. SNMP is datagram oriented and the implementations can be pretty lightweight. Although it may be possible to provide network management capabilities through the new application protocol, SNMP may still hold its significance due to its technical maturity established by experiences in the implementation and operation. I don't think ruling SNMP out would be an appropriate option. On Mon, Oct 19, 2009 at 10:06 PM, Zach Shelby wrote: > Hi, > > We have posted a 6lowapp draft summarizing Smart Energy 2.0 with > requirements identified for the new working group effort along with possi= ble > future work. This is just a first draft, and will surely still evolve dur= ing > and after Hiroshima. > > http://www.ietf.org/id/draft-sturek-6lowapp-smartenergy-00.txt > > Zach (on behalf of Don) > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: October 19, 2009 16:03:50 GMT+03:00 >> To: zach@sensinode.com >> Cc: >> d.sturek@att.net,Daniel.Lohman@itron.com,Michael.Stuber@itron.com,skip.a= shton@ember.com >> Subject: New Version Notification for draft-sturek-6lowapp-smartenergy-0= 0 >> >> >> A new version of I-D, draft-sturek-6lowapp-smartenergy-00.txt has been >> successfuly submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0 =A0draft-sturek-6lowapp-smartenergy >> Revision: =A0 =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 Smart Energy Requiements for 6LowApp >> Creation_date: =A0 2009-10-19 >> WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end- >> to-end connectivity between energy providers, energy consumers, and >> their respective equipment. =A0This effort has been recognized as part >> of the Smart Grid roadmap by the US National Institute of Standards >> and Technology (NIST). =A0Whereas SE 1 was based on a proprietary >> ZigBee stack, SE 2 will is based on IPv6 with support for IEEE >> 802.15.4, HomePlug and use across the Internet. =A0The work in 6LowApp >> on application protocols and commissioning is an important component >> of SE 2. =A0This document introduces SE 2 along with requirements >> identified for 6LowApp and considerations for future work. >> >> >> >> The IETF Secretariat. >> >> > > -- > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From rstruik@certicom.com Mon Oct 26 13:19:21 2009 Return-Path: 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 6A59D3A6A80 for <6lowapp@core3.amsl.com>; Mon, 26 Oct 2009 13:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cCr77snyMnsp for <6lowapp@core3.amsl.com>; Mon, 26 Oct 2009 13:19:20 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id A5B073A67AA for <6lowapp@ietf.org>; Mon, 26 Oct 2009 13:19:17 -0700 (PDT) X-AuditID: 0a666446-b7b48ae000001222-76-4ae604524e0e Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id BC.71.04642.25406EA4; Mon, 26 Oct 2009 16:19:30 -0400 (EDT) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:19:30 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 Date: Mon, 26 Oct 2009 16:18:53 -0400 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC401BFC3A4@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-struik-6lowapp-security-considerations Thread-Index: AcpRDnK7wGXa7IvxS82OhUhH2sjmewFano3g From: "Rene Struik" To: <6lowapp@ietf.org> X-OriginalArrivalTime: 26 Oct 2009 20:19:30.0204 (UTC) FILETIME=[9F97D5C0:01CA5679] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: [6lowapp] draft-struik-6lowapp-security-considerations 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:19:21 -0000 RGVhciBjb2xsZWFndWVzOg0KDQpQbGVhc2UgYmUgYWR2aXNlZCBvZiB0aGUgZm9sbG93aW5n IGludGVybmV0IGRyYWZ0LCB3aGljaCBJIHN1Ym1pdHRlZCBNb25kYXkgbGFzdCB3ZWVrLCBP Y3RvYmVyIDE5LCAyMDA5Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXN0cnVp ay02bG93YXBwLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zLTAwLnR4dA0KDQpCZXN0IHJlZ2Fy ZHMsIFJlbmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1E IFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50 OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMDkgNjo1MCBQTQ0KVG86IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KQ2M6IFJlbmUgU3RydWlrDQpTdWJqZWN0OiBNYW51YWwgUG9zdCBSZXF1 ZXN0ZWQgZm9yIGRyYWZ0LXN0cnVpay02bG93YXBwLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25z IA0KDQpNYW51YWwgUG9zdGluZyBSZXF1ZXN0ZWQgZm9yIGZvbGxvd2luZyBJbnRlcm5ldC1E cmFmdDoNCg0KSS1EIFN1Ym1pc3Npb24gVG9vbCBVUkw6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvaWRzdC9zdGF0dXMuY2dpP3N1Ym1pc3Npb25faWQ9MTg4ODMNCg0KDQpGaWxl bmFtZToJICAgZHJhZnQtc3RydWlrLTZsb3dhcHAtc2VjdXJpdHktY29uc2lkZXJhdGlvbnMN ClZlcnNpb246CSAgIDAwDQpTdGFnaW5nIFVSTDoJICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z dGFnaW5nL2RyYWZ0LXN0cnVpay02bG93YXBwLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zLTAw LnR4dA0KVGl0bGU6CQkgICBTZWN1cml0eSBBcmNoaXRlY3R1cmFsIERlc2lnbiBDb25zaWRl cmF0aW9ucyBmb3IgTG93LVBvd2VyIFdpcmVsZXNzIFNlbnNvciBOZXR3b3Jrcw0KQ3JlYXRp b25fZGF0ZToJICAgMjAwOS0xMC0xOQ0KV0cgSUQ6CQkgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCk51bWJlcl9vZl9wYWdlczogMjENCkFic3RyYWN0Og0KV2UgZGlzY3VzcyBzZWN1cml0 eSBhcmNoaXRlY3R1cmFsIGRlc2lnbiBjb25zaWRlcmF0aW9ucyBmb3INCiAgZ2VuZXJhbC1w dXJwb3NlIG11bHRpLWhvcCBhZC1ob2MgbmV0d29ya3MuIFRoZSBzZWN1cml0eQ0KICBhcmNo aXRlY3R1cmUgZml0cyBleHRyZW1lbHkgY29uc3RyYWluZWQgd2lyZWxlc3MgZW52aXJvbm1l bnRzLA0KICBzdWNoIGFzIHNlbnNvciBuZXR3b3Jrcywgd2hpbGUgcmVtYWluaW5nIHVuaWZv cm0gYW5kIGdlbmVyYWwNCiAgZW5vdWdoIHRvIGZpdCBhbnkgd2lyZWxlc3MgbmV0d29yay4g VGhlIGRlc2lnbiBpcyB0YWlsb3JlZCB0b3dhcmRzDQogIGxvdyBvdmVyYWxsIGltcGxlbWVu dGF0aW9uIGNvc3QsIHN1cHBvcnRzIHNlbWktYXV0b21hdGljIGxpZmVjeWNsZQ0KICBtYW5h Z2VtZW50LCBpbmNsdWRpbmcgZWFzZSBvZiBpbnN0YWxsYXRpb24gYW5kIGNvbmZpZ3VyYXRp b24sDQogIHNjYWxhYmlsaXR5LCBzdXJ2aXZhYmlsaXR5LCBtb2JpbGl0eSwgYW5kIGlzIGFk YXB0YWJsZSB0b3dhcmRzDQogIG5ldHdvcmsgdG9wb2xvZ3kgY2hhbmdlcyBhbmQgdG93YXJk cyBkaWZmZXJlbnQgdHJ1c3QgbW9kZWxzDQogIHVuZGVybHlpbmcgbmV0d29yayBvcGVyYXRp b25zLg0KDQpTdWJtaXR0ZXI6IFJlbmUgU3RydWlrIChyc3RydWlrQGNlcnRpY29tLmNvbSkN Cg0KQXV0aG9yKHMpOg0KUmVuZSBTdHJ1aWssIHJzdHJ1aWtAY2VydGljb20uY29tDQoNCg0K Q29tbWVudDoNCnBsZWFzZSBjYWxsIG9uIGNlbGwgcGhvbmUgKzEgKDQxNikgNDMzLTc4ODAg b3Igd29yayBwaG9uZSArMSAoOTA1KSA1MDEtNjA4MyBpbiBjYXNlIG9mIHByb2JsZW1zLg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBh dHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2 aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBz b2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNv bnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9y bWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMg cHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRp b24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9u IGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJl IHVubGF3ZnVsLg0K From fluffy@cisco.com Wed Oct 28 23:42:51 2009 Return-Path: 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 E90A53A67F2 for <6lowapp@core3.amsl.com>; Wed, 28 Oct 2009 23:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.846 X-Spam-Level: X-Spam-Status: No, score=-109.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 PJVd91JulZaV for <6lowapp@core3.amsl.com>; Wed, 28 Oct 2009 23:42:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8B3763A69F3 for <6lowapp@ietf.org>; Wed, 28 Oct 2009 23:42:43 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsAABbW6EqQ/uCWe2dsb2JhbACbRAEBFiQGp1WYEIQ/BA X-IronPort-AV: E=Sophos;i="4.44,644,1249257600"; d="scan'208";a="53060440" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 06:42:58 +0000 Received: from dhcp-10-55-80-16.cisco.com (dhcp-10-55-80-16.cisco.com [10.55.80.16]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T6gw37029640; Thu, 29 Oct 2009 06:42:58 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> Date: Thu, 29 Oct 2009 07:42:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> To: 6lowapp@ietf.org X-Mailer: Apple Mail (2.1076) Cc: Don Sturek Subject: [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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 06:42:51 -0000 I've been talking to various folks about the how quickly they would like to get initial standards on this topic complete. To move quickly, I think we need an initial charter that is extremely focused and makes it clear what we are going to go do. After we meat the initial goals of the WG, we could expand the WG to explore into more area and extend the protocols to do more. I bounced some ideas around with Zack, Carsten, and Don and have put an initial draft of what I think of as a focused charter might look like below. It's just a straw man and it has some problems in it. I've been trying to merge all the various things different people have told me and organize them. I'm not promoting that I think this is the best plan - it just a plan that we can use as a baseline to talk about what we really want to do as group and if this charter reflects that or not. Please, read it. Think about, if the WG did this, could you live with that. If No, why and what requirements do you have this does not meet. If you could live with it but some changes would make it better, what are they. Thanks, Cullen ---------------------------------------- Applications are being developed for networks that have very limed packets sizes, have high degree of packet loss, and where a substantial number of devices that may be powered of at any point in time but periodically "wake up" for beef periods of time. These Networks are referred to as Constrained Networks (CNEets). Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. These networks are becoming increasing important for applications such as home automation, energy management, and the Internet of Things. This working group will define a framework a limited class of applications that deal with manipulation of simple resources on devices on a CNet. This includes applications to monitor simple sensors such as a temperature gauge, light switch, or power meter and control an actuator such as a light switch, heating system, or door lock. Typical uses include power management and reporting, and home automation. The general architecture consists of nodes on the CNet, called Devices, that have one or more Resources that represent sensors and actuators. Devices send message to change and query resources on other devices. Devices can send notifications about changed resource values to subscribed Devices. In other words, the architecture requires push, pull and and a notify approach to manipulating resources. As part of the framework for building these applications, the WG will define a CNet Application Protocol (CoAP) for manipulation or Resources on Devices. The framework will also specify a way to define new interface profiles that can be defined by vendors and other standards bodies to define the particular Resources on a Device and what manipulation are possible. There are also nodes called PEPs (Performance Enhancing Proxy) that gateway between the protocols typically used by the applications on the Internet and the protocol used on the CNet. An application on the general network can use HTTP REST to communicate with the PEP which will use CoAP to manipulate the Resource on the Device. The WG will define a mapping on the PEP from the CoAP to the a HTTP REST API. Each interface profile will define the Resources on the device that application can manipulate and what manipulations are possible. This will determine the HTTP REST APIs on the PEPs and the CoAP protocol encoding to manipulate the Resources on the Device it will also specify an XML MINE type for each class of Device that can be used to described the Resource state in the the body of HTTP REST messages. The WG may also work on a mapping to SNMP on the PEP. It is worth noting that the PEP does not have to be deployed at the boundary of the CNet and the more general network but can be deployed at various location in the network. The PEP boxes can provide various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to the a PEP that subscribed, when the PEP receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. The PEPs may also provide support for discovering devices that may not be currently responding as they are temporarily asleep. The initial work item of the WG are to define: 1) A requirements and architecture document that documents the high level boxes and arrows view of the protocol along with high level description of how the security, particular for commissioning of new devices into the network will work. The WG may also produce a document that describes various uses cases that help motivate the requirements. 2) Specification of the framework for defining interface profiles and the defining the CoAP. The CoAP will be able to set and query a resource on a Device. It will allow a device to publish a value or event to another Device. It will support a non-reliable multicast message to be sent to a group of devices to manipulate a resource on all the devices simultaneously (roughly within 50 ms of each other). The protocol will operate over UDP assuming a TBD byte payload and assume an underlying network bandwidth of approximately TBD kbps. The payload will be based on interface profile specific XML document compressed with EXI. 3) Specification on how to use the CoAP to discover Devices on the LoPAN and to interrogate them to find out which interface profiles they support. 4) Specification for the HTTP REST based API on the PEP to communicate with Devices. 4a) Possibly specify a separate specifications with mappings to SNMP. [[NOte: In the BOF it would be nice to figure out if this is in the charter or not.]] 5) A small set of basic interface profiles to illustrate how this is done. Interface profiles will be done for a power meter, a light and light switch, and temperature sensor. 6) A document with operation and management advice about running a network using these applications. Security, particularly keying of new Devices, is very challenging for these applications. On one hand this needs to support models where an end user can introduce a new device onto their network that may have no display or not input capability's. On the other end this may transport information about alarm systems or controlling door locks to a building over a wireless network. The CoAP protocol will support three commissioning methodologies. 1) Duckling mode. One device is put in a "mother duck" mode where it listens for broadcasts of Devices trying to imprint. Other Devices are put in a "duckling" mode where they broad cast to the "mother duck" Device then "imprint" by forming a new shared secret between the two Devices. Once this is complete the devices are taken out of this mode and can be use in a secure fashion. 2) Out of Band Key mode. Each device in manufactured with an initial symmetric key physically printed on the side in numeric and barcode form. Alternatively the device could have a barcode that forms a URL which when dereferenced with appropriate authorization provides a secure access to the key. A human can enter or scan this into a computer that can then be used form a secure connection with the Device. Once a secure connection is formed, the symmetric key can be changed. 3) Certificate mode. Each device is manufactured with a certificate with an asymmetric key. The fingerprint of the certificate is printed on a barcode. During commissioning, a computer can scan the barcode, the connect to the device and replace the certificate with a locally generated certificate that can be used for forming secure connections. Modes 1 and 2 are mandatory to implement but mode 3 is option. In all modes, once Device A and Device B have formed a secure connection with Device C, Device C can be used to transitively introduce A and B so now A and B have a secure connection with C. This transitive trust introduction can be used during commissioning even if A and B do not yet have network connectivity to each other. The CoAP will use CMS for object security. The WG will request the security area define a subset of CMS along with an EXI encoding instead of ASN.1 that is appropriate for a CNet network and for theses types of devices. It will have one mandatory to implement crytpo profile with no public key cryptograph to support modes 1 and 2 and additional crypto profile with public key cryptograph for support of mode 3. In mode 3, it will (or will not TBD) require support for Elliptical Curve Cryptograph (ECC). The WG will coordinate on requirements from TBD (other SDO and organizations). The WG will closing coordinate with other IETF WGs including ROLL 6LowPAN and appropriate groups in OAM and Security. Milestone: Jan 2010 - Select WG document for basis of CoAP protocol Jun 2010 - Requirements and Architecture to IESG as Info Dec 2010 - Core protocol specification to IESG as PS Dec 2010 - HTTP Rest API mapping to IESG as PS Mar 2011 - Discovery specification to IESG as PS Mar 2011 - Specifications of basic interface profiles to IESG as PS Mar 2012 - Ops & Management advice to IESG as Info From jukka.manner@tkk.fi Thu Oct 29 07:21:09 2009 Return-Path: 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 920023A6ADD for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 o0nD6rNv7fIS for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 07:21:07 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id 683503A6ADC for <6lowapp@ietf.org>; Thu, 29 Oct 2009 07:21:06 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9TELEsQ018977; Thu, 29 Oct 2009 16:21:14 +0200 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 24185-49-2; Thu, 29 Oct 2009 16:21:14 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9TEL3XK018921; Thu, 29 Oct 2009 16:21:03 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 0BBCB1E148; Thu, 29 Oct 2009 16:21:03 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sez8R1CS0NwB; Thu, 29 Oct 2009 16:20:58 +0200 (EET) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id A08A31E140; Thu, 29 Oct 2009 16:20:58 +0200 (EET) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id A842B120050; Thu, 29 Oct 2009 16:20:57 +0200 (EET) Message-ID: <4AE9A4C8.4030402@tkk.fi> Date: Thu, 29 Oct 2009 16:20:56 +0200 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> In-Reply-To: <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> Content-Type: multipart/mixed; boundary="------------020603040805070407020903" X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:21:09 -0000 This is a multi-part message in MIME format. --------------020603040805070407020903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm somewhat struggling with understanding the charter, but at least two items pop out: 1. This seems to indicate that 6lowapp will not be tied to any existing work, it will work on its own goals, but in collaboration with others (which is somewhat open as what it means). I would have expected that 6lowapp would specifically look at existing work in related WGs and see how build on top of that. 2. The charter goes quite far in the design of the solution and it's details. To me this seems a bit too far into the future, but also somewhat limited and very specific and narrow(?). Maybe this is fine for a BOF charter, but way too detailed for a WG charter. I'll comment more when I understand the goals more (if that happens anytime soon). regards, Jukka Cullen Jennings wrote: > > I've been talking to various folks about the how quickly they would like > to get initial standards on this topic complete. To move quickly, I > think we need an initial charter that is extremely focused and makes it > clear what we are going to go do. After we meat the initial goals of the > WG, we could expand the WG to explore into more area and extend the > protocols to do more. I bounced some ideas around with Zack, Carsten, > and Don and have put an initial draft of what I think of as a focused > charter might look like below. > > It's just a straw man and it has some problems in it. I've been trying > to merge all the various things different people have told me and > organize them. I'm not promoting that I think this is the best plan - it > just a plan that we can use as a baseline to talk about what we really > want to do as group and if this charter reflects that or not. > > Please, read it. Think about, if the WG did this, could you live with > that. If No, why and what requirements do you have this does not meet. > If you could live with it but some changes would make it better, what > are they. > > Thanks, Cullen > > ---------------------------------------- > > > > Applications are being developed for networks that have very limed > packets sizes, have high degree of packet loss, and where a substantial > number of devices that may be powered of at any point in time but > periodically "wake up" for beef periods of time. These Networks are > referred to as Constrained Networks (CNEets). Low-Power Wireless > Personal Area Networks (LoWPANs) are an example of this type of network. > These networks are becoming increasing important for applications such > as home automation, energy management, and the Internet of Things. This > working group will define a framework a limited class of applications > that deal with manipulation of simple resources on devices on a CNet. > This includes applications to monitor simple sensors such as a > temperature gauge, light switch, or power meter and control an actuator > such as a light switch, heating system, or door lock. Typical uses > include power management and reporting, and home automation. > > The general architecture consists of nodes on the CNet, called Devices, > that have one or more Resources that represent sensors and actuators. > Devices send message to change and query resources on other devices. > Devices can send notifications about changed resource values to > subscribed Devices. In other words, the architecture requires push, pull > and and a notify approach to manipulating resources. As part of the > framework for building these applications, the WG will define a CNet > Application Protocol (CoAP) for manipulation or Resources on Devices. > The framework will also specify a way to define new interface profiles > that can be defined by vendors and other standards bodies to define the > particular Resources on a Device and what manipulation are possible. > > There are also nodes called PEPs (Performance Enhancing Proxy) that > gateway between the protocols typically used by the applications on the > Internet and the protocol used on the CNet. An application on the > general network can use HTTP REST to communicate with the PEP which will > use CoAP to manipulate the Resource on the Device. The WG will define a > mapping on the PEP from the CoAP to the a HTTP REST API. Each interface > profile will define the Resources on the device that application can > manipulate and what manipulations are possible. This will determine the > HTTP REST APIs on the PEPs and the CoAP protocol encoding to manipulate > the Resources on the Device it will also specify an XML MINE type for > each class of Device that can be used to described the Resource state in > the the body of HTTP REST messages. The WG may also work on a mapping to > SNMP on the PEP. It is worth noting that the PEP does not have to be > deployed at the boundary of the CNet and the more general network but > can be deployed at various location in the network. > > The PEP boxes can provide various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes > and sends the current temperature to the a PEP that subscribed, when the > PEP receives a request over HTTP for that temperature resource, it can > respond with the last seen value instead of trying to query the Device > which is currently asleep. The PEPs may also provide support for > discovering devices that may not be currently responding as they are > temporarily asleep. > > The initial work item of the WG are to define: > > 1) A requirements and architecture document that documents the high > level boxes and arrows view of the protocol along with high level > description of how the security, particular for commissioning of new > devices into the network will work. The WG may also produce a document > that describes various uses cases that help motivate the requirements. > > 2) Specification of the framework for defining interface profiles and > the defining the CoAP. The CoAP will be able to set and query a resource > on a Device. It will allow a device to publish a value or event to > another Device. It will support a non-reliable multicast message to be > sent to a group of devices to manipulate a resource on all the devices > simultaneously (roughly within 50 ms of each other). The protocol will > operate over UDP assuming a TBD byte payload and assume an underlying > network bandwidth of approximately TBD kbps. The payload will be based > on interface profile specific XML document compressed with EXI. > > 3) Specification on how to use the CoAP to discover Devices on the LoPAN > and to interrogate them to find out which interface profiles they support. > > 4) Specification for the HTTP REST based API on the PEP to communicate > with Devices. > > 4a) Possibly specify a separate specifications with mappings to SNMP. > [[NOte: In the BOF it would be nice to figure out if this is in the > charter or not.]] > > 5) A small set of basic interface profiles to illustrate how this is > done. Interface profiles will be done for a power meter, a light and > light switch, and temperature sensor. > > 6) A document with operation and management advice about running a > network using these applications. > > Security, particularly keying of new Devices, is very challenging for > these applications. On one hand this needs to support models where an > end user can introduce a new device onto their network that may have no > display or not input capability's. On the other end this may transport > information about alarm systems or controlling door locks to a building > over a wireless network. > > The CoAP protocol will support three commissioning methodologies. > > 1) Duckling mode. One device is put in a "mother duck" mode where it > listens for broadcasts of Devices trying to imprint. Other Devices are > put in a "duckling" mode where they broad cast to the "mother duck" > Device then "imprint" by forming a new shared secret between the two > Devices. Once this is complete the devices are taken out of this mode > and can be use in a secure fashion. > > 2) Out of Band Key mode. Each device in manufactured with an initial > symmetric key physically printed on the side in numeric and barcode > form. Alternatively the device could have a barcode that forms a URL > which when dereferenced with appropriate authorization provides a secure > access to the key. A human can enter or scan this into a computer that > can then be used form a secure connection with the Device. Once a secure > connection is formed, the symmetric key can be changed. > > 3) Certificate mode. Each device is manufactured with a certificate with > an asymmetric key. The fingerprint of the certificate is printed on a > barcode. During commissioning, a computer can scan the barcode, the > connect to the device and replace the certificate with a locally > generated certificate that can be used for forming secure connections. > > Modes 1 and 2 are mandatory to implement but mode 3 is option. In all > modes, once Device A and Device B have formed a secure connection with > Device C, Device C can be used to transitively introduce A and B so now > A and B have a secure connection with C. This transitive trust > introduction can be used during commissioning even if A and B do not yet > have network connectivity to each other. > > The CoAP will use CMS for object security. The WG will request the > security area define a subset of CMS along with an EXI encoding instead > of ASN.1 that is appropriate for a CNet network and for theses types of > devices. It will have one mandatory to implement crytpo profile with no > public key cryptograph to support modes 1 and 2 and additional crypto > profile with public key cryptograph for support of mode 3. In mode 3, it > will (or will not TBD) require support for Elliptical Curve Cryptograph > (ECC). > > The WG will coordinate on requirements from TBD (other SDO and > organizations). The WG will closing coordinate with other IETF WGs > including ROLL 6LowPAN and appropriate groups in OAM and Security. > > Milestone: > > Jan 2010 - Select WG document for basis of CoAP protocol > > Jun 2010 - Requirements and Architecture to IESG as Info > > Dec 2010 - Core protocol specification to IESG as PS > > Dec 2010 - HTTP Rest API mapping to IESG as PS > > Mar 2011 - Discovery specification to IESG as PS > > Mar 2011 - Specifications of basic interface profiles to IESG as PS > > Mar 2012 - Ops & Management advice to IESG as Info > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi --------------020603040805070407020903 Content-Type: text/x-vcard; charset=utf-8; name="jukka_manner.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jukka_manner.vcf" begin:vcard fn:Jukka Manner n:Manner;Jukka org:Helsinki University of Technology (TKK);Department of Communications and Networking (Comnet) adr:(Visiting address: Otakaari 5 A);;P.O.Box 3000;TKK;;02015;Finland email;internet:jukka.manner@tkk.fi title:Professor, PhD. tel;work:+358-9-4512481 tel;fax:+358-9-4512474 tel;cell:+358-50-5112973 x-mozilla-html:FALSE url:http://comnet.tkk.fi version:2.1 end:vcard --------------020603040805070407020903-- From d.sturek@att.net Thu Oct 29 07:47:54 2009 Return-Path: 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 DEB393A6828 for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 07:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 ln9Y8fVVJ+fR for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 07:47:53 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 4886E3A68E9 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 07:47:53 -0700 (PDT) Received: from [209.191.108.97] by n18.bullet.mail.mud.yahoo.com with NNFMP; 29 Oct 2009 14:48:07 -0000 Received: from [68.142.201.250] by t4.bullet.mud.yahoo.com with NNFMP; 29 Oct 2009 14:48:07 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 29 Oct 2009 14:48:07 -0000 X-Yahoo-Newman-Id: 474417.74285.bm@omp411.mail.mud.yahoo.com Received: (qmail 56997 invoked from network); 29 Oct 2009 14:48:07 -0000 Received: from adsl-67-124-200-41.dsl.sndg02.pacbell.net (d.sturek@67.124.200.41 with login) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2009 07:48:06 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: HWDDij0VM1mWDblzv21MBDKILRYmjz11NsU0uehwBYSiYvJsnRrJA0JOyjtgYBuB7Rh3.dcAhZpSKw4A9NIUz1O8JdBg3092GXQi38ldc0bE2rhRgmXOAT_dBK1exq0GJbUXvEVI4a51NbyDH6xzSiT171XJrFyDFFU.C8aqxh6jod5pz1aw3R5u0LDmoe9q3aXULd8vKOQDmNCQqn0VgINMS0kCTZEey2206Zh.3K9SxBbGdBsFb6wiA0tj_mKek8llsDxmGngIZgdI_HVZuTTmDf5j2g9YqJaqNdSMcC4n2fp81Ps- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , <6lowapp@ietf.org> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> In-Reply-To: Date: Thu, 29 Oct 2009 07:48:05 -0700 Message-ID: <00bf01ca58a6$d2d94430$788bcc90$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpYY1+LL+FbLTJCTuCfSHo37IxnGAAQQpEQAACVpcA= Content-Language: en-us Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:47:55 -0000 Sorry for the resend... First one was with the wrong e-mail account. Don -----Original Message----- From: Don Sturek Sent: Thursday, October 29, 2009 7:37 AM To: 'Cullen Jennings'; 6lowapp@ietf.org Cc: Zach Shelby; Carsten Bormann; Lisa Dusseault Subject: RE: Proposed charter for 6LoWAPP BOF Hi Cullen, Overall, the proposed charter looks interesting. On the Commissioning methods, I think making the "Duckling" mode mandatory as indicated in the text below should not be decided in the charter. Unless this commissioning method has undergone some form of security review, it could well be something we (at least in Smart Energy) cannot use. It would be a shame to waste code space for something like this. While we (again Smart Energy) are looking at a RESTfull HTTP architecture, it would be good to point out that this is only one option. It would be nice to see if other popular communication solutions can work as well. One more thng: The discussion below indicates two level of communication: PEPs and CoAps. I would hope we could avoid this. It would be nice to address and communicate with CoAp devices as you would with any other device on the internet whether a PEP was present or not. I would not want to have the group focused on this type of gateway approach. Overall though this was a good start for the charter. Don -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Wednesday, October 28, 2009 11:43 PM To: 6lowapp@ietf.org Cc: Zach Shelby; Carsten Bormann; Don Sturek; Lisa Dusseault Subject: Proposed charter for 6LoWAPP BOF I've been talking to various folks about the how quickly they would like to get initial standards on this topic complete. To move quickly, I think we need an initial charter that is extremely focused and makes it clear what we are going to go do. After we meat the initial goals of the WG, we could expand the WG to explore into more area and extend the protocols to do more. I bounced some ideas around with Zack, Carsten, and Don and have put an initial draft of what I think of as a focused charter might look like below. It's just a straw man and it has some problems in it. I've been trying to merge all the various things different people have told me and organize them. I'm not promoting that I think this is the best plan - it just a plan that we can use as a baseline to talk about what we really want to do as group and if this charter reflects that or not. Please, read it. Think about, if the WG did this, could you live with that. If No, why and what requirements do you have this does not meet. If you could live with it but some changes would make it better, what are they. Thanks, Cullen ---------------------------------------- Applications are being developed for networks that have very limed packets sizes, have high degree of packet loss, and where a substantial number of devices that may be powered of at any point in time but periodically "wake up" for beef periods of time. These Networks are referred to as Constrained Networks (CNEets). Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. These networks are becoming increasing important for applications such as home automation, energy management, and the Internet of Things. This working group will define a framework a limited class of applications that deal with manipulation of simple resources on devices on a CNet. This includes applications to monitor simple sensors such as a temperature gauge, light switch, or power meter and control an actuator such as a light switch, heating system, or door lock. Typical uses include power management and reporting, and home automation. The general architecture consists of nodes on the CNet, called Devices, that have one or more Resources that represent sensors and actuators. Devices send message to change and query resources on other devices. Devices can send notifications about changed resource values to subscribed Devices. In other words, the architecture requires push, pull and and a notify approach to manipulating resources. As part of the framework for building these applications, the WG will define a CNet Application Protocol (CoAP) for manipulation or Resources on Devices. The framework will also specify a way to define new interface profiles that can be defined by vendors and other standards bodies to define the particular Resources on a Device and what manipulation are possible. There are also nodes called PEPs (Performance Enhancing Proxy) that gateway between the protocols typically used by the applications on the Internet and the protocol used on the CNet. An application on the general network can use HTTP REST to communicate with the PEP which will use CoAP to manipulate the Resource on the Device. The WG will define a mapping on the PEP from the CoAP to the a HTTP REST API. Each interface profile will define the Resources on the device that application can manipulate and what manipulations are possible. This will determine the HTTP REST APIs on the PEPs and the CoAP protocol encoding to manipulate the Resources on the Device it will also specify an XML MINE type for each class of Device that can be used to described the Resource state in the the body of HTTP REST messages. The WG may also work on a mapping to SNMP on the PEP. It is worth noting that the PEP does not have to be deployed at the boundary of the CNet and the more general network but can be deployed at various location in the network. The PEP boxes can provide various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to the a PEP that subscribed, when the PEP receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. The PEPs may also provide support for discovering devices that may not be currently responding as they are temporarily asleep. The initial work item of the WG are to define: 1) A requirements and architecture document that documents the high level boxes and arrows view of the protocol along with high level description of how the security, particular for commissioning of new devices into the network will work. The WG may also produce a document that describes various uses cases that help motivate the requirements. 2) Specification of the framework for defining interface profiles and the defining the CoAP. The CoAP will be able to set and query a resource on a Device. It will allow a device to publish a value or event to another Device. It will support a non-reliable multicast message to be sent to a group of devices to manipulate a resource on all the devices simultaneously (roughly within 50 ms of each other). The protocol will operate over UDP assuming a TBD byte payload and assume an underlying network bandwidth of approximately TBD kbps. The payload will be based on interface profile specific XML document compressed with EXI. 3) Specification on how to use the CoAP to discover Devices on the LoPAN and to interrogate them to find out which interface profiles they support. 4) Specification for the HTTP REST based API on the PEP to communicate with Devices. 4a) Possibly specify a separate specifications with mappings to SNMP. [[NOte: In the BOF it would be nice to figure out if this is in the charter or not.]] 5) A small set of basic interface profiles to illustrate how this is done. Interface profiles will be done for a power meter, a light and light switch, and temperature sensor. 6) A document with operation and management advice about running a network using these applications. Security, particularly keying of new Devices, is very challenging for these applications. On one hand this needs to support models where an end user can introduce a new device onto their network that may have no display or not input capability's. On the other end this may transport information about alarm systems or controlling door locks to a building over a wireless network. The CoAP protocol will support three commissioning methodologies. 1) Duckling mode. One device is put in a "mother duck" mode where it listens for broadcasts of Devices trying to imprint. Other Devices are put in a "duckling" mode where they broad cast to the "mother duck" Device then "imprint" by forming a new shared secret between the two Devices. Once this is complete the devices are taken out of this mode and can be use in a secure fashion. 2) Out of Band Key mode. Each device in manufactured with an initial symmetric key physically printed on the side in numeric and barcode form. Alternatively the device could have a barcode that forms a URL which when dereferenced with appropriate authorization provides a secure access to the key. A human can enter or scan this into a computer that can then be used form a secure connection with the Device. Once a secure connection is formed, the symmetric key can be changed. 3) Certificate mode. Each device is manufactured with a certificate with an asymmetric key. The fingerprint of the certificate is printed on a barcode. During commissioning, a computer can scan the barcode, the connect to the device and replace the certificate with a locally generated certificate that can be used for forming secure connections. Modes 1 and 2 are mandatory to implement but mode 3 is option. In all modes, once Device A and Device B have formed a secure connection with Device C, Device C can be used to transitively introduce A and B so now A and B have a secure connection with C. This transitive trust introduction can be used during commissioning even if A and B do not yet have network connectivity to each other. The CoAP will use CMS for object security. The WG will request the security area define a subset of CMS along with an EXI encoding instead of ASN.1 that is appropriate for a CNet network and for theses types of devices. It will have one mandatory to implement crytpo profile with no public key cryptograph to support modes 1 and 2 and additional crypto profile with public key cryptograph for support of mode 3. In mode 3, it will (or will not TBD) require support for Elliptical Curve Cryptograph (ECC). The WG will coordinate on requirements from TBD (other SDO and organizations). The WG will closing coordinate with other IETF WGs including ROLL 6LowPAN and appropriate groups in OAM and Security. Milestone: Jan 2010 - Select WG document for basis of CoAP protocol Jun 2010 - Requirements and Architecture to IESG as Info Dec 2010 - Core protocol specification to IESG as PS Dec 2010 - HTTP Rest API mapping to IESG as PS Mar 2011 - Discovery specification to IESG as PS Mar 2011 - Specifications of basic interface profiles to IESG as PS Mar 2012 - Ops & Management advice to IESG as Info From arjunrc@gmail.com Thu Oct 29 11:11:48 2009 Return-Path: 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 9941A3A68FF for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 11:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 PbbFNEQYyoAZ for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 11:11:47 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 704293A67A8 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 11:11:46 -0700 (PDT) Received: by qyk41 with SMTP id 41so1351671qyk.29 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 11:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=38q+iTsVM3bEkLJv1SjmF1kQseuJyy0p79CX20++Dtc=; b=T24aC/QjsUrCe53HNd7N3EXzb8H66Si/+1RgK9b/dGkhtv9gGMHURr0mUSa0v4lJU+ vW5ZwUz8ek+t7hjV42Njh6v3xIPR4hOKGLU1A+7GlVEdoQ+xeo8RonIIzhSFluuo1JaH TkomDd7UHQQwm5wnZP2iTtYBHTKm/9V6YUGyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=CJ6FL1yKvZaBxFD+IGZ2XdzajfoqGfhaEW9hvGk/3AX9Cr7E6Ly0YCDuBrCDWQp4BI dgeuiNRBr/P0BKmvfGkZTc4K13qrQAUvb9LV8Eai89w3DVtsrj/nI5TyULDIsvN0HSMo 8d3nOAsJaDDNtA9Ybdur6xVskFQ6mTc64zAj4= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.52.144 with SMTP id i16mr234147qag.210.1256839919166; Thu, 29 Oct 2009 11:11:59 -0700 (PDT) In-Reply-To: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> From: Arjun Roychowdhury Date: Thu, 29 Oct 2009 14:11:39 -0400 X-Google-Sender-Auth: f5483239cf06eb4b Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=00c09f89999bebe76c047716d87a Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:11:48 -0000 --00c09f89999bebe76c047716d87a Content-Type: text/plain; charset=ISO-8859-1 My comments: The charter seems to combine goals as well as architecture together in one go. Probably can be simplified ? Specific comments below: On Thu, Oct 29, 2009 at 2:42 AM, Cullen Jennings wrote: > > > Applications are being developed for networks that have very limed packets > sizes, have high degree of packet loss, and where a substantial number of > devices that may be powered of at any point in time but periodically "wake > up" for beef periods of time. These Networks are referred to as Constrained > Networks (CNEets). Low-Power Wireless Personal Area Networks (LoWPANs) are > an example of this type of network. These networks are becoming increasing > important for applications such as home automation, energy management, and > the Internet of Things. This working group will define a framework a limited > class of applications that deal with manipulation of simple resources on > devices on a CNet. This includes applications to monitor simple sensors such > as a temperature gauge, light switch, or power meter and control an actuator > such as a light switch, heating system, or door lock. Typical uses include > power management and reporting, and home automation. > ARC> We are implicitly stating that devices in a lowpan will have simple management requirements (kind of like set/get mostly). I'd like to see this group also consider (in terms of usecases) what are the various control functions that are desirable, given an internet connect ecosystem? I don't think we should assume that just because most home control was mostly about simple on/off/read till date, that is what we should architect for. It is a minimal requirement, but not complete by itself. > > The general architecture consists of nodes on the CNet, called Devices, > that have one or more Resources that represent sensors and actuators. > Devices send message to change and query resources on other devices. Devices > can send notifications about changed resource values to subscribed Devices. > In other words, the architecture requires push, pull and and a notify > approach to manipulating resources. As part of the framework for building > these applications, the WG will define a CNet Application Protocol (CoAP) > for manipulation or Resources on Devices. The framework will also specify a > way to define new interface profiles that can be defined by vendors and > other standards bodies to define the particular Resources on a Device and > what manipulation are possible. > > There are also nodes called PEPs (Performance Enhancing Proxy) that gateway > between the protocols typically used by the applications on the Internet and > the protocol used on the CNet. An application on the general network can use > HTTP REST to communicate with the PEP which will use CoAP to manipulate the > Resource on the Device. The WG will define a mapping on the PEP from the > CoAP to the a HTTP REST API. Each interface profile will define the > Resources on the device that application can manipulate and what > manipulations are possible. This will determine the HTTP REST APIs on the > PEPs and the CoAP protocol encoding to manipulate the Resources on the > Device it will also specify an XML MINE type for each class of Device that > can be used to described the Resource state in the the body of HTTP REST > messages. The WG may also work on a mapping to SNMP on the PEP. It is worth > noting that the PEP does not have to be deployed at the boundary of the CNet > and the more general network but can be deployed at various location in the > network. > ARC> I don't think HTTP to XX mapping should be assumed at this stage. HTTP may be a popular protocol, but there could be others. So a general goal of internet protocols to device control protocol mapping is more suitable > > The PEP boxes can provide various forms of "caching". For example, if a > temperature sensor is normally asleep but wakes up every five minutes and > sends the current temperature to the a PEP that subscribed, when the PEP > receives a request over HTTP for that temperature resource, it can respond > with the last seen value instead of trying to query the Device which is > currently asleep. The PEPs may also provide support for discovering devices > that may not be currently responding as they are temporarily asleep. > ARC> Is this needed as a part of the charter? > > The initial work item of the WG are to define: > > > > > The CoAP protocol will support three commissioning methodologies. > > 1) Duckling mode. One device is put in a "mother duck" mode where it > listens for broadcasts of Devices trying to imprint. Other Devices are put > in a "duckling" mode where they broad cast to the "mother duck" Device then > "imprint" by forming a new shared secret between the two Devices. Once this > is complete the devices are taken out of this mode and can be use in a > secure fashion. > ARC> This seems to be a requirement specification of what a CoAP should be. I think it should be left for a dedicated req doc, not as part of a charter. > > -- Arjun Roychowdhury --00c09f89999bebe76c047716d87a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My comments:

The charter seems to combine goals as well = as architecture together in one go. Probably can be simplified ? Specific c= omments below:


On Thu, Oct 29,= 2009 at 2:42 AM, Cullen Jennings <fluffy@cisco.com> wrote:


Applications are being developed for networks that have very limed packets = sizes, have high degree of packet loss, and where a substantial number of d= evices that may be powered of at any point in time but periodically "w= ake up" for beef periods of time. These Networks are referred to as Co= nstrained Networks (CNEets). Low-Power Wireless Personal Area Networks (LoW= PANs) are an example of this type of network. These networks are becoming i= ncreasing important for applications such as home automation, energy manage= ment, and the Internet of Things. This working group will define a framewor= k a limited class of applications that deal with manipulation of simple res= ources on devices on a CNet. This includes applications to monitor simple s= ensors such as a temperature gauge, light switch, or power meter and contro= l an actuator such as a light switch, heating system, or door lock. Typical= uses include power management and reporting, and home automation.

ARC> We are implicitly stating that dev= ices in a lowpan will have simple management requirements (kind of like set= /get mostly). I'd like to see this group also consider (in terms of use= cases) what are the various control functions that are desirable, given an = internet connect ecosystem? I don't think we should assume that just be= cause most home control was mostly about simple on/off/read =A0till date, t= hat is what we should architect for. It is a minimal requirement, but not c= omplete by itself.

=A0

The general architecture consists of nodes on the CNet, called Devices, tha= t have one or more Resources that represent sensors and actuators. Devices = send message to change and query resources on other devices. Devices can se= nd notifications about changed resource values to subscribed Devices. In ot= her words, the architecture requires push, pull and and a notify approach t= o manipulating resources. As part of the framework for building these appli= cations, the WG will define a CNet Application Protocol (CoAP) for manipula= tion or Resources on Devices. The framework will also specify a way to defi= ne new interface profiles that can be defined by vendors and other standard= s bodies to define the particular Resources on a Device and what manipulati= on are possible.

There are also nodes called PEPs (Performance Enhancing Proxy) that gateway= between the protocols typically used by the applications on the Internet a= nd the protocol used on the CNet. An application on the general network can= use HTTP REST to communicate with the PEP which will use CoAP to manipulat= e the Resource on the Device. The WG will define a mapping on the PEP from = the CoAP to the a HTTP =A0REST API. Each interface profile will define the = Resources on the device that application can manipulate and what manipulati= ons are possible. =A0This will determine the HTTP REST APIs on the PEPs and= the CoAP protocol encoding to manipulate the Resources on the Device it wi= ll also specify an XML MINE type for each class of Device that can be used = to described the Resource state in the the body of HTTP REST messages. The = WG may also work on a mapping to SNMP on the PEP. It is worth noting that t= he PEP does not have to be deployed at the boundary of the CNet and the mor= e general network but can be deployed at various location in the network.

ARC> I don't think HTTP to XX mappi= ng should be assumed at this stage. HTTP may be a popular protocol, but the= re could be others. So a general goal of internet protocols to device contr= ol protocol mapping is more suitable
=A0

The PEP boxes can provide various forms of "caching". For example= , if a temperature sensor is normally asleep but wakes up every five minute= s and sends the current temperature to the a PEP that subscribed, when the = PEP receives a request over HTTP for that temperature resource, it can resp= ond with the last seen value instead of trying to query the Device which is= currently asleep. The PEPs may also provide support for discovering device= s that may not be currently responding as they are temporarily asleep.

ARC> Is this needed as a part of the ch= arter?=A0
=A0

The initial work item of the WG are to define:

=A0


The CoAP protocol will support three commissioning methodologies.

1) Duckling mode. One device is put in a "mother duck" mode where= it listens for broadcasts of Devices trying to imprint. Other Devices are = put in a "duckling" mode where they broad cast to the "mothe= r duck" Device then "imprint" by forming a new shared secret= between the two Devices. Once this is complete the devices are taken out o= f this mode and can be use in a secure fashion.

<etc>

ARC&g= t; This seems to be a requirement specification of what a CoAP should be. I= think it should be left for a dedicated req doc, not as part of a charter.=
=A0

--
= Arjun Roychowdhury

--00c09f89999bebe76c047716d87a-- From lisa.dusseault@gmail.com Thu Oct 29 12:09:49 2009 Return-Path: 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 5A0043A683E for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 12:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 EgvzOBi1VjQ7 for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 12:09:48 -0700 (PDT) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 695903A67D9 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 12:09:48 -0700 (PDT) Received: by vws31 with SMTP id 31so418565vws.29 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 12:10:02 -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 :content-transfer-encoding; bh=RKrHOc11ZrvEUFeJTx7Nuif5Lck0NHfGsSpjrDkOabU=; b=RFOrJMr2jKbr8KumOyKo826BvY1Hfs7QKZkYsY+XO6H+ObS9NT/NPks86+405K4Hvp LoMdHVIGHqjTAfoyjg3iSER/851BKEEbMcBQiaF9kCKBnVIoKsEB6UkvknXMXTD645rT loCWqqz7uSG6gNsz0Zxd52z0c6CkXDDUmJxdc= 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:content-transfer-encoding; b=YCAWExHkNA7RgSCjaV9uWlYaZNoqC3VmGGjsNxHHJGUqY/wLiooq48UYu9DijYDKy4 ZbQbR0aoVL4/BrjFIVbLei9WTi/LBYzhY7WIDU3z8/euaMJXbU1X+ZoU+wHkmfF8axbF TTR9elzZiVBBkLo/py8ieCaG9/JJgMFZyoxgM= MIME-Version: 1.0 Received: by 10.220.125.5 with SMTP id w5mr708537vcr.30.1256843401963; Thu, 29 Oct 2009 12:10:01 -0700 (PDT) In-Reply-To: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> Date: Thu, 29 Oct 2009 12:10:01 -0700 Message-ID: From: Lisa Dusseault To: arjun.lists@hsc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:09:49 -0000 Hi Arjun, As sponsoring Area Director, I've asked that the BOF discuss a more focused WG charter because this isn't "the charter for low-power IP applications protocols" it's merely *a* charter for a subset of those things. We can't boil the ocean in one WG or even come to agreement on forming a WG if the scope is too big. Besides considering that other WGs can tackle this larger space, consider that this WG could always go on to more complex use cases after solving simple ones. I mention this in response to your mail although others have been leaning in both directions, because I can give specific examples: On Thu, Oct 29, 2009 at 11:11 AM, Arjun Roychowdhury wrote: > My comments: > The charter seems to combine goals as well as architecture together in on= e > go. Yes, because WGs seem to need not only functional goals but also at least an anchoring architecture to start from. I've been involved in many software projects, both internal and community (open source) and while software projects seem to be able to decide on an architecture starting from a blank page, WGs seem to have more difficulty. > > ARC> We are implicitly stating that devices in a lowpan will have simple > management requirements (kind of like set/get mostly). I'd like to see th= is > group also consider (in terms of usecases) what are the various control > functions that are desirable, given an internet connect ecosystem? I don'= t > think we should assume that just because most home control was mostly abo= ut > simple on/off/read =A0till date, that is what we should architect for. It= is a > minimal requirement, but not complete by itself. What would the WGs achievable objectives here be? So far I can only see "Write a requirements or use cases document for possible other control functions". Without a solid scope here, I don't think the WG could take on more than that. > ARC> I don't think HTTP to XX mapping should be assumed at this stage. HT= TP > may be a popular protocol, but there could be others. So a general goal o= f > internet protocols to device control protocol mapping is more suitable It is a popular protocol, and some groups specifically have interoperability with HTTP as a deployment requirement, so perhaps this is just the first. It's definitely not the only. The general goal of mapping protocols is not, IMO, achievable at this point. I wouldn't object if the charter picked something other than HTTP that was achievable, but I don't see how the WG could tackle "internet protocols" as a class. I do appreciate your input, but I wanted the chance to expose the pressure I'm putting the BOF co-ordinators under to specify a small set of documents and an achievable scope. I hope this reassures you that the IETF would not be saying no to a larger scope in the longer run. thanks, Lisa Dusseault From stpeter@stpeter.im Thu Oct 29 12:21:30 2009 Return-Path: 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 B2B393A6A19 for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 12:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 5VzG-ubVD2jm for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 12:21:29 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B2EF93A6949 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 12:21:29 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 111E34038E; Thu, 29 Oct 2009 13:21:44 -0600 (MDT) Message-ID: <4AE9EB47.6030005@stpeter.im> Date: Thu, 29 Oct 2009 13:21:43 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lisa Dusseault References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:21:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 1:10 PM, Lisa Dusseault wrote: > Hi Arjun, > > As sponsoring Area Director, I've asked that the BOF discuss a more > focused WG charter because this isn't "the charter for low-power IP > applications protocols" it's merely *a* charter for a subset of those > things. We can't boil the ocean in one WG or even come to agreement > on forming a WG if the scope is too big. Besides considering that > other WGs can tackle this larger space, consider that this WG could > always go on to more complex use cases after solving simple ones. Thanks for the clarification, Lisa. One thing I see missing from the proposed charter is a clear problem statement. The charter states that Low-Power Wireless Personal Area Networks are increasingly important and that the WG will define a framework for manipulation of resources that are available on LoWPANs. But I'm not sure what is driving the need for such a framework, exactly what problem we're solving at the IETF, how our solutions will serve the needs of operators, device manufacturers, application developers, and end users, and why we think that the IETF can bring special expertise or insight to bear on an application space that is already being addressed by other SDOs and industry groups. However, I freely admit that I might be missing context. :) /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrp60cACgkQNL8k5A2w/vzEmQCePTN4u5pizC1M0Dkiwrh4o4Kg d8AAoNaZGNNKx1yIsrcXg8txKsvmQNdk =e35R -----END PGP SIGNATURE----- From arjunrc@gmail.com Thu Oct 29 12:25:39 2009 Return-Path: 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 032883A6899 for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 oYOIdvkYFDHY for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 12:25:38 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id EE8C03A6867 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 12:25:37 -0700 (PDT) Received: by qyk41 with SMTP id 41so1392544qyk.29 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 12:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=tAinFlQLXOc6Hm6V+MSpafU7VmVS13lvtxF0Pwbuglw=; b=v2ayqMc5Hdj5dZ7jla2IumuBVq1Q26qzhFoAVFLYVZ2W0IxoWamkpcCoWgxAr7CCFY 8ZGH4OkRnGIZ1Bg7pPYMaHsjsPnjGdEc9kA/ZhJTVVPjEJTvy4uLxrBEtSY6zi/8eim9 dN3sPYIP9AHbmG+RRtwkafFrjRqPnlB7+DlCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=a7veFhYrfCbKG0To/JUkuvTvU8n7tn+toGvxwBbgI90obhtbrEuzptuniiUUjA98nO B6BBF8j7bYF6rvC4ENon2voQOCUgN6wrjF2a9Mb7vusXPeMPtPyM18tL0tuo2ZIj3YaI 9EvSMffC8aqZhQcbDoguP7FrGpLo/tE66LpG4= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.52.144 with SMTP id i16mr280330qag.210.1256844351354; Thu, 29 Oct 2009 12:25:51 -0700 (PDT) In-Reply-To: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> From: Arjun Roychowdhury Date: Thu, 29 Oct 2009 15:25:31 -0400 X-Google-Sender-Auth: 8f7ce363124b6788 Message-ID: To: Lisa Dusseault Content-Type: multipart/alternative; boundary=00c09f89999b19b779047717e164 Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:25:39 -0000 --00c09f89999b19b779047717e164 Content-Type: text/plain; charset=ISO-8859-1 Hi Lisa, responses inlined. regds arjun On Thu, Oct 29, 2009 at 3:10 PM, Lisa Dusseault wrote: > > focused WG charter because this isn't "the charter for low-power IP > applications protocols" it's merely *a* charter for a subset of those > things. We can't boil the ocean in one WG or even come to agreement > on forming a WG if the scope is too big. Besides considering that > other WGs can tackle this larger space, consider that this WG could > always go on to more complex use cases after solving simple ones. > ARC> I think this comment pretty much summarizes the difference of thought between what I thought 6lowapp vs doing vs what you are describing. The group name itself, "6lowapp" seems to specify it is a group to to specificy low-power IP app protocols, and not a subset. draft-bormann-6lowpan-6lowapp-problem-01 also seems to indicate this group is dealing with the larger set. So my comment would be if this is not so, then it needs to be explicitly stated, otherwise the natural understanding is 6lowapp is the application protocol group for 6lowpan devices - and what comes out of here, would likely be adopted going forward in deployments, I can respond to your other comments in more detail, but then again, if the scope is going to be limited, then so be it. -- Arjun Roychowdhury --00c09f89999b19b779047717e164 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lisa, responses inlined.
regds
arjun


On Thu, Oct 29, 2009 at 3:10 PM, Lisa Dusseault <lisa.dusseau= lt@gmail.com> wrote:

focused WG charter because this isn't "the charter for low-power I= P
applications protocols" it's merely *a* charter for a subset of th= ose
things. =A0We can't boil the ocean in one WG or even come to agreement<= br> on forming a WG if the scope is too big. =A0Besides considering that
other WGs can tackle this larger space, consider that this WG could
always go on to more complex use cases after solving simple ones.

ARC> I think this comment pretty much summari= zes the difference of thought between what I thought 6lowapp vs doing vs wh= at you are describing. The group name itself, "6lowapp" seems to = specify it is a group to to specificy low-power IP app protocols, and not a= subset.=A0draft-bormann-6lowpan-6lowapp-problem-01 also seems to indicate = this group is dealing with the larger set.

So my comment would be if this is not so, then it needs= to be explicitly stated, otherwise the natural understanding is 6lowapp is= the application protocol group for 6lowpan devices - and what comes out of= here, would likely be adopted going forward in deployments,

I can respond to your other comments in more detail, bu= t then again, if the scope is going to be limited, then so be it.
=A0
--
Arjun Roychowdhury

--00c09f89999b19b779047717e164-- From lisa.dusseault@gmail.com Thu Oct 29 14:40:10 2009 Return-Path: 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 327CD3A6810 for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 14:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 Kt6h6eOwUmGb for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 14:40:09 -0700 (PDT) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id AF1573A69A8 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 14:40:08 -0700 (PDT) Received: by vws31 with SMTP id 31so468499vws.29 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 14:40:21 -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=Z/776OhU1J88HIMXy/UzPkMYbZlo2hHyt1FkHvmtyN4=; b=YJazm6mxow9QbcK9y09o3oPQ8m4WmvvzFbp2w4XzaqGrdRluEZVdZTOMaYsdReRX3x Z10vkuT363JWLWhYhcLbDfIYCmP96rooXZMUR4LO5bzqIEm/m6EtcgD2ACaMk/FDZy0D GKbelKtIfGQbMqPkwqtmVU0z2Op+TigBfXJjY= 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=pMX9QJ0lKmKjJL2CuvXCrZ/KbSg4V+X0ZECBl9rtHYdJGP51Je7t5wsAog5A3D97+d wWRqJIXhaHJkPfBFsyrmlcGfp8vbJv3T22xfZ5cJTt5fBmjVK9GNm1408ISQpJlgBNkq g+Dh/qCQZn2LJH0cjWCetzqtxLq9TSzYsNmQk= MIME-Version: 1.0 Received: by 10.220.127.26 with SMTP id e26mr882489vcs.39.1256852421590; Thu, 29 Oct 2009 14:40:21 -0700 (PDT) In-Reply-To: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> Date: Thu, 29 Oct 2009 14:40:21 -0700 Message-ID: From: Lisa Dusseault To: arjun.lists@hsc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:40:10 -0000 On Thu, Oct 29, 2009 at 12:25 PM, Arjun Roychowdhury wrote: > So my comment would be if this is not so, then it needs to be explicitly > stated, otherwise the natural understanding is 6lowapp is the application > protocol group for 6lowpan devices - and what comes out of here, would > likely be adopted going forward in deployments, Fair enough, and I think there has been some talk of choosing a name for the WG that would not imply so large a scope as the BOF does. > I can respond to your other comments in more detail, but then again, if the > scope is going to be limited, then so be it. The discussion is still open about what the limited scope is going to be however! I did not mean to shut down debate but to channel it early towards picking part of the 80% value according to the 80/20 rule, or alternately to pick the most important pieces to build first. BTW, there has already been discussion about further splitting up the work besides just 6LOWPAN and whatever WG is spun off by a 6LOWAPP BOF; I wouldn't be surprised at if we saw another charter proposed by next summer, if not sooner. Lisa From jhui@archrock.com Thu Oct 29 22:08:06 2009 Return-Path: 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 B9F1F3A6961 for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 22:08:06 -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 tAy84MMdFLsJ for <6lowapp@core3.amsl.com>; Thu, 29 Oct 2009 22:08:05 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 2D2DE3A6952 for <6lowapp@ietf.org>; Thu, 29 Oct 2009 22:08:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1AAF0AFA42; Thu, 29 Oct 2009 22:08:22 -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 DQnbkGpVV-p0; Thu, 29 Oct 2009 22:08:17 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id 372B4AFA3F; Thu, 29 Oct 2009 22:08:17 -0700 (PDT) Message-Id: <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> From: Jonathan Hui To: Cullen Jennings In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 22:08:16 -0700 References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> X-Mailer: Apple Mail (2.936) Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 05:08:06 -0000 Hi Cullen, This is a good start. Generally, I think it covers the necessary work items. But while its important to have a focused charter that constrains the work, I'd rather have the charter focus on one or more target applications rather than a particular solution. Doing so will let the application requirements guide the solutions. See below: On Oct 28, 2009, at 11:42 PM, Cullen Jennings wrote: > 1) A requirements and architecture document that documents the high > level boxes and arrows view of the protocol along with high level > description of how the security, particular for commissioning of new > devices into the network will work. The WG may also produce a > document that describes various uses cases that help motivate the > requirements. Generating requirements is the most important first step. Though, I would suggest generating a set of application-specific requirements documents for a small and carefully chosen set of applications. The charter should indicate what applications we will work on first. It is useful to call out different applications due to their diversity. We did this in ROLL and it allowed us identify a base set of common features and those outside the base. It drives what we work on and the solutions. Just as important, it helped to bring other WG members up to speed on the variety of application requirements. Fortunately, we already have a number of individual submissions - but are there other not-yet-represented application areas that people want to work on? I would drop the "and architecture" from "requirements and architecture document". I'd prefer that the requirements docs drive the architecture, not specify it. > 2) Specification of the framework for defining interface profiles > and the defining the CoAP. The CoAP will be able to set and query a > resource on a Device. It will allow a device to publish a value or > event to another Device. It will support a non-reliable multicast > message to be sent to a group of devices to manipulate a resource on > all the devices simultaneously (roughly within 50 ms of each other). > The protocol will operate over UDP assuming a TBD byte payload and > assume an underlying network bandwidth of approximately TBD kbps. > The payload will be based on interface profile specific XML document > compressed with EXI. I would drop all the "it will do X, Y, Z". Let the requirements documents guide what the protocol/framework will support. > 3) Specification on how to use the CoAP to discover Devices on the > LoPAN and to interrogate them to find out which interface profiles > they support. Good. > 4) Specification for the HTTP REST based API on the PEP to > communicate with Devices. > > 4a) Possibly specify a separate specifications with mappings to > SNMP. [[NOte: In the BOF it would be nice to figure out if this is > in the charter or not.]] A REST/HTTP interface to the nodes is useful. But based on my experience, such a device provides the most benefit as a full-blown gateway, not just a proxy. In particular, just intercepting requests is not sufficient. For example, the gateway may queue data/events sent periodically by a node which are slurped up by a REST/HTTP client. The gateway may also provide additional metadata about the data (e.g. when it was received). There's a number of additional non- proxy-like functions I can think of. So I'd suggest changing the name to indicate gateway. > 5) A small set of basic interface profiles to illustrate how this is > done. Interface profiles will be done for a power meter, a light and > light switch, and temperature sensor. Again, let the set of application requirements drive the specific interface profiles we develop. > 6) A document with operation and management advice about running a > network using these applications. Good. > Security, particularly keying of new Devices, is very challenging > for these applications. On one hand this needs to support models > where an end user can introduce a new device onto their network that > may have no display or not input capability's. On the other end this > may transport information about alarm systems or controlling door > locks to a building over a wireless network. Important as well. Though I wouldn't go so far as to say what is mandatory and what is not in the charter. -- Jonathan Hui From cabo@tzi.org Fri Oct 30 00:33:48 2009 Return-Path: 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 DEC033A677E for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 00:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 qIgKeqylbRIp for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 00:33:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 954183A69EB for <6lowapp@ietf.org>; Fri, 30 Oct 2009 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9U7XjY3021112; Fri, 30 Oct 2009 08:33:46 +0100 (CET) Received: from [192.168.217.101] (p5489FD7F.dip.t-dialin.net [84.137.253.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2DD1AB099; Fri, 30 Oct 2009 08:33:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Carsten Bormann In-Reply-To: <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> Date: Fri, 30 Oct 2009 08:33:43 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1076) Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:33:49 -0000 Jonathan, I believe we have enough requirements documents. Application requirements are documented e.g. in the ZigBee/Homeplug MRD. The ROLL documents also contain a lot of information about application requirements. These have been focused on routing requirements in their later versions (and a lot of information that is useful to us has been removed), but people have already started resurrecting the earlier documents and retargeting them for 6lowapp. Now, application *protocol* requirements. Well, there are general technical requirements of constrained nodes/networks; I think we know these (both the ROLL documents and the 6LoWPAN documents contain some). I'd say beyond those there are no "requirements" for a protocol, unless you have an architecture. E.g., if you don't know whether PEPs (or gateways) are part of the architecture, you don't know whether you are designing for 100 % end-to-end usage or for usage that can get help from a PEP where required. That's why "requirements" and architecture are one milestone in the charter proposal. I understand that to build a bridge, you first write a requirements document (how many cars per hour?), and then design the bridge. This works well because bridges are a lot like each other, so you know what questions to ask (in essence, there is a well-known architecture for bridges). That kind of engineering is what engineers are mostly taught to do and what "feels right" to many, even though it is often not the way successful information/communication technologies work is done. In a design activity like the one we are undertaking, requirements (really: objectives) and solutions evolve in parallel. That's why it would not only be *slow* to spend a year on requirements first, but also be *wrong* fundamentally. Back to the application requirements: I do agree we should focus on a small number of specific areas of application, at least for making sure we have thought through some specific examples for each in detail. I think it would be useful if we called them out explicitly in the charter. Right now I'm seeing a lot of interest in 6lowapp from Energy (SE V2 etc.) and building automation (which may or may not include home automation). The charter does identify light switches, temp sensors, power meters, HVAC systems, and door locks as specific items that we will look at; so maybe we should be a bit more specific and identify the communication relationships we are addressing (and add light fixtures, plug-in vehicles and washing machines in the process). Gruesse, Carsten PS.: I wrote more on the rationale for trying not to get stuck in a requirements mire in http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html From jhui@archrock.com Fri Oct 30 01:31:53 2009 Return-Path: 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 83C7F3A6A61 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 01:31:53 -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 nHoACHGoiDYA for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 01:31:52 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B8F083A6A34 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 01:31:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 91210AF84A; Fri, 30 Oct 2009 01:32:09 -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 A3cgUhVkHQiI; Fri, 30 Oct 2009 01:32:05 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id 3F6C9AF849; Fri, 30 Oct 2009 01:32:05 -0700 (PDT) Message-Id: <9C1F3468-CD7F-4264-B1A5-576BC4FA0F9D@archrock.com> From: Jonathan Hui To: Carsten Bormann In-Reply-To: <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> 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 01:32:03 -0700 References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> X-Mailer: Apple Mail (2.936) Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 08:31:53 -0000 Hi Carsten, On Oct 30, 2009, at 12:33 AM, Carsten Bormann wrote: > Back to the application requirements: I do agree we should focus on > a small number of specific areas of application, at least for making > sure we have thought through some specific examples for each in > detail. I think it would be useful if we called them out explicitly > in the charter. Right now I'm seeing a lot of interest in 6lowapp > from Energy (SE V2 etc.) and building automation (which may or may > not include home automation). The charter does identify light > switches, temp sensors, power meters, HVAC systems, and door locks > as specific items that we will look at; so maybe we should be a bit > more specific and identify the communication relationships we are > addressing (and add light fixtures, plug-in vehicles and washing > machines in the process). It certainly would have helped me if the charter would have been more precise about what applications or subsets of applications we are trying to address. Without that knowledge, its hard to say whether or not we have the proper requirements written anywhere. BTW, I don't think the ZigBee/Homeplug MRD is sufficient in itself. Is the TRD available? Given the application(s), it would be even better if somewhere we indicated what functionality we plan to develop first. Are we only addressing manipulation of attributes that are relatively small in size? Are the most important profiles to get done first power, light, light switch, and temp? In the end, if we are to take knowledge of the application requirements for granted, the charter should be precise about what we are addressing. It's good to see that we are in line here. > Gruesse, Carsten > > PS.: I wrote more on the rationale for trying not to get stuck in a > requirements mire in > http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html I do prefer your suggested terminology of "objectives" vs. "requirements". -- Jonathan Hui From apezzuto@cisco.com Fri Oct 30 05:02:28 2009 Return-Path: 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 71E253A68A4 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 05:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7eQp9518SCuo for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 05:02:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 366A63A6814 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 05:02:27 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4AAJZy6kqQ/uCWe2dsb2JhbACbUAEBFiQGrU+YIYQ9BA X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208";a="53198757" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 12:02:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UC2gEW025235 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 12:02:42 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 13:02:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {61CE3C3E-B617-4735-98AA-FC299E2C47D3} x-cr-hashedpuzzle: An5u Ay5O B2Tt B4xM DP5Y DQiO DzWY EyBe EyW6 FrSf Ft5R F9lU GegY IvIR J6nB Kn8o; 1; NgBsAG8AdwBhAHAAcABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {61CE3C3E-B617-4735-98AA-FC299E2C47D3}; YQBwAGUAegB6AHUAdABvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 30 Oct 2009 12:02:39 GMT; WwA2AGwAbwB3AGEAcABwAF0AIABSAGUAYQBsAGwAeQAgAHcAZQAgAG4AZQBlAGQAIABmAG8AcgAgAEgAVABUAFAAIABvAG4AIABzAG0AYQByAHQAIABkAGUAdgBpAGMAZQBzAD8A Content-class: urn:content-classes:message Date: Fri, 30 Oct 2009 13:02:39 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Really we need for HTTP on smart devices? Thread-Index: AcpZWODfOIlfPZ/8SOKnR5dwHmOf1w== From: "Adriano Pezzuto (apezzuto)" To: <6lowapp@ietf.org> X-OriginalArrivalTime: 30 Oct 2009 12:02:42.0844 (UTC) FILETIME=[E2ACA5C0:01CA5958] Subject: [6lowapp] Really we need for HTTP on smart devices? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 12:02:28 -0000 Hello, there is a lot effort to push HTTP and REST interfaces on smart objects assuming that smart devices (sensor/actuators/readers) should act as Web providers. On the other side, 6lowpan and other wireless sensor networks are made by resource-constrained embedded devices so HTTP looks like too resource expensive. We are seeing a lot of proxying and gatewaying solutions to bring HTTP and REST on the 6lowpan devices. But working with gateways and proxies are always struggling especially at application level. My question here is why we need to bring HTTP on smart objects? Smart objects interact with the Internet as they like (and can) as humans do. Humans type on a computer keyboard or play in front of the iPhone camera while Things send sensing data or get commands to act on the real world. Humans do not have an embedded HTTP server even if the results of their actions (i.e. typing on a keyboard and playing in front of a camera) are available as Web resources. In the same way, Things do not need for an embedded HTTP server. Things interact with the Internet using a lightweight protocol while the results of their interaction are available on the Web as resources. It is a sort of "information shadow" data that Things have on the Web. This data will be collected in a suitable manner for the resource-constrained embedded devices and make available as Web resource with HTTP and REST interfaces. What do you think about it? Regards, Adriano From trifa@inf.ethz.ch Fri Oct 30 05:35:36 2009 Return-Path: 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 6D74F3A6869 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 05:35:36 -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 MjCHFq8YUhFu for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 05:35:35 -0700 (PDT) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.237]) by core3.amsl.com (Postfix) with ESMTP id BC3C63A657C for <6lowapp@ietf.org>; Fri, 30 Oct 2009 05:35:34 -0700 (PDT) Received: from CAS00.d.ethz.ch (129.132.178.234) by gws00.d.ethz.ch (129.132.178.237) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 30 Oct 2009 13:35:49 +0100 Received: from vs57.inf.ethz.ch (129.132.130.236) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 30 Oct 2009 13:35:27 +0100 Message-ID: From: Vlad Trifa To: "Adriano Pezzuto (apezzuto)" In-Reply-To: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> 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 13:35:27 +0100 References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 30 Oct 2009 05:41:22 -0700 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 12:36:46 -0000 Hello, Adriano: the web of things is exactly going beyond the "web information shadow" as you put it. We've been putting data from devices on the web since a decade, so what? nothing new there, but if you can turn devices by design into actual web actors (just as any other Web server), it open doors and completely new design possibilities as opposed to just make their data available on the web - it's a completely different (or broader) way of viewing things. Well, I think the "HTTP is too heavy" argument is certainly valid when you have very tight/specific requirements and need to maximize the throughput of your communication. Of course it is a verbose protocol, but you might gain a lot of using it directly on devices, especially in terms of application level interoperability, and even more important for plug & play integration with the Web and Web applications. Let's put it that way: how many people know/use the zillions application protocols/middlewares available (I don't want to mention any, because many are excellent for specific applications, but I don't believe much in the *perfect* middleware) hundreds? maybe thousands? Ok and now how may people use http/xml? I think you get my point here. Indeed, what you lose in performance (and it's not as bad as one thinks) you gain in terms of integrability. When I think smart homes, I think many constructors need to agree on a protocol. But I also think few messages here and there to control lights/HVAC and read energy meters with sub-second delay requirements. I don't think, thousands of messages per second nor high-frequency distributed sampling. Eventually, we want to reuse infrastructure that's already there (web), so why not use and adapt http/xml directly for that matter, as we need to design an application protocol anyway? Of course one can use gateways for doing this, but if you can have directly http on devices, then your gateway simply become routers across physical interfaces, and it's much faster because you don't need to open or understand packets passing through. Then if you think lots of concurrent people reading all types of http sensors from all types and constructors, then you can simply pop in a squid or any web cache, and voila, massively scalable infrastructure to store data (we got 20 years of experience with the web and the associated techs, so why reinvent the wheel when it rolls where you want?). I shall stop here, and please have a look at some of our work, I think we try to motivate and illustrate that exact point well there: http://www.vs.inf.ethz.ch/publ/papers/guinardSensorMashups09.pdf http://www.vs.inf.ethz.ch/publ/papers/dguinard_09_WOTMashups.pdf However, sorry I don't get the "humans don't have a web server" argument, what is your point with that? Vlad On Oct 30, 2009, at 1:02 PM, Adriano Pezzuto (apezzuto) wrote: > Hello, > there is a lot effort to push HTTP and REST interfaces on smart > objects > assuming that smart devices (sensor/actuators/readers) should act as > Web > providers. On the other side, 6lowpan and other wireless sensor > networks > are made by resource-constrained embedded devices so HTTP looks like > too > resource expensive. > > We are seeing a lot of proxying and gatewaying solutions to bring HTTP > and REST on the 6lowpan devices. But working with gateways and proxies > are always struggling especially at application level. My question > here > is why we need to bring HTTP on smart objects? > > Smart objects interact with the Internet as they like (and can) as > humans do. Humans type on a computer keyboard or play in front of the > iPhone camera while Things send sensing data or get commands to act on > the real world. Humans do not have an embedded HTTP server even if the > results of their actions (i.e. typing on a keyboard and playing in > front > of a camera) are available as Web resources. In the same way, Things > do > not need for an embedded HTTP server. Things interact with the > Internet > using a lightweight protocol while the results of their interaction > are > available on the Web as resources. It is a sort of "information > shadow" > data that Things have on the Web. This data will be collected in a > suitable manner for the resource-constrained embedded devices and make > available as Web resource with HTTP and REST interfaces. > > What do you think about it? > > Regards, > Adriano > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Fri Oct 30 06:13:48 2009 Return-Path: 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 A3C743A681A for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 06:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 h5OXSBWbONE2 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 06:13:47 -0700 (PDT) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id CC0323A6817 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 06:13:47 -0700 (PDT) Received: (qmail 81595 invoked from network); 30 Oct 2009 13:14:02 -0000 Received: from adsl-69-224-190-125.dsl.sndg02.pacbell.net (d.sturek@69.224.190.125 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 30 Oct 2009 06:14:02 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: gZz3l6MVM1mOt5Nm.4e35Y4Fp3DYww7aAfsNKwn9vDo5lOParpOCC4UytKOYclAYMWojYQzyRRN8s05v7GO4iN1mqf8W7RK6Glwb.pToF6SaTKHtAKk2VkxEJDUbt_.n.Wr.6K.nGalNZVtJL.65dLSd9lFxvSZj_JFgd_ROta6Ti5gDAbj56RHuk6qOyjPfzFfxZ.X7z5T9Cpz4VD_RNpTaeQOU8EN_1NMAi._yBjK5FWz7HU3z4.2EMlfZMZjh0QDa9TZ2QAeX2v9hok_9339y63Ig2wqDJvlhqnHJ1MmXTLotyfI- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Adriano Pezzuto \(apezzuto\)'" , <6lowapp@ietf.org> References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> Date: Fri, 30 Oct 2009 06:13:58 -0700 Message-ID: <007501ca5962$d7e3d460$87ab7d20$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZWODfOIlfPZ/8SOKnR5dwHmOf1wACWbIg Content-Language: en-us Subject: Re: [6lowapp] Really we need for HTTP on smart devices? X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:13:48 -0000 Hi Adriano, We spent some time looking at the options for message exchange in Smart Energy V2. We knew we would be using self describing data (XML most likely) and looked at the technologies that would allow the best integration with existing internet/web solutions (basically trying to avoid a proprietary binary protocol if we could). I agree full HTTP would be too heavy on a small device. However, using a minimal set of HTTP features and a REST data exchange paradigm seemed to be the most elegant solution. I don't expect each device to host a web server but I would expect some devices to do so It just seemed that if we could align on a known, deployed standard, adapted for small devices, we would gain a lot in adoption. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Adriano Pezzuto (apezzuto) Sent: Friday, October 30, 2009 5:03 AM To: 6lowapp@ietf.org Subject: [6lowapp] Really we need for HTTP on smart devices? Hello, there is a lot effort to push HTTP and REST interfaces on smart objects assuming that smart devices (sensor/actuators/readers) should act as Web providers. On the other side, 6lowpan and other wireless sensor networks are made by resource-constrained embedded devices so HTTP looks like too resource expensive. We are seeing a lot of proxying and gatewaying solutions to bring HTTP and REST on the 6lowpan devices. But working with gateways and proxies are always struggling especially at application level. My question here is why we need to bring HTTP on smart objects? Smart objects interact with the Internet as they like (and can) as humans do. Humans type on a computer keyboard or play in front of the iPhone camera while Things send sensing data or get commands to act on the real world. Humans do not have an embedded HTTP server even if the results of their actions (i.e. typing on a keyboard and playing in front of a camera) are available as Web resources. In the same way, Things do not need for an embedded HTTP server. Things interact with the Internet using a lightweight protocol while the results of their interaction are available on the Web as resources. It is a sort of "information shadow" data that Things have on the Web. This data will be collected in a suitable manner for the resource-constrained embedded devices and make available as Web resource with HTTP and REST interfaces. What do you think about it? Regards, Adriano _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Fri Oct 30 06:17:54 2009 Return-Path: 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 C4B263A69D2 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 06:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[AWL=1.484, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 vt+HANiL4blQ for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 06:17:54 -0700 (PDT) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id 0E6293A67A1 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 06:17:54 -0700 (PDT) Received: (qmail 82511 invoked from network); 30 Oct 2009 13:18:11 -0000 Received: from adsl-69-224-190-125.dsl.sndg02.pacbell.net (d.sturek@69.224.190.125 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 30 Oct 2009 06:18:10 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: iAE4p1sVM1mBwfCHfVKuiz5m6trrHRDiAMr.B7wthDFFleZZO.JhadfSQmhZ6U1.jASoi0wM3fnMj1C83ZcufraPVjsxDJ0tvauIpOVEETBMatw2Gp_kkPbosGRxr9JPY81X7MDIhJ02G9b38UgERchexHqo_VqCSEhgZml2IzqUa49fUFt8ETk7sXD2i.QzMtlRc26csdTLK2VS1wWXpMdD.GvXDbjSxu.3TAjOu7qMPV5maAylQhMCGf.oKvoHhyf7IG0T3kpj2h3MdESKWxTVYtous2MGzROTTRmIIMF0pp36090- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" , "'Carsten Bormann'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <9C1F3468-CD7F-4264-B1A5-576BC4FA0F9D@archrock.com> In-Reply-To: Date: Fri, 30 Oct 2009 06:18:07 -0700 Message-ID: <007d01ca5963$6c091790$441b46b0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZO4IvWbRA7D1jQXCNOL+MIHwT7wAJ5IYAAAATTHA= Content-Language: en-us 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 Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:17:54 -0000 Hi Jonathan, In ZigBee/HomePlug, we are working on a TRD to address the MRD and Use Cases (have you also looked at the use cases?). We hope to have a draft of the TRD posted soon. Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Friday, October 30, 2009 1:32 AM To: Carsten Bormann Cc: Cullen Jennings; Don Sturek; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF Hi Carsten, On Oct 30, 2009, at 12:33 AM, Carsten Bormann wrote: > Back to the application requirements: I do agree we should focus on > a small number of specific areas of application, at least for making > sure we have thought through some specific examples for each in > detail. I think it would be useful if we called them out explicitly > in the charter. Right now I'm seeing a lot of interest in 6lowapp > from Energy (SE V2 etc.) and building automation (which may or may > not include home automation). The charter does identify light > switches, temp sensors, power meters, HVAC systems, and door locks > as specific items that we will look at; so maybe we should be a bit > more specific and identify the communication relationships we are > addressing (and add light fixtures, plug-in vehicles and washing > machines in the process). It certainly would have helped me if the charter would have been more precise about what applications or subsets of applications we are trying to address. Without that knowledge, its hard to say whether or not we have the proper requirements written anywhere. BTW, I don't think the ZigBee/Homeplug MRD is sufficient in itself. Is the TRD available? Given the application(s), it would be even better if somewhere we indicated what functionality we plan to develop first. Are we only addressing manipulation of attributes that are relatively small in size? Are the most important profiles to get done first power, light, light switch, and temp? In the end, if we are to take knowledge of the application requirements for granted, the charter should be precise about what we are addressing. It's good to see that we are in line here. > Gruesse, Carsten > > PS.: I wrote more on the rationale for trying not to get stuck in a > requirements mire in > http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html I do prefer your suggested terminology of "objectives" vs. "requirements". -- Jonathan Hui From d.sturek@att.net Fri Oct 30 06:25:31 2009 Return-Path: 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 9D8A73A6910 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 06:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 OSe0lKrW3aua for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 06:25:30 -0700 (PDT) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id 82F3A3A68DA for <6lowapp@ietf.org>; Fri, 30 Oct 2009 06:25:30 -0700 (PDT) Received: from [209.191.108.97] by n13.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2009 13:25:46 -0000 Received: from [68.142.201.253] by t4.bullet.mud.yahoo.com with NNFMP; 30 Oct 2009 13:25:46 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 30 Oct 2009 13:25:46 -0000 X-Yahoo-Newman-Id: 77033.77386.bm@omp414.mail.mud.yahoo.com Received: (qmail 19125 invoked from network); 30 Oct 2009 13:25:45 -0000 Received: from unknown (HELO Studio) (d.sturek@69.224.190.125 with login) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 30 Oct 2009 13:25:45 -0000 X-YMail-OSG: ORz_rT8VM1kYbTroqiT1v2AETdijZI2.D0ssa0rtgpd0PEEZuvjiLe_IFrR9OoJD8LY8hSWt9TjMftlZNuVDnHDThS6tUiAwFUq24RARuLStorV93jXr79z0zy98T047I4zYPfQzXq0NLaUjzI9cL3ny6CwOHBCchW4rifZ1OMZpAfbdQCJD21Su1rchUFEzAAMm8DbtPn1u_n9WjXmlF1qrs.I5ptAW_LfTaAH0i4cWzTF6xoLDVyNFyNI3Cvu7TLT0CJhlnaVcqdka3RIM_iI6MAvZrF6UFiv1smmXKSCKOp94tHlvZXwweeQYKZN5VTpd6lE- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , "'Jonathan Hui'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> In-Reply-To: <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> Date: Fri, 30 Oct 2009 06:25:41 -0700 Message-ID: <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZM116W0bqsLWnQayWjLQxusIEIAAMEd9Q Content-Language: en-us 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 Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:25:31 -0000 Hi Carsten, 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. We were hoping to scope a useful, mainstream subset of existing protocols. This is why we plan to start with HTTP (obviously not a full implementation but whatever meaningful legal subset we can use) along with a RESTful message exchange. At least this is what we are going to start with, in terms of interoperability testing. Clearly the story does not stop here. Ideally we would like to see as many mainstream services as practical/possible deployed on these small devices (hopefully without proxy). Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Friday, October 30, 2009 12:34 AM To: Jonathan Hui Cc: Don Sturek; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF Jonathan, I believe we have enough requirements documents. Application requirements are documented e.g. in the ZigBee/Homeplug MRD. The ROLL documents also contain a lot of information about application requirements. These have been focused on routing requirements in their later versions (and a lot of information that is useful to us has been removed), but people have already started resurrecting the earlier documents and retargeting them for 6lowapp. Now, application *protocol* requirements. Well, there are general technical requirements of constrained nodes/networks; I think we know these (both the ROLL documents and the 6LoWPAN documents contain some). I'd say beyond those there are no "requirements" for a protocol, unless you have an architecture. E.g., if you don't know whether PEPs (or gateways) are part of the architecture, you don't know whether you are designing for 100 % end-to-end usage or for usage that can get help from a PEP where required. That's why "requirements" and architecture are one milestone in the charter proposal. I understand that to build a bridge, you first write a requirements document (how many cars per hour?), and then design the bridge. This works well because bridges are a lot like each other, so you know what questions to ask (in essence, there is a well-known architecture for bridges). That kind of engineering is what engineers are mostly taught to do and what "feels right" to many, even though it is often not the way successful information/communication technologies work is done. In a design activity like the one we are undertaking, requirements (really: objectives) and solutions evolve in parallel. That's why it would not only be *slow* to spend a year on requirements first, but also be *wrong* fundamentally. Back to the application requirements: I do agree we should focus on a small number of specific areas of application, at least for making sure we have thought through some specific examples for each in detail. I think it would be useful if we called them out explicitly in the charter. Right now I'm seeing a lot of interest in 6lowapp from Energy (SE V2 etc.) and building automation (which may or may not include home automation). The charter does identify light switches, temp sensors, power meters, HVAC systems, and door locks as specific items that we will look at; so maybe we should be a bit more specific and identify the communication relationships we are addressing (and add light fixtures, plug-in vehicles and washing machines in the process). Gruesse, Carsten PS.: I wrote more on the rationale for trying not to get stuck in a requirements mire in http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From apezzuto@cisco.com Fri Oct 30 07:59:11 2009 Return-Path: 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 50F2A3A6974 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 07:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 QIshHYvtek6I for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 07:59:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B3A2C3A68E6 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 07:59:08 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkAAJqb6kqQ/uCWe2dsb2JhbACbVgEBFiQGrXKYIYI5ggQE X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208";a="53219664" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 14:59:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UExOvG027870; Fri, 30 Oct 2009 14:59:24 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:59:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 15:59:23 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC8E8736@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Really we need for HTTP on smart devices? Thread-Index: AcpZXYmGBYu6OvI5T0y6AJgphzc2qQAD/CvQ References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> From: "Adriano Pezzuto (apezzuto)" To: "Vlad Trifa" , X-OriginalArrivalTime: 30 Oct 2009 14:59:24.0487 (UTC) FILETIME=[91BEFD70:01CA5971] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:59:11 -0000 Vlad/Don, thanks for your feedbacks. Nice to see starting a debate here. Vlad, I know your work at the Web of Things and it's fine. On the other side, today we do not see many real 6lowpan devices able to = support HTTP on TCP. SunSpot is fine but for 6lowpan we have 60-80 bytes = of payload and 10kbps in application throughput to deal with. It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and = gatewaying/proxying is only a compromise not a solution. I'm try to find = different points of view, so my initial question. Please have a look to this interesting paper from Tim O'Reilly and John = Battelle: http://www.web2summit.com/web2009/public/schedule/detail/10194 " Many who talk about "the Internet of Things" assume that what will get = us there is the combination of ultra-cheap RFID and IP addresses for = everyday objects. The assumption is that every object must have a unique = identifier for the "Internet of Things" to work. What the Web 2.0 sensibility tells us is that we'll get to the Internet = of Things via a hodgepodge of sensor data contributing, bottom-up, to = machine-learning applications that gradually make more and more sense of = the data that is handed to them. A bottle of wine on your supermarket = shelf (or any other object) needn't have an RFID tag to join the = "Internet of Things," it simply needs you to take a picture of its = label. Your mobile phone, image recognition, search, and the sentient = web will do the rest. We don't have to wait until each item in the = supermarket has a unique machine-readable ID. Instead, we can make do = with bar codes, tags on photos, and other "hacks" that are simply ways = of brute-forcing identity out of reality. " Regards, Adriano -----Original Message----- From: Vlad Trifa [mailto:trifa@inf.ethz.ch]=20 Sent: venerd=EC 30 ottobre 2009 13.35 To: Adriano Pezzuto (apezzuto) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? Hello, Adriano: the web of things is exactly going beyond the "web =20 information shadow" as you put it. We've been putting data from =20 devices on the web since a decade, so what? nothing new there, but if =20 you can turn devices by design into actual web actors (just as any =20 other Web server), it open doors and completely new design =20 possibilities as opposed to just make their data available on the web =20 - it's a completely different (or broader) way of viewing things. Well, I think the "HTTP is too heavy" argument is certainly valid when =20 you have very tight/specific requirements and need to maximize the =20 throughput of your communication. Of course it is a verbose protocol, =20 but you might gain a lot of using it directly on devices, especially =20 in terms of application level interoperability, and even more =20 important for plug & play integration with the Web and Web =20 applications. Let's put it that way: how many people know/use the =20 zillions application protocols/middlewares available (I don't want to =20 mention any, because many are excellent for specific applications, but =20 I don't believe much in the *perfect* middleware) hundreds? maybe =20 thousands? Ok and now how may people use http/xml? I think you get my =20 point here. Indeed, what you lose in performance (and it's not as bad as one =20 thinks) you gain in terms of integrability. When I think smart homes, =20 I think many constructors need to agree on a protocol. But I also =20 think few messages here and there to control lights/HVAC and read =20 energy meters with sub-second delay requirements. I don't think, =20 thousands of messages per second nor high-frequency distributed =20 sampling. Eventually, we want to reuse infrastructure that's already =20 there (web), so why not use and adapt http/xml directly for that =20 matter, as we need to design an application protocol anyway? Of course one can use gateways for doing this, but if you can have =20 directly http on devices, then your gateway simply become routers =20 across physical interfaces, and it's much faster because you don't =20 need to open or understand packets passing through. Then if you think lots of concurrent people reading all types of http =20 sensors from all types and constructors, then you can simply pop in a =20 squid or any web cache, and voila, massively scalable infrastructure =20 to store data (we got 20 years of experience with the web and the =20 associated techs, so why reinvent the wheel when it rolls where you =20 want?). I shall stop here, and please have a look at some of our work, I think =20 we try to motivate and illustrate that exact point well there: http://www.vs.inf.ethz.ch/publ/papers/guinardSensorMashups09.pdf http://www.vs.inf.ethz.ch/publ/papers/dguinard_09_WOTMashups.pdf However, sorry I don't get the "humans don't have a web server" =20 argument, what is your point with that? Vlad On Oct 30, 2009, at 1:02 PM, Adriano Pezzuto (apezzuto) wrote: > Hello, > there is a lot effort to push HTTP and REST interfaces on smart =20 > objects > assuming that smart devices (sensor/actuators/readers) should act as =20 > Web > providers. On the other side, 6lowpan and other wireless sensor =20 > networks > are made by resource-constrained embedded devices so HTTP looks like =20 > too > resource expensive. > > We are seeing a lot of proxying and gatewaying solutions to bring HTTP > and REST on the 6lowpan devices. But working with gateways and proxies > are always struggling especially at application level. My question =20 > here > is why we need to bring HTTP on smart objects? > > Smart objects interact with the Internet as they like (and can) as > humans do. Humans type on a computer keyboard or play in front of the > iPhone camera while Things send sensing data or get commands to act on > the real world. Humans do not have an embedded HTTP server even if the > results of their actions (i.e. typing on a keyboard and playing in =20 > front > of a camera) are available as Web resources. In the same way, Things =20 > do > not need for an embedded HTTP server. Things interact with the =20 > Internet > using a lightweight protocol while the results of their interaction =20 > are > available on the Web as resources. It is a sort of "information =20 > shadow" > data that Things have on the Web. This data will be collected in a > suitable manner for the resource-constrained embedded devices and make > available as Web resource with HTTP and REST interfaces. > > What do you think about it? > > Regards, > Adriano > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From adam@sics.se Fri Oct 30 08:03:56 2009 Return-Path: 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 D3A763A697D for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 3NJCzOeJkYil for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:03:56 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id DAA613A6969 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 08:03:55 -0700 (PDT) Received: from [10.1.1.19] (unknown [10.1.1.19]) by letter.sics.se (Postfix) with ESMTP id 933AD4010C; Fri, 30 Oct 2009 16:04:11 +0100 (CET) Message-ID: <4AEB0065.7090108@sics.se> Date: Fri, 30 Oct 2009 16:04:05 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Adriano Pezzuto (apezzuto)" References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC8E8736@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC8E8736@XMB-AMS-106.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 15:03:56 -0000 Adriano Pezzuto (apezzuto) wrote: > Vlad, > I know your work at the Web of Things and it's fine. > On the other side, today we do not see many real 6lowpan devices able to support HTTP on TCP. SunSpot is fine but for 6lowpan we have 60-80 bytes of payload and 10kbps in application throughput to deal with. > > It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and gatewaying/proxying is only a compromise not a solution. I'm try to find different points of view, so my initial question. HTTP is quite lightweight and not a problem for constrained devices per se. See e.g. http://www.sics.se/~adam/yazar09efficient.pdf That said, HTTP may not always be the perfect solution for everything, but it is definitely achievable. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From jhui@archrock.com Fri Oct 30 08:08:50 2009 Return-Path: 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: From: Jonathan Hui To: 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: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <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: , List-Archive: List-Post: List-Help: List-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 From d.sturek@att.net Fri Oct 30 08:20:37 2009 Return-Path: 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 E9CCB3A6974 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 c6t33aA1vQ6a for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:20:34 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 92EEC3A692D for <6lowapp@ietf.org>; Fri, 30 Oct 2009 08:20:34 -0700 (PDT) Received: (qmail 53279 invoked from network); 30 Oct 2009 15:20:48 -0000 Received: from adsl-69-224-190-125.dsl.sndg02.pacbell.net (d.sturek@69.224.190.125 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 30 Oct 2009 08:20:48 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: EnQn1HYVM1mbGeWGpErK.RRvLv4i.UZH62HKwV2gMq9_MS6NwTsh_RPhX5nzentIznNZncHpjYw_cX_UBKATA5TLW3eY6SF3Ekash3fzvfB80qpetobTytslj1KKXzhhJVT4f_99Vi9u6QH4pdJZ._b4CIFbRfHuTPN2JdQQTYx4BxyeY8qU4zZYKa1blrWsRyQDDxcr5KlmkFuLKyKkWHfiKLJyF3eXt_OPmhomed7jS1YnbjRAGJ88FLqTuG5PPdFCk9TJT6MHQKJIpFDqHj3Q9OCPJy0gVBalw.ynwPQTZc5f.3ksU9K6UUnn_R8hv9BNlLa9WYU3rjsQJ0yHQg1R3hjG X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net> In-Reply-To: Date: Fri, 30 Oct 2009 08:20:42 -0700 Message-ID: <014001ca5974$8cb63430$a6229c90$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZcuzzmOa/1h90ScG4yI/iwaYgbAAATI0Q Content-Language: en-us 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 Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 15:20:38 -0000 Hi Jonathan, Most utilities already have Data Aggregators in their network. Those are typically used in the neighborhood area network where collections of meters are interfaced to the utility back office. One example of this is Outage notification. Having a few meters tell you there is an outage is fine, having all of the meters in Los Angeles tell you the power went out is not helpful....... Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Friday, October 30, 2009 8:09 AM To: d.sturek@att.net Cc: 'Carsten Bormann'; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF 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 From jhui@archrock.com Fri Oct 30 08:48:46 2009 Return-Path: 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 042B228C113 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:48:46 -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 U5hR6t0Zf9PT for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:48:45 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3137428C10F for <6lowapp@ietf.org>; Fri, 30 Oct 2009 08:48:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 83819AF89E; Fri, 30 Oct 2009 08:49:02 -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 fC1LGXDpK+v9; Fri, 30 Oct 2009 08:48:57 -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 9F550AF849; Fri, 30 Oct 2009 08:48:57 -0700 (PDT) Message-Id: From: Jonathan Hui To: In-Reply-To: <014001ca5974$8cb63430$a6229c90$@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:48:56 -0700 References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net> <014001ca5974$8cb63430$a6229c90$@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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 15:48:46 -0000 Hi Don, On Oct 30, 2009, at 8:20 AM, Don Sturek wrote: > Most utilities already have Data Aggregators in their network. > Those are > typically used in the neighborhood area network where collections of > meters > are interfaced to the utility back office. One example of this is > Outage > notification. Having a few meters tell you there is an outage is > fine, > having all of the meters in Los Angeles tell you the power went out > is not > helpful....... Right. Then I would ask if you would find it useful/necessary for this WG to work on standardizing a service that can effectively aggregate LLN devices? I'm really asking these questions because I don't think it's obvious what pieces are necessary. Even less obvious if we don't have clear- cut application targets. -- Jonathan Hui From apezzuto@cisco.com Fri Oct 30 08:57:23 2009 Return-Path: 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 334A13A6783 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 iR-AKIINztaR for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 08:57:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 352FD3A6859 for <6lowapp@ietf.org>; Fri, 30 Oct 2009 08:57:22 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+p6kqrR7Ht/2dsb2JhbADJa5gthD0E X-IronPort-AV: E=Sophos;i="4.44,654,1249257600"; d="scan'208";a="47427598" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2009 15:57:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UFvaH0011226; Fri, 30 Oct 2009 15:57:39 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 16:57:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 16:57:37 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC8E87A0@XMB-AMS-106.cisco.com> In-Reply-To: <4AEB0065.7090108@sics.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Really we need for HTTP on smart devices? Thread-Index: AcpZclG2vOYc9KutTAev/PbalFirRAABbC7w References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC8E8736@XMB-AMS-106.cisco.com> <4AEB0065.7090108@sics.se> From: "Adriano Pezzuto (apezzuto)" To: "Adam Dunkels" X-OriginalArrivalTime: 30 Oct 2009 15:57:37.0946 (UTC) FILETIME=[B40287A0:01CA5979] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 15:57:23 -0000 Thanks Adam, It's a very interested work.=20 Regards, Adriano -----Original Message----- From: Adam Dunkels [mailto:adam@sics.se]=20 Sent: venerd=EC 30 ottobre 2009 16.04 To: Adriano Pezzuto (apezzuto) Cc: Vlad Trifa; d.sturek@att.net; 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? Adriano Pezzuto (apezzuto) wrote: > Vlad, > I know your work at the Web of Things and it's fine. > On the other side, today we do not see many real 6lowpan devices able = to support HTTP on TCP. SunSpot is fine but for 6lowpan we have 60-80 = bytes of payload and 10kbps in application throughput to deal with. >=20 > It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and = gatewaying/proxying is only a compromise not a solution. I'm try to find = different points of view, so my initial question. HTTP is quite lightweight and not a problem for constrained devices per=20 se. See e.g. http://www.sics.se/~adam/yazar09efficient.pdf That said, HTTP may not always be the perfect solution for everything,=20 but it is definitely achievable. /adam --=20 Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From trifa@inf.ethz.ch Fri Oct 30 09:01:23 2009 Return-Path: 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 AD7173A694C for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 09:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 xPtAqVqB74vc for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 09:01:22 -0700 (PDT) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.238]) by core3.amsl.com (Postfix) with ESMTP id 6BB5F28C0FC for <6lowapp@ietf.org>; Fri, 30 Oct 2009 09:01:20 -0700 (PDT) Received: from CAS00.d.ethz.ch (129.132.178.234) by gws01.d.ethz.ch (129.132.178.238) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 30 Oct 2009 17:01:35 +0100 Received: from vs57.inf.ethz.ch (129.132.130.236) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 30 Oct 2009 17:01:35 +0100 Message-ID: <24264A7A-4233-4135-8DDC-F77EA79A682D@inf.ethz.ch> From: Vlad Trifa To: "Adriano Pezzuto (apezzuto)" In-Reply-To: <0D212BD466921646B58854FB79092CEC8E8736@XMB-AMS-106.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Oct 2009 17:01:35 +0100 References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC8E8736@XMB-AMS-106.cisco.com> X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:01:23 -0000 I totally agree with you! I don't think I ever said that "everything =20 in the world must be a web server". Of course I'm in favor of rfid and =20= hacks and barcodes to get data about the real-world on the web and =20 even better when it doesn't need a web server or not a machine. What you say really feels like you're trying to convince me about =20 something we both know and agree with (just like every one else here I =20= guess), so I don't see the point of discussing that. When it comes to electronic devices I think HTTP is sufficient for =20 many applications (again not all, just many), but as Adam points it =20 out, it's not perfect for everything. I simply disagree with your =20 comment "SunSpot is fine but for 6lowpan we have 60-80 bytes of =20 payload and 10kbps in application throughput to deal with.". I'll also add another example: Smews is a web server able to do comet = (http://en.wikipedia.org/wiki/Comet_%28programming%29=20 ) with 100's of simultaneous subscribers (devices push http =20 notifications to the subscribers) with decent amount of time. Smews =20 needs 8kb and has been running on a standard msp430-based sensor node. It's certainly slower than custom solutions, but it's there and works, =20= and if you want to collect a temperature reading every minute, that's =20= more than enough. On Oct 30, 2009, at 3:59 PM, Adriano Pezzuto (apezzuto) wrote: > Vlad/Don, > thanks for your feedbacks. Nice to see starting a debate here. > > Vlad, > I know your work at the Web of Things and it's fine. > On the other side, today we do not see many real 6lowpan devices =20 > able to support HTTP on TCP. SunSpot is fine but for 6lowpan we have =20= > 60-80 bytes of payload and 10kbps in application throughput to deal =20= > with. > > It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and =20= > gatewaying/proxying is only a compromise not a solution. I'm try to =20= > find different points of view, so my initial question. > > Please have a look to this interesting paper from Tim O'Reilly and =20 > John Battelle: > > http://www.web2summit.com/web2009/public/schedule/detail/10194 > " > Many who talk about "the Internet of Things" assume that what will =20 > get us there is the combination of ultra-cheap RFID and IP addresses =20= > for everyday objects. The assumption is that every object must have =20= > a unique identifier for the "Internet of Things" to work. > > What the Web 2.0 sensibility tells us is that we'll get to the =20 > Internet of Things via a hodgepodge of sensor data contributing, =20 > bottom-up, to machine-learning applications that gradually make more =20= > and more sense of the data that is handed to them. A bottle of wine =20= > on your supermarket shelf (or any other object) needn't have an RFID =20= > tag to join the "Internet of Things," it simply needs you to take a =20= > picture of its label. Your mobile phone, image recognition, search, =20= > and the sentient web will do the rest. We don't have to wait until =20 > each item in the supermarket has a unique machine-readable ID. =20 > Instead, we can make do with bar codes, tags on photos, and other =20 > "hacks" that are simply ways of brute-forcing identity out of =20 > reality. " > > Regards, > Adriano > > > > -----Original Message----- > From: Vlad Trifa [mailto:trifa@inf.ethz.ch] > Sent: venerd=EC 30 ottobre 2009 13.35 > To: Adriano Pezzuto (apezzuto) > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Really we need for HTTP on smart devices? > > Hello, > > Adriano: the web of things is exactly going beyond the "web > information shadow" as you put it. We've been putting data from > devices on the web since a decade, so what? nothing new there, but if > you can turn devices by design into actual web actors (just as any > other Web server), it open doors and completely new design > possibilities as opposed to just make their data available on the web > - it's a completely different (or broader) way of viewing things. > > Well, I think the "HTTP is too heavy" argument is certainly valid when > you have very tight/specific requirements and need to maximize the > throughput of your communication. Of course it is a verbose protocol, > but you might gain a lot of using it directly on devices, especially > in terms of application level interoperability, and even more > important for plug & play integration with the Web and Web > applications. Let's put it that way: how many people know/use the > zillions application protocols/middlewares available (I don't want to > mention any, because many are excellent for specific applications, but > I don't believe much in the *perfect* middleware) hundreds? maybe > thousands? Ok and now how may people use http/xml? I think you get my > point here. > > Indeed, what you lose in performance (and it's not as bad as one > thinks) you gain in terms of integrability. When I think smart homes, > I think many constructors need to agree on a protocol. But I also > think few messages here and there to control lights/HVAC and read > energy meters with sub-second delay requirements. I don't think, > thousands of messages per second nor high-frequency distributed > sampling. Eventually, we want to reuse infrastructure that's already > there (web), so why not use and adapt http/xml directly for that > matter, as we need to design an application protocol anyway? > > Of course one can use gateways for doing this, but if you can have > directly http on devices, then your gateway simply become routers > across physical interfaces, and it's much faster because you don't > need to open or understand packets passing through. > > Then if you think lots of concurrent people reading all types of http > sensors from all types and constructors, then you can simply pop in a > squid or any web cache, and voila, massively scalable infrastructure > to store data (we got 20 years of experience with the web and the > associated techs, so why reinvent the wheel when it rolls where you > want?). > > I shall stop here, and please have a look at some of our work, I think > we try to motivate and illustrate that exact point well there: > > http://www.vs.inf.ethz.ch/publ/papers/guinardSensorMashups09.pdf > http://www.vs.inf.ethz.ch/publ/papers/dguinard_09_WOTMashups.pdf > > However, sorry I don't get the "humans don't have a web server" > argument, what is your point with that? > > > Vlad > > > On Oct 30, 2009, at 1:02 PM, Adriano Pezzuto (apezzuto) wrote: > >> Hello, >> there is a lot effort to push HTTP and REST interfaces on smart >> objects >> assuming that smart devices (sensor/actuators/readers) should act as >> Web >> providers. On the other side, 6lowpan and other wireless sensor >> networks >> are made by resource-constrained embedded devices so HTTP looks like >> too >> resource expensive. >> >> We are seeing a lot of proxying and gatewaying solutions to bring =20 >> HTTP >> and REST on the 6lowpan devices. But working with gateways and =20 >> proxies >> are always struggling especially at application level. My question >> here >> is why we need to bring HTTP on smart objects? >> >> Smart objects interact with the Internet as they like (and can) as >> humans do. Humans type on a computer keyboard or play in front of the >> iPhone camera while Things send sensing data or get commands to act =20= >> on >> the real world. Humans do not have an embedded HTTP server even if =20= >> the >> results of their actions (i.e. typing on a keyboard and playing in >> front >> of a camera) are available as Web resources. In the same way, Things >> do >> not need for an embedded HTTP server. Things interact with the >> Internet >> using a lightweight protocol while the results of their interaction >> are >> available on the Web as resources. It is a sort of "information >> shadow" >> data that Things have on the Web. This data will be collected in a >> suitable manner for the resource-constrained embedded devices and =20 >> make >> available as Web resource with HTTP and REST interfaces. >> >> What do you think about it? >> >> Regards, >> Adriano >> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > From d.sturek@att.net Fri Oct 30 09:02:10 2009 Return-Path: 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 C736728C0D7 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 b3R3T7ao9BTd for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 09:02:10 -0700 (PDT) Received: from n12b.bullet.mail.mud.yahoo.com (n12b.bullet.mail.mud.yahoo.com [209.191.125.179]) by core3.amsl.com (Postfix) with SMTP id DF8033A694C for <6lowapp@ietf.org>; Fri, 30 Oct 2009 09:02:09 -0700 (PDT) Received: from [68.142.194.244] by n12.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2009 16:02:25 -0000 Received: from [68.142.201.253] by t2.bullet.mud.yahoo.com with NNFMP; 30 Oct 2009 16:02:25 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 30 Oct 2009 16:02:25 -0000 X-Yahoo-Newman-Id: 24230.34946.bm@omp414.mail.mud.yahoo.com Received: (qmail 98865 invoked from network); 30 Oct 2009 16:02:24 -0000 Received: from adsl-69-224-190-125.dsl.sndg02.pacbell.net (d.sturek@69.224.190.125 with login) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 30 Oct 2009 09:02:24 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: dhoQFYwVM1nwDnv8VpH33Zfde.UXeWIMHoU5yO4gm_xCxyywZR_G8a_ngqfcRCsjn7fCD2cN7hMwbIghgQ9EvWc8k0hAZOj.9LdUNMI9ThY9giNZzn_NWYXx7or0NmLz3P1RgutDqDdV_KgX8ZYdZGpJFCxb888oBDPBqUURUEdBDInm3rs6YK92KiZT5oUxVgpfgAnc3EGNE2Kriwjdp9XYWv1TKRuHAcAY4nVhL8k6WgZR1BUyOE6TtWU- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Jonathan Hui'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net> <014001ca5974$8cb63430$a6229c90$@sturek@att.net> In-Reply-To: Date: Fri, 30 Oct 2009 09:02:18 -0700 Message-ID: <017401ca597a$5c54e470$14fead50$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZeIGsKQqcasnEQvyBseZAmE5F3gAAXdTA Content-Language: en-us 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 Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:02:10 -0000 Hi Jonathan, Aggregators are great devices when defined by end customers to meet an application need. The trouble comes in when we introduce them for network layer support in non-obvious places. I think we should try to find solutions which avoid PEPs and other aggregation devices in general. If we find we have to have these devices, we should work with those responsible for deployment to be sure this maps to their solution space. Don -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Friday, October 30, 2009 8:49 AM To: d.sturek@att.net Cc: 'Carsten Bormann'; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF Hi Don, On Oct 30, 2009, at 8:20 AM, Don Sturek wrote: > Most utilities already have Data Aggregators in their network. > Those are > typically used in the neighborhood area network where collections of > meters > are interfaced to the utility back office. One example of this is > Outage > notification. Having a few meters tell you there is an outage is > fine, > having all of the meters in Los Angeles tell you the power went out > is not > helpful....... Right. Then I would ask if you would find it useful/necessary for this WG to work on standardizing a service that can effectively aggregate LLN devices? I'm really asking these questions because I don't think it's obvious what pieces are necessary. Even less obvious if we don't have clear- cut application targets. -- Jonathan Hui From jhui@archrock.com Fri Oct 30 09:19:00 2009 Return-Path: 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 074543A69D3 for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 09:19:00 -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 nNWflRQQqK9G for <6lowapp@core3.amsl.com>; Fri, 30 Oct 2009 09:18:59 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4D0D73A68AB for <6lowapp@ietf.org>; Fri, 30 Oct 2009 09:18:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5D126AFA5B; Fri, 30 Oct 2009 09:19:16 -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 i9-dcc6rQjRU; Fri, 30 Oct 2009 09:19:11 -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 80C2EAF834; Fri, 30 Oct 2009 09:19:11 -0700 (PDT) Message-Id: <240D9CD9-0B51-43C0-9A8C-435DAA213ACB@archrock.com> From: Jonathan Hui To: In-Reply-To: <017401ca597a$5c54e470$14fead50$@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 09:19:09 -0700 References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <008201ca5964$7aa1b4a0$6fe51de0$@sturek@att.net> <014001ca5974$8cb63430$a6229c90$@sturek@att.net> <017401ca597a$5c54e470$14fead50$@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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:19:00 -0000 Hi Don, On Oct 30, 2009, at 9:02 AM, Don Sturek wrote: > Aggregators are great devices when defined by end customers to meet an > application need. The trouble comes in when we introduce them for > network > layer support in non-obvious places. Exactly! If we don't know what the service provider's requirements are, we can't design for them, much less avoid conflicting with them. > I think we should try to find solutions which avoid PEPs and other > aggregation devices in general. If we find we have to have these > devices, > we should work with those responsible for deployment to be sure this > maps to > their solution space. I would agree with this approach. -- Jonathan Hui From fluffy@cisco.com Sat Oct 31 10:29:06 2009 Return-Path: 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 DA2DD3A68C3 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.282 X-Spam-Level: X-Spam-Status: No, score=-110.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 PhkfKoaCu1Zz for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A01433A67EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:29:05 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAH8Q7EqQ/uCWe2dsb2JhbACbUwEBFiQGqCKXeYI0ggUE X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281346" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:29:22 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHT0b7024147; Sat, 31 Oct 2009 17:29:21 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <9C1F3468-CD7F-4264-B1A5-576BC4FA0F9D@archrock.com> Date: Sat, 31 Oct 2009 11:29:20 -0600 Content-Transfer-Encoding: 7bit Message-Id: <052CC770-329B-4375-8DA6-F6743464FDBF@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <9C1F3468-CD7F-4264-B1A5-576BC4FA0F9D@archrock.com> To: Jonathan Hui , Carsten Bormann X-Mailer: Apple Mail (2.1076) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:29:06 -0000 So trying to get specific advice about how to edit stuff here ... So Jonathan sounds like you would like the list of existing use case / requirements document added to the charter as input to the WG and and also an explicit list of applications the WG will consider. That seems well worth trying. Can you and other folks on the email list help 1) list the documents we can start with 2) list the applications or subsets of applications we should start with in the first phrase. Once we have a list we can decide if we need to prioritize are argue stuff in or out. Thanks Cullen On Oct 30, 2009, at 2:32 , Jonathan Hui wrote: > > Hi Carsten, > > On Oct 30, 2009, at 12:33 AM, Carsten Bormann wrote: > >> Back to the application requirements: I do agree we should focus on >> a small number of specific areas of application, at least for >> making sure we have thought through some specific examples for each >> in detail. I think it would be useful if we called them out >> explicitly in the charter. Right now I'm seeing a lot of interest >> in 6lowapp from Energy (SE V2 etc.) and building automation (which >> may or may not include home automation). The charter does identify >> light switches, temp sensors, power meters, HVAC systems, and door >> locks as specific items that we will look at; so maybe we should be >> a bit more specific and identify the communication relationships we >> are addressing (and add light fixtures, plug-in vehicles and >> washing machines in the process). > > It certainly would have helped me if the charter would have been > more precise about what applications or subsets of applications we > are trying to address. Without that knowledge, its hard to say > whether or not we have the proper requirements written anywhere. > BTW, I don't think the ZigBee/Homeplug MRD is sufficient in itself. > Is the TRD available? > > Given the application(s), it would be even better if somewhere we > indicated what functionality we plan to develop first. Are we only > addressing manipulation of attributes that are relatively small in > size? Are the most important profiles to get done first power, > light, light switch, and temp? > > In the end, if we are to take knowledge of the application > requirements for granted, the charter should be precise about what > we are addressing. It's good to see that we are in line here. > >> Gruesse, Carsten >> >> PS.: I wrote more on the rationale for trying not to get stuck in a >> requirements mire in >> http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html > > > I do prefer your suggested terminology of "objectives" vs. > "requirements". > > -- > Jonathan Hui > From fluffy@cisco.com Sat Oct 31 10:29:12 2009 Return-Path: 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 36FEF3A692B for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 9M7Um446nBmF for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EDDA53A67EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:29:10 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAH8Q7EqQ/uCWe2dsb2JhbACbUwEBFiQGqCKXeYQ5BA X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281349" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:29:29 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHT0b8024147; Sat, 31 Oct 2009 17:29:28 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <4AE9A4C8.4030402@tkk.fi> Date: Sat, 31 Oct 2009 11:29:27 -0600 Content-Transfer-Encoding: 7bit Message-Id: <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> To: Jukka Manner X-Mailer: Apple Mail (2.1076) Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:29:12 -0000 On Oct 29, 2009, at 8:20 , Jukka Manner wrote: > 1. This seems to indicate that 6lowapp will not be tied to any > existing work, it will work on its own goals, but in collaboration > with others (which is somewhat open as what it means). I would have > expected that 6lowapp would specifically look at existing work in > related WGs and see how build on top of that. My mistake - I did not mean to imply that it was not layered on top of closely related existing work. I think most people assumed that this would run on top of a LoPAN but it seemed they also wanted it to be able to run on top of a other things including a normal IP LAN and WAN. Clearly this is all about same use cases as 6LoPAN and ties closing with 6LoPAN and ROLL as well as work going on at many other SDOs. However, I'm not sure what needs to be said. Are WG drafts with use case / requirements from other WG that we should be referencing? Give me ideas on what things you were thinking here. Clearly the IESG would not be keen on chartering a new WG to do something another WG was already charted to do - repeating work in two places seldom ends well :-) Can you suggest some specific text for the charter that you think would have fairly wide consent and captures what you are looking for here? From fluffy@cisco.com Sat Oct 31 10:29:27 2009 Return-Path: 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 D2F1A3A68C3 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.312 X-Spam-Level: X-Spam-Status: No, score=-110.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 5rcWfrdq-O8c for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1926A3A67EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:29:25 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAH8Q7EqQ/uCWe2dsb2JhbACbUwEBFiQGqCKXeYQ5BA X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281353" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:29:43 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHT0b9024147; Sat, 31 Oct 2009 17:29:41 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: Date: Sat, 31 Oct 2009 11:29:41 -0600 Content-Transfer-Encoding: 7bit Message-Id: <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> To: arjun.lists@hsc.com X-Mailer: Apple Mail (2.1076) Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:29:27 -0000 On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > My comments: > > The charter seems to combine goals as well as architecture together > in one go. Probably can be simplified ? Specific comments below: > > > On Thu, Oct 29, 2009 at 2:42 AM, Cullen Jennings > wrote: > > > Applications are being developed for networks that have very limed > packets sizes, have high degree of packet loss, and where a > substantial number of devices that may be powered of at any point in > time but periodically "wake up" for beef periods of time. These > Networks are referred to as Constrained Networks (CNEets). Low-Power > Wireless Personal Area Networks (LoWPANs) are an example of this > type of network. These networks are becoming increasing important > for applications such as home automation, energy management, and the > Internet of Things. This working group will define a framework a > limited class of applications that deal with manipulation of simple > resources on devices on a CNet. This includes applications to > monitor simple sensors such as a temperature gauge, light switch, or > power meter and control an actuator such as a light switch, heating > system, or door lock. Typical uses include power management and > reporting, and home automation. > > ARC> We are implicitly stating that devices in a lowpan will have > simple management requirements (kind of like set/get mostly). I'd > like to see this group also consider (in terms of usecases) what are > the various control functions that are desirable, given an internet > connect ecosystem? I don't think we should assume that just because > most home control was mostly about simple on/off/read till date, > that is what we should architect for. It is a minimal requirement, > but not complete by itself. You bring up an important architecture consideration in design of a system like this. Roughly I think about the different levels of data/ transaction models we could have as going something like this In order of complexity... 1) simple set of fixed variables that could be controlled 2) a single flat list of dynamically changeable set of variables that can can take on simple types (I might place IPFIX as being somewhat close to this model) 3) a hierarchical list of variables that can be related (I'd place basic usage SNMP roughly in this category but more advanced usage of SNMP probably can do category 4) 4) a REST based approach (I'd place HTTP REST in this case) 5) a full RPC model (I'd place CORBA in this class) Every use case I have seen so far could be solved by 3, 4, or 5. I think most people have expressed an opinion that about 4 looks about the right level of flexibility for this. So the questions is, if there is pretty good agreement on that, then I think we should just roll with it as tentative decision and see what it starts looking like as a design evolves. As the design evolves, one may find this was a bogus choice and need to revisit it. If you think there is a strong argument for 3 or 5 or even 1 or 2, lets get that info out on the list. > > > > The general architecture consists of nodes on the CNet, called > Devices, that have one or more Resources that represent sensors and > actuators. Devices send message to change and query resources on > other devices. Devices can send notifications about changed resource > values to subscribed Devices. In other words, the architecture > requires push, pull and and a notify approach to manipulating > resources. As part of the framework for building these applications, > the WG will define a CNet Application Protocol (CoAP) for > manipulation or Resources on Devices. The framework will also > specify a way to define new interface profiles that can be defined > by vendors and other standards bodies to define the particular > Resources on a Device and what manipulation are possible. > > There are also nodes called PEPs (Performance Enhancing Proxy) that > gateway between the protocols typically used by the applications on > the Internet and the protocol used on the CNet. An application on > the general network can use HTTP REST to communicate with the PEP > which will use CoAP to manipulate the Resource on the Device. The WG > will define a mapping on the PEP from the CoAP to the a HTTP REST > API. Each interface profile will define the Resources on the device > that application can manipulate and what manipulations are > possible. This will determine the HTTP REST APIs on the PEPs and > the CoAP protocol encoding to manipulate the Resources on the Device > it will also specify an XML MINE type for each class of Device that > can be used to described the Resource state in the the body of HTTP > REST messages. The WG may also work on a mapping to SNMP on the PEP. > It is worth noting that the PEP does not have to be deployed at the > boundary of the CNet and the more general network but can be > deployed at various location in the network. > > ARC> I don't think HTTP to XX mapping should be assumed at this > stage. HTTP may be a popular protocol, but there could be others. So > a general goal of internet protocols to device control protocol > mapping is more suitable OK - The way I want to try and derive us towards a decision here is get a list of candidate protocols then for each one ask the yes/no is the their agreement that we should do a mapping to that protocol. The protocols I have heard so far are HTTP, SNMP, SMTP. So two questions 1) what other protocols mapping should we do? 2) Given some people want HTTP, can you live with the answer to HTTP being yes and understanding that just because we said yes to HTTP does not mean we are saying no to everything else? > > > The PEP boxes can provide various forms of "caching". For example, > if a temperature sensor is normally asleep but wakes up every five > minutes and sends the current temperature to the a PEP that > subscribed, when the PEP receives a request over HTTP for that > temperature resource, it can respond with the last seen value > instead of trying to query the Device which is currently asleep. The > PEPs may also provide support for discovering devices that may not > be currently responding as they are temporarily asleep. > > ARC> Is this needed as a part of the charter? I don't know. I had someone I showed the charter to say, "but no I need a cache somewhere, these Device use low power" and I put this in to show that the PEP could be used this way. > > > The initial work item of the WG are to define: > > > > > The CoAP protocol will support three commissioning methodologies. > > 1) Duckling mode. One device is put in a "mother duck" mode where it > listens for broadcasts of Devices trying to imprint. Other Devices > are put in a "duckling" mode where they broad cast to the "mother > duck" Device then "imprint" by forming a new shared secret between > the two Devices. Once this is complete the devices are taken out of > this mode and can be use in a secure fashion. > > > > ARC> This seems to be a requirement specification of what a CoAP > should be. I think it should be left for a dedicated req doc, not as > part of a charter. Fair enough. See my other thread on Architecture Sketch. I agree with you there are cons to doing something like this in the charter. > > > -- > Arjun Roychowdhury > From fluffy@cisco.com Sat Oct 31 10:29:36 2009 Return-Path: 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 DC83B3A6935 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.325 X-Spam-Level: X-Spam-Status: No, score=-110.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 XetPXEtfr0-S for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:29:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9D4393A67EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:29:35 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAH8Q7EqQ/uCWe2dsb2JhbACbUwEBFiQGqCKXeYI3ggIE X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281355" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:29:52 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHT0bA024147; Sat, 31 Oct 2009 17:29:51 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: Date: Sat, 31 Oct 2009 11:29:51 -0600 Content-Transfer-Encoding: 7bit Message-Id: <6661C9D7-9CD3-4D66-8D1F-7F842921C1DA@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> To: arjun.lists@hsc.com X-Mailer: Apple Mail (2.1076) Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:29:36 -0000 On Oct 29, 2009, at 13:25 , Arjun Roychowdhury wrote: > > On Thu, Oct 29, 2009 at 3:10 PM, Lisa Dusseault > wrote: > > focused WG charter because this isn't "the charter for low-power IP > applications protocols" it's merely *a* charter for a subset of those > things. We can't boil the ocean in one WG or even come to agreement > on forming a WG if the scope is too big. Besides considering that > other WGs can tackle this larger space, consider that this WG could > always go on to more complex use cases after solving simple ones. > > ARC> I think this comment pretty much summarizes the difference of > thought between what I thought 6lowapp vs doing vs what you are > describing. The group name itself, "6lowapp" seems to specify it is > a group to to specificy low-power IP app protocols, and not a > subset. draft-bormann-6lowpan-6lowapp-problem-01 also seems to > indicate this group is dealing with the larger set. > > So my comment would be if this is not so, then it needs to be > explicitly stated, otherwise the natural understanding is 6lowapp is > the application protocol group for 6lowpan devices - and what comes > out of here, would likely be adopted going forward in deployments, > > I can respond to your other comments in more detail, but then again, > if the scope is going to be limited, then so be it. > This is a good point about the name. When I started talking to people about the use cases and requirements for this WG, it became clear to me that we might want a name that was different than 6LoAPP. By the time I figured this out the name of the BOF had already been submitted in the the scheduling for IETF 76 so the BOF name was somewhat locked down but we really need to talk about the name of the WG. We would not want a name that caused people to daw the wrong conclusions. So to comment on scope for a second From fluffy@cisco.com Sat Oct 31 10:30:14 2009 Return-Path: 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 8C8263A692C for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.337 X-Spam-Level: X-Spam-Status: No, score=-110.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 YxTRhmomZI8F for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:30:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4D4803A6928 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:30:13 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAKoR7EqQ/uCWe2dsb2JhbACbUwEBFiQGqBaXeIQ5BA X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281374" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:30:17 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHT0bC024147; Sat, 31 Oct 2009 17:30:16 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: Date: Sat, 31 Oct 2009 11:30:16 -0600 Content-Transfer-Encoding: 7bit Message-Id: <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> To: Don Sturek X-Mailer: Apple Mail (2.1076) 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:30:14 -0000 On Oct 29, 2009, at 8:37 , Don Sturek wrote: > Hi Cullen, > > Overall, the proposed charter looks interesting. > > On the Commissioning methods, I think making the "Duckling" mode > mandatory as indicated in the text below should not be decided in > the charter. Fair enough. Let me start a separate thread on this. > Unless this commissioning method has undergone some form of > security review, it could well be something we (at least in Smart > Energy) cannot use. Agree, but even worse. The IETF is not going to publish any of this as an RFC until it has had reasonable security review so I certainly don't want anything that would be a significant innovation in security or is broken from a security point of view. > It would be a shame to waste code space for something like this. > > While we (again Smart Energy) are looking at a RESTfull HTTP > architecture, it would be good to point out that this is only one > option. It would be nice to see if other popular communication > solutions can work as well. Yep - several other people have told me this too. What other popular protocols should we consider? > > One more thng: The discussion below indicates two level of > communication: PEPs and CoAps. I would hope we could avoid > this. It would be nice to address and communicate with CoAp devices > as you would with any other device on the internet whether a PEP was > present or not. I would not want to have the group focused on this > type of gateway approach. Agree - I was trying to make it clear any computer on the internet could talk CoAp directly to Device but failed to express that. Could you suggest some text to make that clear? > > Overall though this was a good start for the charter. > > Don > From fluffy@cisco.com Sat Oct 31 10:33:12 2009 Return-Path: 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 DE4713A6935 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.358 X-Spam-Level: X-Spam-Status: No, score=-110.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 5OmO2KlodDb3 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:33:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CABE63A691D for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:33:11 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAKoR7EqQ/uCWe2dsb2JhbACbUwEBFiQGqBaXeIQ5BA X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281438" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:33:28 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHXSjK024626 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:33:28 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sat, 31 Oct 2009 11:33:24 -0600 Message-Id: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] Where does TCP not work 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:33:13 -0000 Multiple people have told me that TCP won't work on some of the types of networks we want to run on. Anyway I'd like to understand a bit more on why this is. I could go dig a 9600 baud modem out of my closet, set the MTU at 100, and emulate 10% packet loss on server side and go try some things. I'm relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all work just fine. So, what are the network conditions that we think are going to cause a problem for TCP? and, what might one do to make something that worked better than TCP in these cases. Thanks, Cullen From fluffy@cisco.com Sat Oct 31 10:33:34 2009 Return-Path: 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 5594D3A6934 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.367 X-Spam-Level: X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ceInmZPLNjPK for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:33:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3479F3A691D for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:33:33 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAKoR7EqQ/uCWe2dsb2JhbACbUwEBFiQGqBaXeIQ5BA X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281441" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:33:50 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHXSjL024626 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:33:49 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sat, 31 Oct 2009 11:33:49 -0600 Message-Id: <671E1ECE-D232-47B0-B8B0-DF354A7514EB@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] Security and Commissioning 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:33:34 -0000 Consider one of the use cases several people have discussed. You install a new light. You install a new light switch. Now, how do you bind them together in the type of deployments where you want security? One way or another we need to meet the requirements of BCP 61. For many BOFs, how they will BCP 61 is fairly obvious and no one worries about it. However, for this BOF, it is not obvious. To get to a WG, I think we need to have enough of a sketch of how we are going to do the security that we can convince the security folks that we are not insane and that we will be able to meet the requirements of BCP 61 in the protocols developed. This duckling imprint approach was a stawman approach to this but it may be totally useless and not what we want to in which case we should promptly eject it from the charter. The question is, what are we going to do? Ideas? Can someone sketch out at the back of a cocktail napkin level enough of an idea on the one or more ways we want to deal wit this? If we agree on that I can do my best to figure out how to get that into the charter in a way that convinces the security people that they don't have to show up and say No. From fluffy@cisco.com Sat Oct 31 10:33:39 2009 Return-Path: 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 842F23A691D for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.376 X-Spam-Level: X-Spam-Status: No, score=-110.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Wep08U3vnVMJ for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:33:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 36E773A694C for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:33:38 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAKoR7EqQ/uCWe2dsb2JhbACbUwEBFiQGqBaXeIQ5BA X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281442" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:33:56 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHXSjM024626 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:33:55 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sat, 31 Oct 2009 11:33:55 -0600 Message-Id: <82431E68-B3B1-4FF7-A1FE-51F8B17D1D54@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] Multicast, do we need it 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:33:39 -0000 So we have a use case now where a light switch gets flicked and several lights are perceived by humans as coming on at the same time. A few people have explained to me that the way we need to meet this is the switch multicasts the on command to the lights. This brings up two questions, reliability and security. On reliability, I'm assuming we would send an unreliable multicast "on" command followed by a reliable unicast "on" command to each light individually. Any light that missed the multicast command would be delayed until they got the unicast command. Is this assumption correct on one way to deal with the reliability issues for things that need it? Do people have something else in mind? I could care less what the approach is but I want to be able to explain, at a sketch level, what the plan is to meet this use case. Now on to the security. Multicast security, particularly with very short messages if obviously solvable but not trivial security issue. As far as I can tell, this use case would force us to have a object security model. I don't pretend to be a security person in the slightest so hopefully I won't get the next part too wrong but someone who has a clue can correct me. Say were doing AES in CBC mode with a 96 byte MAC - It seems that the object will need to have somewhere in the order of: IV 16 bytes Mac 12 bytes Key identifiers 4 bytes time or sequence replay protection 4 bytes Various version code points 4 bytes Padding 1 to 16 bytes The smallest message possible is already looking like 56 bytes. One can argue any of these numbers up or down but my point is, I don't know if our effective MTU is 40,50,60, 128, or 1200. Various people have asserted all the above numbers and I understand that the real answer is not going to be hard and fast and it all depends. But it seems like we might be in the range where it's feasible to use CMS, perhaps with AES in CBC mode with HMAC-SHA-96 and some sort of scheme wit unicast challenge response to set up a sliding sequence counter window for replay protection or perhaps AES with CTR mode might be able to make it smaller. I'm not proposing this group would do this type of security work, I imagine we would go find it in something existing but this is just a back of envelope calculation on the lower bound of object security approach. And this brings up a a whole other issue, how to do replay protection on multicast messages. Clearly replaying the "unlock door" command would not be good. I have a hard time imaging anyone being keen on synchronized time between the devices. I've also seen that whatever discovery protocol is done might also need to use some secure multicast. So I am working on the assumption that we need multicast and we need object security inside it. And that this complicated out lives particularly if we want the messages to be small. Do folks agree this assumption? If folks agree, any ideas on what existing security standards we can use. I'd probably start by looking at what could be done with CMS. IS that a good starting point? One or two people suggested to me that we could use EAP but I don't know if they meant for this or something else. So as always, back to my usual questions, what is it people want to do for any of this. If there looks like there might be agreement, I can try and figure out what would be needed in the charter. From fluffy@cisco.com Sat Oct 31 10:41:50 2009 Return-Path: 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 78D2F3A6928 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.384 X-Spam-Level: X-Spam-Status: No, score=-110.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 9V2LTKlKGhHo for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 10:41:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 244093A68C3 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 10:41:47 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgAAAQU7EqQ/uCWe2dsb2JhbACbUwEBFiQGqA2Xd4Q5BIFi X-IronPort-AV: E=Sophos;i="4.44,659,1249257600"; d="scan'208";a="53281550" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 17:42:05 +0000 Received: from ams3-vpn-dhcp4750.cisco.com (ams3-vpn-dhcp4750.cisco.com [10.61.82.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VHg41W025321 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:42:04 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sat, 31 Oct 2009 11:42:03 -0600 Message-Id: To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] Architecture Sketch in 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 17:41:50 -0000 Right now the draft charter has a sketch of some of the key parts of the architecture. I'd like to talk about the pro's and cons of putting this in a charter. Typically charters don't have this. Many BOFs fail when all the people in the room don't lave having a common idea of what the group will do. Typically the architecture is developed in a draft and often can take considerable time however there's nothing stopping this type of information form being in a charter. Now this effort is a bit different from your typically BOF. Let me list some differences: 1) This is not meant to run on normal networks. We've told the transport folks, yah, we are going to have to make different assumptions than normal application protocols make because there some special stuff going on here. That makes the Transport and INT people very nervous. 2) We told the security people, none of your off the shelf security approaches will work for us because we have special requirements. We are not even 100% sure it is feasibly to simultaneously satisfy all the requirements. That makes the Security people, uh, prickly. 3) Some people have suggest that SIP might be just the thing to build on over for things like controlling a garage door opener. Many (but not all) SIP folks feel that SIP is for User to User communications and often use SIP to control the garage door and the prototypical example of what should *not* be done with SIP. This makes the RAI people want to come and say "hi". I'm not saying we could not use SIP but I am saying the SIP people would want to come and talk about the issues before that decision got made. Hopefully they won't ask if any of this has any real time application properties or infrastructure they could help with. 4) The OAM folks must be thinking, so how is this different from what we do every single day? 5) The INT and Routing guys want to know how this related to work they are doing. 6) I've had a few questions that loosely translated to "so what feature of IPv6 are you using to guarantee that this will only work on a v6 network". If we told the DNS guys we were consider doing all our senor reading use DNS so we could leverage the DNS caching we would have pretty much every area "concerned". People have questions. Lots of questions. The challenge for a successful BOF like this is to put together a coherent story of what the big picture looks like and how it all hangs together. I believe we have a reasonable chance of having a WG approved if we can show that there is a group of people that have 1) a clear idea of what they want to build 2) the same common idea of what it is 3) it is an engineering project, and not science project requiring invention of new techniques 4) it meets the type of requirements the IETF has for standards track work The quickest way to do this would be to have in some document that we take into the BOF use cases, requirements, and a high level architecture. We have drafts with use case and requirements and we can refine theses int he slides used in the BOF. If we can agree on an architecture, we can stuff that in the charter. I'm probably a bit naive to think we can come up with a sketch of an architecture and agree to it in the BOF. But if we do, we have a chance at having the a protocol document finished before 2011. A more tried and true approach to this would be to work on the requirement, use case, and architecture in some ad-hoc meetings then go for a BOF. The P2PSIP WG had problems similar to this WG in that they were going to have some harder than average transport and security issues. They meant for multiple hours at every IETF for multiple years *before* the WG was approved. Lots of the meetings had around 100 people with pretty substantial effort. Another approach would be to charter just to do requirements then recharter to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle of scotch that would not finish before 2011 and even odds on a bottle of scotch it would not finish before 2012. Many people have expressed that time is of the essence on this work and something that delivers in 2012 will be of very little deployment value. I'm not in a good position to evaluate how quickly something is needed here but I'm happy to take everything people tell m at when this is needed at face value. The sponsoring AD has read me the riot act on scope for the initial set of work, make this a small bite size chunk that meets a reasonable set of needs and we can complete quickly. As that completes, I'm sure there would be no problem re-charting to expand the scope for more things or forming other WG to take on related work. So bottom line, I'm trying to drive this to figure out what is small bite size chunk that everyone could live with for the initial stuff to be worked on. If we are lucky, we can end up agreeing on requirements, uses cases, and a high level sketch of the architecture without a long drawn out process. If this fails, and I admit it very well could, well then we can just move back to some other way of dealing with this. A good charter is a plan for work as well as something that constrains the number of possibilities a WG has to consider. Now clearly we can't constrain things beyond what is needed. If we can mange to agree on a tight charter, the WG will be able to progress work very rapidly. If we fail to do this in the next few week, having tried will not set back the work in any significant way. I hope this explains, I'm not trying to convince anyone the architecture in the draft is the right one. I'm just trying to convince people to fix it before the BOF. Sorry for such a long email, Cullen From shidan@gmail.com Sat Oct 31 11:33:22 2009 Return-Path: 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 B71913A6782 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dTcoKsPf9eNt for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 11:33:22 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 941753A67F1 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 11:33:21 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so193675eya.51 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 11:33:36 -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=hXmeEQuH8KhzXnG40gG8dlsN4a/aeTmZt8yidTwCRjw=; b=Z/pfIFguAyvj1jEk3UxcPQMRg87epZIt3y4Uy4IkErFM3Yh2Dap/gN3yV9AViNG6sb nLV0VC1u8ovi0rejuP6VHkL2t+mJhxRp9TZC239y2jzeBEArWwJ3nGM6aJw+q3eZWg7z sT0+X7VAhVC+eKiWshZCuzcSHaMNfqIiP/1vI= 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=GIEalxq1L6kz67Mvoml2bOK6Q++ftqaMMVWyKxmoxgPcYvDEvPOSuKxKOciY27OUsH wgx7Xl6qQ7B0ql6JBdvxhAyisQqaANZb32QfZmA1SeVpII2OI3gKZW6AEJY0LxJhvEtn N8PBrGf3D227ZJYNDOP/HbYLKQs61h8SKb38I= MIME-Version: 1.0 Received: by 10.216.93.12 with SMTP id k12mr2046308wef.195.1257014016241; Sat, 31 Oct 2009 11:33:36 -0700 (PDT) In-Reply-To: <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> Date: Sat, 31 Oct 2009 14:33:36 -0400 Message-ID: <429b380e0910311133k784f8fe8w878f81560fc28800@mail.gmail.com> From: Shidan To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e6d99f38ea709d04773f613b Cc: Don Sturek , 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 18:33:22 -0000 --0016e6d99f38ea709d04773f613b Content-Type: text/plain; charset=ISO-8859-1 Hi Cullen, I would check the motivational draft Arjun and I submitted for SIP. > OK - The way I want to try and derive us towards a decision here is get a > list of candidate protocols then for each one ask the yes/no is the their > agreement that we should do a mapping to that protocol. The protocols I > have heard so far are HTTP, SNMP, SMTP. So two questions > 1) what other protocols mapping should we do? > In general there are many practical applications which are using SIP and XMPP for M2M communications. This should be a consideration. > > 2) Given some people want HTTP, can you live with the answer to HTTP being > yes and understanding that just because we said yes to HTTP does not mean we > are saying no to everything else? > > Personally, I think HTTP is the most important and minimum protocol to support. --0016e6d99f38ea709d04773f613b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Cullen, I would check the motivational d= raft Arjun and I submitted for SIP.=A0
=A0
OK - The way I want to try and derive us towards a decision here is get a l= ist of candidate protocols then for each one ask the yes/no is the their ag= reement that we should do a mapping to that protocol. =A0The protocols I ha= ve heard so far are HTTP, SNMP, =A0SMTP. So two questions
=A0
1) what other protocols mapping should we do?

In general there are many practical applications which are using SIP= and XMPP for M2M communications. This should be a consideration.
=A0

2) Given some people want HTTP, can you live with the answer to HTTP being = yes and understanding that just because we said yes to HTTP does not mean w= e are saying no to everything else?


Personally, I think HTTP is the most important and mini= mum protocol to support.
--0016e6d99f38ea709d04773f613b-- From shidan@gmail.com Sat Oct 31 15:41:21 2009 Return-Path: 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 C68CE3A67FD for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 15:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 AffIQElB9SoZ for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 15:41:19 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 96B4B3A63EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 15:41:18 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so210585eya.51 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 15:41:33 -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=uUn5jDFYyJr99fRNwk5og5AJY0KvIZ/+rLNlfxxRonU=; b=Yzsu8jnOa0+pYebPP183WSb820S2ZCbBkHojAZ28YPr809QFsDfitVbuKd5Xx/L2ok +5OUUcqON+olPd7073EzMe1rfGV4+i/eZyU6ldGHuVFuk6q+ialuXAccRriYtG4fyIAR oJNf1R2i7TZsMm4nk3sOXuBHuN9saTqzAtUBc= 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=f+P/W8MTQV2uMPlmYTVqtHsslkhIgV13eoPTZqrLM9mwFhHPbDR6yVB5bvm3/Lutga JcfsED6XTfVNxdWg4JqkyAR8uS6TKzZSnthp42XQrZg2d24Q0zg5PpXijTHjRg+/tzJA XVEjCK1rxX5yF/C1qUY8/LvpfbSx01ARBbFh0= MIME-Version: 1.0 Received: by 10.216.88.10 with SMTP id z10mr2404056wee.108.1257028892720; Sat, 31 Oct 2009 15:41:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Oct 2009 18:41:32 -0400 Message-ID: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> From: Shidan To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e6d785469f80d7047742d874 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 22:41:22 -0000 --0016e6d785469f80d7047742d874 Content-Type: text/plain; charset=ISO-8859-1 Hi Fluffy, I definitely agree with your overall sentiment, but one thing that I always find dissapointing is when people give me the "turn on and off" garage doors, thermostats, etc as the only examples of what a HAN should be about. I think this is part of the reason some, specially me, are a little confused by the WG. The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX, etc replacement; they do a fine job of turning things on and off. Let me list a few things I would like in my HAN: 1) I want a network that goes beyond enabling me to discover and control a device to one that enables devices to discover, control and communicate with each other and mixed groups of devices and people. 2) I want devices to do things based on time and other arbitrary policies as part of the network 3) I want mobile & secure smart objects to take advantage of pervasive global networks and objects that are location aware. 4) I want a system that can evolve so that when it makes economic sense, the physical components of a smart appliance are "smart components" themselves. I also see a day when people will be upgrading the features and functionality of their washing machine through a firmware upgrade.The last two are probably sound silly now, but they're real considerations of how things can evolve. The truth of the matter is that even with X10 and gateways, except for device mobility, most of this is possible. It's further true that the most difficult challenge of HANs is not the networking but end user programmability and moving intelligence to the network will help in developing these systems. Right now, the difficulty I'm having is that it almost seems, and this could be a wrong interpretation I hope, that this working group is saying "let's forget about addressing the greater problem of HANs through network intelligence and let's just focus on satisfying the bare minimum needs of the energy industry so they can move to IP" and "then we will let the system evolve." Another approach could be that this working group could start by considering the HAN application layers like UPnP and see how they need to evolve for pervasive access, where they have gone wrong for developers and so on and then see how much of this better system you define can be brought down to LoPANs. This is something I think can be done in the time frames this WG has proposed and anything that comes out of it would work great for the energy industry as well. Of course, even better would be a general application layer framework for LoPANS, but since this is technological limitation, I think looking at requirements is absolutely necessary. A side note, I definitely think SIP and XMPP are relevant in this field Cullen, there is a reason why so many M2M applications are using XMPP, specially in BRIC countries. There is also a reason why the leading demand response provider is using XMPP today, if you can take this all the way to the home and on AMI networks then why not? There is also a reason why the few MSOs and incumbents that I know of who are offering home media management and media delivery to connected devices are switching to SIP-DLNA gateways. Again, this is not even the real issue, who really cares what you name a protocol as long as it works and the proper requirements have been considered. My concern above is much more important. Shidan Gouran On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings wrote: > > Right now the draft charter has a sketch of some of the key parts of the > architecture. I'd like to talk about the pro's and cons of putting this in a > charter. Typically charters don't have this. Many BOFs fail when all the > people in the room don't lave having a common idea of what the group will > do. Typically the architecture is developed in a draft and often can take > considerable time however there's nothing stopping this type of information > form being in a charter. Now this effort is a bit different from your > typically BOF. Let me list some differences: > > 1) This is not meant to run on normal networks. We've told the transport > folks, yah, we are going to have to make different assumptions than normal > application protocols make because there some special stuff going on here. > That makes the Transport and INT people very nervous. > > 2) We told the security people, none of your off the shelf security > approaches will work for us because we have special requirements. We are not > even 100% sure it is feasibly to simultaneously satisfy all the > requirements. That makes the Security people, uh, prickly. > > 3) Some people have suggest that SIP might be just the thing to build on > over for things like controlling a garage door opener. Many (but not all) > SIP folks feel that SIP is for User to User communications and often use SIP > to control the garage door and the prototypical example of what should *not* > be done with SIP. This makes the RAI people want to come and say "hi". I'm > not saying we could not use SIP but I am saying the SIP people would want to > come and talk about the issues before that decision got made. Hopefully they > won't ask if any of this has any real time application properties or > infrastructure they could help with. > > 4) The OAM folks must be thinking, so how is this different from what we do > every single day? > > 5) The INT and Routing guys want to know how this related to work they are > doing. > > 6) I've had a few questions that loosely translated to "so what feature of > IPv6 are you using to guarantee that this will only work on a v6 network". > > If we told the DNS guys we were consider doing all our senor reading use > DNS so we could leverage the DNS caching we would have pretty much every > area "concerned". > > People have questions. Lots of questions. The challenge for a successful > BOF like this is to put together a coherent story of what the big picture > looks like and how it all hangs together. I believe we have a reasonable > chance of having a WG approved if we can show that there is a group of > people that have > > 1) a clear idea of what they want to build > > 2) the same common idea of what it is > > 3) it is an engineering project, and not science project requiring > invention of new techniques > > 4) it meets the type of requirements the IETF has for standards track work > > The quickest way to do this would be to have in some document that we take > into the BOF use cases, requirements, and a high level architecture. We have > drafts with use case and requirements and we can refine theses int he slides > used in the BOF. If we can agree on an architecture, we can stuff that in > the charter. > > I'm probably a bit naive to think we can come up with a sketch of an > architecture and agree to it in the BOF. But if we do, we have a chance at > having the a protocol document finished before 2011. > > A more tried and true approach to this would be to work on the requirement, > use case, and architecture in some ad-hoc meetings then go for a BOF. The > P2PSIP WG had problems similar to this WG in that they were going to have > some harder than average transport and security issues. They meant for > multiple hours at every IETF for multiple years *before* the WG was > approved. Lots of the meetings had around 100 people with pretty substantial > effort. > > Another approach would be to charter just to do requirements then recharter > to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle > of scotch that would not finish before 2011 and even odds on a bottle of > scotch it would not finish before 2012. > > Many people have expressed that time is of the essence on this work and > something that delivers in 2012 will be of very little deployment value. I'm > not in a good position to evaluate how quickly something is needed here but > I'm happy to take everything people tell m at when this is needed at face > value. > > The sponsoring AD has read me the riot act on scope for the initial set of > work, make this a small bite size chunk that meets a reasonable set of needs > and we can complete quickly. As that completes, I'm sure there would be no > problem re-charting to expand the scope for more things or forming other WG > to take on related work. > > So bottom line, I'm trying to drive this to figure out what is small bite > size chunk that everyone could live with for the initial stuff to be worked > on. If we are lucky, we can end up agreeing on requirements, uses cases, and > a high level sketch of the architecture without a long drawn out process. > If this fails, and I admit it very well could, well then we can just move > back to some other way of dealing with this. > > A good charter is a plan for work as well as something that constrains the > number of possibilities a WG has to consider. Now clearly we can't constrain > things beyond what is needed. If we can mange to agree on a tight charter, > the WG will be able to progress work very rapidly. If we fail to do this in > the next few week, having tried will not set back the work in any > significant way. > > I hope this explains, I'm not trying to convince anyone the architecture > in the draft is the right one. I'm just trying to convince people to fix it > before the BOF. > > Sorry for such a long email, > Cullen > > > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --0016e6d785469f80d7047742d874 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fluffy,=A0

I definitely agree with your ov= erall sentiment, but one thing that I always find dissapointing is when peo= ple give me the "turn on and off" garage doors, thermostats, etc = as the only examples of what a HAN should be about. I think this is part of= the reason some, specially me, are a little confused by the WG.

The truth is, I'm personally not looking for a X10,= legacy 802.15.4, KNX, etc replacement; they do a fine job of turning thing= s on and off. Let me list a few things I would like in my HAN:

1) I want a network that goes beyond enabling me to discover= and control a device to one that enables devices to discover, control and = communicate with each other and mixed groups of devices and people.=A0

2) I want devices to do things based on time and other = arbitrary policies as part of the network

3) I wan= t mobile & secure smart objects to take advantage of pervasive global n= etworks and objects that are location aware.

4) I want a system that can evolve so that when it make= s economic sense, the physical components of a smart appliance are "sm= art components" themselves. I also see a day when people will be upgra= ding the features and functionality of their washing machine through a
firmware upgrade.The last two are probably sound silly now, but they&#= 39;re real considerations of how things can evolve.

The truth of the matter is that even with X10 and gateways, except for de= vice mobility, most of this is possible. It's further true that the mos= t difficult challenge of HANs is not the networking but end user programmab= ility and moving intelligence to the network will help in developing these = systems.

Right now, the difficulty I'm having is that it alm= ost seems, and this could be a wrong interpretation I hope, that this worki= ng group is saying "let's forget about addressing the greater prob= lem of HANs through network intelligence and let's just focus on satisf= ying the bare minimum needs of the energy industry so they can move to IP&q= uot; and "then we will let the system evolve."=A0

Another approach could be that this working group could= start by considering the HAN application layers like UPnP and see how they= need to evolve for pervasive access, where they have gone wrong for develo= pers and so on and then see how much of this better system you define can b= e brought down to LoPANs. This is something I think can be done in the time= frames this WG has proposed and anything that comes out of it would work g= reat for the energy industry as well.

Of course, even better would be a general application l= ayer framework for LoPANS, but since this is technological limitation, I th= ink looking at requirements is absolutely necessary.=A0

A side note, I definitely think SIP and XMPP are relevant in this fiel= d Cullen, there is a reason why so many M2M applications are using XMPP, sp= ecially in BRIC countries. There is also a reason why the leading demand re= sponse provider is using XMPP today, if you can take this all the way to th= e home and on AMI networks then why not? There is also a reason why the few= MSOs and incumbents=A0that I know of who are offering home media managemen= t =A0and media delivery to connected devices are switching to SIP-DLNA gate= ways. Again, this is not even the real issue, who really cares what you nam= e a protocol as long as it works and the proper requirements have been cons= idered. My concern above is much more important.

Shidan Gouran

On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings &l= t;fluffy@cisco.com> wrote= :

Right now the draft charter has a sketch of some of the key parts of the ar= chitecture. I'd like to talk about the pro's and cons of putting th= is in a charter. Typically charters don't have this. Many BOFs fail whe= n all the people in the room don't lave having a common idea of what th= e group will do. Typically =A0the architecture is developed in a draft and = often can take considerable time however there's nothing stopping this = type of information form being in a charter. Now this effort is a bit diffe= rent from your typically BOF. Let me list some differences:

1) This is not meant to run on normal networks. We've told the transpor= t folks, yah, we are going to have to make different assumptions than norma= l application protocols make because there some special stuff going on here= . That makes the Transport and INT people very nervous.

2) We told the security people, none of your off the shelf security approac= hes will work for us because we have special requirements. We are not even = 100% sure it is feasibly to simultaneously satisfy all the requirements. Th= at makes the Security people, uh, prickly.

3) Some people have suggest that SIP might be just the thing to build on ov= er for things like controlling a garage door opener. =A0Many (but not all) = SIP folks feel that SIP is for User to User communications and often use SI= P to control the garage door and the prototypical example of what should *n= ot* be done with SIP. This makes the RAI people want to come and say "= hi". I'm not saying we could not use SIP but I am saying the SIP p= eople would want to come and talk about the issues before that decision got= made. Hopefully they won't ask if any of this has any real time applic= ation properties or infrastructure they could help with.

4) The OAM folks must be thinking, so how is this different from what we do= every single day?

5) The INT and Routing guys want to know how this related to work they are = doing.

6) I've had a few questions that loosely translated to "so what fe= ature of IPv6 are you using to guarantee that this will only work on a v6 n= etwork".

If we told the DNS guys we were consider doing all our senor reading use DN= S so we could leverage the DNS caching we would have pretty much every area= "concerned".

People have questions. Lots of questions. The challenge for a successful BO= F like this is to put together a coherent story of what the big picture loo= ks like and how it all hangs together. I believe we have a reasonable chanc= e of having a WG approved if we can show that there is a group of people th= at have

1) a clear idea of what they want to build

2) the same common idea of what it is

3) it is an engineering project, and not science project requiring inventio= n of new techniques

4) it meets the type of requirements the IETF has for standards track work<= br>
The quickest way to do this would be to have in some document that we take = into the BOF use cases, requirements, and a high level architecture. We hav= e drafts with use case and requirements and we can refine theses int he sli= des used in the BOF. If we can agree on an architecture, we can stuff that = in the charter.

I'm probably a bit naive to think we can come up with a sketch of an ar= chitecture and agree to it in the BOF. But if we do, we have a chance at ha= ving the a protocol document finished before 2011.

A more tried and true approach to this would be to work on the requirement,= use case, and architecture in some ad-hoc meetings then go for a BOF. The = P2PSIP WG had problems similar to this WG in that they were going to have s= ome harder than average transport and security issues. They meant for multi= ple hours at every IETF for multiple years *before* the WG was approved. Lo= ts of the meetings had around 100 people with pretty substantial effort.
Another approach would be to charter just to do requirements then recharter= to do the protocols. I'd bet anyone on odds of a bottle of beer to a b= ottle of scotch that would not finish before 2011 and even odds on a bottle= of scotch it would not finish before 2012.

Many people have expressed that time is of the essence on this work and som= ething that delivers in 2012 will be of very little deployment value. I'= ;m not in a good position to evaluate how quickly something is needed here = but I'm happy to take everything people tell m at when this is needed a= t face value.

The sponsoring AD has read me the riot act on scope for the initial set of = work, make this a small bite size chunk that meets a reasonable set of need= s and we can complete quickly. As that completes, I'm sure there would = be no problem re-charting to expand the scope for more things or forming ot= her WG to take on related work.

So bottom line, I'm trying to drive this to figure out what is small bi= te size chunk that everyone could live with for the initial stuff to be wor= ked on. If we are lucky, we can end up agreeing on requirements, uses cases= , and a high level sketch of the architecture without a long drawn out proc= ess. =A0If this fails, and I admit it very well could, well then we can jus= t move back to some other way of dealing with this.

A good charter is a plan for work as well as something that constrains the = number of possibilities a WG has to consider. Now clearly we can't cons= train things beyond what is needed. If we can mange to agree on a tight cha= rter, the WG will be able to progress work very rapidly. If we fail to do t= his in the next few week, having tried will not set back the work in any si= gnificant way.

I hope this explains, I'm not =A0trying to convince anyone the architec= ture in the draft is the right one. =A0I'm just trying to convince peop= le to fix it before the BOF.

Sorry for such a long email,
Cullen





_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

--0016e6d785469f80d7047742d874-- From d.sturek@att.net Sat Oct 31 16:22:54 2009 Return-Path: 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 1AA0F3A6843 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] 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 ua3OqSuD4Cvu for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:22:40 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id C21C83A67AA for <6lowapp@ietf.org>; Sat, 31 Oct 2009 16:22:39 -0700 (PDT) Received: from [68.142.194.244] by n14.bullet.mail.mud.yahoo.com with NNFMP; 31 Oct 2009 23:22:55 -0000 Received: from [68.142.201.241] by t2.bullet.mud.yahoo.com with NNFMP; 31 Oct 2009 23:22:55 -0000 Received: from [127.0.0.1] by omp402.mail.mud.yahoo.com with NNFMP; 31 Oct 2009 23:22:55 -0000 X-Yahoo-Newman-Id: 795929.38266.bm@omp402.mail.mud.yahoo.com Received: (qmail 82000 invoked from network); 31 Oct 2009 23:22:55 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 31 Oct 2009 16:22:54 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: NzdD4R4VM1ml2jiSoHM9nb.5P5Ym7Sq7K9YN94xjpzEsk97Sl2eurl0Nd3zRmf0EY8JwUT3FpF7fCA1wZVhDtEp1b3.MEWKuCD1wBAY6fd9cRxVxAwGu94xrskJv748mKCFAz9fcpDAc74KFvED5VdAj1_o6BRXNakX5YSrzkMm5sBdl20GFnKdLkwzCP6VlUJwaRlGTpPIEQQX0ofAZX9ZNpVIj1oUranQssK6S_eYaBzv3DgW1xkbuqRM09hZoTgLxaBsjooaA0KjwCMFIGB1aZneVhuVyLSxKTlwl9Xe85y3eA9Q- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Shidan'" , "'Cullen Jennings'" References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> In-Reply-To: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> Date: Sat, 31 Oct 2009 16:22:51 -0700 Message-ID: <005501ca5a81$11a641f0$34f2c5d0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01CA5A46.654769F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpae1P8DQTelOWdRkSxB2eEih3HuwABLrWw Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 23:22:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0056_01CA5A46.654769F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Shidan, All of this sounds fantastic, however: 1) The Smart Metering work is not going to wait while we sort out all of this and then figure out what standards we need. The reality is that early smart metering deployments need to start next year. We need to figure out how to supply a "Generation 1" solution that allows scalability. I have provided what we (the ZigBee and utility team) think is possible/practical for us to deploy in the short term. If what is proposed (RESTfull HTTP, Extensions to SLP for tokenization, W3C EXi, etc.) is not a good starting point, let's discuss. If what you wrote below builds on what is proposed for the near term then we are in alignment. If we have to wait an extended time to finalize a series of new standards to redefine HAN automation, then we will miss our window of relevance (at least in my opinion). Don From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Shidan Sent: Saturday, October 31, 2009 3:42 PM To: Cullen Jennings Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter Hi Fluffy, I definitely agree with your overall sentiment, but one thing that I always find dissapointing is when people give me the "turn on and off" garage doors, thermostats, etc as the only examples of what a HAN should be about. I think this is part of the reason some, specially me, are a little confused by the WG. The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX, etc replacement; they do a fine job of turning things on and off. Let me list a few things I would like in my HAN: 1) I want a network that goes beyond enabling me to discover and control a device to one that enables devices to discover, control and communicate with each other and mixed groups of devices and people. 2) I want devices to do things based on time and other arbitrary policies as part of the network 3) I want mobile & secure smart objects to take advantage of pervasive global networks and objects that are location aware. 4) I want a system that can evolve so that when it makes economic sense, the physical components of a smart appliance are "smart components" themselves. I also see a day when people will be upgrading the features and functionality of their washing machine through a firmware upgrade.The last two are probably sound silly now, but they're real considerations of how things can evolve. The truth of the matter is that even with X10 and gateways, except for device mobility, most of this is possible. It's further true that the most difficult challenge of HANs is not the networking but end user programmability and moving intelligence to the network will help in developing these systems. Right now, the difficulty I'm having is that it almost seems, and this could be a wrong interpretation I hope, that this working group is saying "let's forget about addressing the greater problem of HANs through network intelligence and let's just focus on satisfying the bare minimum needs of the energy industry so they can move to IP" and "then we will let the system evolve." Another approach could be that this working group could start by considering the HAN application layers like UPnP and see how they need to evolve for pervasive access, where they have gone wrong for developers and so on and then see how much of this better system you define can be brought down to LoPANs. This is something I think can be done in the time frames this WG has proposed and anything that comes out of it would work great for the energy industry as well. Of course, even better would be a general application layer framework for LoPANS, but since this is technological limitation, I think looking at requirements is absolutely necessary. A side note, I definitely think SIP and XMPP are relevant in this field Cullen, there is a reason why so many M2M applications are using XMPP, specially in BRIC countries. There is also a reason why the leading demand response provider is using XMPP today, if you can take this all the way to the home and on AMI networks then why not? There is also a reason why the few MSOs and incumbents that I know of who are offering home media management and media delivery to connected devices are switching to SIP-DLNA gateways. Again, this is not even the real issue, who really cares what you name a protocol as long as it works and the proper requirements have been considered. My concern above is much more important. Shidan Gouran On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings wrote: Right now the draft charter has a sketch of some of the key parts of the architecture. I'd like to talk about the pro's and cons of putting this in a charter. Typically charters don't have this. Many BOFs fail when all the people in the room don't lave having a common idea of what the group will do. Typically the architecture is developed in a draft and often can take considerable time however there's nothing stopping this type of information form being in a charter. Now this effort is a bit different from your typically BOF. Let me list some differences: 1) This is not meant to run on normal networks. We've told the transport folks, yah, we are going to have to make different assumptions than normal application protocols make because there some special stuff going on here. That makes the Transport and INT people very nervous. 2) We told the security people, none of your off the shelf security approaches will work for us because we have special requirements. We are not even 100% sure it is feasibly to simultaneously satisfy all the requirements. That makes the Security people, uh, prickly. 3) Some people have suggest that SIP might be just the thing to build on over for things like controlling a garage door opener. Many (but not all) SIP folks feel that SIP is for User to User communications and often use SIP to control the garage door and the prototypical example of what should *not* be done with SIP. This makes the RAI people want to come and say "hi". I'm not saying we could not use SIP but I am saying the SIP people would want to come and talk about the issues before that decision got made. Hopefully they won't ask if any of this has any real time application properties or infrastructure they could help with. 4) The OAM folks must be thinking, so how is this different from what we do every single day? 5) The INT and Routing guys want to know how this related to work they are doing. 6) I've had a few questions that loosely translated to "so what feature of IPv6 are you using to guarantee that this will only work on a v6 network". If we told the DNS guys we were consider doing all our senor reading use DNS so we could leverage the DNS caching we would have pretty much every area "concerned". People have questions. Lots of questions. The challenge for a successful BOF like this is to put together a coherent story of what the big picture looks like and how it all hangs together. I believe we have a reasonable chance of having a WG approved if we can show that there is a group of people that have 1) a clear idea of what they want to build 2) the same common idea of what it is 3) it is an engineering project, and not science project requiring invention of new techniques 4) it meets the type of requirements the IETF has for standards track work The quickest way to do this would be to have in some document that we take into the BOF use cases, requirements, and a high level architecture. We have drafts with use case and requirements and we can refine theses int he slides used in the BOF. If we can agree on an architecture, we can stuff that in the charter. I'm probably a bit naive to think we can come up with a sketch of an architecture and agree to it in the BOF. But if we do, we have a chance at having the a protocol document finished before 2011. A more tried and true approach to this would be to work on the requirement, use case, and architecture in some ad-hoc meetings then go for a BOF. The P2PSIP WG had problems similar to this WG in that they were going to have some harder than average transport and security issues. They meant for multiple hours at every IETF for multiple years *before* the WG was approved. Lots of the meetings had around 100 people with pretty substantial effort. Another approach would be to charter just to do requirements then recharter to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle of scotch that would not finish before 2011 and even odds on a bottle of scotch it would not finish before 2012. Many people have expressed that time is of the essence on this work and something that delivers in 2012 will be of very little deployment value. I'm not in a good position to evaluate how quickly something is needed here but I'm happy to take everything people tell m at when this is needed at face value. The sponsoring AD has read me the riot act on scope for the initial set of work, make this a small bite size chunk that meets a reasonable set of needs and we can complete quickly. As that completes, I'm sure there would be no problem re-charting to expand the scope for more things or forming other WG to take on related work. So bottom line, I'm trying to drive this to figure out what is small bite size chunk that everyone could live with for the initial stuff to be worked on. If we are lucky, we can end up agreeing on requirements, uses cases, and a high level sketch of the architecture without a long drawn out process. If this fails, and I admit it very well could, well then we can just move back to some other way of dealing with this. A good charter is a plan for work as well as something that constrains the number of possibilities a WG has to consider. Now clearly we can't constrain things beyond what is needed. If we can mange to agree on a tight charter, the WG will be able to progress work very rapidly. If we fail to do this in the next few week, having tried will not set back the work in any significant way. I hope this explains, I'm not trying to convince anyone the architecture in the draft is the right one. I'm just trying to convince people to fix it before the BOF. Sorry for such a long email, Cullen _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp ------=_NextPart_000_0056_01CA5A46.654769F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shidan,

 

All of this sounds fantastic, = however:

1)       The Smart Metering work is not going to wait while = we sort out all of this and then figure out what standards we = need.

 

The reality is that early smart metering deployments need = to start next year.  We need to figure out how to supply a “Generation = 1” solution that allows scalability.

 

I have provided what we (the ZigBee and utility team) = think is possible/practical for us to deploy in the short term.  If what is = proposed (RESTfull HTTP, Extensions to SLP for tokenization, W3C EXi, etc.) is not a good = starting point, let’s discuss. If what you wrote below  builds on what = is proposed for the near term then we are in alignment.   If we have to wait = an extended time to finalize a series of new standards to redefine HAN automation, then = we will miss our window of relevance (at least in my = opinion).


Don

 

 

From:= 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf = Of Shidan
Sent: Saturday, October 31, 2009 3:42 PM
To: Cullen Jennings
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Architecture Sketch in = Charter

 

Hi Fluffy, 

 

I definitely agree with your overall sentiment, but = one thing that I always find dissapointing is when people give me the = "turn on and off" garage doors, thermostats, etc as the only examples of = what a HAN should be about. I think this is part of the reason some, specially me, = are a little confused by the WG.

 

The truth is, I'm personally not looking for a X10, = legacy 802.15.4, KNX, etc replacement; they do a fine job of turning things on = and off. Let me list a few things I would like in my HAN:

 

1) I want a network that goes beyond enabling me to = discover and control a device to one that enables devices to discover, control = and communicate with each other and mixed groups of devices and = people. 

 

2) I want devices to do things based on time and = other arbitrary policies as part of the network

 

3) I want mobile & secure smart objects to take advantage of pervasive global networks and objects that are location = aware.

 

4) I want a system that can evolve so that when it = makes economic sense, the physical components of a smart appliance are = "smart components" themselves. I also see a day when people will be = upgrading the features and functionality of their washing machine through = a

firmware upgrade.The last two are probably sound = silly now, but they're real considerations of how things can evolve.

 

The truth of the matter is that even with X10 and = gateways, except for device mobility, most of this is possible. It's further true = that the most difficult challenge of HANs is not the networking but end user programmability and moving intelligence to the network will help in = developing these systems.

 

Right now, the difficulty I'm having is that it = almost seems, and this could be a wrong interpretation I hope, that this = working group is saying "let's forget about addressing the greater problem of = HANs through network intelligence and let's just focus on satisfying the bare minimum needs of the energy industry so they can move to IP" and "then we will let the system evolve." 

 

Another approach could be that this working group = could start by considering the HAN application layers like UPnP and see how = they need to evolve for pervasive access, where they have gone wrong for = developers and so on and then see how much of this better system you define can be = brought down to LoPANs. This is something I think can be done in the time frames = this WG has proposed and anything that comes out of it would work great for = the energy industry as well.

 

Of course, even better would be a general = application layer framework for LoPANS, but since this is technological limitation, I = think looking at requirements is absolutely necessary. 

 

A side note, I definitely think SIP and XMPP are = relevant in this field Cullen, there is a reason why so many M2M applications are = using XMPP, specially in BRIC countries. There is also a reason why the = leading demand response provider is using XMPP today, if you can take this all = the way to the home and on AMI networks then why not? There is also a reason why = the few MSOs and incumbents that I know of who are offering home media management  and media delivery to connected devices are switching = to SIP-DLNA gateways. Again, this is not even the real issue, who really = cares what you name a protocol as long as it works and the proper requirements = have been considered. My concern above is much more important.

 

Shidan Gouran

 

On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings = <fluffy@cisco.com> = wrote:


Right now the draft charter has a sketch of some of the key parts of the architecture. I'd like to talk about the pro's and cons of putting this = in a charter. Typically charters don't have this. Many BOFs fail when all the = people in the room don't lave having a common idea of what the group will do. Typically  the architecture is developed in a draft and often can = take considerable time however there's nothing stopping this type of = information form being in a charter. Now this effort is a bit different from your = typically BOF. Let me list some differences:

1) This is not meant to run on normal networks. We've told the transport = folks, yah, we are going to have to make different assumptions than normal = application protocols make because there some special stuff going on here. That = makes the Transport and INT people very nervous.

2) We told the security people, none of your off the shelf security = approaches will work for us because we have special requirements. We are not even = 100% sure it is feasibly to simultaneously satisfy all the requirements. That = makes the Security people, uh, prickly.

3) Some people have suggest that SIP might be just the thing to build on = over for things like controlling a garage door opener.  Many (but not = all) SIP folks feel that SIP is for User to User communications and often use SIP = to control the garage door and the prototypical example of what should = *not* be done with SIP. This makes the RAI people want to come and say = "hi". I'm not saying we could not use SIP but I am saying the SIP people would = want to come and talk about the issues before that decision got made. = Hopefully they won't ask if any of this has any real time application properties or = infrastructure they could help with.

4) The OAM folks must be thinking, so how is this different from what we = do every single day?

5) The INT and Routing guys want to know how this related to work they = are doing.

6) I've had a few questions that loosely translated to "so what = feature of IPv6 are you using to guarantee that this will only work on a v6 = network".

If we told the DNS guys we were consider doing all our senor reading use = DNS so we could leverage the DNS caching we would have pretty much every area = "concerned".

People have questions. Lots of questions. The challenge for a successful = BOF like this is to put together a coherent story of what the big picture = looks like and how it all hangs together. I believe we have a reasonable = chance of having a WG approved if we can show that there is a group of people that = have

1) a clear idea of what they want to build

2) the same common idea of what it is

3) it is an engineering project, and not science project requiring = invention of new techniques

4) it meets the type of requirements the IETF has for standards track = work

The quickest way to do this would be to have in some document that we = take into the BOF use cases, requirements, and a high level architecture. We have = drafts with use case and requirements and we can refine theses int he slides = used in the BOF. If we can agree on an architecture, we can stuff that in the = charter.

I'm probably a bit naive to think we can come up with a sketch of an architecture and agree to it in the BOF. But if we do, we have a chance = at having the a protocol document finished before 2011.

A more tried and true approach to this would be to work on the = requirement, use case, and architecture in some ad-hoc meetings then go for a BOF. The = P2PSIP WG had problems similar to this WG in that they were going to have some = harder than average transport and security issues. They meant for multiple = hours at every IETF for multiple years *before* the WG was approved. Lots of the meetings had around 100 people with pretty substantial effort.

Another approach would be to charter just to do requirements then = recharter to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle = of scotch that would not finish before 2011 and even odds on a bottle of = scotch it would not finish before 2012.

Many people have expressed that time is of the essence on this work and something that delivers in 2012 will be of very little deployment value. = I'm not in a good position to evaluate how quickly something is needed here = but I'm happy to take everything people tell m at when this is needed at face = value.

The sponsoring AD has read me the riot act on scope for the initial set = of work, make this a small bite size chunk that meets a reasonable set of = needs and we can complete quickly. As that completes, I'm sure there would be = no problem re-charting to expand the scope for more things or forming other = WG to take on related work.

So bottom line, I'm trying to drive this to figure out what is small = bite size chunk that everyone could live with for the initial stuff to be worked = on. If we are lucky, we can end up agreeing on requirements, uses cases, and a = high level sketch of the architecture without a long drawn out process. =  If this fails, and I admit it very well could, well then we can just move = back to some other way of dealing with this.

A good charter is a plan for work as well as something that constrains = the number of possibilities a WG has to consider. Now clearly we can't = constrain things beyond what is needed. If we can mange to agree on a tight = charter, the WG will be able to progress work very rapidly. If we fail to do this in = the next few week, having tried will not set back the work in any = significant way.

I hope this explains, I'm not  trying to convince anyone the = architecture in the draft is the right one.  I'm just trying to convince people = to fix it before the BOF.

Sorry for such a long email,
Cullen





_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<= /o:p>

 

------=_NextPart_000_0056_01CA5A46.654769F0-- From d.sturek@att.net Sat Oct 31 16:34:16 2009 Return-Path: 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 DE0DE3A62C1 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.174 X-Spam-Level: X-Spam-Status: No, score=0.174 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 8lun4BOVmEaB for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:34:15 -0700 (PDT) Received: from smtp108.sbc.mail.gq1.yahoo.com (smtp108.sbc.mail.gq1.yahoo.com [67.195.14.111]) by core3.amsl.com (Postfix) with SMTP id DC8803A67AA for <6lowapp@ietf.org>; Sat, 31 Oct 2009 16:34:15 -0700 (PDT) Received: (qmail 33526 invoked from network); 31 Oct 2009 23:34:31 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 31 Oct 2009 16:34:30 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: PzzCP_0VM1mDWtdTud31z.mMp3zOmxMHtJVWuRwrew7XTaLSH6KVA_fHgMR8bIdKKFxofpgV9vAHxrsXucNFLd4ulrK6l7jcTH7ucdzxUH_PHqLUgZykt148FtAY7AGZibvEuGs_VBhthyXPiPl2p3aJAp_HdVsjURCJuuKvtjFWxd.3561Y3V1GAStEzYVD._Imet9eE7.vusN3soNOPw3rjOHWy1A6Ol.iyH_1VwAK9WZjsWDDiF74D9fyWgl5l5i3PjcsUS7b1ldJ2CLvMTPQrYXPFW9HPA1CZqSItDSf3XT3GqM- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , <6lowapp@ietf.org> References: <82431E68-B3B1-4FF7-A1FE-51F8B17D1D54@cisco.com> In-Reply-To: <82431E68-B3B1-4FF7-A1FE-51F8B17D1D54@cisco.com> Date: Sat, 31 Oct 2009 16:34:27 -0700 Message-ID: <005a01ca5a82$b0900fc0$11b02f40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpaUFaVcOg9A75PSamTFH2Q9BNeqQAMVXTQ Content-Language: en-us Subject: Re: [6lowapp] Multicast, do we need it X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 23:34:17 -0000 Hi Cullen, For the Smart Metering solution, we made the following assumptions: 1) The Utilities would like to trust the minimum number of devices 2) Biggest "bang for the buck" (meaning the devices which consume the most electricity) are Heating and Air Conditioning (by a wide margin). 3) Utility would like to get additional savings but that can be through "Energy Management Systems". Those devices on one side are utility trusted and on the other side interface to untrusted devices in the home (like the lighting devices you mentioned). 4) Utilities would like to see security certificates in trusted devices. The security bar for untrusted devices is much lower (many times, a simple shared security key with AES-128 encryption is plenty good on the untrusted devices according to companies I have talked with producing home automation products). 5) The utilities have ways to verify when the Energy Management System is told to save 20% of usage, agrees it can, and tells the untrusted devices to optimize usage to save 20%. The meter in the premise will tell whether the 20% was actually saved or not. The uptake on this: The requirements for trusted utility devices (which I think are far fewer in number) are quite different from untrusted devices. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Saturday, October 31, 2009 10:34 AM To: 6lowapp@ietf.org Subject: [6lowapp] Multicast, do we need it So we have a use case now where a light switch gets flicked and several lights are perceived by humans as coming on at the same time. A few people have explained to me that the way we need to meet this is the switch multicasts the on command to the lights. This brings up two questions, reliability and security. On reliability, I'm assuming we would send an unreliable multicast "on" command followed by a reliable unicast "on" command to each light individually. Any light that missed the multicast command would be delayed until they got the unicast command. Is this assumption correct on one way to deal with the reliability issues for things that need it? Do people have something else in mind? I could care less what the approach is but I want to be able to explain, at a sketch level, what the plan is to meet this use case. Now on to the security. Multicast security, particularly with very short messages if obviously solvable but not trivial security issue. As far as I can tell, this use case would force us to have a object security model. I don't pretend to be a security person in the slightest so hopefully I won't get the next part too wrong but someone who has a clue can correct me. Say were doing AES in CBC mode with a 96 byte MAC - It seems that the object will need to have somewhere in the order of: IV 16 bytes Mac 12 bytes Key identifiers 4 bytes time or sequence replay protection 4 bytes Various version code points 4 bytes Padding 1 to 16 bytes The smallest message possible is already looking like 56 bytes. One can argue any of these numbers up or down but my point is, I don't know if our effective MTU is 40,50,60, 128, or 1200. Various people have asserted all the above numbers and I understand that the real answer is not going to be hard and fast and it all depends. But it seems like we might be in the range where it's feasible to use CMS, perhaps with AES in CBC mode with HMAC-SHA-96 and some sort of scheme wit unicast challenge response to set up a sliding sequence counter window for replay protection or perhaps AES with CTR mode might be able to make it smaller. I'm not proposing this group would do this type of security work, I imagine we would go find it in something existing but this is just a back of envelope calculation on the lower bound of object security approach. And this brings up a a whole other issue, how to do replay protection on multicast messages. Clearly replaying the "unlock door" command would not be good. I have a hard time imaging anyone being keen on synchronized time between the devices. I've also seen that whatever discovery protocol is done might also need to use some secure multicast. So I am working on the assumption that we need multicast and we need object security inside it. And that this complicated out lives particularly if we want the messages to be small. Do folks agree this assumption? If folks agree, any ideas on what existing security standards we can use. I'd probably start by looking at what could be done with CMS. IS that a good starting point? One or two people suggested to me that we could use EAP but I don't know if they meant for this or something else. So as always, back to my usual questions, what is it people want to do for any of this. If there looks like there might be agreement, I can try and figure out what would be needed in the charter. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Sat Oct 31 16:35:46 2009 Return-Path: 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 545A13A6843 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.963 X-Spam-Level: X-Spam-Status: No, score=0.963 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 2dB-Xl+ZBOwj for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:35:45 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 8D9A53A62C1 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 16:35:45 -0700 (PDT) Received: (qmail 29915 invoked from network); 31 Oct 2009 23:36:04 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 31 Oct 2009 16:36:03 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: dN1BHBUVM1nVtnqVnX5nzc.CozPw1IsinQCUqi9zWwAb797tgJhcpXttkTTto5FzNJPWTsgeIIjaD3lvjv0kh3HCvdQMXDgUTMrzcrpNJwGiZbhNpx_yhUaHU8N4bFIQOa.5qL8MfVUeIGQMYVF6NNXYUcq659ifA_1xXiWaxiIERaVGeQypoUrExaqrEQu5.IlCXFjRw4lgH3wu8LqdpD9HtxJrlgvvGiMAUCZu6CEeKZC9YRHHjgpo6YOOaUJc7P8dqEya9v57xg4D1xOdpQMqYoId8gzL9wXqBJwyBQk7gz1kRrs- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , <6lowapp@ietf.org> References: <671E1ECE-D232-47B0-B8B0-DF354A7514EB@cisco.com> In-Reply-To: <671E1ECE-D232-47B0-B8B0-DF354A7514EB@cisco.com> Date: Sat, 31 Oct 2009 16:35:59 -0700 Message-ID: <005b01ca5a82$e8039e40$b80adac0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpaUFQz9HEYdQwWQIGysMJkw5NgeAAMmyIg Content-Language: en-us Subject: Re: [6lowapp] Security and Commissioning X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 23:35:46 -0000 Hi Cullen, I think I could easily outline the options for this type of commissioning. About half that I know of are patented. Is this really something 6LowAPP would address though? Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Saturday, October 31, 2009 10:34 AM To: 6lowapp@ietf.org Subject: [6lowapp] Security and Commissioning Consider one of the use cases several people have discussed. You install a new light. You install a new light switch. Now, how do you bind them together in the type of deployments where you want security? One way or another we need to meet the requirements of BCP 61. For many BOFs, how they will BCP 61 is fairly obvious and no one worries about it. However, for this BOF, it is not obvious. To get to a WG, I think we need to have enough of a sketch of how we are going to do the security that we can convince the security folks that we are not insane and that we will be able to meet the requirements of BCP 61 in the protocols developed. This duckling imprint approach was a stawman approach to this but it may be totally useless and not what we want to in which case we should promptly eject it from the charter. The question is, what are we going to do? Ideas? Can someone sketch out at the back of a cocktail napkin level enough of an idea on the one or more ways we want to deal wit this? If we agree on that I can do my best to figure out how to get that into the charter in a way that convinces the security people that they don't have to show up and say No. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Sat Oct 31 17:02:17 2009 Return-Path: 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 9305B3A6862 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 BZ73fTSUeC6X for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:02:16 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 67C0F3A6809 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:02:16 -0700 (PDT) Received: (qmail 69707 invoked from network); 1 Nov 2009 00:02:31 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 31 Oct 2009 17:02:31 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Nj5u9rUVM1mQuT6t4WEYlJsLrk_SwcCG8g1shbaG5ZxRZX1mrzEs2oirhuMwberbdc.j1gpK4AFGKRVZe53io9LspHw_Ug45oMVKG5Zy8NmhUYgzQCVbbiCvNRG08cAm41m3kQmisjc9II1MYTvcT1iVRIZ0GNAxQ2jOsKV8yk2JmE2hORoxnrVtSGRvO57WdJkVFSiAIzltIDIYzSGMA3ZPHnFzYwtdHwwEYBrwUZRfHfveW8prJwwZDyYe.pPpGVp50JIW0YqaftnmEWQQnNdc9PCMbDUhFBC8UOnt9Qy3d7xucbN9gxVTD3vgQi5ThdvbrY8VQEaSURwjQ31nY4EswdBiDyA61HCFt11Miv5OzYm7h.KamF1UuiBHFffwDTkQ71omGdSxlnoSkB3tiK5_8hao8FIrC0vd1MmjutLQp1ydEdTeW0MmZtw.L.pBzU.VpuY4 X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , <6lowapp@ietf.org> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> In-Reply-To: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> Date: Sat, 31 Oct 2009 17:02:28 -0700 Message-ID: <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpaUESz2K/hens9QeGn81/d5X4V+QAMuZvQ Content-Language: en-us Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 00:02:17 -0000 Hi Cullen, Sorry, I meant to provide some references on this issue. Basically, here is the problem: 1) TCP was written back in the day when Ethernet was the primary transport. One key assumption made in TCP was that packet timeout was related to congestion. TCP reacts to packet timeouts by adjusting the transmit timing and using back off. 2) Wireless networks (especially mesh topologies) experience packet loss as a result of failure of the RF link. Note that IEEE 802.11 does not typically exhibit this type of loss. The reason is that for IEEE 802.11 (actually WiFi) the last hop wireless link from the AP can be guaranteed via MAC level acknowledges and retries. The trouble with mesh links is that link errors are not propagated and, even if they are, result in route re-establishment which violates the TCP timeout on the far end and starts the "congestion management" procedure in TCP (which actually makes the problem worse as some of the links below indicate). I am not saying categorically that TCP does not work for wireless links. I am saying that for many wireless links, TCP does not work well (and in some extreme cases, at all). Here are some examples from the IETF archives and other industry trials...... http://www.rfc-editor.org/rfc/rfc4653.txt http://www.sics.se/~adam/ewsn2004.pdf http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=686057 I used to have a more exhaustive reference list but I think if you do a search you will see this is a long standing problem.... Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Saturday, October 31, 2009 10:33 AM To: 6lowapp@ietf.org Subject: [6lowapp] Where does TCP not work Multiple people have told me that TCP won't work on some of the types of networks we want to run on. Anyway I'd like to understand a bit more on why this is. I could go dig a 9600 baud modem out of my closet, set the MTU at 100, and emulate 10% packet loss on server side and go try some things. I'm relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all work just fine. So, what are the network conditions that we think are going to cause a problem for TCP? and, what might one do to make something that worked better than TCP in these cases. Thanks, Cullen _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Sat Oct 31 17:09:43 2009 Return-Path: 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 AE4083A6810 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 EJJKJz4sKA+f for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:09:42 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id CDFB63A67FB for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:09:42 -0700 (PDT) Received: (qmail 70635 invoked from network); 1 Nov 2009 00:09:58 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 31 Oct 2009 17:09:58 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Aty_pC8VM1m8ZPLAeh_JErW15Gbe_e1xynAjNueXZAmWqLhpXIt5SoN95GMTnhZZKNvds3Ox4fo0k6iHUOyizKwUBnukqf1usTG.jjal6AuN6S.pxtKIrr4DxZqt_lEuYUKf6kzNnkD2gxCCSJxJgQphMy41j3pPMvumIvcq30kfFCkuIWTDPIwQ9MrC5nH3xHzabcNZxnt4KEhY2F_vwuMvfeuulMP4OsEe2Y6MjuIWR4WQnLN5wihvFmvays2hILlyZSz4UcG7kY5NSafyrUeN.phLArIrqm9PS1NjVogfu7wJ6yjM2PTIcXdPuTIjFnO1hOentTiAwOU_A5mB4.Dtre_Tb.EbzTJReCHeYfrUzBGuFQi6Nwkx8l7RlcGQLs4X3ou515r90I93A59BeJUffpDzC_agHbgr2SQWk0KMLmJKuNO7vfOJqMRW4ckyR1HVOc9l X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> In-Reply-To: <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> Date: Sat, 31 Oct 2009 17:09:55 -0700 Message-ID: <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpaT9g4D9XirQlMTxO8uemOGbnxHAANvC6Q Content-Language: en-us 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 Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 00:09:43 -0000 Hi Cullen, I don't have a lot to add to what you wrote below except on the question of what other application protocols to suggest: 1) We (the Smart Energy team) would like to use something that is mainstream and extensible. We could resort to a proprietary binary protocol to address our near term needs but it would be a shame to do this 2) We would like to start with assumption we can use a simplified version of RESTfull HTTP with the following backup plans: a. Providing some alternative to TCP if we find we cannot use that due to code size or performance on wireless mesh links (see my earlier note) b. Providing some backup to HTTP text if we find the number of packets generated causes congestion/throughput issues. We welcome other suggestions like XMPP and SIP but we did look at those and ruled them out for reasons like: 1) Verboseness (using text string exchanges for devices with very small transmit/receive packet sizes) 2) Session management overhead Don -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Saturday, October 31, 2009 10:30 AM To: Don Sturek Cc: 6lowapp@ietf.org; Zach Shelby; Carsten Bormann; Lisa Dusseault Subject: Re: Proposed charter for 6LoWAPP BOF On Oct 29, 2009, at 8:37 , Don Sturek wrote: > Hi Cullen, > > Overall, the proposed charter looks interesting. > > On the Commissioning methods, I think making the "Duckling" mode > mandatory as indicated in the text below should not be decided in > the charter. Fair enough. Let me start a separate thread on this. > Unless this commissioning method has undergone some form of > security review, it could well be something we (at least in Smart > Energy) cannot use. Agree, but even worse. The IETF is not going to publish any of this as an RFC until it has had reasonable security review so I certainly don't want anything that would be a significant innovation in security or is broken from a security point of view. > It would be a shame to waste code space for something like this. > > While we (again Smart Energy) are looking at a RESTfull HTTP > architecture, it would be good to point out that this is only one > option. It would be nice to see if other popular communication > solutions can work as well. Yep - several other people have told me this too. What other popular protocols should we consider? > > One more thng: The discussion below indicates two level of > communication: PEPs and CoAps. I would hope we could avoid > this. It would be nice to address and communicate with CoAp devices > as you would with any other device on the internet whether a PEP was > present or not. I would not want to have the group focused on this > type of gateway approach. Agree - I was trying to make it clear any computer on the internet could talk CoAp directly to Device but failed to express that. Could you suggest some text to make that clear? > > Overall though this was a good start for the charter. > > Don > From d.sturek@att.net Sat Oct 31 17:15:08 2009 Return-Path: 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 BAF7A3A6844 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 iosE9ni+rn6F for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:15:07 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id AE7A43A63EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:15:07 -0700 (PDT) Received: (qmail 10314 invoked from network); 1 Nov 2009 00:15:22 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 31 Oct 2009 17:15:19 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: LYALXeUVM1nwPzvboappKlYd1pwxYh8PvvmiAhBQe6REXmKO_pKU_I2bDO2gk_Ynzt0PiBGDAJzTCIBu7u7H5t0z6KmYI0edAHt_DrLby3OYLGIuaoreYN0K7Z0NeHPqB_31NeKqNA9h3YLUOPfjF9qf3989U2PkEnK_PC8.qBsgHqBsjiMqYu6gKeAybLYXJWwYlAFiBe4RFmpz4y5FD68rk56As1PpqWqH5HQOZjrUECc7prYLwafn.GZQi0igmHIPWAawojgT2q.I7Gm74NuwPSPttFqOCrsHKJ.qGCAPLpSrQIuK3y.Vhp6YB.8tYlKLcgH3pc8yAJ0Q_cFzL0uuKQJCcGbUcpNE_0Gk2T1b6lyX_AmJoVDeURQzsDXMrzZYDnruel8wImUOELC4X.Mnn4oh4jVg9PwXd89N8CQliDq1GKQ.y95ZBM0ai2UcbIAlTbsZ3DSyNMnD6oea4_khUGk- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , "'Jukka Manner'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> In-Reply-To: <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> Date: Sat, 31 Oct 2009 17:15:16 -0700 Message-ID: <006c01ca5a88$6600eff0$3202cfd0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpaT7UOcBUktmsjQEObv95LaSXjBwAOFLEQ Content-Language: en-us Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 00:15:08 -0000 Hi Cullen, One important use case to consider: 1) Devices to manage are running on 6LowPAN (using some 6LowAPP defined protocol). Controlling devices are running someplace on the wider internet. 2) Does this mean that the scope of protocol work in 6LowAPP needs to identify this type of control as a valid use case? 3) Does the use of 6LowAPP protocols on the wider internet need to then be in the scope of 6LowAPP? Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Saturday, October 31, 2009 10:29 AM To: Jukka Manner Cc: Don Sturek; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF On Oct 29, 2009, at 8:20 , Jukka Manner wrote: > 1. This seems to indicate that 6lowapp will not be tied to any > existing work, it will work on its own goals, but in collaboration > with others (which is somewhat open as what it means). I would have > expected that 6lowapp would specifically look at existing work in > related WGs and see how build on top of that. My mistake - I did not mean to imply that it was not layered on top of closely related existing work. I think most people assumed that this would run on top of a LoPAN but it seemed they also wanted it to be able to run on top of a other things including a normal IP LAN and WAN. Clearly this is all about same use cases as 6LoPAN and ties closing with 6LoPAN and ROLL as well as work going on at many other SDOs. However, I'm not sure what needs to be said. Are WG drafts with use case / requirements from other WG that we should be referencing? Give me ideas on what things you were thinking here. Clearly the IESG would not be keen on chartering a new WG to do something another WG was already charted to do - repeating work in two places seldom ends well :-) Can you suggest some specific text for the charter that you think would have fairly wide consent and captures what you are looking for here? _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Sat Oct 31 17:26:57 2009 Return-Path: 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 15E0A3A682F for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] 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 eqsyn85QJWri for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 17:26:56 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id D4E093A63EC for <6lowapp@ietf.org>; Sat, 31 Oct 2009 17:26:55 -0700 (PDT) Received: from [209.191.108.97] by n14.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2009 00:27:12 -0000 Received: from [68.142.201.65] by t4.bullet.mud.yahoo.com with NNFMP; 01 Nov 2009 00:27:12 -0000 Received: from [127.0.0.1] by omp417.mail.mud.yahoo.com with NNFMP; 01 Nov 2009 00:27:12 -0000 X-Yahoo-Newman-Id: 770171.15166.bm@omp417.mail.mud.yahoo.com Received: (qmail 74706 invoked from network); 1 Nov 2009 00:27:12 -0000 Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 31 Oct 2009 17:27:11 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: ld3b2DEVM1nu5DjDtZ7hwqkyGd8YHPyGhCImMnAI663riktmopFGYJM817WiJEq7Dru6hqCDp9mINatTOX6qvf7AzdMayA4YLqXq0LAXrGIDcNmh.QyG099BEq4NRuC25rY.fw0Mh28.ROfOzIHoD2VGc5vqAIfnwq2n7.ANXA8YJt6JbtMFY6.mHsJw1ca2AiHod0Ktoo2aUs0kPgGs0pH7ZuqQRs8EUuYWkdmHnxl0Go6FLP5_64gzNooiqQM6lGGsldAem_ia3OLdiWCBYNnVhlN0npK6PKgbGZJgz291zpmQoOj2wnZR X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" , "'Jonathan Hui'" , "'Carsten Bormann'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <21B63CBB-3197-4985-A2FA-1214F159ADFC@archrock.com> <0C312AA6-92FD-4B55-9F6D-6A3989F9CC40@tzi.org> <9C1F3468-CD7F-4264-B1A5-576BC4FA0F9D@archrock.com> <052CC770-329B-4375-8DA6-F6743464FDBF@cisco.com> In-Reply-To: <052CC770-329B-4375-8DA6-F6743464FDBF@cisco.com> Date: Sat, 31 Oct 2009 17:27:09 -0700 Message-ID: <006f01ca5a8a$0cb3ff30$261bfd90$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpaT7NEqHzaI04HSkmXP/xrKC//nwAOVbsQ Content-Language: en-us 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 Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 00:26:57 -0000 There are a lot of use cases to start with. Here is a starter set: 1) OpenHAN: http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%200808 19-1.pdf 2) SmartGridipedia: http://www.smartgridipedia.org/index.php/Category:Use_Cases, both the Intelligrid and Southern California Edison use cases are good 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are using for our Smart Energy V2 work): http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf There are more is the list above is not enough. For the NIST Smart Grid standards work, several other groups are generating use cases as we speak..... Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Saturday, October 31, 2009 10:29 AM To: Jonathan Hui; Carsten Bormann Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF So trying to get specific advice about how to edit stuff here ... So Jonathan sounds like you would like the list of existing use case / requirements document added to the charter as input to the WG and and also an explicit list of applications the WG will consider. That seems well worth trying. Can you and other folks on the email list help 1) list the documents we can start with 2) list the applications or subsets of applications we should start with in the first phrase. Once we have a list we can decide if we need to prioritize are argue stuff in or out. Thanks Cullen On Oct 30, 2009, at 2:32 , Jonathan Hui wrote: > > Hi Carsten, > > On Oct 30, 2009, at 12:33 AM, Carsten Bormann wrote: > >> Back to the application requirements: I do agree we should focus on >> a small number of specific areas of application, at least for >> making sure we have thought through some specific examples for each >> in detail. I think it would be useful if we called them out >> explicitly in the charter. Right now I'm seeing a lot of interest >> in 6lowapp from Energy (SE V2 etc.) and building automation (which >> may or may not include home automation). The charter does identify >> light switches, temp sensors, power meters, HVAC systems, and door >> locks as specific items that we will look at; so maybe we should be >> a bit more specific and identify the communication relationships we >> are addressing (and add light fixtures, plug-in vehicles and >> washing machines in the process). > > It certainly would have helped me if the charter would have been > more precise about what applications or subsets of applications we > are trying to address. Without that knowledge, its hard to say > whether or not we have the proper requirements written anywhere. > BTW, I don't think the ZigBee/Homeplug MRD is sufficient in itself. > Is the TRD available? > > Given the application(s), it would be even better if somewhere we > indicated what functionality we plan to develop first. Are we only > addressing manipulation of attributes that are relatively small in > size? Are the most important profiles to get done first power, > light, light switch, and temp? > > In the end, if we are to take knowledge of the application > requirements for granted, the charter should be precise about what > we are addressing. It's good to see that we are in line here. > >> Gruesse, Carsten >> >> PS.: I wrote more on the rationale for trying not to get stuck in a >> requirements mire in >> http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html > > > I do prefer your suggested terminology of "objectives" vs. > "requirements". > > -- > Jonathan Hui > _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp