Fwd: your comments for 6man, draft-ietf-6man-addr-select-sol-00.txt

Ruri Hiromi <hiromi@inetcore.com> Thu, 08 May 2008 15:49 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801D128D16F; Thu, 8 May 2008 08:49:47 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA1028D16F for <ipv6@core3.amsl.com>; Thu, 8 May 2008 08:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.14
X-Spam-Level:
X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, 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 UtDu99NjYugj for <ipv6@core3.amsl.com>; Thu, 8 May 2008 08:49:44 -0700 (PDT)
Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by core3.amsl.com (Postfix) with ESMTP id E47E828CE36 for <ipv6@ietf.org>; Thu, 8 May 2008 06:39:06 -0700 (PDT)
Received: from [IPv6:2001:200:167:1104:21b:63ff:fec9:f412] (unknown [IPv6:2001:200:167:1104:21b:63ff:fec9:f412]) by inc.inetcore.com (Postfix) with ESMTP id C4E01D567D7 for <ipv6@ietf.org>; Thu, 8 May 2008 21:44:57 +0900 (JST)
Message-Id: <3BE3B304-A5F5-424D-B319-02F8EBD932A5@inetcore.com>
From: Ruri Hiromi <hiromi@inetcore.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Fwd: your comments for 6man, draft-ietf-6man-addr-select-sol-00.txt
Date: Thu, 08 May 2008 21:44:57 +0900
References: <E49C2DED-765E-4AA7-9D84-BE343B8B6E6C@inetcore.com>
X-Mailer: Apple Mail (2.919.2)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0714923445=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi all,

About draft-ietf-6man-addr-select-sol-00.txt, we are going to update  
it after looking over the last meeting minutes and comments. (http://tools.ietf.org/wg/6man/minutes 
)

Does someone have further comments?

Thanks in advance,

Begin forwarded message:

> 差出人: Ruri Hiromi <hiromi@inetcore.com>
> 日時: 2008年4月30日 14:05:43:JST
> 宛先: Jinmei_Tatuya@isc.org, Dave Thaler  
> <dthaler@windows.microsoft.com>, Erik Nordmark  
> <erik.nordmark@sun.com>, Thomas Narten <narten@us.ibm.com>, Bob  
> Hinden <bob.hinden@nokia.com>
> Cc: Arifumi Matsumoto <arifumi@nttv6.net>, "(Tomohiro 智宏) - 
> INSTALLER- Fujisaki/藤崎" <fujisaki@syce.net>, 金山  
> KANAYAMA Ken-ichi 健一 / <kanayama_kenichi@intec-si.co.jp>,  
> Ruri Hiromi <hiromi@inetcore.com>
> 件名: your comments for 6man, draft-ietf-6man-addr-select- 
> sol-00.txt
>
>
> Hello,
>
> We would like to summarise the comments we have had during IETF71 on  
> our Address Solution Analysis document. (draft-ietf-6man-addr-select- 
> sol-00.txt)
> 6man chairs also told us getting more comment from yours.
>
> First of all, could I summarise your comment as follows.
>
> [1, from dthaler]  pick up Marcelo Bagnulo's 3484 update, the  
> behavior of his proposal in 3484 update will be hard to choose  
> destination address selection. And also there will be a need to  
> select those of src/dest address from application, especially in  
> with multi-interfaces, how does it be carried out?
> [2, from Erik]  additional thoughts of "interface selection", how  
> does it be described in this document?
> [3, from Jinmei] Should update 3484.
> [4, from Thomas Narten] Consideration about uRPF, but it is  
> described in Problem Statement doc.
> [5, From Bob Hinden] Check out the current status of 3484 update.
>
> About [2], There is no obvious proposal about this. This document is  
> simply evaluate solutions. Currently we are just considering about  
> interface selection(*), but it seems to be for a specific  
> circumstance, not for the general purpose. Do you have heard any  
> idea of this?
> (put some weight for each interface to be selectable from API, like  
> DNS mechanism)
>
> About [3], Apart from this solution analysis document, Arifumi will  
> do this(?).  Updating RFC3484 itself will be allright but there are  
> no consensus about ULA into a policy table.  How does it be  
> treated?  I am anxious about that we should update RFC3484 every  
> time if there will be other special use address blocks.  To comply  
> with these  demands, it will be better to insert policies(hints)  
> from others(ie, admin), we think.
>
> About [4], your suggesting point is described in Problem Statement  
> document, and there are some solutions against/co-working with  
> uRPF.  Do you mean we should describe it in Requirement?  Also we  
> agree with your 2nd point of that we should carefully find "general  
> solution".
>
> Could you please review your comment and send us modification or  
> further comments?
>
> Regards,
>

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




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------