Subject: Re: [addr-select-dt] poll on the address selection DT suggestions ?

From: Tim Chown <[email-masked]>
Date: Wed, 28 Jul 2010 14:32:44 +0100

Thanks, this is a well summarised message.

I'd be interested to hear what the result was :)

Tim

On 28 Jul 2010, at 06:44, Arifumi Matsumoto wrote:

> Hi,
> 
> At the yesterday's 6man session, the design team suggested three main points.
> Though it was decided to discuss more about this issue of address selection at this mailing list, I'd like to see to how much extent those suggestions were accepted by the 6man people *now*.
> 
> This is important, because not delaying the standardization of the basic mechanism is one of the main suggestion from the DT. And because it determines if any further work at DT is necessary or not.
> 
> The three main points were:
> 
> - separating the basic mechanism from other advanced mechanisms/features.
>  The policy merging process should be host issue, and we need to focus on network issue of delivering protocol, because host issue can be implemented in the same way of other configuration information.
>  And, another separation is the frequently updating of policy mainly from the help of routing mechanisms, such as ICMP errors from routers. From our consideration, many of the cases do not need such a frequent updates of policy. Moreover, such a dynamic case forces a host to react dynamically, and this involves host protocol stack renovation, just like shim6 and mptcp, and so on.
>  The basic mechanism is powerful enough to solve many problems and harmless enough to keep RFC3484 as it is, and should not be delayed because of these advanced/future mechanisms.
> 
> - as the delivering protocol, DHCP should be the most appropriate choice, considering the target environments.
> 
> - the RFC 3484 revision needs to be done.
>  Maybe this point needs no poll any more.
>  This point was accepted and now in confirmation process in the ML.
>  I think, if we agree this kind of minor revision of RFC 3484, we also agreed we carry on the existing model for some years, or we need a solution that does not renovate the existing model.
> 
> 
> So, I'm glad to have your everyone's mood on these three points.
> Can we poll at today's 6man session, or at the ML ?
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------