RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 04 July 2008 20:52 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 7BACB3A69A8; Fri, 4 Jul 2008 13:52:07 -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 C7E0F3A69A8 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 13:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.42
X-Spam-Level:
X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 zv6QNupLc1vd for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 13:52:05 -0700 (PDT)
Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id 49B3A3A67D9 for <ietf@ietf.org>; Fri, 4 Jul 2008 13:52:05 -0700 (PDT)
Received: from BLU137-W41 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 13:52:09 -0700
Message-ID: <BLU137-W4119825EB30C448D9C87B7939B0@phx.gbl>
X-Originating-IP: [70.56.71.55]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: John C Klensin <john-ietf@jck.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 ?)
Date: Fri, 04 Jul 2008 13:52:09 -0700
Importance: Normal
In-Reply-To: <795604F9E96F8D31B307B8E1@p3.JCK.COM>
References: <200807032314.m63NEY56048085@drugs.dv.isc.org> <E709066D4201B0B9202841FC@p3.JCK.COM> <BLU137-W50030593690ADECA1032C7939B0@phx.gbl> <795604F9E96F8D31B307B8E1@p3.JCK.COM>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jul 2008 20:52:09.0520 (UTC) FILETIME=[D3917B00:01C8DE17]
Cc: ietf@ietf.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: multipart/mixed; boundary="===============0349550358=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 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.

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. 

> 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.


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.  


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf