Re: [6lowapp] Updated BOF proposal/draft charter

[Carsten Bormann <[e-mail]>]

David,

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

On Oct 10, 2009, at 02:07, David Ryan wrote:

> I also note that the Goals and Milsestones have been updated:
>
> 01/2010  Milestone: Working group document for the Application
> Protocol Specification.
>
> 03/2010  Submit 6lowapp Problem Statement and Objectives to IESG for
> consideration of publication as Informational.
>
> This states that the specification will be documented before the
> problem statement and objectives have been considered and before the
> "state of the art" has been reviewed.  This does not follow basic
> engineering principles.

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

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

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

Let me put this in a little figure:

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

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

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

Gruesse, Carsten