From cabo@tzi.org Mon Sep 7 03:40: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 1ECE83A6767 for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 03:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=-3.032, BAYES_40=-0.185] 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 TtsIuq2XXBef for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 03:40:14 -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 0A4043A63EC for <6lowapp@ietf.org>; Mon, 7 Sep 2009 03:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n87AeQt0001152; Mon, 7 Sep 2009 12:40:29 +0200 (CEST) Message-Id: <8A596C15-3A4F-46B8-B4D1-F453F2FCE8C0@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: Mon, 7 Sep 2009 12:40:26 +0200 X-Mailer: Apple Mail (2.936) Subject: [6lowapp] End of vacation period... BOF request deadline coming up 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, 07 Sep 2009 10:40:15 -0000 The timing of the summer IETF is somewhat unfortunate, since at least the European participants fall into the great holiday void of August immediately afterward. This is my first day back in the office, so I'd like to welcome the now 51 members of the mailing list. We already have a target date coming up close: Today is the deadline for submitting BOF requests for IETF 76 (Hiroshima). I have no idea who put this important date on the Canadian/US Labor Day, but that's the way it is. I think we are in reasonable shape with an existing problem statement draft and some structure on the Wiki, but the actual BOF request has to be written today. I'll send a proposal for a BOF request later today, then we have a couple of hours to discuss it before we have to hand it in. I don't think it makes sense to try to attach a charter proposal to that BOF request -- the main result of *the BOF* should be the structure of the work. The AD has to approve (or not) the BOF proposal next Monday (Sep 14), so we'll be to change some details in that process. (And then we have two months to do the actual work leading to a good BOF.) Stay tuned for later today... Gruesse, Carsten From zach@sensinode.com Mon Sep 7 05:33: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 3592628C0FC for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 05:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_40=-0.185, 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 KD01yPOVQnjl for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 05:33:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D80B13A6A77 for <6lowapp@ietf.org>; Mon, 7 Sep 2009 05:33:12 -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 n87CXZ06030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowapp@ietf.org>; Mon, 7 Sep 2009 15:33:36 +0300 Message-ID: <4AA4FDA1.9070602@sensinode.com> Date: Mon, 07 Sep 2009 15:33:37 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowapp] Contributing to 6lowapp 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, 07 Sep 2009 12:33:14 -0000 Hi, Now that 6lowapp is getting off the ground, and we will have a BOF proposal later today, I wanted to encourage people to contribute on the mailing list and especially with Internet-Drafts before Hiroshima: 2009-10-19 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. This is a great time to contribute, as we are now collecting requirements, experience and solutionlets that may later be part of a related working group's chartered work. Contributions could be related to any of the subjects listed on the wiki, or if we are missing your subject then let us know that too: http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp IDs at this point can be short, incomplete or even just ideas. So don't worry about submitting something that is perfect... For information on writing and submitting an Internet-Draft see: http://www.ietf.org/id-info/guidelines.html Please note IETF IPR policy: http://www.ietf.org/about/note-well.html Use naming like this to associate this towards the 6lowapp activity as an individual submission draft-(yourname)-6lowapp-(subject)-00 If you plan on contributing something, or if you are looking for co-authors feel free to let us know on the list or directly to Carsten and myself. Regards, Zach -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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. From cabo@tzi.org Mon Sep 7 08:05: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 077993A6979 for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.255, 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 goMUyOJT+iZB for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 08:05:20 -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 8C23A3A6822 for <6lowapp@ietf.org>; Mon, 7 Sep 2009 08:05:19 -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 n87F5cUc019958 for <6lowapp@ietf.org>; Mon, 7 Sep 2009 17:05:38 +0200 (CEST) Received: from [192.168.217.101] (p5489D6CC.dip.t-dialin.net [84.137.214.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 1D7C2B2D3; Mon, 7 Sep 2009 17:05:38 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowapp@ietf.org In-Reply-To: <8A596C15-3A4F-46B8-B4D1-F453F2FCE8C0@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Sep 2009 17:05:36 +0200 References: <8A596C15-3A4F-46B8-B4D1-F453F2FCE8C0@tzi.org> X-Mailer: Apple Mail (2.936) Subject: Re: [6lowapp] End of vacation period... BOF request deadline coming up 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, 07 Sep 2009 15:05:21 -0000 On Sep 7, 2009, at 12:40, Carsten Bormann wrote: > I'll send a proposal for a BOF request later today I condensed some offline input to the proposal below. Feedback welcome, from "+1" to "that doesn't work for me", please! (Feedback needed today for the initial proposal.) Gruesse, Carsten (Draft) BOF request for IETF 76 (Hiroshima) $Revision: 1.2 $ BOF Name: 6lowapp 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, Zach Shelby Description: The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. In the 6lowapp Bar BOF discussion at IETF 75 in Stockholm, five areas of work were identified. (Section references point to the problem statement document, http://tools.ietf.org/html/6lowapp-problem .) a -- Security (section 6). 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. c -- Data Representation, both for the application data and for the protocols themselves. This is often referred to as "binary encoding"; the main benefits come less from being binary than from being efficient, easily processable and in particular predictable (reducing code size). W3C EXI was one of the schemes mentioned. d -- Base Application Protocols. HTTP and SNMP were mentioned; there is a strong relationship to the Transport problem on one side and the data representation problem on the other side. A related area is the choice of *Namespaces*, e.g., HTTP has URIs, SNMP has Object Identifiers. e -- Service Discovery (section 4). The BOF will focus on the last three items (c to e), with a clear emphasis on application (d) and service discovery (e) protocols. (Rationale: a and b probably require longer time frames and may fan out to different IETF areas. This does not mean we should ignore them.) The goal of the BOF is to build up the content for a WG charter proposal for one initial working group in the APP area. Agenda (2 hours): 5 min Agenda bashing Carsten 10 min Goal and purpose of the BOF Carsten 10 min Description of the problem/problem space Carsten 15 min 6lowapp WG proposal Zach 30 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) -- Solutions based on existing standards (EXI, IPFIX) -- Solutions based on industry protocols 40 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 51 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.) From d.sturek@att.net Mon Sep 7 08:15:41 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 38EF63A69BF for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 08:15:41 -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 BAWatYiXWl6S for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 08:15:40 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 1FBC628C15D for <6lowapp@ietf.org>; Mon, 7 Sep 2009 08:15:38 -0700 (PDT) Received: (qmail 23144 invoked from network); 7 Sep 2009 15:16:02 -0000 Received: from unknown (HELO Studio) (d.sturek@69.226.24.170 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 7 Sep 2009 15:16:01 -0000 X-YMail-OSG: Ge7MfAQVM1kXqghDByNPus9vJbfo8.W9TrQMnmxK1M4yw7u0jqpDKartGERgB4bnqOn6OKf7Gf40kg2NBoYvIeQ9OdsGOYZQlw_vQ4AAlZo0a_Bi1MYFxTITicuZixNpCcDT0QbM4F52O3E7XHuP82ih5n3E3NI5RQinePXC6DrZ1yTxr.92CXXB77koeJZsYup2i32e5.F708OOaUx83J6jCzvRJJgUkMx7EPwQUPKRCNLHqutSHo0lipDqSxcqMV8XXB1_eIU7Pgxr2LxrlRVccXk6lr_SYHSCmLGlMLzhnZ_8BvogRhoaLtLOgLTXEQ-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , <6lowapp@ietf.org> References: <8A596C15-3A4F-46B8-B4D1-F453F2FCE8C0@tzi.org> In-Reply-To: Date: Mon, 7 Sep 2009 08:16:01 -0700 Message-ID: <003001ca2fce$1c65c300$55314900$@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: AcovzLDUHgSSbhyQRtSOYeb3/VUtgAAAN2dg Content-Language: en-us Subject: Re: [6lowapp] End of vacation period... BOF request deadline coming up 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, 07 Sep 2009 15:15:41 -0000 Hi Carsten, Agree with the text below (mark me down as "+1"). Here is what I can commit to in the coming weeks: 1) An I-D on an extension to SLP for small footprint devices (using an encoded binary protocol that will be compatible with existing SLP). I submitted the proposal as part of the "ZigBee IP" work and am in the process of writing the I-D for it along with Dan Lohman of Itron. 2) The ZigBee/HomePlug Technical requirements document should be complete/reviewed in time for Hiroshima and publicly available. It was contributions from 14 or so utilities plus many/most of the large vendors in the metering space. It would be worth a discussion of key requirements from that document (some were presented during my presentation in Stockholm but the document was not nearly complete at that time). Best Regards, Don Sturek -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, September 07, 2009 8:06 AM To: 6lowapp@ietf.org Subject: Re: [6lowapp] End of vacation period... BOF request deadline coming up On Sep 7, 2009, at 12:40, Carsten Bormann wrote: > I'll send a proposal for a BOF request later today I condensed some offline input to the proposal below. Feedback welcome, from "+1" to "that doesn't work for me", please! (Feedback needed today for the initial proposal.) Gruesse, Carsten (Draft) BOF request for IETF 76 (Hiroshima) $Revision: 1.2 $ BOF Name: 6lowapp 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, Zach Shelby Description: The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. In the 6lowapp Bar BOF discussion at IETF 75 in Stockholm, five areas of work were identified. (Section references point to the problem statement document, http://tools.ietf.org/html/6lowapp-problem .) a -- Security (section 6). 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. c -- Data Representation, both for the application data and for the protocols themselves. This is often referred to as "binary encoding"; the main benefits come less from being binary than from being efficient, easily processable and in particular predictable (reducing code size). W3C EXI was one of the schemes mentioned. d -- Base Application Protocols. HTTP and SNMP were mentioned; there is a strong relationship to the Transport problem on one side and the data representation problem on the other side. A related area is the choice of *Namespaces*, e.g., HTTP has URIs, SNMP has Object Identifiers. e -- Service Discovery (section 4). The BOF will focus on the last three items (c to e), with a clear emphasis on application (d) and service discovery (e) protocols. (Rationale: a and b probably require longer time frames and may fan out to different IETF areas. This does not mean we should ignore them.) The goal of the BOF is to build up the content for a WG charter proposal for one initial working group in the APP area. Agenda (2 hours): 5 min Agenda bashing Carsten 10 min Goal and purpose of the BOF Carsten 10 min Description of the problem/problem space Carsten 15 min 6lowapp WG proposal Zach 30 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) -- Solutions based on existing standards (EXI, IPFIX) -- Solutions based on industry protocols 40 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 51 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.) _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From cabo@tzi.org Mon Sep 7 14:21: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 CA93E3A69E2 for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 14:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.230, 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 xpOsHq6r2cHh for <6lowapp@core3.amsl.com>; Mon, 7 Sep 2009 14:21:51 -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 737E73A6A44 for <6lowapp@ietf.org>; Mon, 7 Sep 2009 14:21:51 -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 n87LMA8c013731 for <6lowapp@ietf.org>; Mon, 7 Sep 2009 23:22:10 +0200 (CEST) Received: from [192.168.217.101] (p5489D6CC.dip.t-dialin.net [84.137.214.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BA2D0B3B5; Mon, 7 Sep 2009 23:22:09 +0200 (CEST) Message-Id: 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: Mon, 7 Sep 2009 23:22:08 +0200 References: <52164A0B-601B-469B-A8F8-D48DC236B710@tzi.org> X-Mailer: Apple Mail (2.936) Subject: [6lowapp] Fwd: BOF request for IETF 76: 6LowApp 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, 07 Sep 2009 21:21:52 -0000 After positive on-list and off-list feedback, I just sent off this BOF request to meet the deadline. By the definition of a BOF, nothing is final, so please continue to comment. Gruesse, Carsten Begin forwarded message: > From: Carsten Bormann > Date: September 7, 2009 23:20:14 +0200 > To: app-ads@tools.ietf.org > Cc: agenda IETF > Subject: BOF request for IETF 76: 6LowApp > > Alexey, Lisa, > > here is the formal BOF request for 6LowApp for IETF 76. > (I will now forward this message to the 6lowapp mailing list for its > further discussion.) > > Gruesse, Carsten > > > BOF request for IETF 76 (Hiroshima) > $Revision: 1.3 $ > > BOF Name: 6lowapp > 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, Zach Shelby > > Description: > > The 6LoWPAN and ROLL WGs are laying the groundwork to make the > Wireless Embedded Internet a reality, but what application protocols > will we use? Request-response protocols like HTTP are a poor fit to a > communication model with battery-operated, mostly sleeping nodes. In > addition, the usual data formats (both headers and body) are perceived > to be too chatty for the 50-60 byte payloads possible in LoWPANs and > to require too much code for the 8-bit and 16-bit processors > dominating the Internet of Things. Still, it would be a mistake to > start a new silo of application protocols that do not benefit from > existing application area Internet experience. > > In the 6lowapp Bar BOF discussion at IETF 75 in Stockholm, five areas > of work were identified. (Section references point to the problem > statement document, http://tools.ietf.org/html/6lowapp-problem .) > > a -- Security (section 6). > > 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. > > c -- Data Representation, both for the application data and for the > protocols themselves. This is often referred to as "binary > encoding"; the main benefits come less from being binary than from > being efficient, easily processable and in particular predictable > (reducing code size). W3C EXI was one of the schemes mentioned. > > d -- Base Application Protocols. HTTP and SNMP were mentioned; there > is > a strong relationship to the Transport problem on one side and the > data representation problem on the other side. A related area is > the choice of *Namespaces*, e.g., HTTP has URIs, SNMP has Object > Identifiers. > > e -- Service Discovery (section 4). > > The BOF will focus on the last three items (c to e), with a clear > emphasis on application (d) and service discovery (e) protocols. > (Rationale: a and b probably require longer time frames and may fan > out to different IETF areas. This does not mean we should ignore > them.) > > The goal of the BOF is to build up the content for a WG charter > proposal for one initial working group in the APP area. > > Agenda (2 hours): > > 5 min Agenda bashing Carsten > 10 min Goal and purpose of the BOF Carsten > 10 min Description of the problem/problem space Carsten > 15 min 6lowapp WG proposal Zach > 30 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; > ZigBee/HomePlug TRD) > -- Input from relevant large projects (e.g., SENSEI) > -- Solutions based on existing standards (EXI, IPFIX, SLP) > -- Solutions based on industry protocols > 40 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 52 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.) From enrico.marocco@telecomitalia.it Thu Sep 10 01: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 7CB843A691D for <6lowapp@core3.amsl.com>; Thu, 10 Sep 2009 01:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 JPh5AqJLijO8 for <6lowapp@core3.amsl.com>; Thu, 10 Sep 2009 01:27:58 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 9899A3A6814 for <6lowapp@ietf.org>; Thu, 10 Sep 2009 01:27:54 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 10 Sep 2009 10:28:27 +0200 Received: from [163.162.173.6] (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Thu, 10 Sep 2009 10:28:26 +0200 Message-ID: <4AA8B8C4.9030407@telecomitalia.it> Date: Thu, 10 Sep 2009 10:28:52 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: <6lowapp@ietf.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030005000204070705070903" Subject: [6lowapp] Notes from the bar 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, 10 Sep 2009 08:27:58 -0000 --------------ms030005000204070705070903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I was wondering if there are any minutes or Jabber logs from the bar BoF? All the way to the social I'd had a feeling like I was forgetting something... :-( -- Ciao, Enrico --------------ms030005000204070705070903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MTAwODI4NTJaMCMG CSqGSIb3DQEJBDEWBBR+JkXYh/uKZBs23viRp/bMxa+FNjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAFvgijif3VWI du7lLRbvI7uIF/Fpr9WLOkt5dlqy9Bf7oHrGSMt98e1KHsWud7YXn8ZtZMGIaN8hdDGowWgb 1cRZqcgEKI+LZyzX0B0sLzr/Uq08VJbVZk8P6DZAo8h4UQjsPObvXf4/i9ofXpfBj9vBYVqm y0jWRutcV25Om/Kkex5EWtFz93lu636K4qkAtVzivzFDuRs0f+7EgSNCh51K7LdsrS63rJK0 iwbcyVnZQBcDk928Xywh5MCMN4NeGZpfGh6cs/Hv7o3XEtxoZdqwbgkAeiHzt551eazIpO2i TdpTHe+xE3Q4Emk2IZUIIYY8Oo/Y+UchpEbnC81ny+0AAAAAAAA= --------------ms030005000204070705070903-- From cabo@tzi.org Thu Sep 10 04:00: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 776C03A6830 for <6lowapp@core3.amsl.com>; Thu, 10 Sep 2009 04:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.379, 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 xuZr3d3-34im for <6lowapp@core3.amsl.com>; Thu, 10 Sep 2009 04:00:41 -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 406E628C0CF for <6lowapp@ietf.org>; Thu, 10 Sep 2009 04:00:41 -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 n8AB168W010692; Thu, 10 Sep 2009 13:01:06 +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 1BF46BE5E; Thu, 10 Sep 2009 13:01:06 +0200 (CEST) From: Carsten Bormann To: Enrico Marocco In-Reply-To: <4AA8B8C4.9030407@telecomitalia.it> References: <4AA8B8C4.9030407@telecomitalia.it> Message-Id: <334A0515-C45C-465D-90C5-421FCE20D74C@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: Thu, 10 Sep 2009 13:01:05 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Notes from the bar 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, 10 Sep 2009 11:00:42 -0000 Enrico, I do have some unedited notes, but I think the Bar BOF is well- captured by the slides and the wiki page. The slide set is under http://u.nu/9i473 = http://trac.tools.ietf.org/area/app/trac/attachment/wiki/BarBofs/IETF75/6LowApp/6lowapp-intro-v2.pdf The wiki page, which outlines the areas of work that we have identified during the Bar BOF, is under: http://6lowapp.net You may also want to look at the BOF proposal for Hiroshima I sent out on Monday: http://www.ietf.org/mail-archive/web/6lowapp/current/msg00006.html And, of course, I'd love to hear feedback on all these. Gruesse, Carsten From enrico.marocco@telecomitalia.it Thu Sep 10 05:21: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 078BE28C189 for <6lowapp@core3.amsl.com>; Thu, 10 Sep 2009 05:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Y-8nlVyC3kkz for <6lowapp@core3.amsl.com>; Thu, 10 Sep 2009 05:21:47 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 738953A67DB for <6lowapp@ietf.org>; Thu, 10 Sep 2009 05:21:46 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 10 Sep 2009 14:22:13 +0200 Received: from [163.162.173.6] (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Thu, 10 Sep 2009 14:22:13 +0200 Message-ID: <4AA8EF8F.2010606@telecomitalia.it> Date: Thu, 10 Sep 2009 14:22:39 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Carsten Bormann References: <4AA8B8C4.9030407@telecomitalia.it> <334A0515-C45C-465D-90C5-421FCE20D74C@tzi.org> In-Reply-To: <334A0515-C45C-465D-90C5-421FCE20D74C@tzi.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000109010407040008030006" Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Notes from the bar 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, 10 Sep 2009 12:21:48 -0000 --------------ms000109010407040008030006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yep, I found them in the archives, but was also interested in the discussion. Never mind, I guess the list on the wiki page is the result of such a discussion and that's enough for me ;-) As far as feedback is concerned, summer holidays and the early deadlines have played against you; however, I'll provide you with mine as soon as I manage to catch up with the latest version of the docs. Enrico Carsten Bormann wrote: > Enrico, > > I do have some unedited notes, but I think the Bar BOF is well- > captured by the slides and the wiki page. > > The slide set is under http://u.nu/9i473 = > http://trac.tools.ietf.org/area/app/trac/attachment/wiki/BarBofs/IETF75/6LowApp/6lowapp-intro-v2.pdf > > The wiki page, which outlines the areas of work that we have > identified during the Bar BOF, is under: > http://6lowapp.net > > You may also want to look at the BOF proposal for Hiroshima I sent out > on Monday: > http://www.ietf.org/mail-archive/web/6lowapp/current/msg00006.html > > And, of course, I'd love to hear feedback on all these. > > Gruesse, Carsten --------------ms000109010407040008030006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MTAxMjIyMzlaMCMG CSqGSIb3DQEJBDEWBBSUphlavJWLXiInx2O5N5olDo4NvjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBABcM86Q+YK1S txVxA9LC7eHQLXxzKHipdZAeOUhmWCw4Zq1XQeBGAsDXGs1Ky8RZf5CRwC0rl8J4oykIEAPu CoPLDp9VFY07HjF0tB/RPcInEOl7MoM4dJjL5+a7MEXEJhHKhIRx/wZPDhROJS/K+JaMyor5 bLwv4z/OmTsddipiQ0MBHztB3yAbPjJWbNHXk73rorWPDp6IngcE0nz4Vs+9qj8XHVo67JvF lTpcmOoS71lVeeiZkmvFGFicxLpgSp4ZP1vfEtj+HI+NRo8rSKR6BRyjG48KHX8WYnLj/g7W FyYOTu7sPTf+aL5bY9P1mkWr2YEBeHO9G0utbYkZo7wAAAAAAAA= --------------ms000109010407040008030006-- From brian.tridium@gmail.com Fri Sep 11 10:44: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 06C9528C190 for <6lowapp@core3.amsl.com>; Fri, 11 Sep 2009 10:44:53 -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 o9jp1Tj1ZdI7 for <6lowapp@core3.amsl.com>; Fri, 11 Sep 2009 10:44:51 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 592A73A6988 for <6lowapp@ietf.org>; Fri, 11 Sep 2009 10:44:51 -0700 (PDT) Received: by bwz19 with SMTP id 19so947326bwz.37 for <6lowapp@ietf.org>; Fri, 11 Sep 2009 10:45:25 -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=SVXgsHi6WboC+6hdoDW6ppBI2C7I+aFWO6ZF4VJVBEk=; b=wrvye0s4RKJoaKWsbm4L12Z4shRmDcxa3rfByNUSjAgKazeqqeWA8bUyoTTtVEIKf5 6V8N2EWyXuKccCLq/rfUUVZ4WwOiJFyt2wTdENhJei2OcBm2unRS/sazyDK6geO7vsti seOxIx5JxuF1dv1RKsf4ati33eLpNCWP3AQhc= 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=WSlIlZw8Raadv9ba7BT8cen2qNmCDHyutnAOs3gYe1KMHa6E38bbHslxHkgS2cp62O KX7Te/SvOTGUY2I007ZNnipm69GXo+EeJebZLt0FgTgPfpSL+i6RrEvfx/ntEez2vzhI x+RfF6aiwj7DPdtpMl67a1GuvZQFiSAVwjoGQ= MIME-Version: 1.0 Received: by 10.204.18.137 with SMTP id w9mr2278773bka.56.1252691125278; Fri, 11 Sep 2009 10:45:25 -0700 (PDT) In-Reply-To: <4AA4FDA1.9070602@sensinode.com> References: <4AA4FDA1.9070602@sensinode.com> Date: Fri, 11 Sep 2009 13:45:25 -0400 Message-ID: <7b191a110909111045o766663f6w65c0b409f6d9021d@mail.gmail.com> From: Brian Frank To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=0003255558268918e6047350e1d9 Subject: Re: [6lowapp] Contributing to 6lowapp 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, 11 Sep 2009 17:44:53 -0000 --0003255558268918e6047350e1d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have resubmitted my Chopan Internet Draft (Compressed HTTP over PANs) under 6lowapp: http://www.ietf.org/id/draft-frank-6lowapp-chopan-00.txt I had submitted a previous version under 6lowpan. This version is almost exactly the same except for one tweak regarding compression of the request-method based on some feedback from the HTTP guys. The idea behind Chopan is that we aren't just creating the "Internet of Things", but hopefully creating the "Web of Things", so that the world at large can identify resources in "edge devices" using standard URIs. Side note: I have started work on a binary oBIX encoding that might be one potential payload over whatever 6lowapp protocol(s) we end up defining (see http://lists.oasis-open.org/archives/obix-xml/200909/msg00000.html) Brian On Mon, Sep 7, 2009 at 8:33 AM, Zach Shelby wrote: > Hi, > > Now that 6lowapp is getting off the ground, and we will have a BOF propos= al > later today, I wanted to encourage people to contribute on the mailing li= st > and especially with Internet-Drafts before Hiroshima: > > 2009-10-19 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission > Tool. > > This is a great time to contribute, as we are now collecting requirements= , > experience and solutionlets that may later be part of a related working > group's chartered work. Contributions could be related to any of the > subjects listed on the wiki, or if we are missing your subject then let u= s > know that too: > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > > IDs at this point can be short, incomplete or even just ideas. So don't > worry about submitting something that is perfect... > > For information on writing and submitting an Internet-Draft see: > http://www.ietf.org/id-info/guidelines.html > > Please note IETF IPR policy: > http://www.ietf.org/about/note-well.html > > Use naming like this to associate this towards the 6lowapp activity as an > individual submission draft-(yourname)-6lowapp-(subject)-00 > > If you plan on contributing something, or if you are looking for co-autho= rs > feel free to let us know on the list or directly to Carsten and myself. > > Regards, > Zach > > -- > 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 > --0003255558268918e6047350e1d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I have resubmitted my Chopan=A0Internet Draft=A0(Compressed HTTP over = PANs) under 6lowapp:


I had submitted a previous version under 6lowpan. =A0Th= is version is almost exactly the same except for one tweak regarding compre= ssion of the request-method based on some feedback from the HTTP guys.

The idea behind Chopan is that we aren't just creat= ing the "Internet of Things", but hopefully creating the "We= b of Things", so that the world at large can identify resources in &qu= ot;edge devices" using standard URIs.

Side note: I have started work on a binary oBIX encodin= g that might be one potential payload over whatever 6lowapp protocol(s) we = end up defining (see=A0http://lists.oasis-open.org/archives/obix-xml/20= 0909/msg00000.html)


Brian



On Mon, Sep 7, 2009 at 8:33 AM, Zach Shelby= <zach@sensinode= .com> wrote:
Hi,

Now that 6lowapp is getting off the ground, and we will have a BOF proposal= later today, I wanted to encourage people to contribute on the mailing lis= t and especially with Internet-Drafts before Hiroshima:

2009-10-19 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool.<= br>
This is a great time to contribute, as we are now collecting requirements, = experience and solutionlets that may later be part of a related working gro= up's chartered work. Contributions could be related to any of the subje= cts listed on the wiki, or if we are missing your subject then let us know = that too:
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp

IDs at this point can be short, incomplete or even just ideas. So don't= worry about submitting something that is perfect...

For information on writing and submitting an Internet-Draft see:
h= ttp://www.ietf.org/id-info/guidelines.html

Please note IETF IPR policy:
http= ://www.ietf.org/about/note-well.html

Use naming like this to associate this towards the 6lowapp activity as an i= ndividual submission draft-(yourname)-6lowapp-(subject)-00

If you plan on contributing something, or if you are looking for co-authors= feel free to let us know on the list or directly to Carsten and myself.
Regards,
Zach

--
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 lega= lly privileged information. If you are not the intended recipient, please c= ontact the sender and delete the e-mail from your system without producing,= distributing or retaining copies thereof.
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

--0003255558268918e6047350e1d9-- From schmitt@net.in.tum.de Mon Sep 14 06:02: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 17D903A67A1 for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 06:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Vk+Sy3T80nx6 for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 06:02:55 -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 E82583A67AA for <6lowapp@ietf.org>; Mon, 14 Sep 2009 06:02:53 -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 A7F3E481DD for <6lowapp@ietf.org>; Mon, 14 Sep 2009 15:03:36 +0200 (CEST) Received: from [127.0.0.1] (ldap [131.159.14.1]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9CD1454F6 for <6lowapp@ietf.org>; Mon, 14 Sep 2009 15:03:36 +0200 (CEST) Message-ID: <4AAE3F2B.8050004@net.in.tum.de> Date: Mon, 14 Sep 2009 15:03:39 +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] Deadlines and Requirements 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, 14 Sep 2009 13:02:56 -0000 Hallo together, we are preparing a draft for the working group. Can anyone tell me when the deadline for draft-registration is and where to upload the draft? Thanks, C.Schmitt -- 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 enrico.marocco@telecomitalia.it Mon Sep 14 08:01: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 672873A6A53 for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.469 X-Spam-Level: X-Spam-Status: No, score=0.469 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 b5Qf3bkZyRJq for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 08:01:11 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 201483A6A50 for <6lowapp@ietf.org>; Mon, 14 Sep 2009 08:01:11 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 14 Sep 2009 17:01:54 +0200 Received: from [163.162.173.24] (163.162.173.24) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Mon, 14 Sep 2009 17:01:53 +0200 Message-ID: <4AAE5AFC.1030503@telecomitalia.it> Date: Mon, 14 Sep 2009 17:02:20 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Schmitt References: <4AAE3F2B.8050004@net.in.tum.de> In-Reply-To: <4AAE3F2B.8050004@net.in.tum.de> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050708080600090404010902" Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Deadlines and Requirements 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, 14 Sep 2009 15:01:12 -0000 --------------ms050708080600090404010902 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cutoff dates for Hiroshima are listed at http://www.ietf.org/meeting/cutoff-dates.html#76 I guess you are looking for this: # 2009-10-19 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool (https://datatracker.ietf.org/idst/upload.cgi). Enrico Schmitt wrote: > Hallo together, > > we are preparing a draft for the working group. Can anyone tell me when > the deadline for draft-registration is and where to upload the draft? > > Thanks, > C.Schmitt --------------ms050708080600090404010902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MTQxNTAyMjBaMCMG CSqGSIb3DQEJBDEWBBSjwB8/HUmsBDXe4wHOMUeVwEUnuTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAJGUy4r3vc13 D86aOkRQdPFtXAZRa4S/NS767GDedVPHIdFprVGlFBPHPLuVtJMpy4Ic+cjCUzGWgG9B3PK+ 2nw0CgJKJn/e/VMJOxIjr3CDua/hHBezt/3e6i1Iw/57Vuq0W7CRocqNjLzl2kT/eKh06WCO zJ1LaQH+awF3t+pVitLwJaK8yk5Vb8t798hNj4KDORCuwyK+RkjaXFRU+zdZuZO4n+e3CBfy LjbYVZonST1H2ympuxlgxXNsmpcb3l0rNKR0dMiMaH9YFVZFZ9yrTOpg0OQcKLXBYxK3vnwW RH8GFAdRgdRA/pnEXHeNOb95bpakvwbm+IL1MkxWRs4AAAAAAAA= --------------ms050708080600090404010902-- From zach@sensinode.com Mon Sep 14 13:09: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 6AFA03A6ABF for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 13:09:51 -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 PB0zIRcx4cF2 for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 13:09:50 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B900D3A6A8C for <6lowapp@ietf.org>; Mon, 14 Sep 2009 13:09:48 -0700 (PDT) Received: from snl-zach.local (line-7700.dyn.kponet.fi [85.29.76.113]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8EKAOhM014480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 23:10:25 +0300 Message-ID: <4AAEA334.2010908@sensinode.com> Date: Mon, 14 Sep 2009 23:10:28 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brian Frank References: <4AA4FDA1.9070602@sensinode.com> <7b191a110909111045o766663f6w65c0b409f6d9021d@mail.gmail.com> In-Reply-To: <7b191a110909111045o766663f6w65c0b409f6d9021d@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Contributing to 6lowapp 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, 14 Sep 2009 20:09:51 -0000 Hi Brian, Thanks for the submission - our first technical submission to 6lowapp by the way - huray! One idea you included in the draft which will be important to keep in mind is how to encode the content and encoding type into a reasonable sized binary field for whatever protocols we develop here. You are suggesting two bytes is reasonable (I would more than agree). In one project we have used one byte which was also plenty for the varieties envisioned over e.g. 6LoWPAN. I think the challenge here will be a representation that IANA can keep track of values for and is yet easily extensible. Brian Frank wrote: > I have resubmitted my Chopan Internet Draft (Compressed HTTP over PANs) > under 6lowapp: > > http://www.ietf.org/id/draft-frank-6lowapp-chopan-00.txt > > I had submitted a previous version under 6lowpan. This version is > almost exactly the same except for one tweak regarding compression of > the request-method based on some feedback from the HTTP guys. > > The idea behind Chopan is that we aren't just creating the "Internet of > Things", but hopefully creating the "Web of Things", so that the world > at large can identify resources in "edge devices" using standard URIs. Right! The loosely coupled URL model is really the core feature of the REST model. I also find REST methods just as useful, although the old request/response pull model of HTTP could use some new features for embedded networks (pushing events or pub/sub). > Side note: I have started work on a binary oBIX encoding that might be > one potential payload over whatever 6lowapp protocol(s) we end up > defining > (see http://lists.oasis-open.org/archives/obix-xml/200909/msg00000.html) > Although I don't know much about the internal structure of oBIX (just the XML face of it), it sounds to me a lot like the encoding problem which the EXI algorithm does for XML. Note that you could easily apply EXI as an algorithm to encode oBIX without first turning your oBIX structure into XML. Your object types, facets, data types and string dictionaries are all handled there pretty nicely. If you need any help with that just drop me an e-mail. - Zach > Brian > > > > On Mon, Sep 7, 2009 at 8:33 AM, Zach Shelby > wrote: > > Hi, > > Now that 6lowapp is getting off the ground, and we will have a BOF > proposal later today, I wanted to encourage people to contribute on > the mailing list and especially with Internet-Drafts before Hiroshima: > > 2009-10-19 (Monday): Internet Draft Cut-off for initial document > (-00) submission by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID > Submission Tool. > > This is a great time to contribute, as we are now collecting > requirements, experience and solutionlets that may later be part of > a related working group's chartered work. Contributions could be > related to any of the subjects listed on the wiki, or if we are > missing your subject then let us know that too: > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > > IDs at this point can be short, incomplete or even just ideas. So > don't worry about submitting something that is perfect... > > For information on writing and submitting an Internet-Draft see: > http://www.ietf.org/id-info/guidelines.html > > Please note IETF IPR policy: > http://www.ietf.org/about/note-well.html > > Use naming like this to associate this towards the 6lowapp activity > as an individual submission draft-(yourname)-6lowapp-(subject)-00 > > If you plan on contributing something, or if you are looking for > co-authors feel free to let us know on the list or directly to > Carsten and myself. > > Regards, > Zach > > -- > http://www.sensinode.com > http://zachshelby.org - My blog “On the Internet of Things” > 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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. From cabo@tzi.org Mon Sep 14 14:44: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 659BC3A67DB for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 14:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.219, 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 12l6aJCtxi6A for <6lowapp@core3.amsl.com>; Mon, 14 Sep 2009 14:44:29 -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 A28DC3A6405 for <6lowapp@ietf.org>; Mon, 14 Sep 2009 14:44:28 -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 n8ELj3kv023739 for <6lowapp@ietf.org>; Mon, 14 Sep 2009 23:45:03 +0200 (CEST) Received: from [192.168.217.101] (p5489DC83.dip.t-dialin.net [84.137.220.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5D27EBB36; Mon, 14 Sep 2009 23:45:03 +0200 (CEST) Message-Id: 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: Mon, 14 Sep 2009 23:45:02 +0200 X-Mailer: Apple Mail (2.936) Subject: [6lowapp] BOF Status 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, 14 Sep 2009 21:44:30 -0000 Just in case some of you have seen the "Important dates" for IETF76 (http://www.ietf.org/meeting/cutoff-dates.html ), you may wonder what's going on with today's BOF approval deadline. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart has the explanation: > Sept 14 is listed as the date ADs approve BOF requests, but that is > in conflict with the day we actually have scheduled discussion > preceding approval -- that is Sept 25. ["we" = the area directors, who are maintaining that Wiki page.] There will be some off-list discussions (between ADs and proposed BOF chairs) in preparation for that date this week; Zach and I will keep you up to date. In preparation for that: If any of you have drafts in the pipeline and can already talk about your plans of submitting them, please do that now! Gruesse, Carsten From cabo@tzi.org Thu Sep 24 00:38: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 E40723A6955 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 3eaybV8Xfhcr for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 00:38:06 -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 1F3013A699C for <6lowapp@ietf.org>; Thu, 24 Sep 2009 00:38:05 -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 n8O7d4vP014710 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 09:39:04 +0200 (CEST) Received: from [192.168.217.101] (p5489ED79.dip.t-dialin.net [84.137.237.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id D8BA5BD68; Thu, 24 Sep 2009 09:39:03 +0200 (CEST) Message-Id: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> From: Carsten Bormann To: 6lowapp@ietf.org In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-6-592835932 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 09:39:02 +0200 References: X-Mailer: Apple Mail (2.936) Subject: [6lowapp] BOF proposal: update 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, 24 Sep 2009 07:38:08 -0000 --Apple-Mail-6-592835932 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit We used the last week to discuss the BOF proposal with our responsible AD and with people from other standards groups. The result is a revised BOF proposal, that already provides an outline for the charter of the new WG. This charter now defines a more specific focus for the WG til the end of 2010. I think that is good because the IETF is much better in handling focused, specific work items than in grand, boil-the-ocean efforts. If we succeed, we can always recharter to attack additional items. A bit more background: The goal of this BOF proposal is to get a BOF going in Hiroshima, the week of Nov 9. The goal of the BOF is to demonstrate that we have enough interest ("energy") and enough focus to solve a credible problem in a defined amount of time; this will enable us to charter a WG following the BOF. Not all of you will be physically present in Hiroshima; that's another reason why it is important to hear your opinions on this mailing list. The charter proposal can and will change until Hiroshima, and now is the time to influence it and to express your support. Also, the IETF is generally driven by Internet-Draft documents, so it would be good to hear on the list what you will be able to contribute. I'm looking forward to your feedback. Gruesse, Carsten --Apple-Mail-6-592835932 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: 316 $ BOF Name: 6lowapp 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 - Applications for resource constrained devices and networks The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet 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 usual data formats (both headers and body) 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 the Internet of Things. 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 kbps 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. 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 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 Outline: --------------------------- 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 work on new content formats or encodings, nor the compression or adaptation of HTTP. (to be expanded) * 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 and OASIS on data formats, the IEC and UCA OpenSG on Smart Energy, ETSI M2M TC on machine-to-machine architecture requirements, ZigBee, 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, content types and encodings, PULL and PUSH interaction models, basic REST methods, both UDP and TCP, a simple form of cachability, and statelessness. -- Proxying with HTTP 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 or DNS-SD must be straightforward. Goals and Milestones: --------------------- 1Q/2010 Submit 6lowapp Problem Statement and Objectives to IESG for consideration of publication as Informational 3Q/2010 Submit Application Protocol Specification document(s) to IESG for consideration of publication as Proposed Standard 4Q/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 Zach 30 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; ZigBee/HomePlug TRD) -- Input from relevant large projects (e.g., SENSEI) -- Solutions based on existing standards (EXI, IPFIX, SLP) -- Solutions based on industry protocols 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 65 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-6-592835932 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-6-592835932-- From j.schoenwaelder@jacobs-university.de Thu Sep 24 00:58: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 EB1B83A67D2 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 00:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_05=-1.11, 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 DooJY-BjrwZn for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 00:58:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1A9273A677D for <6lowapp@ietf.org>; Thu, 24 Sep 2009 00:58:25 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84301C0015; Thu, 24 Sep 2009 09:59:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SGkiOx8rrXO7; Thu, 24 Sep 2009 09:59:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07489C0004; Thu, 24 Sep 2009 09:59:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1B0D6CFD360; Thu, 24 Sep 2009 09:59:30 +0200 (CEST) Date: Thu, 24 Sep 2009 09:59:30 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20090924075930.GA16551@elstar.local> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] BOF proposal: update X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder 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, 24 Sep 2009 07:58:26 -0000 On Thu, Sep 24, 2009 at 09:39:02AM +0200, Carsten Bormann wrote: > I'm looking forward to your feedback. I doubt you can leave out security. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From enrico.marocco@telecomitalia.it Thu Sep 24 01:22: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 951133A677E for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 8vzRSp+Xwzyz for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 01:22:44 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 62B183A657C for <6lowapp@ietf.org>; Thu, 24 Sep 2009 01:22:42 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 24 Sep 2009 10:23:40 +0200 Received: from [163.162.173.6] (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Thu, 24 Sep 2009 10:23:47 +0200 Message-ID: <4ABB2CAF.8040800@telecomitalia.it> Date: Thu, 24 Sep 2009 10:24:15 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Juergen Schoenwaelder References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <20090924075930.GA16551@elstar.local> In-Reply-To: <20090924075930.GA16551@elstar.local> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040208000405040402090705" Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 08:22:44 -0000 --------------ms040208000405040402090705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: >> I'm looking forward to your feedback. > > I doubt you can leave out security. Probably the charter should be clearer that what's out of scope is a generic security framework for embedded devices; I certainly don't expect documents produced by the proposed WG to have empty Security Considerations sections (I don't thing that is the intention though). -- Ciao, Enrico --------------ms040208000405040402090705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MjQwODI0MTVaMCMG CSqGSIb3DQEJBDEWBBRTN5XNa3KV/3zafhR46U8XTNhNnDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBADK2RzhhFKh3 JK63tLWhRYNjaD9vuS9cIubDF6NfgPA7PYDj4oIOabLpRtbNnwuin/GdZlD770D/VerLvm84 7V1tTlZg7mI0ZeWoy9PViiJfDx8T0rU81qp7dBsLXHHMRk1UDfSp+3UvIIbwOR1a48yns/5U 9F9482X+tWGjCUu8MHSw4T7uC2g1wTlsJxIHGJgSqKi7F20mZGZK7cB867M+xncmV3nUgThq WLp0u2NuKBMjHWDKL3TGCA8SB1MHOrZowXuFyZSixfBp2NgFny+HLhezZuWvPay3T9kjknN3 ozBDKOIx3xlL+fHnHnsfYUeoO8zljBk+/W03YQjp598AAAAAAAA= --------------ms040208000405040402090705-- From zach@sensinode.com Thu Sep 24 01:27: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 079283A692D for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 01:27:15 -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 a3RcYnblIu0w for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 01:27:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D18853A686E for <6lowapp@ietf.org>; Thu, 24 Sep 2009 01:27:13 -0700 (PDT) Received: from snl-zach.local ([213.145.205.251]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8O8SHAQ006131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2009 11:28:17 +0300 Message-ID: <4ABB2DA3.9010305@sensinode.com> Date: Thu, 24 Sep 2009 11:28:19 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Enrico Marocco References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <20090924075930.GA16551@elstar.local> <4ABB2CAF.8040800@telecomitalia.it> In-Reply-To: <4ABB2CAF.8040800@telecomitalia.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 08:27:15 -0000 Enrico Marocco wrote: > Juergen Schoenwaelder wrote: >>> I'm looking forward to your feedback. >> I doubt you can leave out security. > > Probably the charter should be clearer that what's out of scope is a > generic security framework for embedded devices; I certainly don't > expect documents produced by the proposed WG to have empty Security > Considerations sections (I don't thing that is the intention though). Exactly. The security considerations for both work items should be of course integral parts of the WG goals. And as you say, we are not working on a generic security framework. Under the "what we do not work on" section we should add some text about that. Plus in the work items we should be specific that security is a part of each item. Thanks, Zach > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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. From enrico.marocco@telecomitalia.it Thu Sep 24 02:26: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 5F7A03A688B for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 02:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 9Nycd52n2uNL for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 02:26:43 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id E8FEB3A67B4 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 02:26:42 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 24 Sep 2009 11:27:48 +0200 Received: from [163.162.173.6] (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Thu, 24 Sep 2009 11:27:49 +0200 Message-ID: <4ABB3BB1.5000403@telecomitalia.it> Date: Thu, 24 Sep 2009 11:28:17 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Carsten Bormann References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> In-Reply-To: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080205070305000501010100" Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 09:26:44 -0000 --------------ms080205070305000501010100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Carsten Bormann wrote: > 20 min 6lowapp WG charter proposal Zach > 30 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; > ZigBee/HomePlug TRD) > -- Input from relevant large projects (e.g., SENSEI) > -- Solutions based on existing standards (EXI, IPFIX, SLP) > -- Solutions based on industry protocols > 30 min Open Discussion All I'd suggest to swap "charter proposal" and "contributions", as I guess the BoF will be more productive if the discussion focuses on the former rather than the latter. -- Ciao, Enrico --------------ms080205070305000501010100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5MjQwOTI4MTdaMCMG CSqGSIb3DQEJBDEWBBQZGSM4DIY21AhOZC/TBLPg8CDykTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAI85+w2ONAkP HFssNenD5krTxTi6+lYB4ffTY0Iuu6Xe2LNx/tGW+96E8SUC9jInMwYAbqJIFFbkHo7B1liM JOa+H0QifDfEzi8pU+Hlzee6P8mexnJhglvhF5vztEigXAU8R4NlgHPazBLNlxnTDD12vfIi PvTZgV1sP96b7kGPXS37ve5k3wjVciMzFVwx3VRt+so5Krdf1xP8vfxbviRb7b47q+Yb9kNu 2Vt9+omzAsBfYOFEprb7ukQq7fwB7aJkIYUajfRVWyxV9eYR7Dqy0ROvCntb6n2eEmCamfG1 JcHtCAy2FuRgRrinHXl/827RkKGiKQKTTzyPrhcTfGwAAAAAAAA= --------------ms080205070305000501010100-- From oobles@gmail.com Thu Sep 24 04:42:35 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 A13CF28C0E2 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 04:42:35 -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 66z835AZeOuF for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 04:42: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 46A4628C0D8 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 04:42:34 -0700 (PDT) Received: by ewy28 with SMTP id 28so2167722ewy.42 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 04:43: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 :content-transfer-encoding; bh=/MqqIW3nE6wSGElst8E9G+ltsXbUfL5vhK1csvDRPUk=; b=AGgViWPi/l6Jm5s8ZxRUT8K+yWPOt50AJkpC5xx1+7ohKneNIhn6TRP/DXDf+yWobL yuGsAUfOiO+znOAaLi8CrAbGmLzvixrPL/Og5jaCA7TSIVZiBP2tll034NKWvitwyqW2 B9Q30Ol7BDLdVDrft+9zmmRheoW9XmI1hKBIk= 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=JJ6K4JhMhxNpjRSa2mh3k1LubR4XXpzsjhBjBA44NVxeQe5E6IhVDtrXyT5O19OfWN eOAoF5fcK5tAP6mdyAJI+6y4hlUI8RtQFCtoAFMAJczvDjKzVny2rYY+rM/rdQhrl1oj a+n+5tiEGuw+ouomjDkYsnw1SElx0jZ+dYSA4= MIME-Version: 1.0 Received: by 10.210.154.20 with SMTP id b20mr7431044ebe.29.1253792617624; Thu, 24 Sep 2009 04:43:37 -0700 (PDT) In-Reply-To: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> Date: Thu, 24 Sep 2009 21:43:36 +1000 Message-ID: <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> From: David Ryan To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 11:42:35 -0000 Hi Carsten, I have a few clarification questions in regards to the BOF proposal. I'll quote the relevant sections and add my remarks/questions. > In particular the Smart Energy v2.0 (collaboration of NIST, UCA > international, ZigBee and the IEC) is in urgent need of both > application protocol and application commissioning solutions. This mentions the urgent need for Smart Energy v2.0. The timeframe for the working group is to submit protocol specifications by Q3 and Q4 2010. Have the timeframes for Smart Energy been published? I'm concerned that decisions will already be made by Smart Energy and this group will simply have to fall inline with decisions already made. If this group is to influence the Smart Energy decision, I think it would be appropriate for them to publish their timeline? Also, it might be fair to add HomePlug to the Smart Energy v2.0 list as that group has also been involved. > The goal of 6lowapp is to produce application protocol and > application commissioning solutions suitable for providing us the web > for resource constrained devices The initial paragraph discusses "application protocols" for the "Wireless Embedded Internet", while other sections discuss the "embedded web" and "web for resource constrained devices". Is there a difference? > This working group will not work on new content formats > or encodings, nor the compression or adaptation of HTTP. (to be expanded) I realise there is a comment that this needs "to be expanded", so I apologise for jumping the gun. If the aim is to build the "embedded web" and not adapt HTTP, does this suggest that the draft submitted by Brian Frank (Chopan) is outside the scope of the working group? This seems to be contradictory with the opening paragraph. Finding appropriate application protocols seems to be more correct and casts a wide net to find a good solu= tion. I'd also like to ask the rational for discarding the concept of new content formats or encodings? Assuming that a new format or encoding has benefits as defined by the "Problem Statement and Objectives", shouldn't it be within the scope to review and debate the merits of such encodings? To be open and clear to everyone on the list, I plan on submitting a draft which incorporates what many will consider a new encoding. The issue of data formats is also mentioned here: > 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. Once again, isn't this a premature to set the scope of the solution before the requirements have been devised. > 6lowapp will cooperate with external organizations on work item > requirements and standards interoperability. These include the W3C > and OASIS on data formats Reading between the lines on this I get the feeling that the choice of using the W3C EXI encoding has already been made. Is there a set list of applicable data formats? If there are, once again, I believe this prematurely defines the solution. >=A0I think that is good > because the IETF is much better in handling focused, specific work > items than in grand, boil-the-ocean efforts. I understand the need here to focus the working group on a specific problem. However, I also think it is very important to not under-estimate the importance of this working group. If the output of this working group is to form the basis for Smart Energy, it will form the corner stone of the "Internet of Things" for years to come. Smart Energy is just the first of many application protocols that will be defined by standards groups. I'm sure everyone will agree that for this reason it is important to get this right and not rush into a pre-defined solution without evaluating a range of possible solutions. Regards, David. From cabo@tzi.org Thu Sep 24 05:35: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 75AB73A692B for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 05:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=0.131, 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 DzAIiBjW-Dd5 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 05:35:14 -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 1947428C0EA for <6lowapp@ietf.org>; Thu, 24 Sep 2009 05:35:13 -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 n8OCaEZ9022643; Thu, 24 Sep 2009 14:36:14 +0200 (CEST) Received: from [192.168.217.101] (p5489ED79.dip.t-dialin.net [84.137.237.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id AC767BEF1; Thu, 24 Sep 2009 14:36:13 +0200 (CEST) From: Carsten Bormann To: David Ryan In-Reply-To: <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> Message-Id: <2C0DF719-FED0-4DF0-89C7-5630F57B2938@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: Thu, 24 Sep 2009 14:36:12 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 12:35:15 -0000 David, thanks your for your input. I'll leave the discussion of Smart Energy timelines to Don for now. Let me just point out that in other places where we had to work with organizations with "impossible" timelines, we were able to do the finishing in parallel. E.g., consider the way ISA100 has now published ISA100.11a, while we are in parallel in the process of preparing for WGLC of 6lowpan-hc. For 6lowapp, the organizations making use of our results may not have to sit on their hands till Q3/Q4 2010. And we *do* need some time for that finishing. (I'm open to suggestions we can be faster than that, but the milestones sound right to my gut feeling.) > Also, it might be fair to add HomePlug to the Smart Energy v2.0 list > as that group has also > been involved. It actually does say on the agenda; we neglected to put that up in the charter outline text as well. Fixed in the current working draft. >> The goal of 6lowapp is to produce application protocol and >> application commissioning solutions suitable for providing us the web >> for resource constrained devices > > The initial paragraph discusses "application protocols" for the > "Wireless Embedded Internet", while other sections > discuss the "embedded web" and "web for resource constrained devices". > Is there a difference? Wireless Embedded Internet is a more general term, just as Internet is more general than Web (at least if you count the networked applications with the networking itself). The proposal is indeed to use the lessons of the Web to empower the Wireless Embedded Internet. We can work on reducing the number of terms here. >> This working group will not work on new content formats >> or encodings, nor the compression or adaptation of HTTP. (to be >> expanded) > > I realise there is a comment that this needs "to be expanded", so I > apologise for jumping > the gun. If the aim is to build the "embedded web" and not adapt > HTTP, does this suggest > that the draft submitted by Brian Frank (Chopan) is outside the scope > of the working group? Indeed, this is a little terse. I think Brian's work is very good input. The point here is that simply compressing HTTP (as in GZIP or something slightly better) does not cut it -- if the embedded node still has to process all the complexity of HTTP that is a problem. If your definition of "compressing" includes coming up with a simplified subset that still solves the important problems, the wording of this exclusion may sound wrong. > I'd also like to ask the rational for discarding the concept of new > content formats or encodings? > Assuming that a new format or encoding has benefits as defined by the > "Problem Statement and > Objectives", shouldn't it be within the scope to review and debate the > merits of such encodings? I think the 6lowapp application protocol needs to be format agnostic, just as MIME types have made HTTP format agnostic. Re standardizing another format/encoding: I have heard a lot of hesitation going into that from individuals interested in this work. The problem is not that there are too few formats. The issue is what are the right properties of the formats for different areas of application. Yes, some people like EXI in this regard, but it may not be our job to choose -- maybe just to elucidate. > To be open and clear to everyone on the list, I plan on submitting a > draft which incorporates what > many will consider a new encoding. The issue of data formats is also > mentioned here: > >> 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. I still think your draft may be good input to the requirements work (the "problem statement and objectives" deliverable). But we cannot take on standardization (i.e., a fourth deliverable) in this crowded space unless we have carved out a very specific set of requirements not covered yet. We won't manage that in time before the BOF, so it would be a mistake to include such a deliverable in the charter. (And thank you for the kind words on how important that new WG will be -- I do agree that this is an important point in time to step forward and act.) Gruesse, Carsten From d.sturek@att.net Thu Sep 24 06:22:35 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 335553A68FE for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 06:22:35 -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 X4kHghLg0SKB for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 06:22:34 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id F39653A6919 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 06:22:33 -0700 (PDT) Received: (qmail 26854 invoked from network); 24 Sep 2009 13:23:40 -0000 Received: from unknown (HELO Studio) (d.sturek@69.225.120.134 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 24 Sep 2009 13:23:40 -0000 X-YMail-OSG: Q6OeKlQVM1nOirWf_AKhelZHX7w3q_F6Nc0e9lTl95HpLuY3NPXfzkFs9_soDKefbZBRrpTb38gB3wRm6UtNqrlCMviSZhGtw3cuEmVj0giKTff0zXNHSTe4rBWyzix.UQcfcdhLdvF6X12INnc.ECAHbI8acekC3rjzym8sERw5OCrhi_Jn4QuD0PBEwRKBIhXe8A9d2tRHiQmorBZFwH89LmPfBVori6wlWxdtsykZthIgTEk7gOwzIc4dKqu8Gg5tkg0bhOPWQU1CCh.F_FlN6Fhao4DbhWjW5JP6n1dQWRGldpBQKMgGtJ2c0fz5WfU- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , "'David Ryan'" References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> <2C0DF719-FED0-4DF0-89C7-5630F57B2938@tzi.org> In-Reply-To: <2C0DF719-FED0-4DF0-89C7-5630F57B2938@tzi.org> Date: Thu, 24 Sep 2009 06:23:30 -0700 Message-ID: <006a01ca3d1a$35fc4650$a1f4d2f0$@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: Aco9E6JLaevCc/QmS/CsADTspdrPqAABNnhQ Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 13:22:35 -0000 Hi Carsten, Just a note on the timelines we are working to for the Smart Energy V2 work (includes work being done now in ZigBee and also HomePlug): 1) Specification drafts complete (including details on which standards, RFCs and I-Ds we use) - December 2009 2) Interop testing January 2010 - June 2010 3) Certification testing for first set of platforms/products - July 2010 - October 2010 4) Initial products deployed - Summer 2011 A few things to note: 1) Just as all internet features were not defined in one initial deployment, the same is true here. This is the start of deployment. 2) Not all deployments will look the same. We are designing to accommodate the lowest common denominator (IEEE 802.15.4) but we need to also consider devices with more processing capability and "Ethernet like" transfer capability. Whatever we build should enable full HTML/HTTP/XML in addition to compressed versions (meaning, new encodings need to also make their way into those standards if they are used) 3) For those interested, US NIST is publishing their Smart Grid roadmap (http://www.nist.gov/smartgrid/). This will give a bit better sense of where the larger effort is focused. There is a process now between NIST, the utilities and the stakeholders listed in the NIST reports to align on standards choices. As you can see, IETF plays a major role. 4) This is an international effort. ESMIG (http://www.esmig.eu/). Australia has many smart metering initiatives underway (don't have a link yet but our next member meeting is in 2 weeks in Melbourne so will update the group then). Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, September 24, 2009 5:36 AM To: David Ryan Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update David, thanks your for your input. I'll leave the discussion of Smart Energy timelines to Don for now. Let me just point out that in other places where we had to work with organizations with "impossible" timelines, we were able to do the finishing in parallel. E.g., consider the way ISA100 has now published ISA100.11a, while we are in parallel in the process of preparing for WGLC of 6lowpan-hc. For 6lowapp, the organizations making use of our results may not have to sit on their hands till Q3/Q4 2010. And we *do* need some time for that finishing. (I'm open to suggestions we can be faster than that, but the milestones sound right to my gut feeling.) > Also, it might be fair to add HomePlug to the Smart Energy v2.0 list > as that group has also > been involved. It actually does say on the agenda; we neglected to put that up in the charter outline text as well. Fixed in the current working draft. >> The goal of 6lowapp is to produce application protocol and >> application commissioning solutions suitable for providing us the web >> for resource constrained devices > > The initial paragraph discusses "application protocols" for the > "Wireless Embedded Internet", while other sections > discuss the "embedded web" and "web for resource constrained devices". > Is there a difference? Wireless Embedded Internet is a more general term, just as Internet is more general than Web (at least if you count the networked applications with the networking itself). The proposal is indeed to use the lessons of the Web to empower the Wireless Embedded Internet. We can work on reducing the number of terms here. >> This working group will not work on new content formats >> or encodings, nor the compression or adaptation of HTTP. (to be >> expanded) > > I realise there is a comment that this needs "to be expanded", so I > apologise for jumping > the gun. If the aim is to build the "embedded web" and not adapt > HTTP, does this suggest > that the draft submitted by Brian Frank (Chopan) is outside the scope > of the working group? Indeed, this is a little terse. I think Brian's work is very good input. The point here is that simply compressing HTTP (as in GZIP or something slightly better) does not cut it -- if the embedded node still has to process all the complexity of HTTP that is a problem. If your definition of "compressing" includes coming up with a simplified subset that still solves the important problems, the wording of this exclusion may sound wrong. > I'd also like to ask the rational for discarding the concept of new > content formats or encodings? > Assuming that a new format or encoding has benefits as defined by the > "Problem Statement and > Objectives", shouldn't it be within the scope to review and debate the > merits of such encodings? I think the 6lowapp application protocol needs to be format agnostic, just as MIME types have made HTTP format agnostic. Re standardizing another format/encoding: I have heard a lot of hesitation going into that from individuals interested in this work. The problem is not that there are too few formats. The issue is what are the right properties of the formats for different areas of application. Yes, some people like EXI in this regard, but it may not be our job to choose -- maybe just to elucidate. > To be open and clear to everyone on the list, I plan on submitting a > draft which incorporates what > many will consider a new encoding. The issue of data formats is also > mentioned here: > >> 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. I still think your draft may be good input to the requirements work (the "problem statement and objectives" deliverable). But we cannot take on standardization (i.e., a fourth deliverable) in this crowded space unless we have carved out a very specific set of requirements not covered yet. We won't manage that in time before the BOF, so it would be a mistake to include such a deliverable in the charter. (And thank you for the kind words on how important that new WG will be -- I do agree that this is an important point in time to step forward and act.) Gruesse, Carsten _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Thu Sep 24 06:33: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 B227E3A6830 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 06:33:02 -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 5Fstm1Tclppd for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 06:33:01 -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 47BEC28C0E1 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 06:33:01 -0700 (PDT) Received: (qmail 92995 invoked from network); 24 Sep 2009 13:34:07 -0000 Received: from unknown (HELO Studio) (d.sturek@69.225.120.134 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 24 Sep 2009 13:34:07 -0000 X-YMail-OSG: g9rChk4VM1meaExEdcDeypoTNblJK8ezyphMNwZ9aPitls4665B4pnIGUdHKRPV5tok53H5M6yGIwttLMqpzPubvqAl8k8wBKcnQKgwUQ.brhKUuO0ZchTJ3huuADNkXuDiZGFC3BsEGlPqk8yVa0eFYh_50ViF260jR99umjkNZwkHEL55pQOs5Yfn0suKVlbTu.PFm284BjisSoZE6dKnr5db4E7QbizvEPkBHIU8MCjBcUvdvy7OG6SLHlAxl4WEKnIeUJ0UW3Tpn09k8AvlGFjtvC3lTBKY8a7183QkMo44OK8aitf_BojKyw5cZNg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , "'David Ryan'" References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> <2C0DF719-FED0-4DF0-89C7-5630F57B2938@tzi.org> In-Reply-To: Date: Thu, 24 Sep 2009 06:33:57 -0700 Message-ID: <008001ca3d1b$ab937720$02ba6560$@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: Aco9E6JLaevCc/QmS/CsADTspdrPqAABNnhQAAC7JzA= Content-Language: en-us Cc: 6lowapp@ietf.org Subject: [6lowapp] UPDATED: BOF proposal: update 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, 24 Sep 2009 13:33:02 -0000 As soon as I sent this, NIST published their initial roadmap document for Smart Grid. IP and the IETF play a significant role in this work. Here is a link to the document: http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf Given IEEE 802.15.4 is a popular communications solution for the premise equipment, 6lowapp plays a key role in realizing this vision. Don -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: Thursday, September 24, 2009 6:24 AM To: 'Carsten Bormann'; 'David Ryan' Cc: '6lowapp@ietf.org' Subject: RE: [6lowapp] BOF proposal: update Hi Carsten, Just a note on the timelines we are working to for the Smart Energy V2 work (includes work being done now in ZigBee and also HomePlug): 1) Specification drafts complete (including details on which standards, RFCs and I-Ds we use) - December 2009 2) Interop testing January 2010 - June 2010 3) Certification testing for first set of platforms/products - July 2010 - October 2010 4) Initial products deployed - Summer 2011 A few things to note: 1) Just as all internet features were not defined in one initial deployment, the same is true here. This is the start of deployment. 2) Not all deployments will look the same. We are designing to accommodate the lowest common denominator (IEEE 802.15.4) but we need to also consider devices with more processing capability and "Ethernet like" transfer capability. Whatever we build should enable full HTML/HTTP/XML in addition to compressed versions (meaning, new encodings need to also make their way into those standards if they are used) 3) For those interested, US NIST is publishing their Smart Grid roadmap (http://www.nist.gov/smartgrid/). This will give a bit better sense of where the larger effort is focused. There is a process now between NIST, the utilities and the stakeholders listed in the NIST reports to align on standards choices. As you can see, IETF plays a major role. 4) This is an international effort. ESMIG (http://www.esmig.eu/). Australia has many smart metering initiatives underway (don't have a link yet but our next member meeting is in 2 weeks in Melbourne so will update the group then). Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, September 24, 2009 5:36 AM To: David Ryan Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update David, thanks your for your input. I'll leave the discussion of Smart Energy timelines to Don for now. Let me just point out that in other places where we had to work with organizations with "impossible" timelines, we were able to do the finishing in parallel. E.g., consider the way ISA100 has now published ISA100.11a, while we are in parallel in the process of preparing for WGLC of 6lowpan-hc. For 6lowapp, the organizations making use of our results may not have to sit on their hands till Q3/Q4 2010. And we *do* need some time for that finishing. (I'm open to suggestions we can be faster than that, but the milestones sound right to my gut feeling.) > Also, it might be fair to add HomePlug to the Smart Energy v2.0 list > as that group has also > been involved. It actually does say on the agenda; we neglected to put that up in the charter outline text as well. Fixed in the current working draft. >> The goal of 6lowapp is to produce application protocol and >> application commissioning solutions suitable for providing us the web >> for resource constrained devices > > The initial paragraph discusses "application protocols" for the > "Wireless Embedded Internet", while other sections > discuss the "embedded web" and "web for resource constrained devices". > Is there a difference? Wireless Embedded Internet is a more general term, just as Internet is more general than Web (at least if you count the networked applications with the networking itself). The proposal is indeed to use the lessons of the Web to empower the Wireless Embedded Internet. We can work on reducing the number of terms here. >> This working group will not work on new content formats >> or encodings, nor the compression or adaptation of HTTP. (to be >> expanded) > > I realise there is a comment that this needs "to be expanded", so I > apologise for jumping > the gun. If the aim is to build the "embedded web" and not adapt > HTTP, does this suggest > that the draft submitted by Brian Frank (Chopan) is outside the scope > of the working group? Indeed, this is a little terse. I think Brian's work is very good input. The point here is that simply compressing HTTP (as in GZIP or something slightly better) does not cut it -- if the embedded node still has to process all the complexity of HTTP that is a problem. If your definition of "compressing" includes coming up with a simplified subset that still solves the important problems, the wording of this exclusion may sound wrong. > I'd also like to ask the rational for discarding the concept of new > content formats or encodings? > Assuming that a new format or encoding has benefits as defined by the > "Problem Statement and > Objectives", shouldn't it be within the scope to review and debate the > merits of such encodings? I think the 6lowapp application protocol needs to be format agnostic, just as MIME types have made HTTP format agnostic. Re standardizing another format/encoding: I have heard a lot of hesitation going into that from individuals interested in this work. The problem is not that there are too few formats. The issue is what are the right properties of the formats for different areas of application. Yes, some people like EXI in this regard, but it may not be our job to choose -- maybe just to elucidate. > To be open and clear to everyone on the list, I plan on submitting a > draft which incorporates what > many will consider a new encoding. The issue of data formats is also > mentioned here: > >> 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. I still think your draft may be good input to the requirements work (the "problem statement and objectives" deliverable). But we cannot take on standardization (i.e., a fourth deliverable) in this crowded space unless we have carved out a very specific set of requirements not covered yet. We won't manage that in time before the BOF, so it would be a mistake to include such a deliverable in the charter. (And thank you for the kind words on how important that new WG will be -- I do agree that this is an important point in time to step forward and act.) Gruesse, Carsten _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From oobles@gmail.com Thu Sep 24 06:58: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 06D023A68FE for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 06:58:57 -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 hCKkAou5dCPP for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 06:58:55 -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 222113A6817 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 06:58:54 -0700 (PDT) Received: by ewy28 with SMTP id 28so2284534ewy.42 for <6lowapp@ietf.org>; Thu, 24 Sep 2009 07:00:00 -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=HnmMAo2ShBdaE+ykB7emusaDlmEawGs6zx+txd2PQzQ=; b=T1My8xCdMvOThGmWNUMBy/zsYZxmgYMCuTTn/9/3vln79oflvjhkJplzRcGkdyUP4m TtWTy8ozcaT8Y+J+3zoHtaOUC7b4WGhyFoAUecn+qGzJYgpjT2JuTV4fGqzyXxD3flPV WgfEnn7gWbpSve8LdlOcDBgw0HaxO0b77TL1Y= 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=krGwuMnFiC5kDNuTkZbA0BpsCRPBT5hqJU6HTiZEhIge70ki/iw/lZncIjZz7LJYXR YYxxS9/VA8s+rwZoTxm83P+rhO5o3KCFB+ZD4FokUMaMtjo04H3lZT3Vx9V5AcSi0cmX ia7tS7tPsS0VWAmlflUWQ2eH6IkYXYfFU2+y8= MIME-Version: 1.0 Received: by 10.211.142.11 with SMTP id u11mr4155706ebn.8.1253800799865; Thu, 24 Sep 2009 06:59:59 -0700 (PDT) In-Reply-To: <6820143332594836442@unknownmsgid> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> <2C0DF719-FED0-4DF0-89C7-5630F57B2938@tzi.org> <6820143332594836442@unknownmsgid> Date: Thu, 24 Sep 2009 23:59:59 +1000 Message-ID: <7f996c490909240659r5937b527s24316c7ad55f7f4f@mail.gmail.com> From: David Ryan To: d.sturek@att.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 13:58:57 -0000 Hi Don, Thanks for providing the details on the Smart Energy V2 work. I had seen these dates but did not feel I had adequate authority to publish them here. Obviously the timeline looks compressed when viewed with the Smart Energy decisions. ie BoF I-D by 2009-10-19, the BOF in November and decisions on which standards are used in December. It's important people are aware of this when preparing to submit I-Ds on this list. In regards to Australia, information on the national program can be found a= t: http://www.aemo.com.au/electricityops/smartmeter.html Also, Melbourne (where the next ZigBee meeting is being held) has programs already started with companies gearing up to roll out smart meters now. The HAN is an important part of the Australian programs with requirements to use ZigBee Smart Energy Profile. Regards, David. On Thu, Sep 24, 2009 at 11:23 PM, Don Sturek wrote: > Hi Carsten, > > Just a note on the timelines we are working to for the Smart Energy V2 wo= rk > (includes work being done now in ZigBee and also HomePlug): > 1) =A0 Specification drafts complete (including details on which standard= s, > RFCs and I-Ds we use) - December 2009 > 2) =A0 Interop testing January 2010 - June 2010 > 3) =A0 Certification testing for first set of platforms/products - July 2= 010 - > October 2010 > 4) =A0 Initial products deployed - Summer 2011 > > A few things to note: > 1) =A0Just as all internet features were not defined in one initial > deployment, the same is true here. =A0 This is the start of deployment. > 2) =A0Not all deployments will look the same. =A0 We are designing to > accommodate the lowest common denominator (IEEE 802.15.4) but we need to > also consider devices with more processing capability and "Ethernet like" > transfer capability. =A0Whatever we build should enable full HTML/HTTP/XM= L in > addition to compressed versions (meaning, new encodings need to also make > their way into those standards if they are used) > 3) =A0For those interested, US NIST is publishing their Smart Grid roadma= p > (http://www.nist.gov/smartgrid/). =A0This will give a bit better sense of > where the larger effort is focused. =A0There is a process now between NIS= T, > the utilities and the stakeholders listed in the NIST reports to align on > standards choices. =A0As you can see, IETF plays a major role. > 4) =A0This is an international effort. =A0ESMIG (http://www.esmig.eu/). > Australia has many smart metering initiatives underway (don't have a link > yet but our next member meeting is in 2 weeks in Melbourne so will update > the group then). > > Don > > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behal= f > Of Carsten Bormann > Sent: Thursday, September 24, 2009 5:36 AM > To: David Ryan > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] BOF proposal: update > > David, > > thanks your for your input. > > I'll leave the discussion of Smart Energy timelines to Don for now. > Let me just point out that in other places where we had to work with > organizations with "impossible" timelines, we were able to do the > finishing in parallel. =A0E.g., consider the way ISA100 has now > published ISA100.11a, while we are in parallel in the process of > preparing for WGLC of 6lowpan-hc. > For 6lowapp, the organizations making use of our results may not have > to sit on their hands till Q3/Q4 2010. > And we *do* need some time for that finishing. > (I'm open to suggestions we can be faster than that, but the > milestones sound right to my gut feeling.) > >> Also, it might be fair to add HomePlug to the Smart Energy v2.0 list >> as that group has also >> been involved. > > It actually does say on the agenda; we neglected to put that up in the > charter outline text as well. =A0Fixed in the current working draft. > >>> The goal of 6lowapp is to produce application protocol and >>> application commissioning solutions suitable for providing us the web >>> for resource constrained devices >> >> The initial paragraph discusses "application protocols" for the >> "Wireless Embedded Internet", while other sections >> discuss the "embedded web" and "web for resource constrained devices". >> Is there a difference? > > Wireless Embedded Internet is a more general term, just as Internet is > more general than Web (at least if you count the networked > applications with the networking itself). > The proposal is indeed to use the lessons of the Web to empower the > Wireless Embedded Internet. > We can work on reducing the number of terms here. > >>> This working group will not work on new content formats >>> or encodings, nor the compression or adaptation of HTTP. (to be >>> expanded) >> >> I realise there is a comment that this needs "to be expanded", so I >> apologise for jumping >> the gun. =A0If the aim is to build the "embedded web" and not adapt >> HTTP, does this suggest >> that the draft submitted by Brian Frank (Chopan) is outside the scope >> of the working group? > > Indeed, this is a little terse. =A0I think Brian's work is very good > input. > The point here is that simply compressing HTTP (as in GZIP or > something slightly better) does not cut it -- if the embedded node > still has to process all the complexity of HTTP that is a problem. =A0If > your definition of "compressing" includes coming up with a simplified > subset that still solves the important problems, the wording of this > exclusion may sound wrong. > >> I'd also like to ask the rational for discarding the concept of new >> content formats or encodings? >> Assuming that a new format or encoding has benefits as defined by the >> "Problem Statement and >> Objectives", shouldn't it be within the scope to review and debate the >> merits of such encodings? > > I think the 6lowapp application protocol needs to be format agnostic, > just as MIME types have made HTTP format agnostic. > > Re standardizing another format/encoding: > I have heard a lot of hesitation going into that from individuals > interested in this work. > The problem is not that there are too few formats. > The issue is what are the right properties of the formats for > different areas of application. > Yes, some people like EXI in this regard, but it may not be our job to > choose -- maybe just to elucidate. > >> To be open and clear to everyone on the list, I plan on submitting a >> draft which incorporates what >> many will consider a new encoding. =A0The issue of data formats is also >> mentioned here: >> >>> 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. > > I still think your draft may be good input to the requirements work > (the "problem statement and objectives" deliverable). > But we cannot take on standardization (i.e., a fourth deliverable) in > this crowded space unless we have carved out a very specific set of > requirements not covered yet. We won't manage that in time before the > BOF, so it would be a mistake to include such a deliverable in the > charter. > > (And thank you for the kind words on how important that new WG will be > -- I do agree that this is an important point in time to step forward > and act.) > > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > From d.sturek@att.net Thu Sep 24 07:22: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 A45C928C130 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 wEnJAiHaFaR9 for <6lowapp@core3.amsl.com>; Thu, 24 Sep 2009 07:22:17 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id 2854328C12F for <6lowapp@ietf.org>; Thu, 24 Sep 2009 07:22:17 -0700 (PDT) Received: (qmail 43830 invoked from network); 24 Sep 2009 14:23:24 -0000 Received: from unknown (HELO Studio) (d.sturek@69.225.120.134 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 24 Sep 2009 14:23:23 -0000 X-Yahoo-SMTP: RL.ukv2swBCmFOHc.o9VWIAUOOfGTiu9CJTsFEQ- X-YMail-OSG: ujSOmY0VM1lRTcldAwBAYV3J.ziap4W30n4lifDvuaJ7wxPH.DaJnGIslXiL33S3fYv9J5LHDgUfi99rIE2UfdhA.ZaXMlqwHdLujjlZ9RSKLbxYvmTG761nLCxxCz033fUGlFFe1II8g6V2U0KeiJ.trWKoO2f2RGXU8Xf8vq_QBS7cswjQSfloZwYcTryVvi2OW1h5ldzU0gdzNrH9kZyRBr2L18v3uhafK.JBdChZOYFLqhlqLwwOyHVq9Mc- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'David Ryan'" References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7f996c490909240443j4febd212m5e841c973138b04@mail.gmail.com> <2C0DF719-FED0-4DF0-89C7-5630F57B2938@tzi.org> <6820143332594836442@unknownmsgid> <7f996c490909240659r5937b527s24316c7ad55f7f4f@mail.gmail.com> In-Reply-To: <7f996c490909240659r5937b527s24316c7ad55f7f4f@mail.gmail.com> Date: Thu, 24 Sep 2009 07:23:13 -0700 Message-ID: <009801ca3d22$8d7fb620$a87f2260$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco9H07fcDwkVFRFSsiEkMa6M1mZfQAALHnw Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 24 Sep 2009 14:22:18 -0000 Hi David, Thanks for the input on the Australia smart metering programs. Here is the motivation for the schedule: 1) Many regulated US utilities have approved rate cases for smart = metering that require deployments now. For those not familiar with regulated US utilities, here is the process: a. Utility must file with their public utility commission (PUC) requesting rate hikes for particular purchasing and services. If the = PUC approves, the utility bills the customer to raise the requested revenue = then is obligated to deploy the solution b. Many of these requests happened several years ago and resulted in the Smart Energy V1 solution. That solution did not gain enough = backing from all utilities to be a standard (or de-facto standard). c. The smart metering deployments, many cases, were to address = the fact that not enough generating capacity was being built. The recession helped reduce electric usage but there is a growing gap in what can be provided versus peak demand. On average, it is 10 years from start to commissioning to get a new plant online. Smart metering is really a = MUST for utilities in this situation (there is a good report from Cap Gemini outlining this issue) d. Energy self sufficiency (wind power, solar power, plug in electric vehicles, distributed storage) require deployment of smart = meters. e. With the US stimulus, NIST became involved (through the US Congress) to identify (or enable establishment of) standards for Smart = Grid (hence the report I forwarded) f. Now with the standards targets in place and the schedule drivers in place, here we are! >From our perspective (Smart Energy V2), we think there are a few key = missing standards for product deployment in 2011: 1) Embedded web services. The proposals on compressed HTTP and Argot = are quite important. The IEC standards listed in the NIST report are = generally large static data models (in UML). We are planning to view the data exchange as XML which should be general enough for use by many = additional higher level services and can be compressed with tokenized XML solutions (like EXI which would be out of scope for IETF). 2) Service Discovery. Need a way for small devices to discover complementary services available in their surroundings. I am in the = process of writing something up as an enhancement to SLP (I did find the = embedded SLP but that didn't appear to solve the problem) 3) Security. Need security services which work (both in terms of data exchange and processing) for small footprint devices like those found in = the HAN. See also the section in the NIST report on Cyber security. This "small footprint" security needs to also integrate with IETF security as deployed in larger systems today. The above I would list as the immediate needs. I would expect the = solutions deployed in the future to look quite a bit different as new standards = emerge and are deployed. Don -----Original Message----- From: David Ryan [mailto:oobles@gmail.com]=20 Sent: Thursday, September 24, 2009 7:00 AM To: d.sturek@att.net Cc: Carsten Bormann; 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update Hi Don, Thanks for providing the details on the Smart Energy V2 work. I had seen these dates but did not feel I had adequate authority to publish them here. Obviously the timeline looks compressed when viewed with the Smart Energy decisions. ie BoF I-D by 2009-10-19, the BOF in November and decisions on which standards are used in December. It's important people are aware of this when preparing to submit I-Ds on this list. In regards to Australia, information on the national program can be = found at: http://www.aemo.com.au/electricityops/smartmeter.html Also, Melbourne (where the next ZigBee meeting is being held) has = programs already started with companies gearing up to roll out smart meters now. The HAN is an important part of the Australian programs with requirements to use ZigBee Smart Energy Profile. Regards, David. On Thu, Sep 24, 2009 at 11:23 PM, Don Sturek wrote: > Hi Carsten, > > Just a note on the timelines we are working to for the Smart Energy V2 work > (includes work being done now in ZigBee and also HomePlug): > 1) =A0 Specification drafts complete (including details on which = standards, > RFCs and I-Ds we use) - December 2009 > 2) =A0 Interop testing January 2010 - June 2010 > 3) =A0 Certification testing for first set of platforms/products - = July 2010 - > October 2010 > 4) =A0 Initial products deployed - Summer 2011 > > A few things to note: > 1) =A0Just as all internet features were not defined in one initial > deployment, the same is true here. =A0 This is the start of = deployment. > 2) =A0Not all deployments will look the same. =A0 We are designing to > accommodate the lowest common denominator (IEEE 802.15.4) but we need = to > also consider devices with more processing capability and "Ethernet = like" > transfer capability. =A0Whatever we build should enable full = HTML/HTTP/XML in > addition to compressed versions (meaning, new encodings need to also = make > their way into those standards if they are used) > 3) =A0For those interested, US NIST is publishing their Smart Grid = roadmap > (http://www.nist.gov/smartgrid/). =A0This will give a bit better sense = of > where the larger effort is focused. =A0There is a process now between = NIST, > the utilities and the stakeholders listed in the NIST reports to align = on > standards choices. =A0As you can see, IETF plays a major role. > 4) =A0This is an international effort. =A0ESMIG = (http://www.esmig.eu/). > Australia has many smart metering initiatives underway (don't have a = link > yet but our next member meeting is in 2 weeks in Melbourne so will = update > the group then). > > Don > > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf > Of Carsten Bormann > Sent: Thursday, September 24, 2009 5:36 AM > To: David Ryan > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] BOF proposal: update > > David, > > thanks your for your input. > > I'll leave the discussion of Smart Energy timelines to Don for now. > Let me just point out that in other places where we had to work with > organizations with "impossible" timelines, we were able to do the > finishing in parallel. =A0E.g., consider the way ISA100 has now > published ISA100.11a, while we are in parallel in the process of > preparing for WGLC of 6lowpan-hc. > For 6lowapp, the organizations making use of our results may not have > to sit on their hands till Q3/Q4 2010. > And we *do* need some time for that finishing. > (I'm open to suggestions we can be faster than that, but the > milestones sound right to my gut feeling.) > >> Also, it might be fair to add HomePlug to the Smart Energy v2.0 list >> as that group has also >> been involved. > > It actually does say on the agenda; we neglected to put that up in the > charter outline text as well. =A0Fixed in the current working draft. > >>> The goal of 6lowapp is to produce application protocol and >>> application commissioning solutions suitable for providing us the = web >>> for resource constrained devices >> >> The initial paragraph discusses "application protocols" for the >> "Wireless Embedded Internet", while other sections >> discuss the "embedded web" and "web for resource constrained = devices". >> Is there a difference? > > Wireless Embedded Internet is a more general term, just as Internet is > more general than Web (at least if you count the networked > applications with the networking itself). > The proposal is indeed to use the lessons of the Web to empower the > Wireless Embedded Internet. > We can work on reducing the number of terms here. > >>> This working group will not work on new content formats >>> or encodings, nor the compression or adaptation of HTTP. (to be >>> expanded) >> >> I realise there is a comment that this needs "to be expanded", so I >> apologise for jumping >> the gun. =A0If the aim is to build the "embedded web" and not adapt >> HTTP, does this suggest >> that the draft submitted by Brian Frank (Chopan) is outside the scope >> of the working group? > > Indeed, this is a little terse. =A0I think Brian's work is very good > input. > The point here is that simply compressing HTTP (as in GZIP or > something slightly better) does not cut it -- if the embedded node > still has to process all the complexity of HTTP that is a problem. = =A0If > your definition of "compressing" includes coming up with a simplified > subset that still solves the important problems, the wording of this > exclusion may sound wrong. > >> I'd also like to ask the rational for discarding the concept of new >> content formats or encodings? >> Assuming that a new format or encoding has benefits as defined by the >> "Problem Statement and >> Objectives", shouldn't it be within the scope to review and debate = the >> merits of such encodings? > > I think the 6lowapp application protocol needs to be format agnostic, > just as MIME types have made HTTP format agnostic. > > Re standardizing another format/encoding: > I have heard a lot of hesitation going into that from individuals > interested in this work. > The problem is not that there are too few formats. > The issue is what are the right properties of the formats for > different areas of application. > Yes, some people like EXI in this regard, but it may not be our job to > choose -- maybe just to elucidate. > >> To be open and clear to everyone on the list, I plan on submitting a >> draft which incorporates what >> many will consider a new encoding. =A0The issue of data formats is = also >> mentioned here: >> >>> 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. > > I still think your draft may be good input to the requirements work > (the "problem statement and objectives" deliverable). > But we cannot take on standardization (i.e., a fourth deliverable) in > this crowded space unless we have carved out a very specific set of > requirements not covered yet. We won't manage that in time before the > BOF, so it would be a mistake to include such a deliverable in the > charter. > > (And thank you for the kind words on how important that new WG will be > -- I do agree that this is an important point in time to step forward > and act.) > > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > From brian.tridium@gmail.com Mon Sep 28 11:03: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 E8BD83A6949 for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 11:03:07 -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 u6fCIEOIB6Yy for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 11:03:04 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 7493E3A6966 for <6lowapp@ietf.org>; Mon, 28 Sep 2009 11:03:03 -0700 (PDT) Received: by bwz6 with SMTP id 6so1456053bwz.37 for <6lowapp@ietf.org>; Mon, 28 Sep 2009 11:04:18 -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=6RRfR7dDtVX2m8nbX684AV5ZMgJVayIc814LDahSQ3c=; b=mPGAnPHeFq3XN4/HHPz+Du97MjnVlABPOVHgSVMHPIJy3swt+ksBngGgDv2z4uijua YHnVLGAc8KDkOq4lnJU4l1rMflWUfmGsWcwGh3Ka8pRBPPzY3qBc1x8i/XpPoIUEG+b3 IhXf4+MJX9oZ6Z9s1CstuKvpgDXCBxZ87H0Iw= 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+qvLY0iKQZGNV0RLtp+o8i05g61Oa6UkyQE7wdZnAhxwASN98hti4KftZW0EbYHcB 85+ZzGKoDXi0FvOhVFR+ptAxBF2PAfdsp1NN4deWVkMSP/7HpzFjiFzQO6d6L67qpJk+ ng5LO6rsk+JnkzZecZlsQqjI1j0DAQe3o9AT8= MIME-Version: 1.0 Received: by 10.204.154.144 with SMTP id o16mr3204357bkw.213.1254161058663; Mon, 28 Sep 2009 11:04:18 -0700 (PDT) In-Reply-To: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> Date: Mon, 28 Sep 2009 14:04:18 -0400 Message-ID: <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> From: Brian Frank To: Carsten Bormann Content-Type: multipart/alternative; boundary=0015175cb40a648f4f0474a72009 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 18:03:08 -0000 --0015175cb40a648f4f0474a72009 Content-Type: text/plain; charset=ISO-8859-1 Couple of my thoughts to echo what some others have said: - I believe the application protocol should be format agnostic. I suspect that it will be difficult to achieve consensus on data formats. I am not sure how that might limit the scope of 6lowapp, but certainly I hope that a debate on formats doesn't derail the transport protocol itself - I personally believe that naming should be based on URIs; however it seems as this is already presumed as a requirement? - just to echo what David said, I read the BOF to say that adaption of HTTP (as proposed by myself) is off the table. But I think the intent was just that we must define some subset of REST functionality can be implemented efficiently? - sleeping nodes are mentioned a couple times already, but I'd just like to re-iterate that I believe sleeping nodes are perhaps the most important problem space for 6lowapp (or least a peer to the problem space of computing/memory/bandwidth constraints) Brian On Thu, Sep 24, 2009 at 3:39 AM, Carsten Bormann wrote: > We used the last week to discuss the BOF proposal with our responsible > AD and with people from other standards groups. > > The result is a revised BOF proposal, that already provides an outline > for the charter of the new WG. This charter now defines a more > specific focus for the WG til the end of 2010. I think that is good > because the IETF is much better in handling focused, specific work > items than in grand, boil-the-ocean efforts. If we succeed, we can > always recharter to attack additional items. > > A bit more background: The goal of this BOF proposal is to get a BOF > going in Hiroshima, the week of Nov 9. The goal of the BOF is to > demonstrate that we have enough interest ("energy") and enough focus > to solve a credible problem in a defined amount of time; this will > enable us to charter a WG following the BOF. Not all of you will be > physically present in Hiroshima; that's another reason why it is > important to hear your opinions on this mailing list. The charter > proposal can and will change until Hiroshima, and now is the time to > influence it and to express your support. Also, the IETF is generally > driven by Internet-Draft documents, so it would be good to hear on the > list what you will be able to contribute. > --0015175cb40a648f4f0474a72009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Couple of my thoughts to echo what some others have said:

- I believe the application protocol should be format agnostic. =A0I susp= ect that it will be=A0difficult to achieve consensus on=A0data formats. I a= m not sure how that might limit the scope of 6lowapp, but certainly I hope = that a debate on formats doesn't derail the transport protocol itself

- I personally believe that naming should be based on U= RIs; however it seems as this is already presumed as a requirement?=A0

- just to echo what David said, I read the BOF to say = that adaption of HTTP (as proposed by myself) is off the table. =A0But I th= ink the intent was just that we must define some subset of REST functionali= ty can be implemented efficiently?

- sleeping nodes are mentioned a couple times already, = but I'd just like to re-iterate that I believe sleeping nodes are perha= ps the most important problem space for 6lowapp (or least a peer to the pro= blem space of computing/memory/bandwidth constraints)

Brian


On T= hu, Sep 24, 2009 at 3:39 AM, Carsten Bormann <cabo@tzi.org> wrote:
We used the last week to discuss the BOF proposal with our responsible
AD and with people from other standards groups.

The result is a revised BOF proposal, that already provides an outline
for the charter of the new WG. =A0This charter now defines a more
specific focus for the WG til the end of 2010. =A0I think that is good
because the IETF is much better in handling focused, specific work
items than in grand, boil-the-ocean efforts. =A0If we succeed, we can
always recharter to attack additional items.

A bit more background: The goal of this BOF proposal is to get a BOF
going in Hiroshima, the week of Nov 9. =A0The goal of the BOF is to
demonstrate that we have enough interest ("energy") and enough fo= cus
to solve a credible problem in a defined amount of time; this will
enable us to charter a WG following the BOF. =A0Not all of you will be
physically present in Hiroshima; that's another reason why it is
important to hear your opinions on this mailing list. =A0The charter
proposal can and will change until Hiroshima, and now is the time to
influence it and to express your support. =A0Also, the IETF is generally driven by Internet-Draft documents, so it would be good to hear on the
list what you will be able to contribute.

--0015175cb40a648f4f0474a72009-- From vieuxtech@gmail.com Mon Sep 28 12:27:32 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 966173A691C for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 12:27:32 -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 nEQIP4kDxP8Z for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 12:27:31 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id DC8E43A67B3 for <6lowapp@ietf.org>; Mon, 28 Sep 2009 12:27:31 -0700 (PDT) Received: by pzk35 with SMTP id 35so4272283pzk.29 for <6lowapp@ietf.org>; Mon, 28 Sep 2009 12:28: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:content-type; bh=dRm0ao46GlQd2vyzTImnD6vY88BDnbpbK6L3hqs+Q0E=; b=mBeo50v8hhDJEaZctY1OzJ8pzzBNWiydCy2PGi9gDVDilawVrAbyP3ukpqIt2SUONu 8LCeehyvQKI0piDBGzMbPAobvxbCcOnwbCeH4CVxhJVLP70p7K19g7agzxhGjzLt0ujh PslhYT06sy1lWTMDJjBlwSSxrFvAOWE/DgnJU= 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=G9XwqfgHrCgAgYsqizHN92pcy0E3ju39quyhcd5SheUnkQNIFbZ7+65O+Y97NMejIm jXZrLmD5784q6kr07uFsxZ4i7CCkOfYzPBJALLWIFfYzLlN1RQRtTuOf7udCk1ySV4i3 8y/T2INcYJzn7+3U11KHVyr2gfOmrQVGPJnL0= MIME-Version: 1.0 Received: by 10.143.154.14 with SMTP id g14mr282633wfo.266.1254166128536; Mon, 28 Sep 2009 12:28:48 -0700 (PDT) In-Reply-To: <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> Date: Mon, 28 Sep 2009 12:28:48 -0700 Message-ID: <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com> From: Sam Roberts To: 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 19:27:32 -0000 On Mon, Sep 28, 2009 at 11:04 AM, Brian Frank wrote: > Couple of my thoughts to echo what some others have said: > - I believe the application protocol should be format agnostic. I suspect > that it will be difficult to achieve consensus on data formats. I am not > sure how that might limit the scope of 6lowapp, but certainly I hope that a > debate on formats doesn't derail the transport protocol itself I share the hope that format discussions won't bog things down. Perhaps I misunderstand what you mean by "format agnostic", won't non-specification of such an important aspect prevent independantly developed implementations of the protocol from interoperating? > - I personally believe that naming should be based on URIs; however it seems > as this is already presumed as a requirement? Have I missed discussion of this, or has rehosting the zigbee application support layer and cluster library on top of IPv6 over 802.15.4 already been discussed and/or discarded as a possibility? A profile supporting RESTful URI based request/response could exit at a zigbee endpoint. Cheers, Sam From d.sturek@att.net Mon Sep 28 13:30: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 5F7383A6A0E for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 13:30:46 -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 MNtwd4LCu4jJ for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 13:30:45 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 772073A691E for <6lowapp@ietf.org>; Mon, 28 Sep 2009 13:30:45 -0700 (PDT) Received: (qmail 61090 invoked from network); 28 Sep 2009 20:32:02 -0000 Received: from unknown (HELO Studio) (d.sturek@12.50.112.194 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 28 Sep 2009 20:32:02 -0000 X-YMail-OSG: fpwx3MkVM1kAXTlo7ctZjdgZUKq67bKi1CynOkcqCO3cY2wY3su1zpvruAEO8S2fSGvBOQmeQmHHbNTOKTagtmCGg5HaalilMektlZAUKXLFgFJvK1RVpu4J3Wir9wwAUxi5EjXLwC9A87L9tj6VYI9q8IhFau6Ja9eY5iTy6wZTyPTeV1ckUBJt58isltnfQpVJMfSiZBbX0LhxzNPKsPkMqGXrcZ9lcuUlXt1NMcGFtTURUkDPRJ1tWUmjU_pU0xAC8_ZtMCBjJGQucICMUJWzHfc6FkjzxWKhtVOijQnoGBEea48_KjgmRIu8WJGk.g-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Sam Roberts'" , <6lowapp@ietf.org> References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com> In-Reply-To: <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com> Date: Mon, 28 Sep 2009 13:32:00 -0700 Message-ID: <017e01ca407a$bbc4b8e0$334e2aa0$@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: AcpAcernbLy6XNeiS0ChDAWRxzmvHAAB1r/A Content-Language: en-us Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 20:30:46 -0000 Hi Sam, The plan in ZigBee Smart Energy V2 is not to rehost the current ZigBee Smart Energy application messaging overtop the IP stack. Work is currently underway to extend the IEC TC57 CIM for the Smart Energy V2 use cases. The CIM is a static data model using UML. The message exchange will be defined as XML (probably) or possibly ASN.1 (at least, some standard self describing protocol). Since we have very small packet sizes using IEEE 802.15.4, we need to use some standard encoding method (like tokenized XML method, which I think is out of scope of IETF) and some efficient embedded web services delivery (which I think should be in scope for IETF). We also need a service discovery method which aligns with the use of the encoding method we use (XML or ASN.1 or ??). I agree with the statement that the 6LowAPP application protocol should be format agnostic. It would be good to see that various encodings are supported and that the XML encoding/embedded web services/binary service discovery defined by 6LowAPP could be transparently used in conjunction with full XML (or other self describing protocol)/current web services protocols/full XML based service discovery for those devices holding the schema and willing to expand/compress for communication with small footprint devices. I think we have most of the communications layers defined to support this, now needing the application support. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Sam Roberts Sent: Monday, September 28, 2009 12:29 PM To: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update On Mon, Sep 28, 2009 at 11:04 AM, Brian Frank wrote: > Couple of my thoughts to echo what some others have said: > - I believe the application protocol should be format agnostic. I suspect > that it will be difficult to achieve consensus on data formats. I am not > sure how that might limit the scope of 6lowapp, but certainly I hope that a > debate on formats doesn't derail the transport protocol itself I share the hope that format discussions won't bog things down. Perhaps I misunderstand what you mean by "format agnostic", won't non-specification of such an important aspect prevent independantly developed implementations of the protocol from interoperating? > - I personally believe that naming should be based on URIs; however it seems > as this is already presumed as a requirement? Have I missed discussion of this, or has rehosting the zigbee application support layer and cluster library on top of IPv6 over 802.15.4 already been discussed and/or discarded as a possibility? A profile supporting RESTful URI based request/response could exit at a zigbee endpoint. Cheers, Sam _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From nicolas.riou@fr.schneider-electric.com Mon Sep 28 13:40: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 DBEC33A63EC for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UbbmsRyWGzwT for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 13:40:05 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id 96EFC3A691E for <6lowapp@ietf.org>; Mon, 28 Sep 2009 13:40:05 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2009092822412049-25632 ; Mon, 28 Sep 2009 22:41:20 +0200 To: 6lowapp@ietf.org MIME-Version: 1.0 Sensitivity: X-Priority: 3 (Normal) X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: nicolas.riou@fr.schneider-electric.com Date: Mon, 28 Sep 2009 22:31:18 +0200 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 28/09/2009 22:41:23, Serialize complete at 28/09/2009 22:41:23, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 09/28/2009 10:41:20 PM, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 09/28/2009 10:41:22 PM, Serialize complete at 09/28/2009 10:41:22 PM Content-Type: multipart/alternative; boundary="=_alternative 0071A57BC125763F_=" Subject: [6lowapp] BOF proposal: update 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, 28 Sep 2009 20:40:07 -0000 Message en plusieurs parties au format MIME --=_alternative 0071A57BC125763F_= Content-Type: text/plain; charset="US-ASCII" Hi Carsten and al, I have a few remarks/suggestions to complement the BOF proposal. I would like to emphasize on the need for seamless integration of up-and-coming architectures and Web Services. > Description: > ... > 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. In the world of wireline embedded solution, the Device Profile for Web Services (DPWS) is now a recognized OASIS standard to provide low cost SOA solution at the device level, providing a complete solution both at the application protocol level and at the commissioning level. In the wireless world, the DPWS solution can be used in conjunction with Binary XML encoding solutions such as EXI. > 6lowapp WG Charter Outline: > --------------------------- > * This working group will not work on new content formats > or encodings, nor the compression or adaptation of HTTP. (to be expanded) ...but does not exclude considering standardized binary XML solutions to compress messages. > 2. Application protocol: > ... > -- Features will include e.g. support for URLs, content types and > encodings, PULL and PUSH interaction models, basic REST methods, > both UDP and TCP, a simple form of cachability, and statelessness. Eventing is also important, e.g. WS-eventing (as provided by DPWS) using SOAP over UDP and Binary XML encoding. > -- Proxying with HTTP and SNMP must be straightforward. Proposal: -- Proxying with HTTP, SNMP and WS-Management must be straightforward. SNMP, despite a large installed based will likely decline in new architectures and will be replaced by new protocols like WS-Management. Seamless integration of WS-Management must be considered. > 3. Application commissioning: > ... > -- Proxying with IP service discovery protocols such as SLP, SSDP or > DNS-SD must be straightforward. Proposal: -- Proxying with IP service discovery protocols such as SLP, SSDP or DNS-SD or WS-Discovery as provided by DPWS must be straightforward. Looking forward for your feedback. Nicolas --=_alternative 0071A57BC125763F_= Content-Type: text/html; charset="US-ASCII"
Hi Carsten and al,

I have a few remarks/suggestions to complement the BOF proposal.
I would like to emphasize on the need for seamless integration of up-and-coming architectures and Web Services.

> Description:
> ...
> 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.
In the world of wireline embedded solution, the Device Profile for Web
Services (DPWS) is now a recognized OASIS standard to provide low cost
SOA solution at the device level, providing a complete solution both at
the application protocol level and at the commissioning level.
In the wireless world, the DPWS solution can be used in conjunction with
Binary XML encoding solutions such as EXI.


> 6lowapp WG Charter Outline:
> ---------------------------
> * This working group will not work on new content formats
>   or encodings, nor the compression or adaptation of HTTP. (to be expanded)
...but does not exclude considering standardized binary XML solutions to compress messages.


> 2. Application protocol:
>  ...
>   -- Features will include e.g. support for URLs, content types and
>      encodings, PULL and PUSH interaction models, basic REST methods,
>      both UDP and TCP, a simple form of cachability, and statelessness.
Eventing is also important, e.g. WS-eventing (as provided by DPWS) using SOAP over UDP and Binary XML encoding.


>   -- Proxying with HTTP and SNMP must be straightforward.
Proposal:
   -- Proxying with HTTP, SNMP and WS-Management must be straightforward.

SNMP, despite a large installed based will likely decline in new architectures and will be replaced by new protocols like WS-Management. Seamless integration of WS-Management must be considered.

>  3. Application commissioning:
>  ...
>    -- Proxying with IP service discovery protocols such as SLP, SSDP or
>    DNS-SD must be straightforward.
Proposal:
     -- Proxying with IP service discovery protocols such as SLP, SSDP or
     DNS-SD or WS-Discovery as provided by DPWS must be straightforward.

Looking forward for your feedback.
Nicolas



--=_alternative 0071A57BC125763F_=-- From zach@sensinode.com Mon Sep 28 14:41: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 3BE463A6852 for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:41:10 -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 A-RIO39+mOIT for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:41:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C259E3A682E for <6lowapp@ietf.org>; Mon, 28 Sep 2009 14:41:07 -0700 (PDT) Received: from snl-zach.local ([212.17.142.122]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8SLgJF9026011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 00:42:20 +0300 Message-ID: <4AC12DBE.2020703@sensinode.com> Date: Mon, 28 Sep 2009 23:42:22 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brian Frank References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> In-Reply-To: <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 21:41:10 -0000 Brian, Brian Frank wrote: > Couple of my thoughts to echo what some others have said: > > - I believe the application protocol should be format agnostic. I > suspect that it will be difficult to achieve consensus on data formats. > I am not sure how that might limit the scope of 6lowapp, but certainly I > hope that a debate on formats doesn't derail the transport protocol itself I totally agree, and this is one important thing we try to make clear in the charter. The application protocol must support common MIME types and encodings, and be easily extensible. For example, your proposal in Section 2.5 of draft-frank-6lowapp-chopan-00 is one very good way of doing it. > - I personally believe that naming should be based on URIs; however it > seems as this is already presumed as a requirement? Yes, definitely. As URIs are string based and often quite long, we should also figure out a way to compress them as well. > - just to echo what David said, I read the BOF to say that adaption of > HTTP (as proposed by myself) is off the table. But I think the intent > was just that we must define some subset of REST functionality can be > implemented efficiently? Exactly! Just drop the word HTTP from draft-frank-6lowapp-chopan-00 and that is a good start. The core REST functionality is exactly what we need to enable the embedded web. > > - sleeping nodes are mentioned a couple times already, but I'd just like > to re-iterate that I believe sleeping nodes are perhaps the most > important problem space for 6lowapp (or least a peer to the problem > space of computing/memory/bandwidth constraints) Yes. One other thing we need to mention is that peer-to-peer interactions between nodes is also important. A client-server only approach won't do here. In building automation P2P is a big MUST. There is a building automation requirements ID being written right now - which will surely point that out well. - Zach > Brian > > > On Thu, Sep 24, 2009 at 3:39 AM, Carsten Bormann > wrote: > > We used the last week to discuss the BOF proposal with our responsible > AD and with people from other standards groups. > > The result is a revised BOF proposal, that already provides an outline > for the charter of the new WG. This charter now defines a more > specific focus for the WG til the end of 2010. I think that is good > because the IETF is much better in handling focused, specific work > items than in grand, boil-the-ocean efforts. If we succeed, we can > always recharter to attack additional items. > > A bit more background: The goal of this BOF proposal is to get a BOF > going in Hiroshima, the week of Nov 9. The goal of the BOF is to > demonstrate that we have enough interest ("energy") and enough focus > to solve a credible problem in a defined amount of time; this will > enable us to charter a WG following the BOF. Not all of you will be > physically present in Hiroshima; that's another reason why it is > important to hear your opinions on this mailing list. The charter > proposal can and will change until Hiroshima, and now is the time to > influence it and to express your support. Also, the IETF is generally > driven by Internet-Draft documents, so it would be good to hear on the > list what you will be able to contribute. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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. From zach@sensinode.com Mon Sep 28 14:54:41 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 9D5673A68F3 for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 lPvvy9gXKB6y for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:54:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3336A3A682E for <6lowapp@ietf.org>; Mon, 28 Sep 2009 14:54:39 -0700 (PDT) Received: from snl-zach.local ([212.17.142.122]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8SLtp6c026122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 00:55:51 +0300 Message-ID: <4AC130EA.6090101@sensinode.com> Date: Mon, 28 Sep 2009 23:55:54 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sam Roberts References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com> In-Reply-To: <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 21:54:41 -0000 Hi, Sam Roberts wrote: > On Mon, Sep 28, 2009 at 11:04 AM, Brian Frank wrote: >> Couple of my thoughts to echo what some others have said: >> - I believe the application protocol should be format agnostic. I suspect >> that it will be difficult to achieve consensus on data formats. I am not >> sure how that might limit the scope of 6lowapp, but certainly I hope that a >> debate on formats doesn't derail the transport protocol itself > > I share the hope that format discussions won't bog things down. > > Perhaps I misunderstand what you mean by "format agnostic", won't > non-specification of such an important aspect prevent independantly > developed implementations of the protocol from interoperating? By format agnostic, we only mean that the protocol must have a content type/encoding identifier. The same philosophy is used by HTTP. Here our challenge is to represent that with 1-2 bytes. Once you have that, application developers may use any kind of content-type over this protocol, including e.g. text/xml, text/plain, rdf+xml, application/octet-stream using any content-encoding such as x-exi. >> - I personally believe that naming should be based on URIs; however it seems >> as this is already presumed as a requirement? > > Have I missed discussion of this, or has rehosting the zigbee > application support layer and cluster library on top of IPv6 over > 802.15.4 already been discussed and/or discarded as a possibility? The current indication from ZigBee/IP and Smart Energy is that they will use a web based approach. The ZigBee application layer is not being used in Smart Energy 2.0 at all, which is currently the only profile being developed for "ZigBee/IP". I would say this is something we should consider in the future (a later re-chartering) if we see there is a need from the other organizations involved. For this charter the goal is to stick to the most urgent tasks. > A profile supporting RESTful URI based request/response could exit at > a zigbee endpoint. Sure, I think you could definitely make them interact, and this would be an interesting draft! Zach > > Cheers, > Sam > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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. From zach@sensinode.com Mon Sep 28 14:57: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 41F6B3A68BB for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 nH8REj2eN+vj for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 14:57:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 950413A682E for <6lowapp@ietf.org>; Mon, 28 Sep 2009 14:57:41 -0700 (PDT) Received: from snl-zach.local ([212.17.142.122]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8SLwnVZ026152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 00:58:51 +0300 Message-ID: <4AC1319D.4070209@sensinode.com> Date: Mon, 28 Sep 2009 23:58:53 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: d.sturek@att.net References: <334E7C18-7C0B-4BC3-ADE9-9D30FBA0F7D7@tzi.org> <7b191a110909281104k10f3869bg534bbfaef0bf8322@mail.gmail.com> <17eac67c0909281228m339084c9u4e27decdd2271af8@mail.gmail.com> <017e01ca407a$bbc4b8e0$334e2aa0$@sturek@att.net> In-Reply-To: <017e01ca407a$bbc4b8e0$334e2aa0$@sturek@att.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 21:57:43 -0000 Don, Don Sturek wrote: > Hi Sam, > > The plan in ZigBee Smart Energy V2 is not to rehost the current ZigBee Smart > Energy application messaging overtop the IP stack. Work is currently > underway to extend the IEC TC57 CIM for the Smart Energy V2 use cases. The > CIM is a static data model using UML. > > The message exchange will be defined as XML (probably) or possibly ASN.1 (at > least, some standard self describing protocol). Since we have very small > packet sizes using IEEE 802.15.4, we need to use some standard encoding > method (like tokenized XML method, which I think is out of scope of IETF) > and some efficient embedded web services delivery (which I think should be > in scope for IETF). We also need a service discovery method which aligns > with the use of the encoding method we use (XML or ASN.1 or ??). These are all covered by existing MIME content-types and standard content-encodings. In 6lowapp we just need to be sure to support a large enough range of these for current and future use. > I agree with the statement that the 6LowAPP application protocol should be > format agnostic. It would be good to see that various encodings are > supported and that the XML encoding/embedded web services/binary service > discovery defined by 6LowAPP could be transparently used in conjunction with > full XML (or other self describing protocol)/current web services > protocols/full XML based service discovery for those devices holding the > schema and willing to expand/compress for communication with small footprint > devices. This is a definite must. > I think we have most of the communications layers defined to support this, > now needing the application support. > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf > Of Sam Roberts > Sent: Monday, September 28, 2009 12:29 PM > To: 6lowapp@ietf.org > Subject: Re: [6lowapp] BOF proposal: update > > On Mon, Sep 28, 2009 at 11:04 AM, Brian Frank > wrote: >> Couple of my thoughts to echo what some others have said: >> - I believe the application protocol should be format agnostic. I suspect >> that it will be difficult to achieve consensus on data formats. I am not >> sure how that might limit the scope of 6lowapp, but certainly I hope that > a >> debate on formats doesn't derail the transport protocol itself > > I share the hope that format discussions won't bog things down. > > Perhaps I misunderstand what you mean by "format agnostic", won't > non-specification of such an important aspect prevent independantly > developed implementations of the protocol from interoperating? > >> - I personally believe that naming should be based on URIs; however it > seems >> as this is already presumed as a requirement? > > Have I missed discussion of this, or has rehosting the zigbee > application support layer and cluster library on top of IPv6 over > 802.15.4 already been discussed and/or discarded as a possibility? > > A profile supporting RESTful URI based request/response could exit at > a zigbee endpoint. > > Cheers, > Sam > _______________________________________________ > 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 -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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. From zach@sensinode.com Mon Sep 28 15:06: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 543183A68F2 for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 15:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 tyLjJ-C4g4TG for <6lowapp@core3.amsl.com>; Mon, 28 Sep 2009 15:06:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E426D3A68C2 for <6lowapp@ietf.org>; Mon, 28 Sep 2009 15:06:28 -0700 (PDT) Received: from snl-zach.local ([212.17.142.122]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n8SM7f15026218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 01:07:43 +0300 Message-ID: <4AC133AE.2040800@sensinode.com> Date: Tue, 29 Sep 2009 00:07:42 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: nicolas.riou@fr.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] BOF proposal: update 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, 28 Sep 2009 22:06:30 -0000 Nicolas, Great, this is really useful input regarding OASIS work. We specifically added OASIS in the charter for that reason. Now this is a good chance to align 6lowapp and OASIS! nicolas.riou@fr.schneider-electric.com wrote: > > Hi Carsten and al, > > I have a few remarks/suggestions to complement the BOF proposal. > I would like to emphasize on the need for seamless integration of > up-and-coming architectures and Web Services. > > > Description: > > ... > > 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. > In the world of wireline embedded solution, the Device Profile for Web > Services (DPWS) is now a recognized OASIS standard to provide low cost > SOA solution at the device level, providing a complete solution both at > the application protocol level and at the commissioning level. > In the wireless world, the DPWS solution can be used in conjunction with > Binary XML encoding solutions such as EXI. Definitely. Obviously some further DPWS optimization might be needed - but it is going in the right direction! So a goal would be that the 6lowapp application protocol must be able to carry DPWS payloads? There may be interaction model issues to think of there (peer-to-peer?). > > > 6lowapp WG Charter Outline: > > --------------------------- > > * This working group will not work on new content formats > > or encodings, nor the compression or adaptation of HTTP. (to be > expanded) > ...but does not exclude considering standardized binary XML solutions to > compress messages. By supporting standard content-encodings (x-exi e.g.) this is easy. And of course application/octet-stream covers any. > > > 2. Application protocol: > > ... > > -- Features will include e.g. support for URLs, content types and > > encodings, PULL and PUSH interaction models, basic REST methods, > > both UDP and TCP, a simple form of cachability, and statelessness. > Eventing is also important, e.g. WS-eventing (as provided by DPWS) using > SOAP over UDP and Binary XML encoding. OK, eventing will be added. I think this is covered by PUSH, but let's be explicit. > > > -- Proxying with HTTP and SNMP must be straightforward. > Proposal: > -- Proxying with HTTP, SNMP and WS-Management must be straightforward. > > SNMP, despite a large installed based will likely decline in new > architectures and will be replaced by new protocols like WS-Management. > Seamless integration of WS-Management must be considered. Very good idea. > > 3. Application commissioning: > > ... > > -- Proxying with IP service discovery protocols such as SLP, SSDP or > > DNS-SD must be straightforward. > Proposal: > -- Proxying with IP service discovery protocols such as SLP, SSDP or > DNS-SD or WS-Discovery as provided by DPWS must be straightforward. Let's add this as well. Great feedback! Could you write a short draft on requirements to use OASIS DPWS and WS- solutions with 6lowapp work items? Zach > Looking forward for your feedback. > Nicolas > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” 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.