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

"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> Mon, 05 July 2010 09:23 UTC

Return-Path: <Chris.Dearlove@baesystems.com>
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 B17393A6846 for <autoconf@core3.amsl.com>; Mon, 5 Jul 2010 02:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 SoPYmRzegvT0 for <autoconf@core3.amsl.com>; Mon, 5 Jul 2010 02:23:58 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id ED7F43A6812 for <autoconf@ietf.org>; Mon, 5 Jul 2010 02:23:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,539,1272841200"; d="scan'208";a="74451178"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Jul 2010 10:23:58 +0100
Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o659Nsrr006332; Mon, 5 Jul 2010 10:23:58 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 10:23:43 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
x-mimeole: Produced By Microsoft Exchange V6.5
Date: Mon, 05 Jul 2010 10:23:42 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D0336CD4D@GLKMS2100.GREENLNK.NET>
In-Reply-To: <4C2E3702.9030606@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal.
thread-index: AcsaggvIEVNOwyieRw2etPwxjzhmlgBnjnpA
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><C67EC3A73E6A814B8F3FE826438C5F8C02A00D5E@ms-dt01thalia.tsn.tno.nl> <4C2E3702.9030606@cisco.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: Mark Townsley <townsley@cisco.com>, autoconf@ietf.org
X-OriginalArrivalTime: 05 Jul 2010 09:23:43.0072 (UTC) FILETIME=[C2F8F600:01CB1C23]
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: Mon, 05 Jul 2010 09:23:59 -0000

I'm going to disagree with that, because there are fundamentally
different requirements - not all MANETs are the same. The
proposed solution in the current draft charter is a single
DHCP server. Putting aside the technical issues in getting that
to work that Charlie and others have pointed out, let's suppose
it can be made to work. But there are several of us whose areas
of interest, and scenarios within that area of interest, would
regard such a single point of failure (or takeover) as not a good
solution. Of course just having a decentralised solution would
not necessarily be sufficient either, hence the comments I've
made about security issues up front. I don't yet know if a
solution that does all I would want it to do exists.

As for how to choose, if one solution is unacceptable, then the
network would clearly be using the other. More generally it's
far from the only administratively configured issue in a MANET
- which routing protocol for example (which also applies in the
fixed Internet, nothing new there).

But perhaps, rather than jumping straight in with one, or even
two, approaches, we need people to indicate what they actually
want/need, and whether the proposal in the draft charter, or
an alternative (the latter having the disadvantage of being
quite vague at this point) would give them what they need.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On
Behalf Of Mark Townsley
Sent: 02 July 2010 19:59
To: autoconf@ietf.org
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter
proposal.


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.
 

My kneejerk reaction to this is that walking in with the goal of having
more than one way to autoconfigure a manet is a bad idea.

If we end up with two ways to autoconfigure, then we will have to invent
an automatic mechanism on top to choose which autoconfiguration
mechanism to use.  That doesn't help anyone. In absence of knowledgeable
human configuration, hard choices that narrow functional options
typically far outweigh the potential benefits of one option vs. the
other. So, even if you can prove that A is better than B, B is still
better than A+B.

Let's strive for making a choice, at least within the MANET domain.

- Mark


On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote:
> Hello autoconfers,
> 
> I support this "two-case"-approach, Christopher mentions: so
> standardizing one centralized and one decentralized solution (or one
> stateful and one stateless solution, just like in the current IPv6
> standards). I agree that the solution should make use of existing
> protocols as much as possible (e.g. DHCP, ND, ...), but my choice
would
> be not to state in the charter that DHCP must be used in all solutions
> coming out of the WG.
> 
> draft-bernardos-manet-autoconf-survey-05 shows there are already many
> proposals existing, making it a good starting point for going into
> solution space. Actually even more than just a starting point since
many
> of the proposals have already been around for a while. So I support
this
> doc.
> 
> Best regards,
> Arjen
> 
>>
>> 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.
>>
>>
> This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
> 
> _______________________________________________
> 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


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************