From addr-select-dt-bounces@ietf.org Thu Sep 11 00:39:38 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE143A6832; Thu, 11 Sep 2008 00:39:38 -0700 (PDT) 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 4B7013A659B for ; Thu, 11 Sep 2008 00:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.758 X-Spam-Level: *** X-Spam-Status: No, score=3.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FRT_POSSIBLE=2.697, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6] 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 H3zrtPdxZ8ub for ; Thu, 11 Sep 2008 00:39:35 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [122.249.92.11]) by core3.amsl.com (Postfix) with ESMTP id ADF913A67F2 for ; Thu, 11 Sep 2008 00:39:34 -0700 (PDT) Received: from [IPv6:2001:200::ff01:21b:63ff:fec9:f412] (unknown [IPv6:2001:200:0:ff01:21b:63ff:fec9:f412]) by inc.inetcore.com (Postfix) with ESMTPSA id A1EFA2CF81B for ; Thu, 11 Sep 2008 16:37:30 +0900 (JST) Message-Id: <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com> From: Ruri Hiromi To: addr-select-dt@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 11 Sep 2008 16:37:27 +0900 X-Mailer: Apple Mail (2.928.1) Subject: [addr-select-dt] discussion point, task and members X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0354952693==" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org --===============0354952693== Content-Type: multipart/alternative; boundary=Apple-Mail-19-145795104 --Apple-Mail-19-145795104 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit # resent on changing Subject line. Dear 3484 policy distribution design team, Here is a outline to start to discuss with. In this team, we will write a protocol design draft for dynamic policy table update. I think here some points. How do you think about them? 1. definition of "default policy" and its administration o a basic "default policy table" is described in RFC3484 but it will have additional address numbers like ORCHID, ULA and so on. o Because of it's possibile modification it is hard to fix entire table. o It is better to refer up-to-date table and it seems better that IANA(or like such authorised organization) manages the table. 2. distribution mechanism o Protocol From the solution document, here is 4 types of mechanisms(obtain- all-info, routing-system-assistance, trial-and-error-approach, all-by- oneself), I think obtain-all-info using DHCPv6 or RA will be a suitable solution for a client connecting to a managed network. But for other network requirement or use cases, we want to make a brand-new protocol? In any cases, how do we consider about cooperation with other protocol(i.e, routing protocol)? Can we use LDAP or other popular protocol? o Timing o Dynamics o Other requirements from address-select-req 3. draft table of contents (1) abstract (2) terminology, definitions (3) data format, syntacs (4) data type(request, response) (5) security consideration 4. Milestone o drafting at the end of Oct. 2008 o presentation at the 6man next IETF73 o the Goal is publishing the draft as RFC - Design Team Members current 3484 policy dynamic update design team - Marc Blanchet - Tim Chown - Marcelo Bagnulo Braun - Suresh Krishnan - Tony Hain - Francis Dupont - Evans TJ - John.zhao - Sebastien Roy - Janos Mohacsi - Tim Enos - Teemu Savolainen - Fujisaki Tomohiro - Arifumi Matsumoto - Ruri Hiromi - Sandbox o ML addr-select-dt@ietf.org o wiki coming soon? - references proposal for updating RFC3484 http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt Problem Statement http://tools.ietf.org/html/rfc5220 Requirement http://tools.ietf.org/html/rfc5221 Solution Analysis http://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/ shim6 using DHC option to carry out distributing table http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt Regards, ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com --Apple-Mail-19-145795104 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
# resent on = changing Subject line.

Dear 3484 policy = distribution design team,

Here is a outline to = start to discuss with.

In this team, we will = write a protocol design draft for dynamic policy table = update.
I think here some points. How do you think about = them?
=
1. definition of "default policy" and its = administration
o a basic "default policy table" = is described in RFC3484 but it will have additional address numbers like = ORCHID, ULA and so on.
  o Because of it's possibile = modification it is hard to fix entire table.
o It is = better to refer up-to-date table and it seems better that IANA(or like = such authorised organization) manages the table.

2. = distribution mechanism
o Protocol
=    =46rom the solution document, here is 4 types of = mechanisms(obtain-all-info, routing-system-assistance, = trial-and-error-approach, all-by-oneself), I think obtain-all-info using = DHCPv6 or RA will be a suitable solution for a client connecting to a = managed network.
   But for other = network requirement or use cases, we want to make a brand-new = protocol?
=    In any cases, how do we consider about cooperation = with other protocol(i.e, routing protocol)?
=    Can we use LDAP or other popular protocol?
o = Timing
= o Dynamics
o Other requirements from = address-select-req

3. draft table of = contents
(1) abstract
(2) = terminology, definitions
(3) data format, = syntacs
(4) data type(request, = response)
(5) security = consideration

4. Milestone
o = drafting at the end of Oct. 2008
o presentation at the 6man next = IETF73
o the Goal is publishing the = draft as RFC

- Design Team = Members
current 3484 policy dynamic update design = team
= - Marc Blanchet
- Tim Chown
- Marcelo = Bagnulo Braun
= - Suresh Krishnan
- Tony Hain
- Francis = Dupont
= - Evans TJ
- John.zhao
- = Sebastien Roy
= - Janos Mohacsi
- Tim Enos
- Teemu = Savolainen
= - Fujisaki Tomohiro
- Arifumi = Matsumoto
- Ruri Hiromi

- = Sandbox
= o ML addr-select-dt@ietf.org
<= div> o = wiki coming soon?

- = references

 proposal for updating = RFC3484
http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt
=  Problem Statement
http://tools.ietf.org/html/rfc= 5220
 Requirement
http://tools.ietf.org/html/rfc= 5221
 Solution Analysis
ht= tp://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/
 = shim6
 using DHC option to carry out distributing table
http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt

Regards,
-------------------------------
Ruri = Hiromi
Intec NetCore, Inc. / Keio university
hiromi@inetcore.com


-------------------------------
Ruri = Hiromi
Intec NetCore, Inc. / Keio university

=

=

