[6lowapp] Architecture Sketch in Charter

[Cullen Jennings <[e-mail]>]

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

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

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

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

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

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

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

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

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

1) a clear idea of what they want to build

2) the same common idea of what it is

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

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

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

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

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

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

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

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

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

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

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

Sorry for such a long email,
Cullen