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 <cabo@tzi.org>
> Date: September 7, 2009 23:20:14 +0200
> To: app-ads@tools.ietf.org
> Cc: agenda IETF <agenda@ietf.org>
> 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.)