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

I'm still trying to work out how step one works. ND, out of
the box, designed for hosts on non-multi-hop Ethernets
won't give you a MANET-wide unique address. You might even
find someone else with the same address as you on your only
route to the server. Or is there some development of ND
that I have overlooked?

-- 
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 Teco Boot
Sent: 03 July 2010 08:57
To: Mark Townsley
Cc: 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.

Easy to invent the automatic mechanism:
Only need an address? Use ND.
Need more? use ND for getting address, find central server, get more.

Teco.

Op 2 jul 2010, om 20:59 heeft Mark Townsley het volgende geschreven:

> 
> 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

_______________________________________________
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.
********************************************************************