Re: Moving to WGLC 3484-bis?

Brian Haberman <brian@innovationslab.net> Fri, 12 August 2011 20:15 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0521F86BB for <ipv6@ietfa.amsl.com>; Fri, 12 Aug 2011 13:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0gyvU7iD4G5 for <ipv6@ietfa.amsl.com>; Fri, 12 Aug 2011 13:15:32 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2892821F8834 for <ipv6@ietf.org>; Fri, 12 Aug 2011 13:15:32 -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 309328816C; Fri, 12 Aug 2011 13:16:10 -0700 (PDT)
Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 095811368394; Fri, 12 Aug 2011 13:16:08 -0700 (PDT)
Message-ID: <4E4589FD.50008@innovationslab.net>
Date: Fri, 12 Aug 2011 16:15:57 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>
Subject: Re: Moving to WGLC 3484-bis?
References: <F7D8B798-BE7F-4AC4-9D68-6A0C4EDC7DDE@ecs.soton.ac.uk> <EMEW3|12429027fc04a7f4a2ae0da321fae730n7BFLb03tjc|ecs.soton.ac.uk|F7D8B798-BE7F-4AC4-9D68-6A0C4EDC7DDE@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|12429027fc04a7f4a2ae0da321fae730n7BFLb03tjc|ecs.soton.ac.uk|F7D8B798-BE7F-4AC4-9D68-6A0C4EDC7DDE@ecs.soton.ac.uk>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2011 20:15:32 -0000

Hi Tim,

On 8/12/11 10:21 AM, Tim Chown wrote:
> Hi guys,
> 
> I think we're almost ready to WGLC the 3484-bis draft, as per
> draft-ietf-6man-rfc3484-revise-04.
> 
> We had 3 issues in Quebec:
> 
> 1) Inclusion of deprecated prefixes.  It seemed the agreement in the
> room was to include compatibles, site-locals and 6bone prefixes in
> the policy table.  If that's what we do, then we need to add
> 3ffe::/16 back in.
> 
> 2) Privacy bit indicator.  We had removed the privacy bit indicator
> after the heavy negative feedback in Prague to a privacy bit option
> for RAs, but Eric Vyncke suggested it should be added back so that an
> enterprise administrator could use the DHCPv6 policy distribution
> method to have hosts in their domain not use privacy addresses for
> talking to other hosts in their domain (same prefix, or ULAs).  At
> the moment, there is no privacy bit support.
> 
> 3) Prefer greatest lifetime.  We agreed to make no change here.
> 
> If we agree to add back 3ffe::/16, we could quickly produce a
> revise-05 and WGLC based on that, and ask in the WGLC whether there's
> strong support for the privacy option.  If there is, then the option
> bit itself would be defined in the DHCPv6 policy distribution text,
> and 3484-bis would need to describe the use of the bit in the updated
> policy table.

I agree with your assessment and this approach as a reasonable way
forward.  Go ahead and generate -05 with 3ffe::/16 back in the table.
When that draft is out, I will start a WG Last Call and specifically
request feedback on the privacy bit issue.

Regards,
Brian