Subject: [addr-select-dt] Fwd: updates from address selection design team

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 16 Jul 2010 20:58:45 +0900

DT members,

I just sent the following e-mail to the 6man ML to start the
discussion about the big picture.
Please correct me either this list or the public list, if I'm wrong.

I want to continue discussion within this ML regarding every aspects
of our work, while seeking consensus about the big picture at 6man ML.

Best regards,

Begin forwarded message:
> 
> All,
> 
> I'm writing this e-mail representing the address selection design team.
> 
> We've worked and discussed much within the design team, and are
> about to make important choices to move forward.
> 
> Our main draft revised this week covers whole issues, so I'd like
> you to review it.
> draft-ietf-6man-addr-select-considerations-02.txt
> 
> I extracted the main changes and the choices below.
> 
> - separating policy merging issue from protocol work.
> 
> The biggest design choice is separation of policy merging
> issue from the policy updating protocol.
> 
> As we know it, policy table make sense as a whole.
> This is mainly because the precedence value is absolute.
> Thus, policy table merging always involve conflict.
> 
> We can merge policies by a heuristic approach.
> But, there is no distinct/established algorithm for merging.
> 
> So, we the design team thought we need experiences and time
> for merging process standardization, and we should move the base
> policy distribution work forward to meet the urgent needs from the
> field, while standardizing the merging algorithm as a experimental
> or informational RFC.
> 
> 
> - RFC 3484 default rule update
> 
>  Though, we the design team is not chartered for revising of
>  RFC 3484, this issue is closely related to our work of policy
>  updating.
> 
>  While analyzing the problem cases, we thought some of them 
>  should be solved by revising the default address selection rules
>  themselves.
> 
>  So the design team also discussed about the revision of RFC 3484.
>  The output was included in the existing revision proposal that
>  I had put together.  
>  draft-arifumi-6man-rfc3484-revise-03.txt
> 
> 
> We definitely need input from 6man people to move forward.
> 
>