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
<steve.crocker@xxxxxxxxx> 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