Re: [addr-select-dt] poll on the address selection DT suggestions ?

Tim Chown <> Wed, 28 July 2010 13:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0026828C15E for <>; Wed, 28 Jul 2010 06:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eXrHh-z5C7Ci for <>; Wed, 28 Jul 2010 06:32:28 -0700 (PDT)
Received: from ( [IPv6:2001:630:d0:f102::25e]) by (Postfix) with ESMTP id 9F15228C17E for <>; Wed, 28 Jul 2010 06:32:27 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id o6SDWlhc026093 for <>; Wed, 28 Jul 2010 14:32:47 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 o6SDWlhc026093
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=200903; t=1280323967; bh=QYqBjt8wufoAKyesBzif8jer/L4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Covglibc6ZopDexzgTOuQH9kM6rqvCc/cSDa3yH6Igv+Lk5fgcQBmFxohC8P7y2Ag uM6n346IDJZcEmPafxrhNCcXiy73/QHrkAoyGSjIcsVUjBzN1yCAS6qhL6nX2pL8MR ixkrB6sq8RJLFvT6snBfdnztzuzIrKlKSuamW4Fw=
Received: from ( [2001:630:d0:f102::25d]) by ( [2001:630:d0:f102::25e]) envelope-from <> with ESMTP id m6REWl0540048236cy ret-id none; Wed, 28 Jul 2010 14:32:47 +0100
Received: from ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o6SDWiMH014808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Wed, 28 Jul 2010 14:32:45 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown <>
In-Reply-To: <>
Date: Wed, 28 Jul 2010 14:32:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|9b15ba373f7c9db7bbd1cf221a920442m6REWl03tjc||>
References: <> <>
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6REWl054004823600; tid=m6REWl0540048236cy; 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: o6SDWlhc026093
Subject: Re: [addr-select-dt] poll on the address selection DT suggestions ?
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, 28 Jul 2010 13:32:31 -0000

Thanks, this is a well summarised message.

I'd be interested to hear what the result was :)


On 28 Jul 2010, at 06:44, Arifumi Matsumoto wrote:

> Hi,
> At the yesterday's 6man session, the design team suggested three main points.
> Though it was decided to discuss more about this issue of address selection at this mailing list, I'd like to see to how much extent those suggestions were accepted by the 6man people *now*.
> This is important, because not delaying the standardization of the basic mechanism is one of the main suggestion from the DT. And because it determines if any further work at DT is necessary or not.
> The three main points were:
> - separating the basic mechanism from other advanced mechanisms/features.
>  The policy merging process should be host issue, and we need to focus on network issue of delivering protocol, because host issue can be implemented in the same way of other configuration information.
>  And, another separation is the frequently updating of policy mainly from the help of routing mechanisms, such as ICMP errors from routers. From our consideration, many of the cases do not need such a frequent updates of policy. Moreover, such a dynamic case forces a host to react dynamically, and this involves host protocol stack renovation, just like shim6 and mptcp, and so on.
>  The basic mechanism is powerful enough to solve many problems and harmless enough to keep RFC3484 as it is, and should not be delayed because of these advanced/future mechanisms.
> - as the delivering protocol, DHCP should be the most appropriate choice, considering the target environments.
> - the RFC 3484 revision needs to be done.
>  Maybe this point needs no poll any more.
>  This point was accepted and now in confirmation process in the ML.
>  I think, if we agree this kind of minor revision of RFC 3484, we also agreed we carry on the existing model for some years, or we need a solution that does not renovate the existing model.
> So, I'm glad to have your everyone's mood on these three points.
> Can we poll at today's 6man session, or at the ML ?
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------