Fwd: your comments for 6man, draft-ietf-6man-addr-select-sol-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 at inetcore.com>
日時: 2008年4月30日 14:05:43:JST
Cc: Arifumi Matsumoto <arifumi at nttv6.net>, "(Tomohiro 智宏) -INSTALLER- Fujisaki/藤崎" <fujisaki at syce.net>, 金山 KANAYAMA Ken-ichi 健一 / <kanayama_kenichi at intec-si.co.jp>, Ruri Hiromi <hiromi at 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




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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.