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