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@xxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf