Hi Brian,
Thanks also for replying; my apologies for my tardy response:
>From: Brian E Carpenter <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 03:09:42 CDT
>To: [EMAIL PROTECTED]
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>,
Syam Madanapalli <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List <ipv6@ietf.org>
>Subject: Re: Prefix Delegation using ICMPv6
>[EMAIL PROTECTED] wrote:
>>>From: "Durand, Alain" <[EMAIL PROTECTED]>
>>>Date: 2006/08/22 Tue PM 10:31:10 CDT
>>>To: [EMAIL PROTECTED], Syam Madanapalli <[EMAIL PROTECTED]>,
>>
>> IETF IPv6 Mailing List <ipv6@ietf.org>
>>
>>>Subject: RE: RE: Prefix Delegation using ICMPv6
>>
>>
>>>>Thanks for the quick e-mail. As one of the co-authors, I'd in
>>>>turn like to reply (and state that ICMPv6 PD is ANOTHER way
>>>>to do IPv6 PD, NOT a replacement for the existing mechanism).
>>>>FWIW, please see comments in-line:
>>>
>>>This is probably the crux of the issue.
>>
>> ...
>>
>>>I believe that having multiple IETF standardized ways to achieve the same
>>>thing is a bad idea.
>>
>>
>> Hi Alain, I respect your opinion but believe differently.
>
>However, Alain is only citing a design principle that we often use when
>deciding whether a new idea is valuable. You'll find it in RFC 1958:
>
> 3.2 If there are several ways of doing the same thing, choose one.
> If a previous design, in the Internet context or elsewhere, has
> successfully solved the same problem, choose the same solution unless
> there is a good technical reason not to. Duplication of the same
> protocol functionality should be avoided as far as possible, without
> of course using this argument to reject improvements.
Good reference, Brian. I'm also thinking that RFC 1958 is Informational in
status, thus to quote from RFC 2026 (section 4.2.2):
"An "Informational" specification is published for the general information of
the Internet community, and does not represent an Internet community consensus
or recommendation... The Informational designation is intended to provide for
the timely publication of a
very broad range of responsible informational documents from many sources,
subject only to editorial considerations and to verification that there has
been adequate coordination with the standards process (see section 4.2.3)."
Given that "does not represent an Internet community consensus or
recommendation" clause (and the Informational status of the RFC), I'd say that
there is an extant way to do IPv6 PD is not inherently to say that we (IPv6 WG
in this instance) ought not consider alternative IPv6 PD mechanisms.
>
>but it certainly wasn't original then. In other words, you have to
>supply "a good technical reason" to add new functions.
One technical reason that motivates our ICMPv6 PD proposal is (quoting from an
earlier e-mail from Syam):
"Also, the subnet model that NetLMM WG wants to choose is to have a unique
prefix for each MN. These extensions for RS/RA allows NetLMM hosts to be able
to get unique prefixes in a better compared to current RS/RA messages."
Given that
>DHCP has become pretty much universal in IPv4 deployment, I'm having
>a hard time seeing why the same won't happen for IPv6.
>
> Brian
Best Regards,
Tim
Rom 8:28
>
>
>> BTW, there is already at least one such instance of their being "multiple
>> IETF standardized ways to achieve" IPv6 addressing for nodes. SLAAC (RFC
>> 2462[bis]) and DHCPv6 (RFC 3315), AND DHCPv6 'lite' (RFC 3736).
>>
>> Tim
>> Rom 8:28
>>
>>
>>> - Alain.
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