= --Apple-Mail-19-145795104-- --===============0354952693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt --===============0354952693==-- From addr-select-dt-bounces@ietf.org Thu Sep 11 05:31:04 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AA23A68C5; Thu, 11 Sep 2008 05:31:04 -0700 (PDT) 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 6F6393A6907 for ; Thu, 11 Sep 2008 05:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=-2.960, BAYES_40=-0.185, FRT_POSSIBLE=2.697, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] 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 QMAN4DwKNVck for ; Thu, 11 Sep 2008 05:30:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2BC8A3A68C5 for ; Thu, 11 Sep 2008 05:30:58 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-151-216.dialup.adsl.anteldata.net.uy [190.135.151.216])by smtp03.uc3m.es (Postfix) with ESMTP id ABBD763208E;Thu, 11 Sep 2008 14:30:22 +0200 (CEST) Message-ID: <48C90F5C.2050200@it.uc3m.es> Date: Thu, 11 Sep 2008 14:30:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ruri Hiromi References: <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com> In-Reply-To: <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.5964 TC:1F TRN:64 TV:5.5.1026(16150.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] discussion point, task and members X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Ruri Hiromi escribi=F3: > # resent on changing Subject line. > > Dear 3484 policy distribution design team, > > Here is a outline to start to discuss with. > > In this team, we will write a protocol design draft for dynamic policy = > table update. really? i thought that the team scope was broader than that, in particular i = thought we were supposed to update rfc3484. In rfc3484, the main issue that i identify is how to deal with multiple = addresses, in particualr how to deal with initial contact failures, when = the failure is due to a problem in the source address (e.g. due to = ingress filtering) dynamic update seems straight forward, i don't really see the need for a = design team, we just need peopel to write the specs. This other problem, otoh, seems much harder to me and could benefit from = new ideas and the expertise of this group Regards, marcelo > I think here some points. How do you think about them? > > 1. definition of "default policy" and its administration > o a basic "default policy table" is described in RFC3484 but it will = > have additional address numbers like ORCHID, ULA and so on. > o Because of it's possibile modification it is hard to fix entire table. > o It is better to refer up-to-date table and it seems better that = > IANA(or like such authorised organization) manages the table. > > 2. distribution mechanism > o Protocol > From the solution document, here is 4 types of = > mechanisms(obtain-all-info, routing-system-assistance, = > trial-and-error-approach, all-by-oneself), I think obtain-all-info = > using DHCPv6 or RA will be a suitable solution for a client connecting = > to a managed network. > But for other network requirement or use cases, we want to make a = > brand-new protocol? > In any cases, how do we consider about cooperation with other = > protocol(i.e, routing protocol)? > Can we use LDAP or other popular protocol? > o Timing > o Dynamics > o Other requirements from address-select-req > > 3. draft table of contents > (1) abstract > (2) terminology, definitions > (3) data format, syntacs > (4) data type(request, response) > (5) security consideration > > 4. Milestone > o drafting at the end of Oct. 2008 > o presentation at the 6man next IETF73 > o the Goal is publishing the draft as RFC > > - Design Team Members > current 3484 policy dynamic update design team > - Marc Blanchet > - Tim Chown > - Marcelo Bagnulo Braun > - Suresh Krishnan > - Tony Hain > - Francis Dupont > - Evans TJ > - John.zhao > - Sebastien Roy > - Janos Mohacsi > - Tim Enos > - Teemu Savolainen > - Fujisaki Tomohiro > - Arifumi Matsumoto > - Ruri Hiromi > > - Sandbox > o ML addr-select-dt@ietf.org > o wiki coming soon? > > - references > > proposal for updating RFC3484 > http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt > Problem Statement > http://tools.ietf.org/html/rfc5220 > Requirement > http://tools.ietf.org/html/rfc5221 > Solution Analysis > http://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/ > shim6 > using DHC option to carry out distributing table > http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt > > Regards, > ------------------------------- > Ruri Hiromi > Intec NetCore, Inc. / Keio university > hiromi@inetcore.com > > > ------------------------------- > Ruri Hiromi > Intec NetCore, Inc. / Keio university > hiromi@inetcore.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt > = _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Sep 11 08:38:50 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D6B3A6896; Thu, 11 Sep 2008 08:38:50 -0700 (PDT) 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 EE74F3A693C for ; Thu, 11 Sep 2008 08:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=-3.807, BAYES_05=-1.11, FRT_POSSIBLE=2.697, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6] 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 jG2N43iLBnwj for ; Thu, 11 Sep 2008 08:38:47 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 550423A6896 for ; Thu, 11 Sep 2008 08:38:47 -0700 (PDT) Received: from ([128.244.206.121]) by pilot.jhuapl.edu with ESMTP id 5502123.113621814; Thu, 11 Sep 2008 11:37:29 -0400 Message-ID: <48C93B38.3010505@innovationslab.net> Date: Thu, 11 Sep 2008 11:37:28 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: addr-select-dt@ietf.org References: <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com> <48C90F5C.2050200@it.uc3m.es> In-Reply-To: <48C90F5C.2050200@it.uc3m.es> Subject: Re: [addr-select-dt] discussion point, task and members X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org All, Let me set the path for this design team. First, I have asked two members of this design team to act as co-chairs = in order to ensure that consensus is reached within the design team on = discussion points. Once I have gotten confirmation of their willingness = to take on this role I will ask them chime in with their views on how = they want to do that. Second, the initial focus of this work should be to determine how = dynamic the updates of an address selection policy need to be. Once = that is accomplished, the focus should be on determining what types of = update approaches satisfy those needs. The third task is to assess = whether those update solutions require/need 3484 to be updated. In some = instances, I could envision solutions that simply use 3484 as guidelines = and provide sufficient controls to address the current limitations in = the RFC. Regards, Brian marcelo bagnulo braun wrote: > Ruri Hiromi escribi=F3: >> # resent on changing Subject line. >> >> Dear 3484 policy distribution design team, >> >> Here is a outline to start to discuss with. >> >> In this team, we will write a protocol design draft for dynamic policy = >> table update. > really? > i thought that the team scope was broader than that, in particular i = > thought we were supposed to update rfc3484. > In rfc3484, the main issue that i identify is how to deal with multiple = > addresses, in particualr how to deal with initial contact failures, when = > the failure is due to a problem in the source address (e.g. due to = > ingress filtering) > = > dynamic update seems straight forward, i don't really see the need for a = > design team, we just need peopel to write the specs. > This other problem, otoh, seems much harder to me and could benefit from = > new ideas and the expertise of this group > = > Regards, marcelo > = > = >> I think here some points. How do you think about them? >> >> 1. definition of "default policy" and its administration >> o a basic "default policy table" is described in RFC3484 but it will = >> have additional address numbers like ORCHID, ULA and so on. >> o Because of it's possibile modification it is hard to fix entire tabl= e. >> o It is better to refer up-to-date table and it seems better that = >> IANA(or like such authorised organization) manages the table. >> >> 2. distribution mechanism >> o Protocol >> From the solution document, here is 4 types of = >> mechanisms(obtain-all-info, routing-system-assistance, = >> trial-and-error-approach, all-by-oneself), I think obtain-all-info = >> using DHCPv6 or RA will be a suitable solution for a client connecting = >> to a managed network. >> But for other network requirement or use cases, we want to make a = >> brand-new protocol? >> In any cases, how do we consider about cooperation with other = >> protocol(i.e, routing protocol)? >> Can we use LDAP or other popular protocol? >> o Timing >> o Dynamics >> o Other requirements from address-select-req >> >> 3. draft table of contents >> (1) abstract >> (2) terminology, definitions >> (3) data format, syntacs >> (4) data type(request, response) >> (5) security consideration >> >> 4. Milestone >> o drafting at the end of Oct. 2008 >> o presentation at the 6man next IETF73 >> o the Goal is publishing the draft as RFC >> >> - Design Team Members >> current 3484 policy dynamic update design team >> - Marc Blanchet >> - Tim Chown >> - Marcelo Bagnulo Braun >> - Suresh Krishnan >> - Tony Hain >> - Francis Dupont >> - Evans TJ >> - John.zhao >> - Sebastien Roy >> - Janos Mohacsi >> - Tim Enos >> - Teemu Savolainen >> - Fujisaki Tomohiro >> - Arifumi Matsumoto >> - Ruri Hiromi >> >> - Sandbox >> o ML addr-select-dt@ietf.org >> o wiki coming soon? >> >> - references >> >> proposal for updating RFC3484 >> http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt >> Problem Statement >> http://tools.ietf.org/html/rfc5220 >> Requirement >> http://tools.ietf.org/html/rfc5221 >> Solution Analysis >> http://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/ >> shim6 >> using DHC option to carry out distributing table >> http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt >> >> Regards, >> ------------------------------- >> Ruri Hiromi >> Intec NetCore, Inc. / Keio university >> hiromi@inetcore.com >> >> >> ------------------------------- >> Ruri Hiromi >> Intec NetCore, Inc. / Keio university >> hiromi@inetcore.com >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> addr-select-dt mailing list >> addr-select-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/addr-select-dt >> = > = > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Sep 11 15:04:29 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A2F3A68D6; Thu, 11 Sep 2008 15:04:29 -0700 (PDT) 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 ABFD93A68D6 for ; Thu, 11 Sep 2008 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=-2.248, BAYES_00=-2.599, FRT_POSSIBLE=2.697, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] 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 JI-QsSMwo4F8 for ; Thu, 11 Sep 2008 15:04:27 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 378DC3A67B4 for ; Thu, 11 Sep 2008 15:04:01 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (26-196.dynamic.dedicado.com.uy [200.108.196.26])by smtp01.uc3m.es (Postfix) with ESMTP id 9B4469F64F5; Fri, 12 Sep 2008 00:04:05 +0200 (CEST) Message-ID: <48C995D2.5070608@it.uc3m.es> Date: Fri, 12 Sep 2008 00:04:02 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Brian Haberman References: <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com><48C90F5C.205 0200@it.uc3m.es> <48C93B38.3010505@innovationslab.net> In-Reply-To: <48C93B38.3010505@innovationslab.net> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.1994 TC:1F TRN:85 TV:5.5.1026(16152.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] discussion point, task and members X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org ok, my bad, i thought that the scope of the DT was broader than that, = RFC3484 update in general, not limited to the policy table configuration. thanks for the clarification regards, marcelo Brian Haberman escribi=F3: > All, > Let me set the path for this design team. > > First, I have asked two members of this design team to act as co-chairs = > in order to ensure that consensus is reached within the design team on = > discussion points. Once I have gotten confirmation of their willingness = > to take on this role I will ask them chime in with their views on how = > they want to do that. > > Second, the initial focus of this work should be to determine how = > dynamic the updates of an address selection policy need to be. Once = > that is accomplished, the focus should be on determining what types of = > update approaches satisfy those needs. The third task is to assess = > whether those update solutions require/need 3484 to be updated. In some = > instances, I could envision solutions that simply use 3484 as guidelines = > and provide sufficient controls to address the current limitations in = > the RFC. > > Regards, > Brian > > marcelo bagnulo braun wrote: > = >> Ruri Hiromi escribi=F3: >> = >>> # resent on changing Subject line. >>> >>> Dear 3484 policy distribution design team, >>> >>> Here is a outline to start to discuss with. >>> >>> In this team, we will write a protocol design draft for dynamic policy = >>> table update. >>> = >> really? >> i thought that the team scope was broader than that, in particular i = >> thought we were supposed to update rfc3484. >> In rfc3484, the main issue that i identify is how to deal with multiple = >> addresses, in particualr how to deal with initial contact failures, when = >> the failure is due to a problem in the source address (e.g. due to = >> ingress filtering) >> >> dynamic update seems straight forward, i don't really see the need for a = >> design team, we just need peopel to write the specs. >> This other problem, otoh, seems much harder to me and could benefit from = >> new ideas and the expertise of this group >> >> Regards, marcelo >> >> >> = >>> I think here some points. How do you think about them? >>> >>> 1. definition of "default policy" and its administration >>> o a basic "default policy table" is described in RFC3484 but it will = >>> have additional address numbers like ORCHID, ULA and so on. >>> o Because of it's possibile modification it is hard to fix entire tab= le. >>> o It is better to refer up-to-date table and it seems better that = >>> IANA(or like such authorised organization) manages the table. >>> >>> 2. distribution mechanism >>> o Protocol >>> From the solution document, here is 4 types of = >>> mechanisms(obtain-all-info, routing-system-assistance, = >>> trial-and-error-approach, all-by-oneself), I think obtain-all-info = >>> using DHCPv6 or RA will be a suitable solution for a client connecting = >>> to a managed network. >>> But for other network requirement or use cases, we want to make a = >>> brand-new protocol? >>> In any cases, how do we consider about cooperation with other = >>> protocol(i.e, routing protocol)? >>> Can we use LDAP or other popular protocol? >>> o Timing >>> o Dynamics >>> o Other requirements from address-select-req >>> >>> 3. draft table of contents >>> (1) abstract >>> (2) terminology, definitions >>> (3) data format, syntacs >>> (4) data type(request, response) >>> (5) security consideration >>> >>> 4. Milestone >>> o drafting at the end of Oct. 2008 >>> o presentation at the 6man next IETF73 >>> o the Goal is publishing the draft as RFC >>> >>> - Design Team Members >>> current 3484 policy dynamic update design team >>> - Marc Blanchet >>> - Tim Chown >>> - Marcelo Bagnulo Braun >>> - Suresh Krishnan >>> - Tony Hain >>> - Francis Dupont >>> - Evans TJ >>> - John.zhao >>> - Sebastien Roy >>> - Janos Mohacsi >>> - Tim Enos >>> - Teemu Savolainen >>> - Fujisaki Tomohiro >>> - Arifumi Matsumoto >>> - Ruri Hiromi >>> >>> - Sandbox >>> o ML addr-select-dt@ietf.org >>> o wiki coming soon? >>> >>> - references >>> >>> proposal for updating RFC3484 >>> http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt >>> Problem Statement >>> http://tools.ietf.org/html/rfc5220 >>> Requirement >>> http://tools.ietf.org/html/rfc5221 >>> Solution Analysis >>> http://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/ >>> shim6 >>> using DHC option to carry out distributing table >>> http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt >>> >>> Regards, >>> ------------------------------- >>> Ruri Hiromi >>> Intec NetCore, Inc. / Keio university >>> hiromi@inetcore.com >>> >>> >>> ------------------------------- >>> Ruri Hiromi >>> Intec NetCore, Inc. / Keio university >>> hiromi@inetcore.com >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> addr-select-dt mailing list >>> addr-select-dt@ietf.org >>> https://www.ietf.org/mailman/listinfo/addr-select-dt >>> = >>> = >> _______________________________________________ >> addr-select-dt mailing list >> addr-select-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/addr-select-dt >> = > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt > > = _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Sep 25 04:50:50 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2313A659A; Thu, 25 Sep 2008 04:50:50 -0700 (PDT) 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 DB0B93A67EA for ; Thu, 25 Sep 2008 04:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 vYDTqbT4N8Z1 for ; Thu, 25 Sep 2008 04:50:49 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id C31CD3A659A for ; Thu, 25 Sep 2008 04:50:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m8PBmVVD010177; Thu, 25 Sep 2008 13:48:31 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200809251148.m8PBmVVD010177@givry.fdupont.fr> From: Francis Dupont To: Ruri Hiromi In-reply-to: Your message of Thu, 11 Sep 2008 16:37:27 +0900. <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com> Date: Thu, 25 Sep 2008 13:48:31 +0200 Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] discussion point, task and members X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org In your previous mail you wrote: 1. definition of "default policy" and its administration => note the "default" word has to be defined here, i.e., what is the scope of this "default". It seems it is "system wide" but first it just moves the issue to the "system" definition and second larger or smaller granularities make sense (for instance "link wide" and "user wide"). Thanks Francis.Dupont@fdupont.fr PS: BTW I prefer pure text messages (no HTML copy, etc). _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Sun Sep 28 20:35:32 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E633A682E; Sun, 28 Sep 2008 20:35:32 -0700 (PDT) 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 4238D3A6A5E for ; Sun, 28 Sep 2008 20:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.698 X-Spam-Level: *** X-Spam-Status: No, score=3.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_74=0.6] 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 CwVi-CM55Pi9 for ; Sun, 28 Sep 2008 20:35:30 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [122.249.92.11]) by core3.amsl.com (Postfix) with ESMTP id E094C3A6A3D for ; Sun, 28 Sep 2008 20:35:26 -0700 (PDT) Received: from [IPv6:2403:2000:1:1:21b:63ff:febb:8ad8] (unknown [IPv6:2403:2000:1:1:21b:63ff:febb:8ad8]) by inc.inetcore.com (Postfix) with ESMTP id 22EC15F0832; Mon, 29 Sep 2008 12:35:08 +0900 (JST) Message-Id: From: Ruri Hiromi To: addr-select-dt@ietf.org, Brian Haberman In-Reply-To: <48C93B38.3010505@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Sep 2008 12:35:07 +0900 References: <7C0DCB96-0DDD-4E87-A2D2-1D38ACF6FB45@inetcore.com> <48C90F5C.2050200@it.uc3m.es> <48C93B38.3010505@innovationslab.net> X-Mailer: Apple Mail (2.929.2) Subject: [addr-select-dt] talking about "Dynamic" (Re: discussion point, task and members) X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hello, To determine how dynamic the updates of an address selection policy = need to be, here is a short talk about "Dynamic" inputed from japanese = tema metes. We can see 2 kinds of "dynamic" : - once in an initial of communication 1) just start to the communication 2) booting the interface settings 3) just gets address(es) from NDP 4) when an special use prefix(es) is assigned/advertised from IANA - administrative trigger(long duration might be allowed for updates = the table cases) 1) administrator set priority use of v4-v6, or global and ULA,etc 2) a renumbering occurs 3) routing table and forwarding table is changed(in site(with = related prefix)/out side of the site) If we consider of cooperation of routing, discussion issues is here; a) RFC3484 treats both of destination and source address selection = mechanisms and the destination selection has to cover a huge area but = end hosts just send a packet dependently with their router/gateway. = Because of this we focused on "source address selection" at this time. b) frequency : what is the most frequently timing in the = communication system? c) multiple routers / single router? --> changes from up/down with the IF, changes from route(s) = information in outer router(s), changes of route(s) information in = whole Internet --> input from router(s), if one of routers going down. In that time = it is better to simply stop DHCP/RA with related ineffectual route(s) level of Dynamic multicast What do you think of this? On 2008/09/12, at 0:37, Brian Haberman wrote: > All, > Let me set the path for this design team. > > First, I have asked two members of this design team to act as co- = > chairs > in order to ensure that consensus is reached within the design team on > discussion points. Once I have gotten confirmation of their = > willingness > to take on this role I will ask them chime in with their views on how > they want to do that. > > Second, the initial focus of this work should be to determine how > dynamic the updates of an address selection policy need to be. Once > that is accomplished, the focus should be on determining what types of > update approaches satisfy those needs. The third task is to assess > whether those update solutions require/need 3484 to be updated. In = > some > instances, I could envision solutions that simply use 3484 as = > guidelines > and provide sufficient controls to address the current limitations in > the RFC. > > Regards, > Brian > > marcelo bagnulo braun wrote: >> Ruri Hiromi escribi=F3: >>> # resent on changing Subject line. >>> >>> Dear 3484 policy distribution design team, >>> >>> Here is a outline to start to discuss with. >>> >>> In this team, we will write a protocol design draft for dynamic = >>> policy >>> table update. >> really? >> i thought that the team scope was broader than that, in particular i >> thought we were supposed to update rfc3484. >> In rfc3484, the main issue that i identify is how to deal with = >> multiple >> addresses, in particualr how to deal with initial contact failures, = >> when >> the failure is due to a problem in the source address (e.g. due to >> ingress filtering) >> >> dynamic update seems straight forward, i don't really see the need = >> for a >> design team, we just need peopel to write the specs. >> This other problem, otoh, seems much harder to me and could benefit = >> from >> new ideas and the expertise of this group >> >> Regards, marcelo >> >> >>> I think here some points. How do you think about them? >>> >>> 1. definition of "default policy" and its administration >>> o a basic "default policy table" is described in RFC3484 but it will >>> have additional address numbers like ORCHID, ULA and so on. >>> o Because of it's possibile modification it is hard to fix entire = >>> table. >>> o It is better to refer up-to-date table and it seems better that >>> IANA(or like such authorised organization) manages the table. >>> >>> 2. distribution mechanism >>> o Protocol >>> From the solution document, here is 4 types of >>> mechanisms(obtain-all-info, routing-system-assistance, >>> trial-and-error-approach, all-by-oneself), I think obtain-all-info >>> using DHCPv6 or RA will be a suitable solution for a client = >>> connecting >>> to a managed network. >>> But for other network requirement or use cases, we want to make a >>> brand-new protocol? >>> In any cases, how do we consider about cooperation with other >>> protocol(i.e, routing protocol)? >>> Can we use LDAP or other popular protocol? >>> o Timing >>> o Dynamics >>> o Other requirements from address-select-req >>> >>> 3. draft table of contents >>> (1) abstract >>> (2) terminology, definitions >>> (3) data format, syntacs >>> (4) data type(request, response) >>> (5) security consideration >>> >>> 4. Milestone >>> o drafting at the end of Oct. 2008 >>> o presentation at the 6man next IETF73 >>> o the Goal is publishing the draft as RFC >>> >>> - Design Team Members >>> current 3484 policy dynamic update design team >>> - Marc Blanchet >>> - Tim Chown >>> - Marcelo Bagnulo Braun >>> - Suresh Krishnan >>> - Tony Hain >>> - Francis Dupont >>> - Evans TJ >>> - John.zhao >>> - Sebastien Roy >>> - Janos Mohacsi >>> - Tim Enos >>> - Teemu Savolainen >>> - Fujisaki Tomohiro >>> - Arifumi Matsumoto >>> - Ruri Hiromi >>> >>> - Sandbox >>> o ML addr-select-dt@ietf.org >>> o wiki coming soon? >>> >>> - references >>> >>> proposal for updating RFC3484 >>> http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt >>> Problem Statement >>> http://tools.ietf.org/html/rfc5220 >>> Requirement >>> http://tools.ietf.org/html/rfc5221 >>> Solution Analysis >>> http://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/ >>> shim6 >>> using DHC option to carry out distributing table >>> http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt >>> >>> Regards, >>> ------------------------------- >>> Ruri Hiromi >>> Intec NetCore, Inc. / Keio university >>> hiromi@inetcore.com >>> ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt