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

Arifumi Matsumoto <arifumi@nttv6.net> Fri, 16 July 2010 11:58 UTC

Return-Path: <arifumi@nttv6.net>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534B53A69D0 for <addr-select-dt@core3.amsl.com>; Fri, 16 Jul 2010 04:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Level:
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqdZrdT-bgQR for <addr-select-dt@core3.amsl.com>; Fri, 16 Jul 2010 04:58:36 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A50E73A6995 for <addr-select-dt@ietf.org>; Fri, 16 Jul 2010 04:58:35 -0700 (PDT)
Received: from radiko.smartstream.ne.jp (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6GBwkj1091472 for <addr-select-dt@ietf.org>; Fri, 16 Jul 2010 20:58:46 +0900 (JST) (envelope-from arifumi@nttv6.net)
References: <7D78D21D-C0CF-4BCC-9B2C-ECC40976DE48@nttv6.net>
From: Arifumi Matsumoto <arifumi@nttv6.net>
Content-Type: text/plain; charset=us-ascii
Message-Id: <C7CDB575-04F2-47F1-915F-77EA311EB480@nttv6.net>
Date: Fri, 16 Jul 2010 20:58:45 +0900
To: addr-select-dt@ietf.org
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:::1]); Fri, 16 Jul 2010 20:58:46 +0900 (JST)
Subject: [addr-select-dt] Fwd: updates from address selection design team
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2010 11:58:37 -0000

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.
> 
>