Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.

Jari Arkko <jari.arkko@piuha.net> Tue, 29 June 2010 22:22 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4508828C0E8 for <autoconf@core3.amsl.com>; Tue, 29 Jun 2010 15:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.179
X-Spam-Level:
X-Spam-Status: No, score=0.179 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm5ZC8XPNXLY for <autoconf@core3.amsl.com>; Tue, 29 Jun 2010 15:22:47 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8CB6328C0DE for <autoconf@ietf.org>; Tue, 29 Jun 2010 15:22:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BF96D2CC62; Wed, 30 Jun 2010 01:22:56 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyy0VkcOHXMP; Wed, 30 Jun 2010 01:22:55 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 791D52CED3; Wed, 30 Jun 2010 01:22:55 +0300 (EEST)
Message-ID: <4C2A723E.3020806@piuha.net>
Date: Wed, 30 Jun 2010 01:22:54 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
References: <BFD8FF22-FD36-436E-9985-7BFA2E234081@gmail.com> <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <ABE739C5ADAC9A41ACCC72DF366B719D0333F14C@GLKMS2100.GREENLNK.NET>
In-Reply-To: <ABE739C5ADAC9A41ACCC72DF366B719D0333F14C@GLKMS2100.GREENLNK.NET>
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2010 22:22:48 -0000

Christopher,

Does this proposal mean the autoconf group will not work on a
    
distributed 
  
address configuration scheme for mesh networks ?
    
Same question, except I'd stick with the terminology ad hoc network.
A centralised distribution mechanism is a very poor fit to much of
what's attractive about an ad hoc network, and a very poor fit (due
to having a single point of failure) to many application areas for
ad hoc networks.

This is not the direction I for one had hoped that the Autoconf WG
would go in. I note the reference to "future extensions", but first
I assume that this is not chartered work, and second that forces
decentralised work into a certain shape, rather than working from
the problem more generally.

I appreciate that the WG can only work on solutions that people are
prepared to work on, and unfortunately I can't offer the effort needed
to make a concrete alternative proposal. I think however I've put in
at least my share of work in the Manet WG.
  

Just so that you know who to blame :-) I was the one who asked Thomas and Ryuji to consider a simple solution with no new protocols.

But back to your feedback on the charter. I would like to respond in two ways. First, I am by no means wedded to the particular solution details. Do you have a suggested edit?

But, second, I will defend the idea that the working group needs to learn to walk before running. We've been through a five year exercise just to define the addressing model. When we attempted to define the architecture as a general model we realized that it was hard, and explaining the model to non ad hoc networking experts was even harder. But when we described a concrete addressing model that some deployments are using we did finally get an RFC. Or almost have, at least. I would like to continue on the same path. I'm told that there are deployed autoconfiguration mechanisms and that some level of support is doable even with existing protocols.

I would like to avoid repeating the experience we had earlier on trying to describe the autoconf problem. One way of avoiding it is to describe either a deployed autoconfiguration mechanism or describe how to employ standard protocols and components to provide autoconfiguration for an ad hoc network. Once this work is complete, we can describe the limitations of this mechanism as the remaining autoconfiguration problem, and work on that. But I do not look forward to more years of discussion of complex routing protocol/neighbor discovery extensions and a constant stream of questions from the outsiders about why ND or DHCP cannot do the job.

I do get that a solution with a central node (and perhaps any solution with DHCP) does not solve all needs. Would you be happier if the charter had four work items:

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

Jari