Subject: [6lowapp] 6lowapp BOF scheduled for Mon, Nov 9, 13-15 (date and time TENTATIVE)

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Oct 2009 08:47:09 +0200

The first draft of the Hiroshima IETF 76 schedule is out:

	https://datatracker.ietf.org/meeting/76/agenda.html

and the 6lowapp BOF has been scheduled for Mon, Nov 9, 13-15.

Note that the meeting schedule is a DRAFT -- scheduling conflicts are  
often only detected when the actual schedule has been laid out, and  
corrective action may mean that sessions are moved around.  Don't book  
a non-refundable airline ticket on the assumption the session will  
stay exactly there.

An updated draft charter reflecting on the comments received will go  
out today.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Oct 2009 17:47:49 +0200

Attached please find another update to the BOF proposal/draft charter.
We believe we have picked up the relevant comments from the list,  
while trying to keep the focus sharp.

If we have missed something, or you see an opportunity to further  
sharpen the focus, please tell us.
Everything that we can fix now doesn't contribute to the load in the  
BOF meeting in Hiroshima.

Gruesse, Carsten

---

From: David Ryan <[email-masked]>
Date: Sat, 10 Oct 2009 11:07:38 +1100

Hi Carsten,

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

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

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

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

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

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

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

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

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

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

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

Regards,
David.

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Oct 2009 09:56:32 +0200

David,

before I go into your more technical points, let me try to clear up a  
process issue:

> "state of the art" has been reviewed.  This does not follow basic

This sequence may indeed be confusing if you are not familiar with the  
IETF WG process.

What the milestones are trying to say is that we want to reach the  
early "WG document" milestone for the application protocol before we  
reach the "Submit to IESG" milestone for the objectives document.  The  
"Submit" milestone for the application protocol is:

09/2010  Submit Application Protocol Specification document(s) to IESG
         for consideration of publication as Proposed Standard.

Let me put this in a little figure:

Objectives |-----------------------------------|
Protocol Spec              |============*1---------------------------|

*1 is the "reach WG document status" milestone; before that, we are  
likely to work on one or more individually submitted Internet-Drafts  
(as depicted by the double line to the left of the *1).
(We haven't defined such a milestone for the objectives document,  
which may add to the confusion; we just didn't see that much potential  
for competing objectives documents going through a selection/adoption  
process.)
Experience tells us that we will need some finishing on the problem  
statement/objectives document before we can submit that -- this does  
not mean that we can't start working from objectives that may not have  
achieved perfect editorial clarity.

On a practical level, what we definitely don't want to do is the  
classical "standardization requirements engineering", i.e. each  
proponent of a solution arguing endlessly to coax a solution-specific  
"mandatory requirement" into some document that is then used to throw  
out the other candidate protocols.  We don't have time for that game;  
this is one of the reasons the document is called "objectives" and not  
"requirements".  More philosophically speaking, I'd say we aren't  
likely to "engineer" a protocol (create it from well-understood non- 
conflicting requirements, as you would engineer a bridge) as much as  
"design" it (evolve the engineering in parallel with the objectives,  
as the latter are influenced by the former about as much as vice  
versa), but the timeline takes somewhat of a middle ground here,  
acknowledging that there is something to be gained by focusing on  
collecting objectives first and that there will be a more engineering- 
like phase at the end during which the design (and thus the  
objectives) already are stable.

Gruesse, Carsten