Re: [addr-select-dt] next step

Brian Haberman <brian@innovationslab.net> Thu, 16 September 2010 13:29 UTC

Return-Path: <brian@innovationslab.net>
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 04F2A3A6B20 for <addr-select-dt@core3.amsl.com>; Thu, 16 Sep 2010 06:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level:
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 N3S0B1Yy7wJO for <addr-select-dt@core3.amsl.com>; Thu, 16 Sep 2010 06:29:49 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id E27703A6A47 for <addr-select-dt@ietf.org>; Thu, 16 Sep 2010 06:29:49 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0499088340; Thu, 16 Sep 2010 06:30:15 -0700 (PDT)
Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 44A711368389; Thu, 16 Sep 2010 06:30:14 -0700 (PDT)
Message-ID: <4C921BE4.2060508@innovationslab.net>
Date: Thu, 16 Sep 2010 09:30:12 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Arifumi Matsumoto <arifumi@nttv6.net>
References: <D6CE49D0-6BF0-488E-B4AD-F28BFE2DEE98@nttv6.net> <4C8FC373.5010404@innovationslab.net> <7E55CDE9-7377-4392-AF43-ED57ED6375EF@nttv6.net>
In-Reply-To: <7E55CDE9-7377-4392-AF43-ED57ED6375EF@nttv6.net>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] next step
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2010 13:29:51 -0000

On 9/16/10 5:28 AM, Arifumi Matsumoto wrote:
> Brian,
> 
> On 2010/09/15, at 3:48, Brian Haberman wrote:
> 
>> Arifumi & DT,
>> 
>> On 9/9/10 6:30 AM, Arifumi Matsumoto wrote:
>>> DT members,
>>> 
>>> the Beijing meeting is approaching now. We have to think about 
>>> the next step for us.
>>> 
>>> As we have reached consensus within this design team, I think the
>>> next step should be going out to 6man wg. If so, it may be better
>>> to declare the conclusion of this design team.
>>> 
>>> What do you think about this ? Do you have in mind any other item
>>> to be discussed here in this design team ?
>> 
>> I believe we have reached a point of completion for the design team
>> with the publication of the address selection considerations draft.
>> What Bob & I would like to see now is a draft proposing the actual
>> changes to RFC 3484.  This should be driven by the issues raised
>> in draft-ietf-6man-rfc3484-revise.  It would be encouraging to see
>> such a draft published soon so that it can be discussed on the
>> mailing list and possibly revised prior to the Beijing meeting.
> 
> as you know, the current some parts of draft-ietf-6man-rfc3484-revise
> are actual changes, and also other parts are possible choices for
> updates.

Right.  My preference would be a draft that has the same title as RFC
3484 and only contains the necessary changes from 3484.  I view the
current draft as a "requirements" draft that identifies the issues that
need resolving.

> 
> One choice has to be picked for each undetermined issue before
> publication of an RFC that revise RFC 3484.
> 
> I hope this document of draft-ietf-6man-rfc3484-revise should be
> re-written to propose the actual changes, in the course of discussion
> at 6man.

If so, then the title should reflect that and it should take on a
structure similar to 3484.

> 
> Or, do you prefer a brand new proposal draft that contains the actual
> changes to RFC 3484 ?

How about moving the requirements/considerations discussion to an
appendix, change the title, and have the body reflect the revised
address selection policies?  This would eliminate the need to ask the WG
to adopt another draft.

Regards,
Brian