From suresh.krishnan@ericsson.com Thu Jul 1 03:18:25 2010
Return-Path:
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 3F77F3A680F for ; Thu, 1 Jul 2010 03:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.293
X-Spam-Level:
X-Spam-Status: No, score=-4.293 tagged_above=-999 required=5 tests=[AWL=2.306, BAYES_00=-2.599, 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 eBzii9beSXKt for ; Thu, 1 Jul 2010 03:18:24 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 450293A6835 for ; Thu, 1 Jul 2010 03:18:24 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o61AQPcN024255; Thu, 1 Jul 2010 05:26:25 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.39]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 1 Jul 2010 06:18:34 -0400
From: Suresh Krishnan
To: Arifumi Matsumoto , "addr-select-dt@ietf.org"
Date: Thu, 1 Jul 2010 06:18:31 -0400
Thread-Topic: [addr-select-dt] 2nd teleconference
Thread-Index: AcsY6KKXmwEEVt0eQDCnY/OsgAEQhAAHfaWA
Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC14F95DA5E0B@EUSAACMS0703.eamcs.ericsson.se>
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net>
In-Reply-To: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [addr-select-dt] 2nd teleconference
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: ,
X-List-Received-Date: Thu, 01 Jul 2010 10:18:25 -0000
Hi Arifumi,
7/2 works well for me and I can make 7/5 if necessary. The other days do =
not work for me.
Thanks
Suresh
=20
> -----Original Message-----
> From: addr-select-dt-bounces@ietf.org=20
> [mailto:addr-select-dt-bounces@ietf.org] On Behalf Of Arifumi=20
> Matsumoto
> Sent: Wednesday, June 30, 2010 11:42 PM
> To: addr-select-dt@ietf.org
> Subject: [addr-select-dt] 2nd teleconference
>=20
> All,
>=20
> I'd like to schedule the 2nd telecon.
> For the 2nd telecon, we should look into concrete items to be=20
> included in our consideration document, and maybe in my=20
> document about policy conflict.
>=20
> And, I have some things that I want to share with you all.
>=20
> As everybody is in different place, so why not have a telecon=20
> at the same time as the previous one.
>=20
> That is,
> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>=20
> 7/2,5,6,7 work for me.
>=20
> Regards,
>=20
> --
> Arifumi Matsumoto
> Secure Communication Project
> NTT Information Sharing Platform Laboratories
> E-mail: arifumi@nttv6.net
>=20
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
> =
From tjc@ecs.soton.ac.uk Mon Jul 5 06:11:07 2010
Return-Path:
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 5D97E3A6987 for ; Mon, 5 Jul 2010 06:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 mUP948USaIWy for ; Mon, 5 Jul 2010 06:11:06 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 7130C3A67F9 for ; Mon, 5 Jul 2010 06:11:02 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o65DB08k005499 for ; Mon, 5 Jul 2010 14:11:00 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o65DB08k005499
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278335461; bh=6o85sdwdPlzoGSWBerhiRsxk140=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=y/5nbT0IwEB9uu2xZ91kCOuNZmYZ+VUo7+2a7H3C5jz5SAWxTV+Y2uvYyhVwm3RKZ Ey7KsgCn8u+f7ZBYtqRuGEWoW6Rw2ARO7PP1ZKMbT3WO7uhojJVwBwN3K8+WhRZoxg BdwerjILlssMINnWuWdskdcCF7uKkwsn2l09aERc=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m64EB00540054099Ez ret-id none; Mon, 05 Jul 2010 14:11:01 +0100
Received: from dhcp-152-78-61-245.ecs.soton.ac.uk (dhcp-152-78-61-245.ecs.soton.ac.uk [152.78.61.245]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o65DAxX7014808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Jul 2010 14:11:00 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown
In-Reply-To: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net>
Date: Mon, 5 Jul 2010 14:10:58 +0100
Content-Transfer-Encoding: 7bit
Message-ID:
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m64EB0054005409900; tid=m64EB00540054099Ez; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o65DB08k005499
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] 2nd teleconference
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: ,
X-List-Received-Date: Mon, 05 Jul 2010 13:11:07 -0000
Hi,
Sorry for the late reply. Now, only 7/7 would work for me.
Thursday or Friday this week are OK at the same time.
Tim
On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
> All,
>
> I'd like to schedule the 2nd telecon.
> For the 2nd telecon, we should look into concrete items
> to be included in our consideration document, and maybe
> in my document about policy conflict.
>
> And, I have some things that I want to share with you all.
>
> As everybody is in different place, so why not have a
> telecon at the same time as the previous one.
>
> That is,
> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>
> 7/2,5,6,7 work for me.
>
> Regards,
>
> --
> Arifumi Matsumoto
> Secure Communication Project
> NTT Information Sharing Platform Laboratories
> E-mail: arifumi@nttv6.net
>
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
From arifumi@nttv6.net Tue Jul 6 02:17:33 2010
Return-Path:
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 A38783A6823 for ; Tue, 6 Jul 2010 02:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 RTctdbRvwB8Y for ; Tue, 6 Jul 2010 02:17:33 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 824E43A67F5 for ; Tue, 6 Jul 2010 02:17:32 -0700 (PDT)
Received: from [IPv6:2001:fa8:1000::2c26:3059:169a:2ded] ([IPv6:2001:fa8:1000:0:2c26:3059:169a:2ded]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o669HWwT076648 for ; Tue, 6 Jul 2010 18:17:32 +0900 (JST) (envelope-from arifumi@nttv6.net)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Arifumi Matsumoto
In-Reply-To:
Date: Tue, 6 Jul 2010 18:17:32 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net>
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 06 Jul 2010 18:17:33 +0900 (JST)
Subject: Re: [addr-select-dt] 2nd teleconference
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: ,
X-List-Received-Date: Tue, 06 Jul 2010 09:17:33 -0000
All,
would you all please let us know 7/8 and 9 work or not.
Please e-mail by 7/7.
Tony, can you setup WebEx again ?
On 2010/07/05, at 22:10, Tim Chown wrote:
> Hi,
>
> Sorry for the late reply. Now, only 7/7 would work for me.
>
> Thursday or Friday this week are OK at the same time.
>
> Tim
>
> On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
>
>> All,
>>
>> I'd like to schedule the 2nd telecon.
>> For the 2nd telecon, we should look into concrete items
>> to be included in our consideration document, and maybe
>> in my document about policy conflict.
>>
>> And, I have some things that I want to share with you all.
>>
>> As everybody is in different place, so why not have a
>> telecon at the same time as the previous one.
>>
>> That is,
>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>
>> 7/2,5,6,7 work for me.
>>
>> Regards,
>>
>> --
>> Arifumi Matsumoto
>> Secure Communication Project
>> NTT Information Sharing Platform Laboratories
>> E-mail: arifumi@nttv6.net
>>
>> _______________________________________________
>> 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
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arifumi@nttv6.net
From alh-ietf@tndh.net Tue Jul 6 08:44:23 2010
Return-Path:
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 109AC3A680D for ; Tue, 6 Jul 2010 08:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.02
X-Spam-Level: *
X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372]
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 F5CJwcLiLCMQ for ; Tue, 6 Jul 2010 08:44:22 -0700 (PDT)
Received: from smtp.tndh.net (static-66-15-163-216.bdsl.verizon.net [66.15.163.216]) by core3.amsl.com (Postfix) with ESMTP id 00ACE3A65A6 for ; Tue, 6 Jul 2010 08:44:22 -0700 (PDT)
Received: from server.tndh.net ([192.168.123.10] helo=eagle) by smtp.tndh.net with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OWAJg-0008pY-8D; Tue, 06 Jul 2010 08:44:22 -0700
From: "Tony Hain"
To: "'Arifumi Matsumoto'" ,
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net>
In-Reply-To: <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net>
Date: Tue, 6 Jul 2010 08:44:07 -0700
Message-ID: <0ac701cb1d22$11c1acb0$35450610$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acsc7CBN1owulCamSq+zuDN1EaefhQANc3bA
Content-Language: en-us
Subject: Re: [addr-select-dt] 2nd teleconference
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: alh-ietf@tndh.net
List-Id: IPv6 Address Selection Design Team
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 06 Jul 2010 15:44:23 -0000
I can only do 7 or 8, and I can set up a webex.
Tony
> -----Original Message-----
> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
> Sent: Tuesday, July 06, 2010 2:18 AM
> To: addr-select-dt@ietf.org
> Subject: Re: [addr-select-dt] 2nd teleconference
>
> All,
>
> would you all please let us know 7/8 and 9 work or not.
> Please e-mail by 7/7.
>
> Tony, can you setup WebEx again ?
>
> On 2010/07/05, at 22:10, Tim Chown wrote:
>
> > Hi,
> >
> > Sorry for the late reply. Now, only 7/7 would work for me.
> >
> > Thursday or Friday this week are OK at the same time.
> >
> > Tim
> >
> > On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
> >
> >> All,
> >>
> >> I'd like to schedule the 2nd telecon.
> >> For the 2nd telecon, we should look into concrete items
> >> to be included in our consideration document, and maybe
> >> in my document about policy conflict.
> >>
> >> And, I have some things that I want to share with you all.
> >>
> >> As everybody is in different place, so why not have a
> >> telecon at the same time as the previous one.
> >>
> >> That is,
> >> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
> >>
> >> 7/2,5,6,7 work for me.
> >>
> >> Regards,
> >>
> >> --
> >> Arifumi Matsumoto
> >> Secure Communication Project
> >> NTT Information Sharing Platform Laboratories
> >> E-mail: arifumi@nttv6.net
> >>
> >> _______________________________________________
> >> 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
>
>
> --
> Arifumi Matsumoto
> Secure Communication Project
> NTT Information Sharing Platform Laboratories
> E-mail: arifumi@nttv6.net
>
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
From arifumi@nttv6.net Wed Jul 7 01:13:31 2010
Return-Path:
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 B44EF3A6880 for ; Wed, 7 Jul 2010 01:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 xfhRK6r20VoS for ; Wed, 7 Jul 2010 01:13:24 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C0A803A67CC for ; Wed, 7 Jul 2010 01:13:23 -0700 (PDT)
Received: from [IPv6:2001:fa8:1000::b59a:74b3:5029:82c8] ([IPv6:2001:fa8:1000:0:b59a:74b3:5029:82c8]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o678DOoL085276; Wed, 7 Jul 2010 17:13:24 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Arifumi Matsumoto
In-Reply-To: <0ac701cb1d22$11c1acb0$35450610$@net>
Date: Wed, 7 Jul 2010 17:13:24 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net>
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net> <0ac701cb1d22$11c1acb0$35450610$@net>
To:
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 07 Jul 2010 17:13:25 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] 2nd teleconference
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: ,
X-List-Received-Date: Wed, 07 Jul 2010 08:13:32 -0000
All,
let me fix the telecon for 7/8 at the same time as before.
>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
Tony, would you please setup the webex ?
The cut-off for the revision draft is just ahead of us.
We should discuss about the actual text or something close to it
to make it for the cut-off.
I'll try to put together some candidate texts, so that we can
just choose one from the candidates.
A brief agenda off the top of my head is,
- Design Team merger with draft-troan-multihoming-without-nat66.
- Applicability statement in our draft.
- Updates for conflict draft.
- Strategy for IETF78 presentation.
- [please add here]
Best wishes,
On 2010/07/07, at 0:44, Tony Hain wrote:
> I can only do 7 or 8, and I can set up a webex.
>
> Tony
>
>
>> -----Original Message-----
>> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
>> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
>> Sent: Tuesday, July 06, 2010 2:18 AM
>> To: addr-select-dt@ietf.org
>> Subject: Re: [addr-select-dt] 2nd teleconference
>>
>> All,
>>
>> would you all please let us know 7/8 and 9 work or not.
>> Please e-mail by 7/7.
>>
>> Tony, can you setup WebEx again ?
>>
>> On 2010/07/05, at 22:10, Tim Chown wrote:
>>
>>> Hi,
>>>
>>> Sorry for the late reply. Now, only 7/7 would work for me.
>>>
>>> Thursday or Friday this week are OK at the same time.
>>>
>>> Tim
>>>
>>> On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
>>>
>>>> All,
>>>>
>>>> I'd like to schedule the 2nd telecon.
>>>> For the 2nd telecon, we should look into concrete items
>>>> to be included in our consideration document, and maybe
>>>> in my document about policy conflict.
>>>>
>>>> And, I have some things that I want to share with you all.
>>>>
>>>> As everybody is in different place, so why not have a
>>>> telecon at the same time as the previous one.
>>>>
>>>> That is,
>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>>>
>>>> 7/2,5,6,7 work for me.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Arifumi Matsumoto
>>>> Secure Communication Project
>>>> NTT Information Sharing Platform Laboratories
>>>> E-mail: arifumi@nttv6.net
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> --
>> Arifumi Matsumoto
>> Secure Communication Project
>> NTT Information Sharing Platform Laboratories
>> E-mail: arifumi@nttv6.net
>>
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arifumi@nttv6.net
From alh-ietf@tndh.net Wed Jul 7 20:53:08 2010
Return-Path:
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 DD8613A67CC for ; Wed, 7 Jul 2010 20:53:08 -0700 (PDT)
X-Quarantine-ID:
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Subject"
X-Spam-Flag: NO
X-Spam-Score: 4.976
X-Spam-Level: ****
X-Spam-Status: No, score=4.976 tagged_above=-999 required=5 tests=[AWL=-3.956, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, HEADER_COUNT_SUBJECT=3.096, HOST_EQ_STATICB=1.372, SARE_OBFU_SPLIT_HR2=0.183, TVD_SPACE_RATIO=2.219]
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 e2K+GIQuX+Du for ; Wed, 7 Jul 2010 20:53:08 -0700 (PDT)
Received: from smtp.tndh.net (static-66-15-163-216.bdsl.verizon.net [66.15.163.216]) by core3.amsl.com (Postfix) with ESMTP id D64053A6359 for ; Wed, 7 Jul 2010 20:53:07 -0700 (PDT)
Received: from server.tndh.net ([192.168.123.10] helo=eagle) by smtp.tndh.net with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OWiAc-000A8c-Mx for addr-select-dt@ietf.org; Wed, 07 Jul 2010 20:53:09 -0700
From: "Tony Hain"
To:
Date: Wed, 7 Jul 2010 20:52:53 -0700
Message-ID: <0e4901cb1e51$0b6fed60$224fc820$@net>
MIME-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acsd7Ua565S8lPPDRTe2e01hJ5Hn0AAAAHfQAAJY0MAAFoGpQA==
Content-Language: en-us
Subject: [addr-select-dt] FW: addr-select-dt
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: alh-ietf@tndh.net
List-Id: IPv6 Address Selection Design Team
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 08 Jul 2010 03:53:09 -0000
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
ATTENDEE;CN=addr-select-dt@ietf.org;RSVP=TRUE:mailto:addr-select-dt@ietf.or
g
CLASS:PUBLIC
CREATED:20100708T035025Z
DESCRIPTION:When: Thursday\, July 08\, 2010 7:00 AM-8:00 AM (GMT-08:00) Pac
ific Time (US & Canada).\nWhere: webex\n\nNote: The GMT offset above does
not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\n I
don't know why this is not coming back to me over the list.\n\n-----Origi
nal Appointment-----\nFrom: Tony Hain [mailto:alh-ietf@tndh.net] \nSent: W
ednesday\, July 07\, 2010 10:07 AM\nTo: 'addr-select-dt@ietf.org'\nSubject
: FW: addr-select-dt\nWhen: Thursday\, July 08\, 2010 7:00 AM-8:00 AM (GMT
-08:00) Pacific Time (US & Canada).\nWhere: webex\n\n\nThis was originally
sent from the Cisco account which is not a list member.....\n\n-----Origi
nal Appointment-----\nFrom: Tony Hain [mailto:ahain@cisco.com] \nSent: Wed
nesday\, July 07\, 2010 8:59 AM\nTo: 'addr-select-dt@ietf.org'\nSubject: a
ddr-select-dt\nWhen: Thursday\, July 08\, 2010 7:00 AM-8:00 AM (GMT-08:00)
Pacific Time (US & Canada).\nWhere: webex\n\n\nAnthony Hain invites you t
o an online meeting using WebEx.\n\nMeeting Number: 206 537 572\nMeeting P
assword: addr-select\n\n--------------------------------------------------
-----\nTo join this meeting (Now from iPhones and other Smartphones too!)\
n-------------------------------------------------------\n1. Go to https:/
/ciscosales.webex.com/ciscosales/j.php?J=206537572&PW=NZjgyYmUwY2Rl\n2. En
ter the meeting password: addr-select\n3. Click "Join Now".\n4. Follow the
instructions that appear on your screen.\n\n\n---------------------------
-------------------------------------\nALERT:Toll-Free Dial Restrictions f
or (408) and (919) Area Codes\n-------------------------------------------
---------------------\n\nThe affected toll free numbers are: (866) 432-990
3 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.\n\nP
lease dial the local access number for your area from the list below:\n-
San Jose/Milpitas (408) area: 525-6800\n- RTP (919) area: 392-3330\n\n-
------------------------------------------------------ \nTo join the telec
onference only \n------------------------------------------------------- \
n1. Dial into Cisco WebEx (view all Global Access Numbers at \nhttp://cisc
o.com/en/US/about/doing_business/conferencing/index.html \n2. Follow the p
rompts to enter the Meeting Number (listed above) or Access Code followed
by the # sign. \n\nSan Jose\, CA: +1.408.525.6800 RTP: +1.919.392.3330 \n
\nUS/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 \n\nIndia:
+91.80.4350.1111 Germany: +49.619.6773.9002 \n\nJapan: +81.3.5763.9394 C
hina: +86.10.8515.5666\n\nhttp://www.webex.com\n\nCCP:+14085256800x2065375
72#\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during th
e session to be recorded. By joining this session\, you automatically cons
ent to such recordings. If you do not consent to the recording\, do not jo
in the session. \n
DTEND:20100708T150000Z
DTSTAMP:20100707T155847Z
DTSTART:20100708T140000Z
LAST-MODIFIED:20100708T035253Z
LOCATION:webex
ORGANIZER;CN="Tony Hain":mailto:alh-ietf@tndh.net
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-us:FW: addr-select-dt
TRANSP:OPAQUE
UID:040000008200E00074C5B7101A82E008000000002017469AB21DCB01000000000000000
0100000003AD015E62402E74CA0C0872BB86B5CD9
X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\nWhen: Thursday\, July 08\, 2010 7:00 AM-8:00 AM (GMT-08:00) Pacific Ti
me (US &\; Canada).
\n\n
Where: webex
\n\nNote: The GMT offset above does not reflec
t daylight saving time adjustments.
\n\n*~*~*~*~*~*~*~*~*~*
\n\
n \;I don't know why this is
not coming back to me over the list.
\n\n-----Original Appointme
nt-----
\n\nFrom: Tony Hain [
mailto:alh-ietf@tndh.net]
\n\nSent: Wednesday\, July 07\, 2
010 10:07 AM
\n\nTo: 'addr-select-dt@ietf.org'
\n\nSub
ject: FW: addr-select-dt
\n\nWhen: Thursday\, July 08\, 2010 7:0
0 AM-8:00 AM (GMT-08:00) Pacific Time (US &\; Canada).
\n\nWh
ere: webex
\n
\n\nThis was originally sent from the Cisco acc
ount which is not a list member.....
\n\n-----Original Appointme
nt-----
\n\nFrom: Tony Hain [ma
ilto:ahain@cisco.com]
\n\nSent: Wednesday\, July 07\, 2010
8:59 AM
\n\nTo: 'addr-select-dt@ietf.org'
\n\n<
P DIR=LTR>Subject:
addr-select-dt
\n\nWhen: Thursday\, July 08\, 2010 7:00 AM-8:00
AM (GMT-08:00) Pacific Time (US &\; Canada).
\n\nWhere: webe
x
\n
\n\nAnthony Hain invites you to an online meeting using
WebEx.
\n\nMeeting Number: 206 537 572
\n\nMeeting Pas
sword: addr-select
\n\n-----------------------------------------
--------------
\n\nTo join this meeting (Now from iPhones and ot
her Smartphones too!)
\n\n<
FONT COLOR="#1F497D" FACE="Calibri">--------------------------------------
-----------------
\n\n1. Go to https://ciscosales.web
ex.com/ciscosales/j.php?J=206537572&PW=NZjgyYmUwY2Rl
\n\n2.
Enter the meeting password: addr-select
\n\n3. Click "\;Join
Now"\;.
\n\n4. Follow the instructions that appear on your
screen.
\n
\n\n----------------------------------------------
------------------
\n\nALERT:Toll-Free Dial Restrictions for (40
8) and (919) Area Codes
\n\n------------------------------------
----------------------------
\n\nThe affected toll free numbers
are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for
the RTP area.
\n\nPlease dial the local access number for your a
rea from the list below:
\n\n- \; San Jose/Milpitas (408) ar
ea: \; 525-6800
\n\n- \; RTP (919) area: \; 392-3330
\n\n-------------------------------------------------------
\n\nTo join the teleconference only
\n\n---------------
----------------------------------------
\n\n
1. Dial into Cisco
WebEx (view all Global Access Numbers at
\n\nhttp://cisco.
com/en/US/about/doing_business/conferencing/index.html <
/P>\n\n
2. Follow the prompts to enter the Meeting Number (listed above) or Access
Code followed by the # sign.
\n\nSan Jose\, CA: +1.408.525.680
0 \; RTP: +1.919.392.3330
\n\nUS/Canada: +1.866.432.9903&nb
sp\; United Kingdom: +44.20.8824.0117
\n\nIndia: +91.80.4350.11
11 \; Germany: +49.619.6773.9002
\n\nJapan: +81.3.5763.9394
 \; China: +86.10.8515.5666
\n\nhttp://www.webex.com
\n\nCCP:+14085256800x206537572#
\n\n<
FONT COLOR="#1F497D" FACE="Calibri">IMPORTANT NOTICE: This WebEx service i
ncludes a feature that allows audio and any documents and other materials
exchanged or viewed during the session to be recorded. By joining this ses
sion\, you automatically consent to such recordings. If you do not consent
to the recording\, do not join the session. \;
\n\n\n
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-ALLOWEXTERNCHECK:TRUE
X-MS-OLK-AUTOSTARTCHECK:FALSE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
From arifumi@nttv6.net Thu Jul 8 06:46:34 2010
Return-Path:
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 0D23B3A67A1 for ; Thu, 8 Jul 2010 06:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 t7vp9lp6r+vy for ; Thu, 8 Jul 2010 06:46:28 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 3368B3A6407 for ; Thu, 8 Jul 2010 06:46:26 -0700 (PDT)
Received: from radiko.smartstream.ne.jp (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o68Dj88h096496; Thu, 8 Jul 2010 22:45:38 +0900 (JST) (envelope-from arifumi@nttv6.net)
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net> <0ac701cb1d22$11c1acb0$35450610$@net> <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net>
In-Reply-To: <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
Message-Id:
Content-Transfer-Encoding: quoted-printable
From: Arifumi Matsumoto
Date: Thu, 8 Jul 2010 22:45:08 +0900
To: alh-ietf@tndh.net, addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:::1]); Thu, 08 Jul 2010 22:46:29 +0900 (JST)
Subject: Re: [addr-select-dt] 2nd teleconference
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: ,
X-List-Received-Date: Thu, 08 Jul 2010 13:46:34 -0000
Hi,
some of my thoughts below.
* general rule for conflict and merge
There is a design choice of
1. the mechanism should allow the merge of two or more polcy sets even =
if there is a conflict between them.
2. the mechanism should allow the merge if there is no conflict.
3. the mechanism should not allow the merge of multiple policy sets.
As studied in my conflict draft, it is not easy to merge two policy =
sets even if there is no conflict.
So, IMO, we should separate every case of policy merge from the basic =
spec.
It means also the merge of a received policy set and the default policy =
and the merge
of any policy sets with manually configured policy set.
That is, one policy set is treated as one atomic information just like =
a DNS server option.
=20
In that case, we should define/endorse the relation between =
auto-configured policy,=20
and manually configured policy and default policy.
I think it should be configurable by user which to choose between =
auto-configured policy
and manually configured policy. These policy sets should override the =
default policy.
And, by default, a host should use auto-configured policy.
These relation should be implementation dependent, though.
* applicability
If we can agree on above, the applicability statement should be =
something like:
=20
This mechanism SHOULD be used only when the administrator of a site =
can make
sure that the address selection information receiver will not receive =
the same kind
of information from any other entity, or the receiver can accept and =
process the received
multiple policy sets correctly, e.g. by using pre-configured =
information.
Even if we define the applicability as above, the mechanism itself =
helps a lot of
important problems, stated in RFC5220 and =
draft-troan-multihoming-without-nat66, etc.
=20
* what happens if multiple policy sets are received
Even if we decided as above, it would be helpful if we can define the =
behavior when
a node received multiple policy sets, and it minimizes the bad effect =
from it.
I think the best way for it is to use a policy set received on the most =
preferred interface.
The most preferred means manual configuration, and OS dependent value.
As studied in mif wg, a lot of implementation has metric value for each =
interface, and
makes use of it to tie-break.
I think we can follow the manner of them here to minimize the damage.
=20
Regards,
On 2010/07/07, at 17:13, Arifumi Matsumoto wrote:
> All,
>=20
> let me fix the telecon for 7/8 at the same time as before.
>>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>=20
>=20
> Tony, would you please setup the webex ?
>=20
> The cut-off for the revision draft is just ahead of us.
>=20
> We should discuss about the actual text or something close to it
> to make it for the cut-off.
>=20
> I'll try to put together some candidate texts, so that we can=20
> just choose one from the candidates.
>=20
> A brief agenda off the top of my head is,
>=20
> - Design Team merger with draft-troan-multihoming-without-nat66.
>=20
> - Applicability statement in our draft.
>=20
> - Updates for conflict draft.
>=20
> - Strategy for IETF78 presentation.
>=20
> - [please add here]
>=20
> Best wishes,
>=20
> On 2010/07/07, at 0:44, Tony Hain wrote:
>=20
>> I can only do 7 or 8, and I can set up a webex.
>>=20
>> Tony
>>=20
>>=20
>>> -----Original Message-----
>>> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
>>> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
>>> Sent: Tuesday, July 06, 2010 2:18 AM
>>> To: addr-select-dt@ietf.org
>>> Subject: Re: [addr-select-dt] 2nd teleconference
>>>=20
>>> All,
>>>=20
>>> would you all please let us know 7/8 and 9 work or not.
>>> Please e-mail by 7/7.
>>>=20
>>> Tony, can you setup WebEx again ?
>>>=20
>>> On 2010/07/05, at 22:10, Tim Chown wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> Sorry for the late reply. Now, only 7/7 would work for me.
>>>>=20
>>>> Thursday or Friday this week are OK at the same time.
>>>>=20
>>>> Tim
>>>>=20
>>>> On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
>>>>=20
>>>>> All,
>>>>>=20
>>>>> I'd like to schedule the 2nd telecon.
>>>>> For the 2nd telecon, we should look into concrete items
>>>>> to be included in our consideration document, and maybe
>>>>> in my document about policy conflict.
>>>>>=20
>>>>> And, I have some things that I want to share with you all.
>>>>>=20
>>>>> As everybody is in different place, so why not have a
>>>>> telecon at the same time as the previous one.
>>>>>=20
>>>>> That is,
>>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>>>>=20
>>>>> 7/2,5,6,7 work for me.
>>>>>=20
>>>>> Regards,
>>>>>=20
>>>>> --
>>>>> Arifumi Matsumoto
>>>>> Secure Communication Project
>>>>> NTT Information Sharing Platform Laboratories
>>>>> E-mail: arifumi@nttv6.net
>>>>>=20
>>>>> _______________________________________________
>>>>> addr-select-dt mailing list
>>>>> addr-select-dt@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>=20
>>>> _______________________________________________
>>>> addr-select-dt mailing list
>>>> addr-select-dt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>=20
>>>=20
>>> --
>>> Arifumi Matsumoto
>>> Secure Communication Project
>>> NTT Information Sharing Platform Laboratories
>>> E-mail: arifumi@nttv6.net
>>>=20
>>> _______________________________________________
>>> addr-select-dt mailing list
>>> addr-select-dt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>=20
>=20
>=20
> --
> Arifumi Matsumoto
> Secure Communication Project
> NTT Information Sharing Platform Laboratories
> E-mail: arifumi@nttv6.net
>=20
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
From alh-ietf@tndh.net Thu Jul 8 06:59:57 2010
Return-Path:
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 77E103A6818 for ; Thu, 8 Jul 2010 06:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.998
X-Spam-Level: **
X-Spam-Status: No, score=2.998 tagged_above=-999 required=5 tests=[AWL=1.978, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372]
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 v7qEw+LMDxMW for ; Thu, 8 Jul 2010 06:59:55 -0700 (PDT)
Received: from smtp.tndh.net (static-66-15-163-216.bdsl.verizon.net [66.15.163.216]) by core3.amsl.com (Postfix) with ESMTP id 52D3C3A6964 for ; Thu, 8 Jul 2010 06:59:55 -0700 (PDT)
Received: from server.tndh.net ([192.168.123.10] helo=eagle) by smtp.tndh.net with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OWrdh-000AYs-3S; Thu, 08 Jul 2010 06:59:57 -0700
From: "Tony Hain"
To: "'Arifumi Matsumoto'" ,
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net> <0ac701cb1d22$11c1acb0$35450610$@net> <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net>
In-Reply-To:
Date: Thu, 8 Jul 2010 06:59:30 -0700
Message-ID: <0ed601cb1ea5$c9468430$5bd38c90$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcsepANb0VQj58vxT36rV1OD9ZzMcQAAZPMA
Content-Language: en-us
Subject: Re: [addr-select-dt] 2nd teleconference
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: alh-ietf@tndh.net
List-Id: IPv6 Address Selection Design Team
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 08 Jul 2010 13:59:57 -0000
For some reason the webex announcement never would go to the list.
Here is another try:::
Anthony Hain invites you to an online meeting using WebEx.
Meeting Number: 206 537 572
Meeting Password: addr-select
-------------------------------------------------------
To join this meeting (Now from iPhones and other Smartphones too!)
-------------------------------------------------------
1. Go to
https://ciscosales.webex.com/ciscosales/j.php?J=206537572&PW=NZjgyYmUwY2Rl
2. Enter the meeting password: addr-select
3. Click "Join Now".
4. Follow the instructions that appear on your screen.
> -----Original Message-----
> From: Arifumi Matsumoto [mailto:arifumi@nttv6.net]
> Sent: Thursday, July 08, 2010 6:45 AM
> To: alh-ietf@tndh.net; addr-select-dt@ietf.org
> Subject: Re: [addr-select-dt] 2nd teleconference
>
> Hi,
>
> some of my thoughts below.
>
> * general rule for conflict and merge
>
> There is a design choice of
> 1. the mechanism should allow the merge of two or more polcy sets
> even if there is a conflict between them.
> 2. the mechanism should allow the merge if there is no conflict.
> 3. the mechanism should not allow the merge of multiple policy sets.
>
> As studied in my conflict draft, it is not easy to merge two policy
> sets even if there is no conflict.
> So, IMO, we should separate every case of policy merge from the basic
> spec.
> It means also the merge of a received policy set and the default
> policy and the merge
> of any policy sets with manually configured policy set.
>
> That is, one policy set is treated as one atomic information just like
> a DNS server option.
>
> In that case, we should define/endorse the relation between auto-
> configured policy,
> and manually configured policy and default policy.
> I think it should be configurable by user which to choose between
> auto-configured policy
> and manually configured policy. These policy sets should override the
> default policy.
> And, by default, a host should use auto-configured policy.
> These relation should be implementation dependent, though.
>
> * applicability
>
> If we can agree on above, the applicability statement should be
> something like:
>
> This mechanism SHOULD be used only when the administrator of a site
> can make
> sure that the address selection information receiver will not receive
> the same kind
> of information from any other entity, or the receiver can accept and
> process the received
> multiple policy sets correctly, e.g. by using pre-configured
> information.
>
> Even if we define the applicability as above, the mechanism itself
> helps a lot of
> important problems, stated in RFC5220 and draft-troan-multihoming-
> without-nat66, etc.
>
>
> * what happens if multiple policy sets are received
>
> Even if we decided as above, it would be helpful if we can define the
> behavior when
> a node received multiple policy sets, and it minimizes the bad effect
> from it.
>
> I think the best way for it is to use a policy set received on the
> most preferred interface.
> The most preferred means manual configuration, and OS dependent value.
> As studied in mif wg, a lot of implementation has metric value for
> each interface, and
> makes use of it to tie-break.
>
> I think we can follow the manner of them here to minimize the damage.
>
>
> Regards,
>
> On 2010/07/07, at 17:13, Arifumi Matsumoto wrote:
>
> > All,
> >
> > let me fix the telecon for 7/8 at the same time as before.
> >>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
> >
> >
> > Tony, would you please setup the webex ?
> >
> > The cut-off for the revision draft is just ahead of us.
> >
> > We should discuss about the actual text or something close to it
> > to make it for the cut-off.
> >
> > I'll try to put together some candidate texts, so that we can
> > just choose one from the candidates.
> >
> > A brief agenda off the top of my head is,
> >
> > - Design Team merger with draft-troan-multihoming-without-nat66.
> >
> > - Applicability statement in our draft.
> >
> > - Updates for conflict draft.
> >
> > - Strategy for IETF78 presentation.
> >
> > - [please add here]
> >
> > Best wishes,
> >
> > On 2010/07/07, at 0:44, Tony Hain wrote:
> >
> >> I can only do 7 or 8, and I can set up a webex.
> >>
> >> Tony
> >>
> >>
> >>> -----Original Message-----
> >>> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
> >>> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
> >>> Sent: Tuesday, July 06, 2010 2:18 AM
> >>> To: addr-select-dt@ietf.org
> >>> Subject: Re: [addr-select-dt] 2nd teleconference
> >>>
> >>> All,
> >>>
> >>> would you all please let us know 7/8 and 9 work or not.
> >>> Please e-mail by 7/7.
> >>>
> >>> Tony, can you setup WebEx again ?
> >>>
> >>> On 2010/07/05, at 22:10, Tim Chown wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Sorry for the late reply. Now, only 7/7 would work for me.
> >>>>
> >>>> Thursday or Friday this week are OK at the same time.
> >>>>
> >>>> Tim
> >>>>
> >>>> On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
> >>>>
> >>>>> All,
> >>>>>
> >>>>> I'd like to schedule the 2nd telecon.
> >>>>> For the 2nd telecon, we should look into concrete items
> >>>>> to be included in our consideration document, and maybe
> >>>>> in my document about policy conflict.
> >>>>>
> >>>>> And, I have some things that I want to share with you all.
> >>>>>
> >>>>> As everybody is in different place, so why not have a
> >>>>> telecon at the same time as the previous one.
> >>>>>
> >>>>> That is,
> >>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
> >>>>>
> >>>>> 7/2,5,6,7 work for me.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> --
> >>>>> Arifumi Matsumoto
> >>>>> Secure Communication Project
> >>>>> NTT Information Sharing Platform Laboratories
> >>>>> E-mail: arifumi@nttv6.net
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>>
> >>> --
> >>> Arifumi Matsumoto
> >>> Secure Communication Project
> >>> NTT Information Sharing Platform Laboratories
> >>> E-mail: arifumi@nttv6.net
> >>>
> >>> _______________________________________________
> >>> addr-select-dt mailing list
> >>> addr-select-dt@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/addr-select-dt
> >>
> >
> >
> > --
> > Arifumi Matsumoto
> > Secure Communication Project
> > NTT Information Sharing Platform Laboratories
> > E-mail: arifumi@nttv6.net
> >
> > _______________________________________________
> > addr-select-dt mailing list
> > addr-select-dt@ietf.org
> > https://www.ietf.org/mailman/listinfo/addr-select-dt
From ahain@cisco.com Wed Jul 7 08:59:09 2010
Return-Path:
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 CCBD73A6812 for ; Wed, 7 Jul 2010 08:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.177
X-Spam-Level:
X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_SPLIT_HR2=0.183, TVD_SPACE_RATIO=2.219]
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 LW5OUpEu5gEY for ; Wed, 7 Jul 2010 08:59:09 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 18A6D3A67D3 for ; Wed, 7 Jul 2010 08:59:09 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgHAJtBNEyrRN+K/2dsb2JhbACDHZA0gRaLK24DpwSBfQsBhx+RRQ2BHIMJcgSDeA
X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="555523975"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2010 15:59:00 +0000
Received: from eagle (ssh-sjc-2.cisco.com [171.68.46.188]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o67Fwx8X026283 for ; Wed, 7 Jul 2010 15:58:59 GMT
From: "Tony Hain"
Sender: "Tony Hain"
To:
Date: Wed, 7 Jul 2010 08:58:49 -0700
Message-ID: <0d0c01cb1ded$4a5dff80$df19fe80$@net>
MIME-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acsd7Ua565S8lPPDRTe2e01hJ5Hn0AAAAHfQ
Content-Language: en-us
X-Mailman-Approved-At: Sun, 11 Jul 2010 06:00:56 -0700
Subject: [addr-select-dt] addr-select-dt
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ahain@cisco.com
List-Id: IPv6 Address Selection Design Team
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 07 Jul 2010 15:59:09 -0000
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
ATTENDEE;CN=addr-select-dt@ietf.org;RSVP=TRUE:mailto:addr-select-dt@ietf.or
g
CLASS:PUBLIC
CREATED:20100707T155847Z
DESCRIPTION:When: Thursday\, July 08\, 2010 7:00 AM-8:00 AM (GMT-08:00) Pac
ific Time (US & Canada).\nWhere: webex\n\nNote: The GMT offset above does
not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\nAn
thony Hain invites you to an online meeting using WebEx.\n\nMeeting Number
: 206 537 572\nMeeting Password: addr-select\n\n--------------------------
-----------------------------\nTo join this meeting (Now from iPhones and
other Smartphones too!)\n-------------------------------------------------
------\n1. Go to https://ciscosales.webex.com/ciscosales/j.php?J=206537572
&PW=NZjgyYmUwY2Rl\n2. Enter the meeting password: addr-select\n3. Click "J
oin Now".\n4. Follow the instructions that appear on your screen.\n\n\n---
-------------------------------------------------------------\nALERT:Toll-
Free Dial Restrictions for (408) and (919) Area Codes\n-------------------
---------------------------------------------\n\nThe affected toll free nu
mbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-352
0 for the RTP area.\n\nPlease dial the local access number for your area f
rom the list below:\n- San Jose/Milpitas (408) area: 525-6800\n- RTP (9
19) area: 392-3330\n\n---------------------------------------------------
---- \nTo join the teleconference only \n---------------------------------
---------------------- \n1. Dial into Cisco WebEx (view all Global Access
Numbers at \nhttp://cisco.com/en/US/about/doing_business/conferencing/inde
x.html \n2. Follow the prompts to enter the Meeting Number (listed above)
or Access Code followed by the # sign. \n\nSan Jose\, CA: +1.408.525.6800
RTP: +1.919.392.3330 \n\nUS/Canada: +1.866.432.9903 United Kingdom: +44.
20.8824.0117 \n\nIndia: +91.80.4350.1111 Germany: +49.619.6773.9002 \n\nJ
apan: +81.3.5763.9394 China: +86.10.8515.5666\n\nhttp://www.webex.com\n\n
CCP:+14085256800x206537572#\n\nIMPORTANT NOTICE: This WebEx service includ
es a feature that allows audio and any documents and other materials excha
nged or viewed during the session to be recorded. By joining this session\
, you automatically consent to such recordings. If you do not consent to t
he recording\, do not join the session. \n
DTEND:20100708T150000Z
DTSTAMP:20100707T155847Z
DTSTART:20100708T140000Z
LAST-MODIFIED:20100707T155848Z
LOCATION:webex
ORGANIZER;CN="Tony Hain":mailto:tony@tndh.net
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-us:addr-select-dt
TRANSP:OPAQUE
UID:040000008200E00074C5B7101A82E008000000002017469AB21DCB01000000000000000
0100000003AD015E62402E74CA0C0872BB86B5CD9
X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\nWhen: Thursday\, July 08\, 2010 7:00 AM-8:00 AM (GMT-08:00) Pacific Ti
me (US &\; Canada).
\n\n
Where: webex
\n\nNote: The GMT offset above does not reflec
t daylight saving time adjustments.
\n\n*~*~*~*~*~*~*~*~*~*
\n\
nAnthony Hain invites
you to an online meeting using WebEx.
\n\nMeeting Number: 206 537 572
\n\nMeeting Pass
word: addr-select
\n\n-------------------------------------------------------
\n\nTo j
oin this meeting (Now from iPhones and other Smartphones too!)
\n\n-------------
------------------------------------------
\n\n1. Go to https://ciscosales.webex.com/ciscosales/j.php?J=206537572
&\;PW=NZjgyYmUwY2Rl
\n\n2. Enter the meeting password: addr-select
\n\n3. Click "\;Join Now&q
uot\;.
\n\n4. Follow the instructions that appear on your screen.<
/P>\n
\n\n
----------
------------------------------------------------------
\n
\nALERT:Toll-Free Dial
Restrictions for (408) and (919) Area Codes
\n\n--------------------------------
--------------------------------
\n\nThe affected toll free numbers are: (866) 4
32-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area
.
\n\n
Please dial the local access number for your area from the list below:
\n\n-&nbs
p\; San Jose/Milpitas (408) area: \; 525-6800
\n\n- \; RTP (919) area:&n
bsp\; 392-3330
\n\n-------------------------------------------------------
\n\nTo joi
n the teleconference only
\n\n-------------------------------------------------
------
\n\n1. Dial into Cisco WebEx (view all Global Access Numbers at <
/SPAN>
\n\n
http://cisco.com/en/US/about/doing
_business/conferencing/index.html
\n\n2. Follow the prompts to en
ter the Meeting Number (listed above) or Access Code followed by the # sig
n.
\n\nSan Jose\, CA: +1.408.525.6800 \; RTP: +1.919.392.3330
\n\nUS/Canada: +1.
866.432.9903 \; United Kingdom: +44.20.8824.0117
\n\
nIndia: +91.80.4350.111
1 \; Germany: +49.619.6773.9002
\n\nJapan: +81.3.5763.9394 \; China: +8
6.10.8515.5666
\n\n<
A HREF="http://www.webex.com">http://www.webex.com
SPAN>
\n\n<
FONT FACE="Calibri">CCP:+14085256800x206537572#
\n\nIMPORTANT NOTICE: This WebEx
service includes a feature that allows audio and any documents and other
materials exchanged or viewed during the session to be recorded. By joinin
g this session\, you automatically consent to such recordings. If you do n
ot consent to the recording\, do not join the session. \;
\n\n\n
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-ALLOWEXTERNCHECK:TRUE
X-MS-OLK-AUTOSTARTCHECK:FALSE
X-MS-OLK-CONFTYPE:0
X-MS-OLK-SENDER;CN="Tony Hain":mailto:ahain@cisco.com
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
From ahain@cisco.com Thu Jul 8 10:08:30 2010
Return-Path:
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 9963A3A6B16 for ; Thu, 8 Jul 2010 10:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.74
X-Spam-Level:
X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8]
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 PGA9SNQe1+M9 for ; Thu, 8 Jul 2010 10:08:29 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BF5573A6B13 for ; Thu, 8 Jul 2010 10:08:29 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApcFAAujNUyrR7Ht/2dsb2JhbACTc4EWiyhxpnGBfgsBmG4NhRgEg3k
X-IronPort-AV: E=Sophos;i="4.53,559,1272844800"; d="scan'208";a="155781156"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 08 Jul 2010 17:08:34 +0000
Received: from eagle (ssh-sjc-2.cisco.com [171.68.46.188]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o68H8aTA000120 for ; Thu, 8 Jul 2010 17:08:36 GMT
From: "Tony Hain"
To:
Date: Thu, 8 Jul 2010 10:08:18 -0700
Message-ID: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcsewCjnNmWuUu/XRJqLverIhfUvdw==
Content-Language: en-us
X-Mailman-Approved-At: Sun, 11 Jul 2010 06:00:56 -0700
Subject: [addr-select-dt] Proposed default policy table
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ahain@cisco.com
List-Id: IPv6 Address Selection Design Team
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 08 Jul 2010 17:08:30 -0000
For updating 3484-revise section 2.2, the table I have been running at home
for some time is:
Precedence Label Prefix
---------- ----- --------------------------------
90 0 ::1/128
75 1 fc00::/8
70 1 fd00::/8
50 2 2001::/16
50 2 2400::/8
50 2 2600::/8
50 2 2a00::/8
50 2 2c00::/8
40 3 2002::/16
30 3 2001::/32
20 4 ::/0
10 5 ::ffff:0:0/96
5 6 ::/96
4 6 fec0::/16
The explicit label 2 set is due to a bug in the vista stack, as that should
be a single entry of 2000::/3, (and the fec0 should be /10). The differences
from the proposed one in the October text are:
- Adding explicit entries for each half of the ULA space to prefer local
when possible (rule 2).
- Explicitly listing 2000::/3 to avoid default resulting in the ambiguous
choice of ula as src.
- Keeping teredo and 6to4 as tunnels labeled the same.
- Tunnels before default to avoid the ambiguous choices default will result
in.
- packaging all deprecated prefixes in the same label.
The currently proposed table in 2.2 does not solve the problem in 1.1, so it
would be good to move that example to an appendix or at least after the 2.2
discussion, and replace it with the one of a host selecting between Internet
access and a closed network.
I understand the desire to move teredo to less than IPv4. While I disagree
with the premise, a resulting policy table that does that might look like:
Precedence Label Prefix
---------- ----- --------------------------------
90 0 ::1/128
75 1 fc00::/8
70 1 fd00::/8
60 2 2000::/3
50 3 ::/0
30 4 2002::/16
20 5 ::ffff:0:0/96
5 4 2001::/32
1 6 ::/96
1 6 fec0::/16
I suggest leaving 10, 40, & 80 in the precedence so people can move IPv4 or
ULA around without feeling the need to rewrite the other labels (they don't
have to, but an obvious hole to park it in reduces confusion). I haven't
tried that, and don't have time before I leave today, but I will put that in
and see how it works before the IETF meeting. It should be close to what the
current text was trying to get to, but with the explicit ula and gua
prefixes to avoid default it should work more consistently.
Tony
From tjc@ecs.soton.ac.uk Sun Jul 11 08:32:09 2010
Return-Path:
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 9ECEF3A6876 for ; Sun, 11 Jul 2010 08:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 OD8O0mCRSnJ3 for ; Sun, 11 Jul 2010 08:32:08 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id E8B303A67B1 for ; Sun, 11 Jul 2010 08:32:06 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFWAih029617 for ; Sun, 11 Jul 2010 16:32:10 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6BFWAih029617
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278862331; bh=mivATiCx//L5QckKtwS+QDiT+o0=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=om9Dv4R+AevSjGSx5aUs4HAgvWfgS+gSoQmwHMgSfdwH5J/7K1a+s4aOmkL+Gpkjx 32V3scji4Ir70X7Id5suDV/FnXrQITv6H50N/pWuJHZE3OaWTBHx2zZIAtTPwQC99R lSxNyVZDZO6TyeIeBVrmn9BI6QF1goNH6kuYcGrw=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m6AGWA0540022385F2 ret-id none; Sun, 11 Jul 2010 16:32:11 +0100
Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFUlYA015312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Jul 2010 16:30:47 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown
In-Reply-To:
Date: Sun, 11 Jul 2010 16:30:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID:
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net> <0ac701cb1d22$11c1acb0$35450610$@net> <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6AGWA054002238500; tid=m6AGWA0540022385F2; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6BFWAih029617
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] 2nd teleconference
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: ,
X-List-Received-Date: Sun, 11 Jul 2010 15:32:09 -0000
Tony, Arifumi and I attended the teleconference.
We discussed various topics, with the policy merging/conflict handling =
issue taking most of our time. We agreed the principles of Arifumi's =
text below were good, though Tony thought it should be scoped to 'within =
the local network'.
Because of the complexity of this topic, and the need to publish the =
address selection considerations draft, we agreed to document the =
conflict/merging problem concisely in the draft and move work on =
solution(s) to a new text. This would allow policy distribution in =
networks without policy conflict to be progressed. Tim will refresh =
the dt draft before the IETF78 cutoff.
=
http://tools.ietf.org/id/draft-ietf-6man-addr-select-considerations-00.txt=
The conflict/merge problem is hard. Conflict implies choice, which a =
general user may not be able to make, and merging may produce a =
suboptimal or even unusable result. The most common 'problem' scenario =
is probably the VPN one, where a user in a coffee shop or enterprise =
network wishes to use a VPN. It was noted that VPN clients typically =
have a user choice in 'send all data via VPN' or 'send only home network =
data via VPN' tickbox.
It was felt that the dt could work with the authors of the =
multihome-without-nat66 draft to bolster contributions to the problem =
space. While the Troan draft considers many of the issues the DT is =
concerned with it does not include policy conflict/merger.=20
http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00
The question arose again if whether RFC3484 should be per node (as now) =
or per interface.
Arifumi agreed to refresh the 3484-bis draft before the cutoff, and Tony =
offered to send some comments over the weekend. Ideally we would like =
to get 3484-bis to a publication-ready state as soon as possible. Many =
vendors/implementors have already implemented many of the changes in the =
current 3484-bis draft.
Tim
On 8 Jul 2010, at 14:45, Arifumi Matsumoto wrote:
> Hi,
>=20
> some of my thoughts below.
>=20
> * general rule for conflict and merge
>=20
> There is a design choice of
> 1. the mechanism should allow the merge of two or more polcy sets =
even if there is a conflict between them.
> 2. the mechanism should allow the merge if there is no conflict.
> 3. the mechanism should not allow the merge of multiple policy sets.
>=20
> As studied in my conflict draft, it is not easy to merge two policy =
sets even if there is no conflict.
> So, IMO, we should separate every case of policy merge from the basic =
spec.
> It means also the merge of a received policy set and the default =
policy and the merge
> of any policy sets with manually configured policy set.
>=20
> That is, one policy set is treated as one atomic information just like =
a DNS server option.
>=20
> In that case, we should define/endorse the relation between =
auto-configured policy,=20
> and manually configured policy and default policy.
> I think it should be configurable by user which to choose between =
auto-configured policy
> and manually configured policy. These policy sets should override the =
default policy.
> And, by default, a host should use auto-configured policy.
> These relation should be implementation dependent, though.
>=20
> * applicability
>=20
> If we can agree on above, the applicability statement should be =
something like:
>=20
> This mechanism SHOULD be used only when the administrator of a site =
can make
> sure that the address selection information receiver will not receive =
the same kind
> of information from any other entity, or the receiver can accept and =
process the received
> multiple policy sets correctly, e.g. by using pre-configured =
information.
>=20
> Even if we define the applicability as above, the mechanism itself =
helps a lot of
> important problems, stated in RFC5220 and =
draft-troan-multihoming-without-nat66, etc.
>=20
>=20
> * what happens if multiple policy sets are received
>=20
> Even if we decided as above, it would be helpful if we can define the =
behavior when
> a node received multiple policy sets, and it minimizes the bad effect =
from it.
>=20
> I think the best way for it is to use a policy set received on the =
most preferred interface.
> The most preferred means manual configuration, and OS dependent value.
> As studied in mif wg, a lot of implementation has metric value for =
each interface, and
> makes use of it to tie-break.
>=20
> I think we can follow the manner of them here to minimize the damage.
>=20
>=20
> Regards,
>=20
> On 2010/07/07, at 17:13, Arifumi Matsumoto wrote:
>=20
>> All,
>>=20
>> let me fix the telecon for 7/8 at the same time as before.
>>>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>=20
>>=20
>> Tony, would you please setup the webex ?
>>=20
>> The cut-off for the revision draft is just ahead of us.
>>=20
>> We should discuss about the actual text or something close to it
>> to make it for the cut-off.
>>=20
>> I'll try to put together some candidate texts, so that we can=20
>> just choose one from the candidates.
>>=20
>> A brief agenda off the top of my head is,
>>=20
>> - Design Team merger with draft-troan-multihoming-without-nat66.
>>=20
>> - Applicability statement in our draft.
>>=20
>> - Updates for conflict draft.
>>=20
>> - Strategy for IETF78 presentation.
>>=20
>> - [please add here]
>>=20
>> Best wishes,
>>=20
>> On 2010/07/07, at 0:44, Tony Hain wrote:
>>=20
>>> I can only do 7 or 8, and I can set up a webex.
>>>=20
>>> Tony
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
>>>> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
>>>> Sent: Tuesday, July 06, 2010 2:18 AM
>>>> To: addr-select-dt@ietf.org
>>>> Subject: Re: [addr-select-dt] 2nd teleconference
>>>>=20
>>>> All,
>>>>=20
>>>> would you all please let us know 7/8 and 9 work or not.
>>>> Please e-mail by 7/7.
>>>>=20
>>>> Tony, can you setup WebEx again ?
>>>>=20
>>>> On 2010/07/05, at 22:10, Tim Chown wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> Sorry for the late reply. Now, only 7/7 would work for me.
>>>>>=20
>>>>> Thursday or Friday this week are OK at the same time.
>>>>>=20
>>>>> Tim
>>>>>=20
>>>>> On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
>>>>>=20
>>>>>> All,
>>>>>>=20
>>>>>> I'd like to schedule the 2nd telecon.
>>>>>> For the 2nd telecon, we should look into concrete items
>>>>>> to be included in our consideration document, and maybe
>>>>>> in my document about policy conflict.
>>>>>>=20
>>>>>> And, I have some things that I want to share with you all.
>>>>>>=20
>>>>>> As everybody is in different place, so why not have a
>>>>>> telecon at the same time as the previous one.
>>>>>>=20
>>>>>> That is,
>>>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>>>>>=20
>>>>>> 7/2,5,6,7 work for me.
>>>>>>=20
>>>>>> Regards,
>>>>>>=20
>>>>>> --
>>>>>> Arifumi Matsumoto
>>>>>> Secure Communication Project
>>>>>> NTT Information Sharing Platform Laboratories
>>>>>> E-mail: arifumi@nttv6.net
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> addr-select-dt mailing list
>>>>>> addr-select-dt@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>>=20
>>>>> _______________________________________________
>>>>> addr-select-dt mailing list
>>>>> addr-select-dt@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>=20
>>>>=20
>>>> --
>>>> Arifumi Matsumoto
>>>> Secure Communication Project
>>>> NTT Information Sharing Platform Laboratories
>>>> E-mail: arifumi@nttv6.net
>>>>=20
>>>> _______________________________________________
>>>> addr-select-dt mailing list
>>>> addr-select-dt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>=20
>>=20
>>=20
>> --
>> Arifumi Matsumoto
>> Secure Communication Project
>> NTT Information Sharing Platform Laboratories
>> E-mail: arifumi@nttv6.net
>>=20
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>=20
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
From tjc@ecs.soton.ac.uk Sun Jul 11 08:38:33 2010
Return-Path:
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 5886F3A67F5 for ; Sun, 11 Jul 2010 08:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 bBuQeWNdjv+F for ; Sun, 11 Jul 2010 08:38:31 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 208923A67B1 for ; Sun, 11 Jul 2010 08:38:30 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFcVHH030400 for ; Sun, 11 Jul 2010 16:38:31 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6BFcVHH030400
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278862711; bh=SPDgymgEjv8oEkPc0/o2LP4vk0Y=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=3rXhJTMnAXzZtUl9UJ6/gOOHXv50q/wkKUIe2Izd5ZWbmEpn5HO38HISSQB7xEniQ gLvGs/da4+lD185HVZk5JS1W2DE0FblWM9GED8o+gC+BXlRamSC4JZ0qEJV6zsqqAA TAuhZ/huXBtN/5rYVrTDyHgBmZdTnKBV9yyRDzuw=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m6AGcV0540022400XK ret-id none; Sun, 11 Jul 2010 16:38:31 +0100
Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFcMk8016516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Jul 2010 16:38:22 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown
In-Reply-To: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
Date: Sun, 11 Jul 2010 16:38:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID:
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6AGcV054002240000; tid=m6AGcV0540022400XK; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6BFcVHH030400
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Sun, 11 Jul 2010 15:38:33 -0000
Tony,
Now that 6rd is done, what's the view on 6to4?
I know a lot of people would be quite keen to see 6to4 deprecated.
Tim
On 8 Jul 2010, at 18:08, Tony Hain wrote:
> For updating 3484-revise section 2.2, the table I have been running at =
home
> for some time is:
>=20
> Precedence Label Prefix
> ---------- ----- --------------------------------
> 90 0 ::1/128
> 75 1 fc00::/8
> 70 1 fd00::/8
> 50 2 2001::/16
> 50 2 2400::/8
> 50 2 2600::/8
> 50 2 2a00::/8
> 50 2 2c00::/8
> 40 3 2002::/16
> 30 3 2001::/32
> 20 4 ::/0
> 10 5 ::ffff:0:0/96
> 5 6 ::/96
> 4 6 fec0::/16
>=20
> The explicit label 2 set is due to a bug in the vista stack, as that =
should
> be a single entry of 2000::/3, (and the fec0 should be /10). The =
differences
> from the proposed one in the October text are:=20
> - Adding explicit entries for each half of the ULA space to prefer =
local
> when possible (rule 2).
> - Explicitly listing 2000::/3 to avoid default resulting in the =
ambiguous
> choice of ula as src.
> - Keeping teredo and 6to4 as tunnels labeled the same.
> - Tunnels before default to avoid the ambiguous choices default will =
result
> in.
> - packaging all deprecated prefixes in the same label.
>=20
> The currently proposed table in 2.2 does not solve the problem in 1.1, =
so it
> would be good to move that example to an appendix or at least after =
the 2.2
> discussion, and replace it with the one of a host selecting between =
Internet
> access and a closed network.=20
>=20
> I understand the desire to move teredo to less than IPv4. While I =
disagree
> with the premise, a resulting policy table that does that might look =
like:
>=20
> Precedence Label Prefix
> ---------- ----- --------------------------------
> 90 0 ::1/128
> 75 1 fc00::/8
> 70 1 fd00::/8
> 60 2 2000::/3
> 50 3 ::/0
> 30 4 2002::/16
> 20 5 ::ffff:0:0/96
> 5 4 2001::/32
> 1 6 ::/96
> 1 6 fec0::/16
>=20
> I suggest leaving 10, 40, & 80 in the precedence so people can move =
IPv4 or
> ULA around without feeling the need to rewrite the other labels (they =
don't
> have to, but an obvious hole to park it in reduces confusion). I =
haven't
> tried that, and don't have time before I leave today, but I will put =
that in
> and see how it works before the IETF meeting. It should be close to =
what the
> current text was trying to get to, but with the explicit ula and gua
> prefixes to avoid default it should work more consistently.
>=20
> Tony
>=20
>=20
>=20
>=20
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
From tjc@ecs.soton.ac.uk Sun Jul 11 10:13:53 2010
Return-Path:
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 1BDE23A69C8 for ; Sun, 11 Jul 2010 10:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 JlwZDlxDrTfq for ; Sun, 11 Jul 2010 10:13:52 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 4CE423A67F9 for ; Sun, 11 Jul 2010 10:13:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BHDsJW011901 for ; Sun, 11 Jul 2010 18:13:54 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6BHDsJW011901
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278868434; bh=xW2jRxneIcG3N/E82w59Bkymqio=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=iEkt1rHt35tFYTGj8TYCLByMcBoBwNrgtyGReOnBT1W7LGNj4IBpv2K1Y/TSqb4Ab Fp01vy5HT0C8UoRVrpitspdtwzwLrkk+JPaLHu1PugITgr6pCD3KxoVb5Mza2wOg07 zftt1Crkg/5rZvK7svNdFe+C8Mz7fUbfujBfaKSo=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m6AIDs0540022608L0 ret-id none; Sun, 11 Jul 2010 18:13:54 +0100
Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BHDnZS031274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Jul 2010 18:13:50 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown
In-Reply-To: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
Date: Sun, 11 Jul 2010 18:13:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID:
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <30111D11-0DAE-4A21-8AA9-2B75BABB82B8@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6AIDs054002260800; tid=m6AIDs0540022608L0; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6BHDsJW011901
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: [addr-select-dt] Update: draft-ietf-6man-addr-select-considerations-01
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: ,
X-List-Received-Date: Sun, 11 Jul 2010 17:13:53 -0000
For info, I have updated the dt draft with the output of the two =
telecons we've held:
http://www.ietf.org/id/draft-ietf-6man-addr-select-considerations-01.txt
If there are any additional changes you feel are needed before the =
cutoff, please email me.
Tim
From Aleksi.Suhonen@tut.fi Sun Jul 11 16:52:13 2010
Return-Path:
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 73A053A6A2A for ; Sun, 11 Jul 2010 16:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 i3+oEWO86BnA for ; Sun, 11 Jul 2010 16:52:12 -0700 (PDT)
Received: from mail-gw1.cc.tut.fi (mail-gw1.cc.tut.fi [130.230.160.15]) by core3.amsl.com (Postfix) with ESMTP id 554F13A68B5 for ; Sun, 11 Jul 2010 16:52:11 -0700 (PDT)
X-AuditID: 82e6a00f-b7b21ae0000009cc-66-4c3a59316691
Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw1.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id 75.18.02508.1395A3C4; Mon, 12 Jul 2010 02:52:17 +0300 (EEST)
Received: from [130.230.52.51] (halli.atm.tut.fi [130.230.52.51]) by mail1.tut.fi (Postfix) with ESMTP id 5C19C11FD97 for ; Mon, 12 Jul 2010 02:52:17 +0300 (EEST)
Message-ID: <4C3A5931.40709@tut.fi>
Date: Sun, 11 Jul 2010 23:52:17 +0000
From: Aleksi Suhonen
Organization: Tampere University of Technology / Department of Communications Engineering
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4
MIME-Version: 1.0
To: addr-select-dt@ietf.org
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
In-Reply-To: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Sun, 11 Jul 2010 23:52:13 -0000
Hi,
Tony wrote:
> I suggest leaving 10, 40,& 80 in the precedence so people can move IPv4 or
> ULA around without feeling the need to rewrite the other labels (they don't
> have to, but an obvious hole to park it in reduces confusion).
The number of bits in the precedence value has not been defined, but I
understand that most implementations use at least 32 bits anyway. I
would like to see the default precedence values multiplied by 100 to
leave more room for algorithmically generated entries and manual tinkering.
There are only 4 values available between fc00::/8 and fd00::/8 for
example. Those could be easily consumed after a couple of corporate fusions.
I guess the idea has been that local administration can override all
values to their liking. However, my understanding of the best practises
for system and network administration is that the defaults are changed
as little as possible. And the defaults should preferably "shine
through" from under local modifications. This means that when the
defaults are changed due to some software update, they might adversely
interfere with the local changes.
I don't mind it if the default precedences are multiplied by even more
than a hundred, I just feel it is important that there should be more
space between the default values.
Tony Hain also wrote:
> Precedence Label Prefix
> ---------- ----- --------------------------------
...
> 1 6 fec0::/16
Aren't we removing site local completely while we're at it? Or if it
should be kept around, then why not add 3ffe::/16 too for the same reason?
--
Aleksi Suhonen
Department of Communications Engineering
Tampere University of Technology
From mohacsi@niif.hu Mon Jul 12 00:01:44 2010
Return-Path:
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 46EC83A6781 for ; Mon, 12 Jul 2010 00:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level:
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 RMNSfjPQQFm1 for ; Mon, 12 Jul 2010 00:01:43 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id C4C163A6901 for ; Mon, 12 Jul 2010 00:01:42 -0700 (PDT)
Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 73030851F8; Mon, 12 Jul 2010 09:01:48 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id rvCGEKlOKLHV; Mon, 12 Jul 2010 09:01:45 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 8436E851CE; Mon, 12 Jul 2010 09:01:45 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 7EF48851C5; Mon, 12 Jul 2010 09:01:45 +0200 (CEST)
Date: Mon, 12 Jul 2010 09:01:45 +0200 (CEST)
From: Mohacsi Janos
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Tim Chown
In-Reply-To:
Message-ID:
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Mon, 12 Jul 2010 07:01:44 -0000
On Sun, 11 Jul 2010, Tim Chown wrote:
> Tony,
>
> Now that 6rd is done, what's the view on 6to4?
>
> I know a lot of people would be quite keen to see 6to4 deprecated.
I think 6to4 and teredo should be treated similarly - after ipv4. They
should be used as a last resort acess to IPv6 resources. I think
6to4 should be kept since 6to4 is the most implemented IPv6 of the CPE
equipments.
Best Regards,
Janos Mohacsi
>
> Tim
>
> On 8 Jul 2010, at 18:08, Tony Hain wrote:
>
>> For updating 3484-revise section 2.2, the table I have been running at home
>> for some time is:
>>
>> Precedence Label Prefix
>> ---------- ----- --------------------------------
>> 90 0 ::1/128
>> 75 1 fc00::/8
>> 70 1 fd00::/8
>> 50 2 2001::/16
>> 50 2 2400::/8
>> 50 2 2600::/8
>> 50 2 2a00::/8
>> 50 2 2c00::/8
>> 40 3 2002::/16
>> 30 3 2001::/32
>> 20 4 ::/0
>> 10 5 ::ffff:0:0/96
>> 5 6 ::/96
>> 4 6 fec0::/16
>>
>> The explicit label 2 set is due to a bug in the vista stack, as that should
>> be a single entry of 2000::/3, (and the fec0 should be /10). The differences
>> from the proposed one in the October text are:
>> - Adding explicit entries for each half of the ULA space to prefer local
>> when possible (rule 2).
>> - Explicitly listing 2000::/3 to avoid default resulting in the ambiguous
>> choice of ula as src.
>> - Keeping teredo and 6to4 as tunnels labeled the same.
>> - Tunnels before default to avoid the ambiguous choices default will result
>> in.
>> - packaging all deprecated prefixes in the same label.
>>
>> The currently proposed table in 2.2 does not solve the problem in 1.1, so it
>> would be good to move that example to an appendix or at least after the 2.2
>> discussion, and replace it with the one of a host selecting between Internet
>> access and a closed network.
>>
>> I understand the desire to move teredo to less than IPv4. While I disagree
>> with the premise, a resulting policy table that does that might look like:
>>
>> Precedence Label Prefix
>> ---------- ----- --------------------------------
>> 90 0 ::1/128
>> 75 1 fc00::/8
>> 70 1 fd00::/8
>> 60 2 2000::/3
>> 50 3 ::/0
>> 30 4 2002::/16
>> 20 5 ::ffff:0:0/96
>> 5 4 2001::/32
>> 1 6 ::/96
>> 1 6 fec0::/16
>>
>> I suggest leaving 10, 40, & 80 in the precedence so people can move IPv4 or
>> ULA around without feeling the need to rewrite the other labels (they don't
>> have to, but an obvious hole to park it in reduces confusion). I haven't
>> tried that, and don't have time before I leave today, but I will put that in
>> and see how it works before the IETF meeting. It should be close to what the
>> current text was trying to get to, but with the explicit ula and gua
>> prefixes to avoid default it should work more consistently.
>>
>> Tony
>>
>>
>>
>>
>> _______________________________________________
>> 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 tjc@ecs.soton.ac.uk Mon Jul 12 00:14:59 2010
Return-Path:
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 3007E3A698D for ; Mon, 12 Jul 2010 00:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 0hozBiD5zYuC for ; Mon, 12 Jul 2010 00:14:50 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 547DB3A67F2 for ; Mon, 12 Jul 2010 00:14:48 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6C7EpSm003568 for ; Mon, 12 Jul 2010 08:14:51 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6C7EpSm003568
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278918891; bh=uYWTRrWtAWSIkpuV0czBGcYvUmo=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=TQJ1rLa3wR9974s5P+mIC4NT6woHHGtA7Y7gZrvth9XAGPEbQihY+5JcrEtUfunfI hs9yDV0BpU+Za137xcdLx141fChkuakjxhmCCmH2sydyiuSdDrPMpKMnBURWycqiAU EYxZjBaUHafcYQlUCEKa+iZr/Kc3rpzLI9n4gqH4=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m6B8Eo0540024228Zo ret-id none; Mon, 12 Jul 2010 08:14:51 +0100
Received: from [192.168.1.12] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6C7DWqQ032137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Jul 2010 08:13:32 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown
In-Reply-To: <4C3A5931.40709@tut.fi>
Date: Mon, 12 Jul 2010 08:13:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID:
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi> <6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6B8Eo054002422800; tid=m6B8Eo0540024228Zo; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6C7EpSm003568
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Mon, 12 Jul 2010 07:15:00 -0000
I have one other topic to add which I can't remember whether I posted =
about recently or not, so apologies if I'm repeating myself.
In undertaking some work recently on router-based hints for address =
selection, we found that we could improve address selection behaviour =
for hosts by using a new ICMP-based message to query a router or route =
server for an ordered list of address pairs to use for given candidate =
addresses. The issue that came up was that if the host were to cache =
the result, and we chose to cache it within the RFC3484 policy tables, =
can we change/augment the current syntax/format to accommodate that?
Tim
On 12 Jul 2010, at 00:52, Aleksi Suhonen wrote:
> Hi,
>=20
> Tony wrote:
>> I suggest leaving 10, 40,& 80 in the precedence so people can move =
IPv4 or
>> ULA around without feeling the need to rewrite the other labels (they =
don't
>> have to, but an obvious hole to park it in reduces confusion).
>=20
> The number of bits in the precedence value has not been defined, but I =
understand that most implementations use at least 32 bits anyway. I =
would like to see the default precedence values multiplied by 100 to =
leave more room for algorithmically generated entries and manual =
tinkering.
>=20
> There are only 4 values available between fc00::/8 and fd00::/8 for =
example. Those could be easily consumed after a couple of corporate =
fusions.
>=20
> I guess the idea has been that local administration can override all =
values to their liking. However, my understanding of the best practises =
for system and network administration is that the defaults are changed =
as little as possible. And the defaults should preferably "shine =
through" from under local modifications. This means that when the =
defaults are changed due to some software update, they might adversely =
interfere with the local changes.
>=20
> I don't mind it if the default precedences are multiplied by even more =
than a hundred, I just feel it is important that there should be more =
space between the default values.
>=20
> Tony Hain also wrote:
> > Precedence Label Prefix
> > ---------- ----- --------------------------------
> ...
> > 1 6 fec0::/16
>=20
> Aren't we removing site local completely while we're at it? Or if it =
should be kept around, then why not add 3ffe::/16 too for the same =
reason?
>=20
> --=20
> Aleksi Suhonen
> Department of Communications Engineering
> Tampere University of Technology
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
From arifumi@nttv6.net Mon Jul 12 00:39:23 2010
Return-Path:
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 A418E3A6956 for ; Mon, 12 Jul 2010 00:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1]
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 eWXCBUy0A-pI for ; Mon, 12 Jul 2010 00:39:12 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 67E203A67B4 for ; Mon, 12 Jul 2010 00:39:12 -0700 (PDT)
Received: from dhcp-3-143.nttv6.com (dhcp-3-143.nttv6.com [192.47.163.143]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6C7cis9023943; Mon, 12 Jul 2010 16:38:44 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Arifumi Matsumoto
In-Reply-To:
Date: Mon, 12 Jul 2010 16:38:44 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi> <6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk>
To: Tim Chown
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Mon, 12 Jul 2010 16:38:45 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Mon, 12 Jul 2010 07:39:23 -0000
Hi,
On 2010/07/12, at 16:13, Tim Chown wrote:
> I have one other topic to add which I can't remember whether I posted =
about recently or not, so apologies if I'm repeating myself.
>=20
> In undertaking some work recently on router-based hints for address =
selection, we found that we could improve address selection behaviour =
for hosts by using a new ICMP-based message to query a router or route =
server for an ordered list of address pairs to use for given candidate =
addresses. The issue that came up was that if the host were to cache =
the result, and we chose to cache it within the RFC3484 policy tables, =
can we change/augment the current syntax/format to accommodate that?
That approach also should have an issue of policy merge/conflict.
When we think about merging process, we may have to think about this
kind of approach, if we think it looks like some advantages in merging.
When we think about non-merging based solution, do we have to think
about this approach ? Which means, policy table can store one ICMPv6
message at a time ?
>=20
> Tim
>=20
> On 12 Jul 2010, at 00:52, Aleksi Suhonen wrote:
>=20
>> Hi,
>>=20
>> Tony wrote:
>>> I suggest leaving 10, 40,& 80 in the precedence so people can move =
IPv4 or
>>> ULA around without feeling the need to rewrite the other labels =
(they don't
>>> have to, but an obvious hole to park it in reduces confusion).
>>=20
>> The number of bits in the precedence value has not been defined, but =
I understand that most implementations use at least 32 bits anyway. I =
would like to see the default precedence values multiplied by 100 to =
leave more room for algorithmically generated entries and manual =
tinkering.
>>=20
>> There are only 4 values available between fc00::/8 and fd00::/8 for =
example. Those could be easily consumed after a couple of corporate =
fusions.
>>=20
>> I guess the idea has been that local administration can override all =
values to their liking. However, my understanding of the best practises =
for system and network administration is that the defaults are changed =
as little as possible. And the defaults should preferably "shine =
through" from under local modifications. This means that when the =
defaults are changed due to some software update, they might adversely =
interfere with the local changes.
>>=20
>> I don't mind it if the default precedences are multiplied by even =
more than a hundred, I just feel it is important that there should be =
more space between the default values.
>>=20
>> Tony Hain also wrote:
>>> Precedence Label Prefix
>>> ---------- ----- --------------------------------
>> ...
>>> 1 6 fec0::/16
>>=20
>> Aren't we removing site local completely while we're at it? Or if it =
should be kept around, then why not add 3ffe::/16 too for the same =
reason?
>>=20
>> --=20
>> Aleksi Suhonen
>> Department of Communications Engineering
>> Tampere University of Technology
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>=20
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arifumi@nttv6.net
From Aleksi.Suhonen@tut.fi Mon Jul 12 01:34:48 2010
Return-Path:
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 7828C3A6902 for ; Mon, 12 Jul 2010 01:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599]
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 DgXq4iu9hJ1e for ; Mon, 12 Jul 2010 01:34:47 -0700 (PDT)
Received: from mail-gw2.cc.tut.fi (mail-gw2.cc.tut.fi [130.230.160.16]) by core3.amsl.com (Postfix) with ESMTP id 294993A690A for ; Mon, 12 Jul 2010 01:34:46 -0700 (PDT)
X-AuditID: 82e6a010-b7c01ae0000009dc-25-4c3ad3ac11d2
Received: from mail2.tut.fi (mail2.tut.fi [130.230.162.20]) by mail-gw2.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id 76.37.02524.CA3DA3C4; Mon, 12 Jul 2010 11:34:52 +0300 (EEST)
Received: from [130.230.52.51] (halli.atm.tut.fi [130.230.52.51]) by mail2.tut.fi (Postfix) with ESMTP id 256BEA7EF9 for ; Mon, 12 Jul 2010 11:34:52 +0300 (EEST)
Message-ID: <4C3AD3AC.5050405@tut.fi>
Date: Mon, 12 Jul 2010 08:34:52 +0000
From: Aleksi Suhonen
Organization: Tampere University of Technology / Department of Communications Engineering
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4
MIME-Version: 1.0
To: addr-select-dt@ietf.org
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi> <6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk> <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net>
In-Reply-To: <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQxEjes=
Subject: Re: [addr-select-dt] Proposed default policy table
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Aleksi Suhonen
List-Id: IPv6 Address Selection Design Team
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 12 Jul 2010 08:34:48 -0000
On 07/12/10 07:38, Arifumi Matsumoto wrote:
>> I have one other topic to add which I can't remember whether I posted about recently or not, so apologies if I'm repeating myself.
>>
>> In undertaking some work recently on router-based hints for address selection, we found that we could improve address selection behaviour for hosts by using a new ICMP-based message to query a router or route server for an ordered list of address pairs to use for given candidate addresses. The issue that came up was that if the host were to cache the result, and we chose to cache it within the RFC3484 policy tables, can we change/augment the current syntax/format to accommodate that?
>
> That approach also should have an issue of policy merge/conflict.
>
> When we think about merging process, we may have to think about this
> kind of approach, if we think it looks like some advantages in merging.
The Linux Way of recent days seems to be to replace /etc/.conf
with /etc/.d/*.conf so in Linux specifically you could
implement it like this:
/etc/gai.conf:
1. default rules that can be overriden
2. include instruction for /etc/gai.d/*.conf
3. system wide rules that can't be overriden
And then your address selection policy update daemon(s) would update
their own file(s) in /etc/gai.d/ safely.
I don't have a good understanding on how other operating systems have
implemented RFC3484 so I can't comment how universal this would be.
--
Aleksi Suhonen
Department of Communications Engineering
Tampere University of Technology
From mohacsi@niif.hu Mon Jul 12 01:53:42 2010
Return-Path:
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 1C2283A6902 for ; Mon, 12 Jul 2010 01:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level:
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 eAkzD4lncMaV for ; Mon, 12 Jul 2010 01:53:41 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id 0A9023A6A6F for ; Mon, 12 Jul 2010 01:53:40 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 2ADEC851CE; Mon, 12 Jul 2010 10:53:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 8fidmv-4Dky5; Mon, 12 Jul 2010 10:53:44 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 65CA2851FB; Mon, 12 Jul 2010 10:53:44 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5FAFD851F9; Mon, 12 Jul 2010 10:53:44 +0200 (CEST)
Date: Mon, 12 Jul 2010 10:53:44 +0200 (CEST)
From: Mohacsi Janos
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Aleksi Suhonen
In-Reply-To: <4C3AD3AC.5050405@tut.fi>
Message-ID:
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi> <6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk> <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net> <4C3AD3AC.5050405@tut.fi>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Mon, 12 Jul 2010 08:53:42 -0000
On Mon, 12 Jul 2010, Aleksi Suhonen wrote:
> On 07/12/10 07:38, Arifumi Matsumoto wrote:
>>> I have one other topic to add which I can't remember whether I posted
>>> about recently or not, so apologies if I'm repeating myself.
>>>
>>> In undertaking some work recently on router-based hints for address
>>> selection, we found that we could improve address selection behaviour for
>>> hosts by using a new ICMP-based message to query a router or route server
>>> for an ordered list of address pairs to use for given candidate addresses.
>>> The issue that came up was that if the host were to cache the result, and
>>> we chose to cache it within the RFC3484 policy tables, can we
>>> change/augment the current syntax/format to accommodate that?
>>
>> That approach also should have an issue of policy merge/conflict.
>>
>> When we think about merging process, we may have to think about this
>> kind of approach, if we think it looks like some advantages in merging.
>
> The Linux Way of recent days seems to be to replace /etc/.conf with
> /etc/.d/*.conf so in Linux specifically you could implement it like
> this:
>
> /etc/gai.conf:
> 1. default rules that can be overriden
> 2. include instruction for /etc/gai.d/*.conf
> 3. system wide rules that can't be overriden
>
> And then your address selection policy update daemon(s) would update their
> own file(s) in /etc/gai.d/ safely.
>
> I don't have a good understanding on how other operating systems have
> implemented RFC3484 so I can't comment how universal this would be.
I think it much more complicated:
- You have default ruleset initialised by the operating system.
- You can have host specific ruleset configured by the particular node
configuration files - usually loaded by the startup process like
from /etc/.conf (or /etc/.d/*.conf) into the kernel
- You might opt from loading something into the kernel from the previous
cache. I don't think it is reliable. OS should send out something like
confirmation, whether it is still valid or ICMPv6/DHCP policy table
solicitation/request.
- You can have a daemon process, that actually initate this policy table
solicitation/request and process the incoming policy table and insert the
ruleset into the kernel.
I don't believe that overriding a particular rule either from
configuration file or any policy table distibution method would be
possible. Every operating system or local setup migth be different
therefore complete table override is possible, but modifying one rule
not....
Best Regards,
Janos Mohacsi
-
>
> --
> Aleksi Suhonen
> Department of Communications Engineering
> Tampere University of Technology
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
>
From arifumi@nttv6.net Mon Jul 12 01:57:11 2010
Return-Path:
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 A838D3A69A8 for ; Mon, 12 Jul 2010 01:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.663
X-Spam-Level:
X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1]
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 aQuBVoLdTqyP for ; Mon, 12 Jul 2010 01:57:10 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 4D10E3A6813 for ; Mon, 12 Jul 2010 01:57:10 -0700 (PDT)
Received: from dhcp-3-143.nttv6.com (dhcp-3-143.nttv6.com [192.47.163.143]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6C8vF4J024356; Mon, 12 Jul 2010 17:57:15 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Arifumi Matsumoto
In-Reply-To: <4C3AD3AC.5050405@tut.fi>
Date: Mon, 12 Jul 2010 17:57:14 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EFB032E-BBFB-4000-9E39-D48A2A5049E2@nttv6.net>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi> <6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk> <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net> <4C3AD3AC.5050405@tut.fi>
To: Aleksi Suhonen
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Mon, 12 Jul 2010 17:57:15 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] Proposed default policy table
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: ,
X-List-Received-Date: Mon, 12 Jul 2010 08:57:11 -0000
Hi Alex,
thank you for comments.
If I understand it correctly, your comments are about implementation.
It's okay if we decide this merging issue is up to implementation.
But, we are still trying to fix a spec for merging.
Moreover, this time, we've almost decided to separate =
non-merging-capable
mechanism from merging-capable one. So, why not fix it first ?
On 2010/07/12, at 17:34, Aleksi Suhonen wrote:
> On 07/12/10 07:38, Arifumi Matsumoto wrote:
>>> I have one other topic to add which I can't remember whether I =
posted about recently or not, so apologies if I'm repeating myself.
>>>=20
>>> In undertaking some work recently on router-based hints for address =
selection, we found that we could improve address selection behaviour =
for hosts by using a new ICMP-based message to query a router or route =
server for an ordered list of address pairs to use for given candidate =
addresses. The issue that came up was that if the host were to cache =
the result, and we chose to cache it within the RFC3484 policy tables, =
can we change/augment the current syntax/format to accommodate that?
>>=20
>> That approach also should have an issue of policy merge/conflict.
>>=20
>> When we think about merging process, we may have to think about this
>> kind of approach, if we think it looks like some advantages in =
merging.
>=20
> The Linux Way of recent days seems to be to replace =
/etc/.conf with /etc/.d/*.conf so in Linux =
specifically you could implement it like this:
>=20
> /etc/gai.conf:
> 1. default rules that can be overriden
> 2. include instruction for /etc/gai.d/*.conf
> 3. system wide rules that can't be overriden
>=20
> And then your address selection policy update daemon(s) would update =
their own file(s) in /etc/gai.d/ safely.
>=20
> I don't have a good understanding on how other operating systems have =
implemented RFC3484 so I can't comment how universal this would be.
>=20
> --=20
> Aleksi Suhonen
> Department of Communications Engineering
> Tampere University of Technology
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arifumi@nttv6.net
From arifumi@nttv6.net Mon Jul 12 02:16:57 2010
Return-Path:
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 8186D3A68D9 for ; Mon, 12 Jul 2010 02:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1]
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 5QbrsG10ulwH for ; Mon, 12 Jul 2010 02:16:56 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0E30F3A659C for ; Mon, 12 Jul 2010 02:16:55 -0700 (PDT)
Received: from dhcp-3-143.nttv6.com (dhcp-3-143.nttv6.com [192.47.163.143]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6C9H2W6024470; Mon, 12 Jul 2010 18:17:02 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Arifumi Matsumoto
In-Reply-To: <4C3A5931.40709@tut.fi>
Date: Mon, 12 Jul 2010 18:17:02 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BEA2A00-5122-4946-884A-8AE873BB0781@nttv6.net>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi>
To: Aleksi Suhonen
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Mon, 12 Jul 2010 18:17:02 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] Proposed default policy table
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: