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

From: John C Klensin <[email-masked]>
Date: Tue, 21 Jul 2015 05:30:46 -0400

--On Monday, July 20, 2015 19:22 +0000 John Levine
<[email-masked]> wrote:

> Now that you and Andrew have pointed it out, and after today's
> dnsop session, I agree that the trickle of not-DNS domain
> names is likely only to become larger, and we need a better
> way to deal with it than a two-month all-IETF debate per name.

yep.   But I think the other part is even more important.

>> why can't we take the Special Names
>> problem to them, say "look, we understand that these names
>> look like names in the public DNS root and that confusion
>> that would have bad effects is a real risk, how about you
>> devise a procedure for dealing with them that recognizes the
>> importance of existing deployment and use and considers the
>> low likelihood that people who are using these names will
>> stop because you tell them too.  Clearly the procedure you
>> use for new gTLD applications won't work.  And, because some
>> of these names won't wait, if you can't get that procedure
>> together immediately, we'd be willing to let you delegate
>> things to us on some reasonable basis until you do."

> That is an excellent question, and I suppose it couldn't hurt
> to ask. But I have little confidence that ICANN in anything
> like its current form, where it is dominated by people who
> want to collect rent on every imaginable TLD, would come up
> with an answer any better than let them pay $185K and take
> their chances.

John, I think many of us have developed very low expectations of
ICANN and, as you certainly know, the situation you describe
above (often known as "capture") is only one of the problems.
One result is that there have been a lot of decisions in recent
years that start from "if we let them near that, they will mess
it up and/or figure out a way to turn it into a profit center"
and then moves to some sort of workaround.  The difficulty with
that approach is that it lets them off the hook and, in the long
term, may make things ever worse.  I've become convinced that is
the wrong approach.  The alternative is to treat them like the
responsible stewards of the DNS root namespace that they claim
to be.  If they screw it up, we (preferably as individuals and
external organizations and with help from ISOC and the press,
not the IETF) hold them accountable in the court of public
opinion and ridicule (not their pre-captured "accountability"
mechanisms).  Of they step up -- which I don't think is
impossible-- we make real progress.  

best,
   john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jul 2015 12:34:33 +0200

Hi John,

On 7/21/15 11:30 AM, John C Klensin wrote:
> term, may make things ever worse.

I see things quite differently.  It lets *us* off the hook when we don't
exercise the technical discretion that we are supposed to have with
regard to the Internet architecture and forces ICANN to separately
develop the capabilities necessary to technically support themselves. 
They are already a long way down that path, and while some of that is a
good thing, too much can lead to divides between the organizations.  And
we ARE supposed to provide something of value to the ICANN community as
to others.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Jul 2015 16:22:10 -0400

Steve,

Quite a bit of background material and comments follow but, if
you (or others) are in a hurry, please skim to the bottom of the
note which contains a conclusion and recommendations.

--On Tuesday, July 21, 2015 12:34 +0200 Steve Crocker
<[email-masked]> wrote:

> John, et al,
> 
> There are a substantial number of ICANN people at this IETF
> meeting, including, of course, the usual IANA team,  three  of
> ICANN's to level managers — David Conrad, Chief Technology
> Officer, Ashwin Rangun, Chief Innovation and Information
> Officer, and Akram Atallah, president of the Global Domains
> Division — several people on David Conrad's team, and four
> people on the ICANN board, including, of course, the IETF
> liaison to the ICANN board, Jonne Soininen, and Suzanne Woolf,
> who serves multiply as the liaison to the ICANN board from the
> root server operators group, RSSAC, chair of DNSOP, and a
> member of the IAB. ICANN is paying a LOT of attention.

Apologies for probably appearing cynical, but I think everyone
reading this has had experiences in which "attended a meeting",
especially "attending a meeting with full organizational support
and presumably at organizational request" does not equate to
"paying attention".  I assume that everyone you've listed _is_
paying attention and acting in good faith, but that doesn't
follow from your list and assertion.  Be that as it may...

> Speaking for myself and not necessarily for the ICANN board or
> the rest of the organization, it seems evident that the nice
> clean separation of name spaces originally envisioned via the
> distinct indicators in DNS, e.g. "IN" for "Internet",
> protocol identifiers in URLs, etc. has not worked out in
> practice.  The original scheme of assigning just seven
> "generic" top level domains plus two letter country code
> TLDs meant the rest of the top level space was left
> unassigned.

Not exactly.  In retrospect, we should have said something much
more explicit in RFC 1591, but there was a quite intentional
model that would have prevented the present problems.  That
model can be summarized as:

 * Single-letter TLDs are prohibited, partially because
	of the security- or confusion-related risks of
	single-character typing errors.  There was also some
	joking about a future extension model if things got out
	of hand, but I don't believe that was ever taken
	seriously.
 * Two-letter TLDs were reserved for ISO 3166 (later
	3166-1) alpha-2 codes.  That was, by the way, _all_ two
	letter codes on the assumption that, over time, the ISO
	Technical Committee responsible for 3166 might changes
	their minds about categories of codes as well as
	assigning new ones and that therefore only the "two
	octets" part could be treated as immutable.
 * Three-letter generic domains.  Six, and then seven, of
	them, with the assumption that more might be assigned
	but that (i) additional ones would still be three
	letters and (ii) that any applications for new ones
	would need to show strong reasons why intelligent use of
	hierarchy would not constitute as good or better a
	solution.   Just for perspective, we came very close to
	allocating an eighth generic TLD in the mid-1990s.  I
	believe, based on conversations with Jon, that it would
	have been approved and delegated had the applicant been
	able to identify sufficient consensus around a
	well-established document or standard that would
	determine what was an appropriate second-level entry and
	what was not.
 * Four-letter codes consisted for "ARPA" with everything
	else being reserved.  I believe that additional
	four-letter infrastructure, management, or transition
	TLDs would have been allocated had a need been
	demonstrated, but that never happened and, unlike issues
	with possible expansion of two and three character
	country-related and generic domains, I can't remember
	its being discussed.
 * Any longer strings were informally, but quite
	explicitly, reserved for precisely the kind of local use
	and/or resolution by mechanisms that don't involve the
	public DNS root that we seem to be talking about today.

ICANN could have insisted on three-character mnemonics but
delegated all of the functional domain ideas in the 2001 set
without altering those rules.  ICANN leadership at the time was
told, not only about the rules, but that longer names were
likely to cause problems and that, even if they allowed such
names, they should at least warn applicants of the issues.  They
declined to either impose the restriction or warn applicants.  I
gather the consequences of those decisions are still a matter
for "universal acceptance" discussions today.

Once the above conventions became obsolete, the issues we are
dealing with now as "Special Names" became inevitable.

>  Nature apparently abhors a vacuum in this area as
> well as in the physical domain.  Various vendors grabbed
> unused names such as local, corp, mail and built then into
> their products.  In principle, these names should not have
> shown up in queries to the DNS root; in practice they have
> shown up in great numbers.  Developers of new protocols have
> also felt comfortable using previously unused top level names,
> with onion being the example getting the most attention right
> now, but with several others previously used and more to come.

Understood and see below.  However, note that every name you
list as an example is four or more characters long.  Had we
stuck with the original rules, we could have made a
recommendation similar to that for private-use IP addresses,
i.e., to block them in DNS servers, thereby eliminating the
problem.  I might also suggest that we could have done a better
job of educating vendors and others about the use of hierarchy
and maybe allocated something like "priv." and established an
FCFS registry for second-level names consistent with
non-public-DNS use, but that would probably have been too much
to ask for.  Too late now, obviously.

