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

Teco Boot <teco@inf-net.nl> Sat, 03 July 2010 07:13 UTC

Return-Path: <teco@inf-net.nl>
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 AA40C3A6859 for <autoconf@core3.amsl.com>; Sat, 3 Jul 2010 00:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.556
X-Spam-Level:
X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_40=-0.185]
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 burbpypzOp6j for <autoconf@core3.amsl.com>; Sat, 3 Jul 2010 00:13:51 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 798813A695B for <autoconf@ietf.org>; Sat, 3 Jul 2010 00:13:48 -0700 (PDT)
Received: by ewy22 with SMTP id 22so1326318ewy.31 for <autoconf@ietf.org>; Sat, 03 Jul 2010 00:13:56 -0700 (PDT)
Received: by 10.213.29.210 with SMTP id r18mr1510796ebc.81.1278141236426; Sat, 03 Jul 2010 00:13:56 -0700 (PDT)
Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm12910257eei.18.2010.07.03.00.13.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 00:13:55 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4C2E16A3.1080007@earthlink.net>
Date: Sat, 03 Jul 2010 09:13:54 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <CB65D069-E4DF-4BD2-B4C9-E6AEBBDD7B77@inf-net.nl>
References: <BFD8FF22-FD36-436E-9985-7BFA2E234081@gmail.com> <201006290803.34192.henning.rogge@fkie.fraunhofer.de><ABE739C5ADAC9A41ACCC72DF366B719D0333F14C@GLKMS2100.GREENLNK.NET><4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> <ABE739C5ADAC9A41ACCC72DF366B719D0333FC2D@GLKMS2100.GREENLNK.NET> <AANLkTilopimg_lJkGSEFnZ5A9Fv8EzH-eI1zGnANs0n-@mail.gmail.com> <4C2E16A3.1080007@earthlink.net>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.1081)
Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
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: Sat, 03 Jul 2010 07:13:54 -0000

Charlie,

Are you in for DHCP for getting prefixes (and other parameters),
for ad hoc networks connected to the Internet (or other managed
fixed network)?

If so, the discussion is on addresses only. We have to deal with
bootstrapping, i.e. first step in autoconf getting a routable
address and the address of a DHCP server. After this, we are done.

IMHO multi-hop signaling between address-less DHCP-client and unknown
DHCP-server is a bad idea. Both are needed for smooth operation.

Teco.


Op 2 jul 2010, om 18:41 heeft Charles E. Perkins het volgende geschreven:

> Hello Emmanuel and all,
> 
> Thanks for supporting the consideration
> of decentralized approach.  I'm pretty
> sure we could get at least one good
> working solution in time a lot faster
> than it took to agree that not everything
> is an Ethernet.
> 
> However, it's important to avoid making
> a sharp dichotomy between "centralized"
> and "decentralized" approaches.  My big
> concern was that somehow the DHCP model
> was going to be considered the only viable
> choice because people (outsiders?) consider
> it to be the only known quantity.  There are
> other ways to have more centralized or less
> centralized procedures, with or without
> proxy assistance, perhaps hybridized
> approaches, and with improved availability
> via elections.
> 
> Those are just a few of the options, and
> probably all of them are way better than
> trying to shoehorn DHCP where it does not
> seem to fit.  Flushing years of development
> and wisdom down the toilet just because
> they doesn't spell DHCP seems really wrong
> to me.
> 
> Another point to keep in mind -- DHCP was
> designed and built from day one to be a
> _managed_ solution for autoconfiguration.
> It seems quite clear to me that most of the
> interesting development and inspiration for
> ad hoc networks has gone towards enabling
> networking in environments where no such
> tightly managed administration is possible.
> Thus, in my view, DHCP almost tautologically
> disqualifies itself from consideration
> without major structural redesign.  How is
> it, then, that DHCP keeps cropping up in
> the discussion?
> 
> Regards,
> Charlie P.
> 
> 
> 
> On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote:
>> 
>> 
>> On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK)
>> <Chris.Dearlove@baesystems.com <mailto:Chris.Dearlove@baesystems.com>>
>> wrote:
>> 
>>    Charles Perkins
>>     > I'd be happy if it were possible for [autoconf] to
>>     > be allowed to consider the excellent body of work that
>>     > was seen already years ago -- the same body of work
>>     > that motivated me and others to create and spend a lot
>>     > of time over the last years and years.
>> 
>>    If Charlie can find a few like-minded people to work on
>>    that, why not add this as a parallel activity? The
>>    rationale of why two cases should be straightforward to
>>    make, they are almost chalk and cheese in e.g. centralised
>>    versus non-centralised. This is actually added safety to
>>    the group producing something, as if one succeeds and the
>>    other fails, that's still good.
>> 
>> 
>> 
>> I also think this parallel approach could be appropriate too.
>> 
>> 
>>    Unfortunately, I can't offer to be one of those people.
>>    Although I should be able to contribute at the read and
>>    comment level, more than that is needed. I only didn't
>>    make the suggestion earlier as it needs people (with
>>    all due respect to Charlie, plural) to do the work.
>> 
>> 
>> 
>> I'd be happy to help out on the matter. So I guess we have a plural +
>> contributors ;)
>> 
>> cheers,
>> 
>> Emmanuel
>> 
>> 
>> 
>> _______________________________________________
>> Autoconf mailing list
>> Autoconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/autoconf
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf