[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributing site-wide RFC 3484 policy



My belief is that we need a method to distribute 3484 policy
in any case, even if we adopt another approach to the general problem.

    Brian

On 2007-07-24 16:55, Ruri Hiromi wrote:
Thanks for the attention.

Before moving to "draft-fujisaki-dhc-addr-select-04.txt", I would like to discuss on what is the best way to this WG with solution draft. Because "draft-fujisaki-dhc-addr-select-04.txt" describes specific protocol to send policy from dhcp server.

If all of you think we can skip the discussion about solution(analysis for the solution) and welcome to move to get into protocol work, it is also happy with me. How do you think?

Or in parallel with solution draft, if we can discuss on the distribution of site-wide RFC3484 policy it it better.

Here we already have "problem statement" and "requirement", the problems wants to be solved, doesn't it?


On 2007/07/24, at 23:16, Brian E Carpenter wrote:

Thanks. So does v6ops have an opinion about
draft-fujisaki-dhc-addr-select-04.txt? It seems
nothing will happen unless it's discussed here or
in ipv6.

   Brian

On 2007-07-23 21:18, Ruri Hiromi wrote:
Hi,
The latest version of this draft is today Arifumi mentioned in his solution document, "draft-fujisaki-dhc-addr-select-04.txt" and "draft-v6ops-addr-select-ps-01.txt". We divided previous draft into 2 part, one for distribution protocol and the other for problem statement. At first, we wrote that draft and presented in DHC-wg. DHC-wg chairs suggested us that we need support from other wg such as v6ops. Then we are here.
On 2007/07/24, at 3:56, Brian E Carpenter wrote:
What happened to
http://tools.ietf.org/id/draft-hirotaka-dhc-source-address-selection-opt-01.txt
and is there any other proposal for site-wide distribution of
address selection policy?

As I said at the mike today, I really think we can't avoid
such a mechanism. There *will* be sites running multiple prefixes
(those too small to insist on PI space, but big enough to
need multiple ISPs).

    Brian

-------------------------------
Ruri Hiromi
hiromi@inetcore.com


-------------------------------
Ruri Hiromi
hiromi@inetcore.com