Bernard,
I'm going to try to respond to both your note and Mark's, using
yours as a base because it better reflects my perspective.
Before I go on, I think the three of us are in agreement about
the situation. The question is what can (or should) be done
about it.
--On Friday, 04 July, 2008 13:52 -0700 Bernard Aboba
<bernard_aboba(_at_)hotmail(_dot_)com> wrote:
Not really. ICANN isn't "selling" single-label domains. They
are selling (and I believe "selling" is probably now the
correct term) plain, ordinary, TLD delegations. If I get one
of those and populate the TLD zone only with delegation
records, there are no problems with what ICANN has done at
all, whether you describe it as a property right or in some
other way.
Agreed.
On the other hand, if they delegate one and the enterprise
that buys it chooses to populate the zone with service
records, then ICANN's position will certainly be that any
inability to use those service records isn't ICANN's problem
-- any more than difficulties using .museum or .aero were
ICANN's problem when those to whom those domains were
delegated discovered that a lot of applications software
thought that the one TLD label of more than three characters
was "ARPA".
Is generic "buyer beware" disclaimer really sufficient here?
The problem isn't just "inability to use" -- it's that other
parties exist who may claim the usage right, and provide
citations to RFCs to back up their claim.
For example, typing http://brooklynbridgepark/ into a browser
utilizing a resolver compliant with RFC 1536 will bring you to
the web site of Brooklyn Bridge Park Conservancy, assuming
that .org is in your searchlist.
We agree so far, but let me note that 1536 is an informational
document. We generally don't claim that systems are expected to
be compliant with those.
If ICANN sells the brooklynbridgepark TLD delegation to
another party who populates the zone with service records,
should that party expect that http://brooklynbridgepark/
will now resolve to their site? RFC 1536 says "no".
Similar problems will occur when the party purchasing the
brooklynbridgepark TLD attempts to use the single-label name
"brooklynbridgepark" for other uses, such as network access.
Yes. And what I fear is that some applications and
implementations will support services on "brooklynbridgepark" as
a TLD and others will start searching. Yes, that goes well
beyond "buyer beware".
And _that_ situation has a lot more to do about "buyer beware"
and understanding of conflicting expectations about use than
it does about ownership.
Today there is a distinction between types of property rights
- surface, subsurface, or rights to the air above a property.
As noted at http://geology.com/articles/mineral-rights.shtml
this was not always the case:
If we go back in time to the days before drilling and
mining, real estate transactions were fee simple
transfers. However, once subsurface mineral production
became
possible, the ways in which people own property became
much more complex.
Sure. But I know who to call --title insurance companies,
lawyers, judges, etc.-- when your mineral rights intrude on my
surface building rights or vice versa.
If the analogy holds (and I'm not a lawyer, so I have no idea
if it does), then we could be talking about a "fee simple"
transfer in a situation where sub-rights may be claimed to
belong to someone else.
But this gets back exactly to both the rude comments I've been
making about ICANN and the example I tried to construct (not
carefully enough) about a Microsoft TLD.
Let's take the second one first. Suppose that Microsoft, at a
high corporate level, decided that they wanted to have a TLD
called "microsoft" and that they wanted to attach services to
it. You would advise against that. I would advise against
that. So would others. We would cite 1535, a number of other
RFCs, and general bad taste. My assumption is that Microsoft
would give it up -- even if they wanted the domain, they
wouldn't expect to locate services at the top level. But
suppose some marketing force took over and overwhelmed those
arguments. The thing that makes Microsoft relevant to this
example is that the company distributes a very popular browser
and a couple of very popular email clients. Were a corporate
decision to be made to support services on a TLD, at least
services on that one special-case TLD, than that decision could
extend to modifications to those application programs that would
permit access to those services.
Again, I don't expect that to happen, but it carries over
directly into the main point I'm trying to make, which is that
"property rights" are a relevant metaphor for this situation
only if there is some basis or authority for enforcing those
rights. As I've pointed out in other contexts recently, the
last few times I've tried to call the Protocol Police, they
didn't answer.
Ultimately, I'm concerned about what the IETF can usefully do
about this situation. I'm fairly depressed about that because
there is little evidence that ICANN is seeking out in-depth
technical advice and acting on it. Certainly this set of issues
are not reflected in the list Lyman circulated (and which John
Leslie recently cited in a different form). If I were actively
involved with the Brooklyn Bridge Park Conservancy and I noticed
that ICANN was considering allocating "brooklynbridgepark" as a
TLD, I would protest and offer to sue ICANN on the grounds that
attempts to use that domain would interfere with the quiet
enjoyment of brooklynbridgepark.org by my members and visitors,
but I don't think we can depend on that in the general case.
I think we could do the following, but given the track ICANN
seems to be on and the rate at which they seem to be trying to
speed down that track, we had better do them soon:
(1) Get RFC 1536, probably RFC 1535, any pieces of 1591 we
still care about, and perhaps some other documents promoted from
Informational to BCP (or generate revisions/ updates to them and
publish those at BCP).
(2) Generate a good "use of these sorts of names would really be
a bad idea" document and move it into BCP. Note that this
document is very different from reserving more names for IETF,
documentation, or similar uses in some form of 2606bis (see the
postscript below).
(3) Review BCP17/RFC2219, be sure that we still believe it (I
see several names that are not on the list in Section 3 of that
document that probably should be), update it as needed, and then
call ICANN's attention to that list and suggest that its entries
be added to their prohibited lists for TLDs.
(4) Tell ICANN that a condition of safe allocation of a large
collection of new TLDs is that they require, as a contractual
matter, that the holders of any new delegations explicitly agree
to not install anything but delegation and glue records in their
TLD zones and to caution people against trying to use glue
records to support services (or whatever rule is actually
correct -- I'm not sure that is it). Whether they would do
that or not might be an interesting test of how much they are
really concerned about the continued usability and
predictability of the DNS.
regards,
john
p.s. I started on a "bad idea to use these names, or use them in
these ways" document fairly early in these discussions, before
they went off in directions I could not have predicted. I have
neither the time nor the resources to finish it and especially
not to try to steer it through dnsops and the Applications Area.
But, if anyone else is contemplating doing such a document and
would like a partially-completed version with the needed
references, etc., filled in as a starting point, I'd be happy to
send what I have along.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf