Since I wasn't in Maastricht, let me give some quick answers:
On 2010-07-28 17: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.
I agree. The basic mechanism needs to be a reasonably small change,
to have a chance of widespread deployment. Going to a very dynamic mechanism
is a much more ambitious project.
>
> - as the delivering protocol, DHCP should be the most appropriate choice,
> considering the target environments.
I agree. I think we should assume that the default policy will be
adequate for sites/hosts that are using SLAAC only.
> - 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.
Sure
> 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.
Not sure I understand what you mean here by "renovate".
Brian
> 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 protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