> Meanwhile, one of the goals included in ICANN's formation
> was increasing competition and choice.  (Don't blame me; I
> wasn't involved at the time.)

I was... don't blame me either, especially for the way that
"competition and choice" ended up being interpreted.  In
particular, for the case mentioned above, I believed then and
believe now that there should have been an explicit discussion
--within the ICANN community and with the IETF-- about the
tradeoffs between continuing to reserve longer top-level names
for other than public DNS use.   For whatever reasons, those
discussions never occurred.

>    The first result was the
> creation of the registrar system, which resulted in a dramatic
> drop in the price of domain names.  The second result, which
> has taken quite a bit longer, was the opening up of the top
> level domain space, which brings us to where we are today.

And, fwiw, "where we are today" is with no mechanism or set of
agreements for dealing with individual strings that ought to be
reserved and kept out of any possible gTLD allocation or
delegation processes.  I don't think that situation reflects
very well on either the IETF or ICANN.

> Irrespective of the original intent to keep various name
> spaces separate, I think we have to accept that these name
> spaces bleed into each other.

Agreed.

>  Once we accept that, to me,
> fairly obvious fact of life, the next step is to work out some
> straightforward coordination between the IETF's processes
> and ICANN's processes.  I don't see why it should be hard
> or lengthy to do so.

I agree that it should not be either hard or lengthy although
I've been surprised and disappointed by the outcome after
similar beliefs in the past.  However, let me repeat and
summarize my recommendation from an earlier note or two.  

(1) First, I think we (IETF and ICANN) should agree that this is
ultimately an ICANN problem and within ICANN's authority.  I
have multiple reasons for that preference but the bottom line is
that only ICANN can control ICANN decisions about what TLDs to
actually allocate and delegate.

(2) For special name requests/ reservations that fall within the
scope of IETF protocol work, the IETF should request that ICANN
allocate and reserve the relevant names.  We should agree that
ICANN will either do that or explain why and, if appropriate,
suggest alternate names and/or mechanisms.  Working out a
definition of "the scope of IETF protocol work" is an IETF
problem but will definitely include the needs of IETF
standards-track protocols.  The IETF is expected to use
hierarchy, rather than separate TLD-like names, whenever
possible.

(3) For special name requests of reservations that are not
deemed by the IETF to fall within the scope of its protocol
work, there should be a process of requesting of ICANN that
names be reserved.  

(4) Determining the ICANN process for evaluating name requests
under (2) or (3) is an ICANN matter, not an IETF one.  My
personal recommendation is that there be assurances that it will
operate in a timely fashion and that decisions about these names
be viewed more as a technical security and stability issue than,
e.g., as part of the current or future gTLD application and
allocation process.

(5) If ICANN discovers, contrary to our mutual prediction that
this should not be hard or lengthy, that getting appropriate
procedures in place is (calendar) time-consuming, I would hope
that ICANN could temporarily delegate actual decision authority
to the IETF and that the IETF would be at least as reasonable
and careful in its consideration of the many issues involved as
it has been so far with ONION.

best,
    john

---

From: Steve Crocker <[email-masked]>
Date: Tue, 21 Jul 2015 12:34:41 +0200

John, et al,

There are a substantial number of ICANN people at this IETF meeting, including, of course, the usual IANA team,  three  of ICANN’s to level managers — David Conrad, Chief Technology Officer, Ashwin Rangun, Chief Innovation and Information Officer, and Akram Atallah, president of the Global Domains Division — several people on David Conrad’s team, and four people on the ICANN board, including, of course, the IETF liaison to the ICANN board, Jonne Soininen, and Suzanne Woolf, who serves multiply as the liaison to the ICANN board from the root server operators group, RSSAC, chair of DNSOP, and a member of the IAB. ICANN is paying a LOT of attention.

Speaking for myself and not necessarily for the ICANN board or the rest of the organization, it seems evident that the nice clean separation of name spaces originally envisioned via the distinct indicators in DNS, e.g. “IN” for “Internet”, protocol identifiers in URLs, etc. has not worked out in practice.  The original scheme of assigning just seven “generic” top level domains plus two letter country code TLDs meant the rest of the top level space was left unassigned.  Nature apparently abhors a vacuum in this area as well as in the physical domain.  Various vendors grabbed unused names such as local, corp, mail and built then into their products.  In principle, these names should not have shown up in queries to the DNS root; in practice they have shown up in great numbers.  Developers of new protocols have also felt comfortable using previously unused top level names, with onion being the example getting the most attention right now, but with several others previously used and more to come.

Meanwhile, one of the goals included in ICANN’s formation was increasing competition and choice.  (Don’t blame me; I wasn’t involved at the time.)   The first result was the creation of the registrar system, which resulted in a dramatic drop in the price of domain names.  The second result, which has taken quite a bit longer, was the opening up of the top level domain space, which brings us to where we are today.

Irrespective of the original intent to keep various name spaces separate, I think we have to accept that these name spaces bleed into each other.  Once we accept that, to me, fairly obvious fact of life, the next step is to work out some straightforward coordination between the IETF’s processes and ICANN’s processes.  I don’t see why it should be hard or lengthy to do so.

Steve

David Conrad’s technical team, Akram Attalah