Re: [DNSOP] moving forward on special use names

Ted Lemon <mellon@fugue.com> Tue, 20 September 2016 19:57 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02112B453 for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 12:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 BPlg__y7sUv7 for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 12:57:43 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3537F12B4D1 for <dnsop@ietf.org>; Tue, 20 Sep 2016 12:57:43 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id y6so24529630lff.1 for <dnsop@ietf.org>; Tue, 20 Sep 2016 12:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tTGz/hnZJZ6cul0QMP6UMcJcVa4ZndTb4DFuQf1hbdI=; b=czkYpuVuj0gBm/6q+CaFkmTvRN+Fy6YG34jyCm+6lyc2WAasebDY9powkOo1ytINj4 AF20iaUXCI+YG7xSQ4THfN2ccayKt1hT9W6pj0iIPZEFn42XERgS0V20n7aKb82gDOK/ DWiGEVyc7nnpp64XtFANHG5nLqqem7G/R7pv5yIyNAxM5WL6ygBGah6Tf6AqLqU4NLBi UdaFwfLddQTbAwbUhB57D1/YYMyaew5rJi7BKELLuc7BV1K6MoP0NpvvLJx0VVok8SGl 0JsO8HWNFG1u0db1PjL2tJr8aPmMEXfq4wpS4Rv4DDGHBPpMOYyHAq0KnNsOYkkuIqVS Oe9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tTGz/hnZJZ6cul0QMP6UMcJcVa4ZndTb4DFuQf1hbdI=; b=Hy4mFUnZ+9PyYFFQ9pE+e1utSQi68K2Gg07Spoe4xW7BqQ0FW/RGinOPxUA4Tfhxo/ yTpPDn/EQpiBRlpWpCS20KaFOECLupUKPP2GcCdr4kyRhxjQ4fQ9el17OqtbX5XHAuPO DpkgU/MSOjb/d0a7ZulVOSQoqqE2IhvIS0I2HaSoU33lmzj2yoCr4AO9zIkYGqCW5xUZ 5/g40VgDhH3zMJE0uUBEUdWd+oEdgItpZPBfjdKz5exTBeR0Yf6Wnh/K1i4IsBTCNtWI MHRCquq2r8OdSnuao2eID3BOTzjr3S6jht2mQVEaraYFegpOVYhkB7Pd9BHXZWuT5HKF 5oqQ==
X-Gm-Message-State: AE9vXwMb4KIujChUGdzCgMkxrraRsvWvUh3KDeDa0tcI1se8fmliNv0RXIFJ6TpEoJ0TRHUlBpf3vAulIIFkNQ==
X-Received: by 10.25.76.136 with SMTP id z130mr4314892lfa.126.1474401461056; Tue, 20 Sep 2016 12:57:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Tue, 20 Sep 2016 12:56:59 -0700 (PDT)
In-Reply-To: <5218DBD4-0D08-41A2-B0FA-6F9D85597ECE@icann.org>
References: <CAPt1N1=xNaHpO-ZxusWK9_UBzOpKa0zk0y0h7iGvRS2P=Og-3g@mail.gmail.com> <20160918234346.78983.qmail@ary.lan> <CAPt1N1nOMUA0ZNQioZ7wngDE6gSjJn_qroBv2a2kdsvFMKngHg@mail.gmail.com> <alpine.OSX.2.11.1609182047100.7288@ary.lan> <0AD4FFFB-EBF5-4CDE-B29C-3220D1DBA111@davecake.net> <CAPt1N1k8hP90EUUXNAYbK1rLofUwnriDe00qBBYy_exPHLoFRg@mail.gmail.com> <979967E8-D48F-4935-9D9C-3721DC8C5B06@gmail.com> <5218DBD4-0D08-41A2-B0FA-6F9D85597ECE@icann.org>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 20 Sep 2016 15:56:59 -0400
Message-ID: <CAPt1N1=HK=gCNTZynLqTCz__bfVKBscwGBUkU3wC4v8Q-XQ_Pg@mail.gmail.com>
To: Alain Durand <alain.durand@icann.org>
Content-Type: multipart/alternative; boundary="001a114b173857d237053cf5d7b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kHxG-JR2KU4LwUPzm_xjSbNDJs8>
Cc: "suzworldwide@gmail.com" <suzworldwide@gmail.com>, dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] moving forward on special use names
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2016 19:57:46 -0000

I have a lot of sympathy for the worry about boiling the ocean, but
actually my fear is that if we do not enumerate all the problems and talk
about what we have to give up to solve this one or that one, we will never
reach consensus regardless of how small a teakettle we put on to boil,
because we will have left out people who have a strong stake in those
unaddressed problems, and they will not agree to the document, because
despite us not having addressed those problems, nevertheless the resulting
document will impact them.

On Tue, Sep 20, 2016 at 3:17 PM, Alain Durand <alain.durand@icann.org>
wrote:

>
> On Sep 20, 2016, at 7:46 AM, Suzanne Woolf <suzworldwide@gmail.com> wrote:
>
> The “toxic waste” names are a “use case” in the sense that people keep
> asking about. The identified need for a default namespace in the homenet
> protocols represents another use case.
>
>
>
> There are many use cases for reserving names under 6761 or an updated
> version of it. We saw that last year: people have an unlimited imagination
> on how to use such special names… good or bad, this is not the question.
>
> It could be tempting for the problem statement to list all of those use
> cases. Actually, if 6761 did not exist, that might even have been the right
> thing to do. But this is not where we are now.
>
> Where we are is that the iETF ran into a number of issues running both the
> process and the registry described in RFC6761. Draft-adpkja is attempting
> to list those issues, first by looking at process issues (section 3), then
> issues related to the operation of the registry (section 4), and, at last,
> looking at issues related to the strings under consideration themselves
> (section 4). The perspective taken by the authors is that these set of
> issues are real. Each of them need to, and can be, addressed. Hence a
> problem statement that focuses narrowly on something that can be fixed as
> opposed to boiling the ocean listing issues that, if the discussion from
> the last 18 months is any guidance, the working group may never reach
> consensus on.
>
> Alain, strictly speaking on my own behalf, not my employer’s.
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>