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

What happens with duplicate DUIDs?
If they don't exist, why would self-generated duplicate addresses occur?

On the two-step approach, I can think of using the ND address temporally, and
get more info from DHCP, including a "better" address. This address would 
be topologically correct in case of border routers and would better fit 
for packetbb compression.

Teco.

Op 5 jul 2010, om 11:13 heeft Dearlove, Christopher (UK) het volgende geschreven:

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