Subject: [Autoconf] Summary of re-chartering discussions.

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 19 Jul 2010 23:32:25 -0700

Hi all,

Thanks for all your comments. We have roughly following opinions. 

- Centralized and/or De-centerized 
- Existing protocols (DHCP and/or ND) vs. new autoconf protocols
- SIngle or Multiple AUTOCONF protocol(s)
- Security issue
- Informational link characteristics document

Chairs will prepare for the detailed summary by the Friday meeting in Maastricht.
We may ask some folks to present their opinion based on the comments we received for the new charter proposal.

Here is my general comment (more like impression) as one of co-chair.
It's important to note that several folks agree on the Jari's proposed milestone. 

>1. Design space survey (Informational)
>2. The simple solution (such as DHCP) (PS)
>3. Limitations of the simple solution (Informational)
>4. Recharter for work on the more general solution

I do agree on the importance of non-centerized approach for MANET and knew
many past works exist for AUTOCONF (I had one proposal, too).  
However, as a co-chair, we see high hurdles to get the new protocol(s) out.

First, we have to define requirements of such new autoconf protocol(s), 
for example:  router's address, Global prefix, centralized-,
non-centerized scenarios, single and/or multiple centralized servers,
security...  
Considering fact that people aim at so many different manet scenarios, 
how can we agree on those requirements?

Second, how can we select (a) past proposed autoconf protocol(s) or
inventing a new protocol..
We don't know yet whether there is "a protocol" supporting all the requirements of 
MANET scenarios. Maybe there is, but we need some investigation.

I am afraid to say that It will require a few more years to define only 
requirements, then protocol standardization for !? years.

Don't you think we need some exercise with the simple solution first
before tackling with these huge issues?  
At the coming AUTOCONF charter, the simplest solution may be defined
as just an experimental RFC. Then, we'll have the document of
"limitations of the simple solution (informational)". 
After having these documents, it's not too late to produce "an
AUTOCONF protocol (PS)".

Let's say if the Jari's proposed milestone takes 1- 1.5 years, we will
have better strategy for "An AUTOCONF protocol (PS)" in those years.
Some of folks may feel waste of time for the Jari's proposed charter,
but i believe this is worth to pay for AUTOCONF activity.

Anyway, let's continue rechartering discussion in Maastricht.

thanks,
ryuji

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Jul 2010 10:42:42 +0200

Ryuji, all,

For what it is worth -- and having followed the discussions -- I don't 
mind the working group picking up the distributed design work 
immediately in the new charter. However, I still want to see the 
specification of what current protocols (DHCP) can achieve unchanged. 
The description of the limitations of that solution is a natural step of 
developing the distributed solution, along with design space analysis 
and other steps that people have mentioned.

Jari

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 20 Jul 2010 17:22:20 -0700

Hi Jari,

Thanks for clarification. 

I agree with you to take a look at current solutions first.
I expect that AUTOCONF WG can finish this work very quickly and move to the real AUTOCONF work soon after that.

regards,
ryuji

On 2010/07/20, at 1:42, Jari Arkko wrote:

> Ryuji, all,
> 
> For what it is worth -- and having followed the discussions -- I don't mind the working group picking up the distributed design work immediately in the new charter. However, I still want to see the specification of what current protocols (DHCP) can achieve unchanged. The description of the limitations of that solution is a natural step of developing the distributed solution, along with design space analysis and other steps that people have mentioned.
> 
> Jari
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Jul 2010 14:45:52 +0300

Ryuji,

Let me try again.

I don't feel a need to delay the work on the distributed solution in any 
way, or bind its progress to the progress of the other deliverable that 
I wanted to see. I merely observed that as a part of the work for 
developing a distributed solution you will go through the usual steps, 
which involve documenting why that solution is needed, what the options 
there are in the design space, and so on. I'm fine adding the 
distributed solution to the charter, if those steps are in the charter.

Also, you used the phrase "real AUTOCONF work". Were you referring to 
new protocol development as real work, or saying something about what 
types of solutions are going to be needed and used? For what it is 
worth, it is not at all clear to me that the fully distributed solutions 
are the only interesting ones. Virtually all networks have Internet 
connectivity for various good reasons, and relying on some subset of 
nodes -- perhaps the Internet gateway router(s) -- for the ad hoc 
network address allocation may be just fine in these networks. 
Particularly if it comes with less complexity and less time spent 
waiting for new software. I know what I would do in my network.

Jari