Re: [DNSOP] moving forward on special use names

Alain Durand <alain.durand@icann.org> Tue, 20 September 2016 19:17 UTC

Return-Path: <alain.durand@icann.org>
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 EA95812B478 for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 12:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level:
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ThQgmUMC_wVD for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 12:17:27 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65AE12B145 for <dnsop@ietf.org>; Tue, 20 Sep 2016 12:17:27 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 20 Sep 2016 12:17:25 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 20 Sep 2016 12:17:25 -0700
From: Alain Durand <alain.durand@icann.org>
To: "suzworldwide@gmail.com" <suzworldwide@gmail.com>, dnsop WG <dnsop@ietf.org>
Thread-Topic: [DNSOP] moving forward on special use names
Thread-Index: AQHSDTMDDdCbyRJC+0a3dK+T8vJr6aCAL4UAgAANlwCAABaFAIAAFFAAgAANu4CAAAQggIACJN6AgAAg3ACAAAS6gIAAfe2A
Date: Tue, 20 Sep 2016 19:17:25 +0000
Message-ID: <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>
In-Reply-To: <979967E8-D48F-4935-9D9C-3721DC8C5B06@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.44.2]
Content-Type: multipart/signed; boundary="Apple-Mail=_5CFB5811-326A-4736-A1C3-820C0676F5ED"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MJnB4qsm8V80qSVYcwcIQZvNYu0>
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:17:29 -0000

> 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.