From owner-freebsd-rc@FreeBSD.ORG Mon Oct 5 22:23:22 2009 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347591065756 for ; Mon, 5 Oct 2009 22:23:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0C90D8FC12 for ; Mon, 5 Oct 2009 22:23:19 +0000 (UTC) Received: (qmail 2121 invoked by uid 399); 5 Oct 2009 22:23:18 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Oct 2009 22:23:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4ACA71D4.6010502@FreeBSD.org> Date: Mon, 05 Oct 2009 15:23:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Hiroki Sato References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 22:23:22 -0000 Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As stated previously my objections are as follows (in decreasing order of general importance): 1. It is a fairly significant change happening too late in the release cycle. IMO that is reason enough to not allow the change. 2. Although 8.0 seems to be getting more beta/rc testing than previous .0 releases, the overall number of users testing it is still a small percentage of the userbase. 3. A dramatically smaller percentage of those users who are actually doing the testing is also using IPv6. 4. There are still rough edges to the changes. 5. I personally disagree with some of the choices you've made and would like to see more discussion about them. (More about 4 and 5 below.) The rough edges I've noticed have to do with the various problems people have reported to the lists, including what seems to be a lack of testing without IPv6 in the kernel, continuing evolution of how to deal with the afnet tests, and personally I've noticed the following on my console, although I haven't had time to research yet whether it's definitely coming from your changes: in6_ifattach_linklocal: failed to add a link-local addr to wpi0 In terms of design decisions you've made, I am still confused about why you insist on deprecating ipv6_enable. Recent discussion on the lists indicates to me that I'm not alone in thinking that this is a valuable mechanism and that there is not only no reason to deprecate it, to do so is not desirable. I'd also like to explore further the idea that I suggested in a previous thread that it should not be necessary to specify ifconfig_IF_ipv6 at all. The vast majority of users will be using RA for the next couple of years at least, so in my mind it makes sense to default to using ipv6_network_interfaces=$network_interfaces and RA by default. If the user has a need to configure something explicitly then you've provided the mechanism for them to do that, but they shouldn't be forced to use it. This is another reason that I think ipv6_enable should be the "master" knob. I like the idea of the ipv6_prefer knob, but I do not like the idea of overloading it with the function of ipv6_enable too. I can certainly understand why you are eager to get these changes into 8.0, however if we do a proper job of maintaining backwards compatibility (which I think we should do anyway) I don't see any reason that they cannot be merged after 8.0, and more importantly after they have had a proper opportunity to shake out in HEAD. Doug -- This .signature sanitized for your protection