Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

John C Klensin <john-ietf@jck.com> Sat, 25 July 2015 16:39 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D571ACDDC for <ietf@ietfa.amsl.com>; Sat, 25 Jul 2015 09:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.101
X-Spam-Level: ****
X-Spam-Status: No, score=4.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] 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 3M5uYUSUrTEW for <ietf@ietfa.amsl.com>; Sat, 25 Jul 2015 09:39:19 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CA41ACDCD for <ietf@ietf.org>; Sat, 25 Jul 2015 09:39:18 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZJ2Ti-0009yJ-PM; Sat, 25 Jul 2015 12:39:14 -0400
Date: Sat, 25 Jul 2015 12:39:05 -0400
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf@frobbit.se>, John R Levine <johnl@taugh.com>
Subject: Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>
Message-ID: <34B3BE89840E1E692528E5AA@JcK-HP5.jck.com>
In-Reply-To: <F6A99810-CBB3-46DD-83FE-64507A2D08BD@frobbit.se>
References: <20150724223103.72650.qmail@ary.lan> <C7F9571D-4446-4FC9-BDB3-1AEEAD5B98DF@nominum.com> <alpine.OSX.2.11.1507242102150.69886@ary.lan> <B419D491-FF05-4C45-9D03-577886BD6A58@frobbit.se> <alpine.OSX.2.11.1507250119350.74632@ary.lan> <78E74FBF-2FDB-42AC-933B-85E39BE4AB14@frobbit.se> <alpine.OSX.2.11.1507250154470.74907@ary.lan> <F6A99810-CBB3-46DD-83FE-64507A2D08BD@frobbit.se>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/CJnx9hTS7Dttl9UWtxZPyrCo39s>
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jul 2015 16:39:21 -0000


--On Saturday, July 25, 2015 8:03 AM +0200 Patrik Fältström
<paf@frobbit.se> wrote:

> On 25 Jul 2015, at 7:56, John R Levine wrote:
> 
>> ICANN excluded the IETF reserved names last time, and it
>> seems certain they would do so next time.  The question is
>> whether we can update that list to be complete enough to be
>> useful, and do so in a timeframe that would keep it useful.
>> I have my doubts.  More than doubts.
> 
> Agree.

And that is, from my point of view, another way to look at the
problem.  We are not, AFAICT, in the "keep a comprehensive list
of applications on the Internet that might use DNS-style names"
business.  Perhaps some of the operational groups (NOG or
otherwise) might be more suitable.  Or not.

Putting that aside for a moment, suppose we make a list and
ICANN treats that as comprehensive (either because the list was
there or because we told them to).  Something that is
significant to some community doesn't make it onto our list.
Remember, for example, that our world now includes IDN TLDs, and
no one has moved to exclude the translation of "local" into
Lower Slobbovian or proposed that all translations of special
names should, themselves, be excluded.  So, some Lower
Slobbovian application is built and becomes widely popular in
that country that uses the relevant name.

Now assume that, since it is not on the list that we built,
ICANN entertains an application for that name.  Assuming there
were a Lower Slobbovian GAC representative by then (there isn't
now) or that someone from another country happens to visit the
country and notice the name in use and mentions it in the GAC.
"Local" and its translations are not a place or national name in
any country that I've heard of, so the GAC doesn't make a strong
recommendation, they just say "you'd better watch out for this
one" at some appropriate part of the process.   Based on the
recent AFRICA decision, ICANN decides to ignore that advice as
excessively vague and outside the GAC charter.  So the name is
delegated and 2/3 of Internet service in Lower Slobbovia ceases
working predictably (for everyone who is old enough, especially
those who recently spent time in Prague, remember what happened
when "CS." was delegated from the root).

