Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt

[Alexandru Petrescu <[e-mail]>]

Charles - I must say thank you for the reply about motivating the
absence of multicast in the autoconf addressing model because of its
ressemblance to broadcast, lack of tools to build trees and dedicated
suitability to non-MANET environments.

I will excuse myself for not replying.  I don't because this group is
not friendly.

Later, when we wonder who owes an answer to whom - it'll be simpler :-)

Alex

Le 17/02/2010 19:23, Charles E. Perkins a écrit :
>
> Hello Alex,
>
> On 2/16/2010 12:20 PM, Alexandru Petrescu wrote:
>> Le 16/02/2010 21:01, Jari Arkko a écrit :
>>> Great. Lets move this doc forward!
>>
>> YEs, let's move this forward and add multicast discussion to it
>> without which autoconf can't fly.
>
> What if we find that the requirements for a mobile ad hoc network do
>  not enable us to rely on a typical autoconfiguration protocol?
>
>
>> Multicast is what typical autoconfiguration protocols use today
>> without which they'd never work.
>
> This isn't true. In every case I am aware of, we could have designed
>  for pure broadcast operation.
>
> But of course you might just say that broadcast is a special case of
>  multicast. In that case, your argument completely loses its apparent
>  force anyway.
>
>
>> Multicast is what IPv6 got builtin precisely for the reason of
>> autoconfing.
>
> Nothing wrong with using the tools available to perform the function
>  for which they were built in the systems where they can be expected
>  to work.
>
>> This draft being silent about multicast spells it's not autoconf,
>> IMHO.
>
> Well, I strongly disagree, especially since your arguments as I
> understand them are fatally flawed.
>
> However, I'd be happy to have a non-tree-based local multicast group
>  consisting of all members within range of a node. There's absolutely
>  zero multicast protocol required to maintain membership in this
> group, conveniently.
>
> I would not insist to have that group definition appear in the
> addr-model draft.
>
>
> Regards, Charlie P.
>
>