Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
Warren Kumari <warren@kumari.net> Sat, 01 October 2016 18:25 UTC
Return-Path: <warren@kumari.net>
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 CC41C12B078 for <dnsop@ietfa.amsl.com>; Sat, 1 Oct 2016 11:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.42
X-Spam-Level:
X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, PLING_QUERY=0.279, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 xS1llp4bbEkT for <dnsop@ietfa.amsl.com>; Sat, 1 Oct 2016 11:25:38 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 3EC7412B0E7 for <dnsop@ietf.org>; Sat, 1 Oct 2016 11:25:38 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id j129so126166937qkd.1 for <dnsop@ietf.org>; Sat, 01 Oct 2016 11:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=63eR2CLEX+geyrNXgh0HQCCyU7s/TNNTbVDf3kHHaCQ=; b=i7sCqa8/yHChIkk6S8IPn06PBD8weMwjO2OBTdExI3XcJ98mY8t8wGm5HDg9aHxgnE /rv/vzcx+HpaWOxwyI+NCmL+BDeuMkam3SpLZ5SD2TKiX+vq1QIwpDcQ1obf1MrQBAtr WDzbalg0UJO97Q4MV0EfKD9e+pKgQjfHqu1bAALd5oknk+lqlB3rYfMu6cczpUqdlq+Z 6z2xQ4l87WYI+vjiB3afkK2W6/jziqkvR/OC8qf+iKX4C+0wnBqTWMQ7MNwf9GIE9ryW x0lPXGMAEh+i6KAo65ZYEA0SM2Omx65T0l3Kguuq3NKfV6zWwxNm2FmXVLcmNHIOikiA 2Zqw==
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:content-transfer-encoding; bh=63eR2CLEX+geyrNXgh0HQCCyU7s/TNNTbVDf3kHHaCQ=; b=fGujK52/m0Sf383YLfruhGttT6+UE0TyNXLzmZFN+FxPkWpDUK2SrYOE+FlQ37DfzN O4Snt+XTdDOda40iexwfXN2JyOwQdStwO5g/b0ziL7Engim9pepdHDXzJt+AJJG5tplT VR6N/NI8NrclJBUFJpm7OriR2VccsNkqtofyVUa+w9ie6y0mVz4/LrYQJQQM1tx3CXkA NdWQhiJp0FBQOh8gKhvGxNHoNgw6VzLRDn4TCP48/4TA2T8e9dpfQMN4DbEDfGrj7pi9 Ge0J56Qd8Po4XDVuDs+0vrZTaK+CCw54q83FDSg0LDiFcN9tvlHY83HeDmQ+IZ/NWpSj I0BA==
X-Gm-Message-State: AA6/9RnvzE/nhRDrL8JBsfSinM8Kb/02ALfbzv8HbEQepP/uV3ON8RjI0ACjy7CMPUW0Xuc4Qy6q+r41IKKSVqyo
X-Received: by 10.55.175.134 with SMTP id y128mr12398887qke.134.1475346337281; Sat, 01 Oct 2016 11:25:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Sat, 1 Oct 2016 11:25:06 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.20.1609292250500.13311@bofh.nohats.ca>
References: <alpine.OSX.2.11.1609292041280.86752@ary.qy> <CAKr6gn04Jj5ar2OhztH2uc4WpFZBZ=WKZdx-1ufdFMb9NAQupQ@mail.gmail.com> <CAPt1N1=zDBcbaPVi50dFJXVVSrsBuUrb52iBu4T76Y_zYuxFkQ@mail.gmail.com> <CAPt1N1=5kAb20mGLJPmmuQCL6ta9aJn3uEdVv=gVgG9erQoKkw@mail.gmail.com> <CAPt1N1km66hoc7VFPvaHi4Sc0WuQxZFtQUPjLjK_Sj6qAtZ5UQ@mail.gmail.com> <CAPt1N1keNUiDAUuVn97XLb3W6oH7zdZhMeNbg3h-O892+acPVQ@mail.gmail.com> <CAHw9_iKS_BQUV1sJ2vm=CSvHNJ3jH6G8VJKN1kSbc78hauPraw@mail.gmail.com> <alpine.LRH.2.20.1609292250500.13311@bofh.nohats.ca>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 01 Oct 2016 14:25:06 -0400
Message-ID: <CAHw9_iKjfrEHxTA0rkzUa8Y-S_jDqvUxAqH2Yik6a2UiSYViTw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_SAkWO9HUc-tnHT-XQ6PdfZM2LM>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)
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: Sat, 01 Oct 2016 18:25:43 -0000
On Thu, Sep 29, 2016 at 11:04 PM, Paul Wouters <paul@nohats.ca> wrote: > On Thu, 29 Sep 2016, Warren Kumari wrote: > >> On Thursday, September 29, 2016, Ted Lemon <mellon@fugue.com> wrote: >> >> So, if anyone is still wondering why we need a /good/ problem >> statement, this discussion is why. You are >> both taking past reach other because you are looking at only the >> part of the problem you care about. >> >> ... and why we need a Special Use Names problem statement, and not just a >> RFC6761 problem statement. This problem is >> bigger than just 6761... > > > I still do not see that. Without 6761, if anyone wants to ask for a TLD, > whether to delegate or never delegate, we (IETF) can say: That is > outside the area of our expertise - you must go to ICANN. > > ICANN already has a blacklist of unsafe domains. IETF can advise them > on that list if needed. No, no it really doesn't -- it has some list of names, which seem to have been fairly arbitrarily chosen. This is not a stable, well published list -- it lurks in the "gTLD Applicant Guidebook", published in January 2012, in Section 2.2.1.2.1 ("It was on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying beware of the leopard."). This list at that point was: "AFRINIC IANA-SERVERS NRO ALAC ICANN RFC-EDITOR APNIC IESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSO INVALID SSAC EXAMPLE* IRTF TEST* GAC ISTF TLD GNSO LACNIC WHOIS GTLD-SERVERS LOCAL WWW IAB LOCALHOST IANA NIC", and "OLYMPIC OLYMPIAD OLYMPIQUE OLYMPIADE OLYMPISCH OLÍMPICO (and Olympic in various scripts which my mailer doesn't want to accept)" and "REDCROSS REDCRESCENT REDCRYSTAL REDLIONANDSUN MAGENDDAVIDADOM REDSTAROFDAVID CROIXROUGE CROIX-ROUGE CROISSANTROUGE CROISSANT-ROUGE CRISTALROUGE CRISTAL-ROUGE (and various Red Cross / Red Crecent and scripts which my mailer shrugged and stared blankly at)". A number of the first list are from the IANA Special Use Names registry -- but many of the others are simply ICANN deciding that their internal groups are special -- for example, GAC, RSSAC, SSAC, CCNSO, ALAC. And then they decided that IETF, IAB, RFC-EDITOR IRTF should also be listed. Seriously, this seems like a good, well run solution? > I don't think at this point either ICANN or IETF would want to add TLDs > to the unsafe list. If at this point someone is still squatting domain > names, they get what they deserve. And all the known security risky > domains (as a result of decades of use of unqualified domain names) > are already known at ICANN, and they won't assign these. Um. No. See .home, .corp and .mail - many would say that these are known security risky names -- when security issues were raised, these were not placed on a blacklist -- instead these have been "deferred indefinitely. ICANN will collaborate with the technical and security communities to determine the best way to handle these strings in the long term.". I have not seen this happening. Applicants for these TLDs recently sent https://www.icann.org/en/system/files/correspondence/home-registry-inc-et-al-to-icann-board-24aug16-en.pdf. I would encourage all to read this... > People creating > new ones are also going against the long standing don't squat advise, > and need no further protection from their own foot bullets. Let's pretend that you had a good reason for needing a name reserved - for example, let's pretend that you are designing some sort of home networking protocol where you'd like to be able to connect thingies together and have name / service discovery just work. It's not mDNS / .local is not appropriate for you. You go through the full IETF process - you hold a BoF, you form a WG, you hold meetings, you design a system. Great. You have IETF consensus. Now what? Currently you / I / the IETF cannot go to ICANN and say "please reserve us a string" -- there is no "blacklist", there is just some list in some applicant guidebook. There is no open process at the moment -- the last round took many many painful years, and there was no method to "reserve" a name (in fact, this was explicitly prohibited). The "list" was not created with the consultation of the community - in fact many names on that list a: didn't know that they were, and b: didn't want to be. Also, the process is currently closed, and even if it were open, last time it cost >$185,000 to apply... You've been to a number of ICANN meetings - do you really trust this process to provide a good outcome for the technical community? Sure, many people didn't like the .ONION discussion / outcome -- but what would your advice have been to the TOR community if we'd already decided to abdicate our position? "Dear TOR folk. Go talk to ICANN.. Yeah, I know that that won't actually help you; you don't fit in their model, and the process isn't open now anyway. Guess you shouldn't have squatted on that name, huh"? Anyway, this is FAR into the solution space, and I was really hoping to avoid getting drawn into that.. I know I'm sounding frustrated / grumpy -=- this whole processes / discussion has been taking up way way too much of our time, hopefully we can *soon* make a decision, ship a document and then get onto more *technical* discussions like "Um, which name is the QNAME?!" :-) > > So that brings the problem statement to: > > IETF had the power to allocate or ban domain names based on the > Special Names RFC-6761. IETF no longer wants that power. That's not a problem statement. That's a "we found this annoying and want someone else to do it" -- that may be true, but that's a /solution/, not a /problem statement/. W > > And the solution for that is a 6761bis document that confirms this. > > Paul -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
- [DNSOP] On the call for adoption on Special Use N… Warren Kumari
- Re: [DNSOP] On the call for adoption on Special U… Stephane Bortzmeyer
- Re: [DNSOP] On the call for adoption on Special U… Warren Kumari
- Re: [DNSOP] On the call for adoption on Special U… Mark Andrews
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] On the call for adoption on Special U… hellekin
- Re: [DNSOP] On the call for adoption on Special U… George Michaelson
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… George Michaelson
- Re: [DNSOP] On the call for adoption on Special U… Alain Durand
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… hellekin
- Re: [DNSOP] On the call for adoption on Special U… hellekin
- Re: [DNSOP] On the call for adoption on Special U… Stephane Bortzmeyer
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] On the call for adoption on Special U… Stephane Bortzmeyer
- Re: [DNSOP] On the call for adoption on Special U… Stephane Bortzmeyer
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… John R. Levine
- Re: [DNSOP] On the call for adoption on Special U… George Michaelson
- Re: [DNSOP] On the call for adoption on Special U… John R Levine
- Re: [DNSOP] On the call for adoption on Special U… George Michaelson
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… Warren Kumari
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] On the call for adoption on Special U… John R Levine
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… John R Levine
- Re: [DNSOP] On the call for adoption on Special U… Alain Durand
- Re: [DNSOP] On the call for adoption on Special U… Ted Lemon
- Re: [DNSOP] On the call for adoption on Special U… hellekin
- Re: [DNSOP] On the call for adoption on Special U… Warren Kumari
- Re: [DNSOP] On the call for adoption on Special U… Philip Homburg
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] On the call for adoption on Special U… Warren Kumari
- Re: [DNSOP] On the call for adoption on Special U… Suzanne Woolf
- Re: [DNSOP] On the call for adoption on Special U… hellekin
- Re: [DNSOP] On the call for adoption on Special U… Paul Wouters
- Re: [DNSOP] In a vacuum, nobody can hear you scre… John Levine
- Re: [DNSOP] In a vacuum, nobody can hear you scre… David Conrad
- Re: [DNSOP] In a vacuum, nobody can hear you scre… Jeremy Rand
- Re: [DNSOP] In a vacuum, nobody can hear you scre… avri doria
- Re: [DNSOP] In a vacuum, nobody can hear you scre… hellekin
- Re: [DNSOP] In a vacuum, nobody can hear you scre… George Michaelson
- Re: [DNSOP] In a vacuum, nobody can hear you scre… John Levine
- Re: [DNSOP] In a vacuum, nobody can hear you scre… Alain Durand
- Re: [DNSOP] In a vacuum, nobody can hear you scre… hellekin