That would clearly constitute a mess, probably a "stability
problem" for the global Internet.  I believe the following
responses are predictable:

 * ICANN 1: Not our problem, we used the IETF's list and
	that wasn't on it.
	
 * ICANN SSAC: No one asked us that specific question, so
	we didn't research the name and give an opinion.
	
 * IETF: No one told us about that name or usage.  Of
	course, everyone on the Internet is obligated to tell us
	every time they deploy an application that uses a name.
	That would be consistent with "permissionless
	innovation" because they need to tell us, not ask,
	except, whoops, getting a name on the list requires IETF
	Consensus and IETF Consensus _does_ imply our giving
	permission or at least deciding the string is important
	enough.
	
 * ICANN 2: It is the responsibility of all applicants to
	do due diligence on the name they picked so, if they
	apply for a name and we allocate and delegate it, and
	then it causes problems, those problems are their fault;
	sort it out with them. [1]
	
 * Government of Lower Slobbovia (and/or one or more BRIC
	countries or the ITU or the next WSIS-related or IGF
	meeting):  This proves that IETF and ICANN are US pawns,
	that the US government doesn't care about Lower
	Slobbovia or anyone else who is not directly relevant to
	their short-term political interests, and therefore all
	DNS name registration (and exclusion) issues should be
	handled by an International Treaty Organization.

There are also race conditions inherent in this (as I think
others have pointed out).   If I correctly understood him, Steve
mentioned that it is probably too late to do anything about the
current list of applications -- if there were problems there,
their handling would have to be according to the current
Applicant Handbook and, unless I've forgotten something, it
doesn't say "no names that appear on the IETF's Special Names
list at the time of application".  So we are now making claims
on name reservations for the next round, when and if it happens
but, if a name shows up on our list after that round starts and
people submit applications and pay money, there is another
ambiguity.

I don't want to see us go anywhere near there.  Dumping this on
ICANN and hoping they can figure out a way to handle it without
things getting too political or being sold to the highest bidder
is almost certainly unfair and probably seems more so to those
who believe that it is impossible for ICANN to make a
TLD-related decision without its being controlled by politics or
"moneyed interests".   Perhaps putting them in a position in
which they have to give SSAC a more prominent and authoritative
role and, independently, get out of the "second-guessing
committee" business is unfair too.   However, it seems me that
they signed up for the job when they were chartered.  

We didn't.  And shouldn't.  Should we agree to tell some
ICANN-designated entity or process every time we run across a
name that should be considered "special"?  Definitely.  That is
just being professional.  Should we offer official opinions
about names that are tied up with our protocols or that appear
especially important to us?  I, personally, think that would be
a fine idea.  But the IETF is not in the business of maintaining
authoritative and comprehensive lists of names that should be
excluded; we don't have the skills, knowledge, and process
appropriate to that activity [2]; and, if we were to go into it
on a per-name basis, it would expose us to engagement in
finger-pointing and claims the could damage our core mission.

I do believe there is one very constructive thing we can do
here.  That is to sort out some appropriate reserved TLD name
with ICANN, possibly even have it delegated to something that
generates authoritative NXDOMAIN messages (or worse) and then
issue a strong statement to developers of future applications
that they should use names in that tree, possibly with courtesy
registrations to help them stay out of each other's way, rather
than potentially causing Internet instabilities or getting
themselves entangled with ICANN.  The "ALT" proposal appears to
be a good step in that direction but I think this discussion has
exposed several issues that future revisions of it should
consider.

   best,
   john

[1] That "due diligence by applicants" argument suggests that
this is a huge fuss about nothing.  If one reaches that
conclusion, I'm not sure why we need to have the discussion or a
Special Names registry whose contents stretch beyond IETF
protocols and names that are obviously widely deployed in
narrowly DNS contexts.

[2} I just had a nightmare vision of adding to our IPR
statements and requirements of the Note Well and related
documents a requirement that all participants in the IETF
disclose any name they know about, even names used internally
and confidentially by their employers or other enterprises, that
might be confused with, or with resolution attempted in, the
DNS.   Not a good idea.