RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
John C Klensin <john-ietf@jck.com> Fri, 04 July 2008 23:49 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848313A6B0F; Fri, 4 Jul 2008 16:49:35 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1C23A6AF0 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 16:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMFhF1T6ZgzQ for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 16:49:31 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 6E5563A6B0F for <ietf@ietf.org>; Fri, 4 Jul 2008 16:49:30 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KEv1x-0001bc-Ny; Fri, 04 Jul 2008 19:49:34 -0400
Date: Fri, 04 Jul 2008 19:49:32 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Mark Andrews <mark_andrews@isc.org>
Subject: RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Message-ID: <6DF6CD2370AAF383D8F9172F@p3.JCK.COM>
In-Reply-To: <BLU137-W4119825EB30C448D9C87B7939B0@phx.gbl>
References: <200807032314.m63NEY56048085@drugs.dv.isc.org> <E709066D4201B0B9202841FC@p3.JCK.COM> <BLU137-W50030593690ADECA1032C7939B0@phx.gbl> <795604F9E96F8D31B307B8E1@p3.JCK.COM> <BLU137-W4119825EB30C448D9C87B7939B0@phx.gbl>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: ietf@ietf.org, Lyman Chapin <lyman@acm.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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@hotmail.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Update of RFC 2606 based on the recent ICANN chan… Marshall Eubanks
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … Marshall Eubanks
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Joe Abley
- RE: Update of RFC 2606 based on the recent ICANN … Hallam-Baker, Phillip
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Lawrence Conroy
- Re: Update of RFC 2606 based on the recent ICANN … Joe Baptista
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Philip Guenther
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Tony Finch
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- RE: Update of RFC 2606 based on the recent ICANN … Hallam-Baker, Phillip
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … Thomas Narten
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Philip Guenther
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Paul Hoffman
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Thomas Narten
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Steve Crocker
- Re: Update of RFC 2606 based on the recent ICANN … Paul Hoffman
- Re: Update of RFC 2606 based on the recent ICANN … Ole Jacobsen
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Paul Hoffman
- RE: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Lyman Chapin
- Re: Update of RFC 2606 based on the recent ICANN … Steve Crocker
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- RE: Update of RFC 2606 based on the recent ICANN … Bernard Aboba
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- RE: Update of RFC 2606 based on the recent ICANN … Bernard Aboba
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- RE: Update of RFC 2606 based on the recent ICANN … Bernard Aboba
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Services and top-level DNS names (was: Re: Update… John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… Bernard Aboba
- Single-letter names (was: Re: Update of RFC 2606 … John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… Bernard Aboba
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Dave Crocker
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- RE: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Single-letter names (was: Re: Update of RFC 2… JFC Morfin
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Services and top-level DNS names Karl Auerbach
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names Frank Ellermann
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names Frank Ellermann
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Brian E Carpenter
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … moore
- Re: Services and top-level DNS names (was: Re: Up… Jaap Akkerhuis
- Re: Update of RFC 2606 based on the recent ICANN … Lyman Chapin
- Re: Update of RFC 2606 based on the recent ICANN … Lyman Chapin
- Re: Update of RFC 2606 based on the recent ICANN … Vint Cerf
- Re: Single-letter names (was: Re: Update of RFC 2… William Tan
- Re: Single-letter names (was: Re: Update of RFC 2… Vint Cerf
- RE: Single-letter names (was: Re: Update of RFC 2… Edmon Chung
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Single-letter names (was: Re: Update of RFC 2… michael.dillon
- RE: Single-letter names (was: Re: Update of RFC 2… Ted Hardie
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Services and top-level DNS names (was: Re: Up… Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Theodore Tso
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Theodore Tso
- Re: Update of RFC 2606 based on the recent ICANN … Willie Gillespie
- Re: Update of RFC 2606 based on the recent ICANN … Karl Auerbach
- Re: Update of RFC 2606 based on the recent ICANN … Theodore Tso
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Joe Abley
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … Douglas Otis
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Services and top-level DNS names (was: Re: Up… Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Marshall Eubanks
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… Cellario Luca
- Re: Update of RFC 2606 based on the recent ICANN … Bob Braden
- Re: Single-letter names Eric Brunner-Williams
- RE: Single-letter names (was: Re: Update of RFC 2… John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Tony Finch
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber