Hi Brian, On 2010/08/02, at 13:04, Brian E Carpenter wrote:
> 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. I believe this separation of RFC3484-based mechanisms, and clean slate mechanisms should be a good way forward. Because we have to manage RFC-3484 based implementations for not a short period, and we can discuss about clean-slate mechanisms as long as you like. >> - 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". > Sorry for my rephrase. Just the same meaning of above-mentioned advanced/future mechanisms that involve the base address selection mechanism defined in RFC 3484. Best regards, > 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 --------------------------------------------------------------------
