IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Owen DeLong <owen@delong.com> Mon, 14 April 2014 20:03 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039601A02AC for <v6ops@ietfa.amsl.com>; Mon, 14 Apr 2014 13:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.263
X-Spam-Level:
X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLnsRMA0cLtx for <v6ops@ietfa.amsl.com>; Mon, 14 Apr 2014 13:03:45 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 420201A0213 for <v6ops@ietf.org>; Mon, 14 Apr 2014 13:03:45 -0700 (PDT)
Received: from [IPv6:2001:1838:1003::a036:4bd9:bfc6:a04c] (unknown.ipv6.scnet.net [IPv6:2001:1838:1003:0:a036:4bd9:bfc6:a04c] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3EK1uJf000678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 13:02:03 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3EK1uJf000678
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397505732; bh=ZUeH0JWqryBlfpFJL7hra+dz39c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=W4V40I4nrHwAYAiPVECjswt84ZxS5TKaQKw9rKFj/hcrI1BV6n/LWMrTB+uyeAXst ftsOd/KQgD4J4ysM+l48XFXgHrX44JWymRdjAFJULPYbeLnJ9tzfuSKfs6AplhZ/rQ u8r3ewnfojX1gK+ekQAg5k4V3vzZ10mN0B9G8ezE=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <B3942C2F-C08E-42F2-9038-92C3C63E0023@nominum.com>
Date: Mon, 14 Apr 2014 13:01:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B36E9516-EDCB-44D9-8DD8-03034A1C1DE1@delong.com>
References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <F08AF14D-22C6-4F4C-9388-670EB4CD8453@nominum.com> <F2A0EC2F-6B41-4560-88BA-CEBF3E921B61@delong.com> <CAEmG1=oK8iHAms2_uVBsCtpCG7xBdhRfh9QQrd+JXUXgjBPqPA@mail.gmail.com> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <B3942C2F-C08E-42F2-9038-92C3C63E0023@nominum.com>
To: Ted Lemon <ted.lemon@nominum.com>
X-Mailer: Apple Mail (2.1874)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 14 Apr 2014 13:02:12 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/u_CrLjcfXboR0RnFg0gBGuWd6KE
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Please review the No IPv4 draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 20:03:46 -0000

On Apr 14, 2014, at 12:42 PM, Ted Lemon <ted.lemon@nominum.com> wrote:

> On Apr 14, 2014, at 2:30 PM, Owen DeLong <owen@delong.com> wrote:
>> Seems to me that the same potential for abuse exists with either situation.
> 
> This is true, and the remedy exists as well.  It's worth pointing out that "please review" doesn't mean "please redesign this."   It means "please point out technical flaws that you see."   None of what you or Nick has said sound like technical flaws to me—they sound like "I would prefer to do it this other way."
> 
> The working group considered doing it that other way and decided that on the balance, the way it's written now is better.   So unless there is some strong technical reason why it _shouldn't_ be done the way the working group has proposed, there's no basis for making a change.   It's issues like that that we are looking for in a v6ops review.

We can agree to disagree, but I feel that informing a host about the availability of IPv4 configuration services through an IPv6 configuration service is, in fact, a technically flawed concept.

Owen

v2.23.0 | Report a Bug | By Email