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 18:35 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 0567A3A6B2B; Fri, 4 Jul 2008 11:35:41 -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 4DFD23A6B2B for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 11:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.982
X-Spam-Level:
X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_MILLIONSOF=0.315]
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 Afznpxk4isMy for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 11:35:38 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 183423A6B29 for <ietf@ietf.org>; Fri, 4 Jul 2008 11:35:38 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KEq8E-000G2K-LN; Fri, 04 Jul 2008 14:35:42 -0400
Date: Fri, 04 Jul 2008 14:35:41 -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: <795604F9E96F8D31B307B8E1@p3.JCK.COM>
In-Reply-To: <BLU137-W50030593690ADECA1032C7939B0@phx.gbl>
References: <200807032314.m63NEY56048085@drugs.dv.isc.org> <E709066D4201B0B9202841FC@p3.JCK.COM> <BLU137-W50030593690ADECA1032C7939B0@phx.gbl>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Friday, 04 July, 2008 10:49 -0700 Bernard Aboba
<bernard_aboba@hotmail.com> wrote:

> 
>> Single label names are local in scope.  Attempting to use
>> them in a global context does not work.  As the names in
>> "." get more interesting the probability of collisions with
>> existing names goes up.  Not many people choose two letter
>> labels for the least significant parts of their host names
>> unless they are choosing their initials.
>> 
>> Single label hostnames are not globally unique.  They SHOULD
>> NOT be used in a context where globally unique names are
>> required.
>> 
>> Mark,
>> 
>> With the understanding that I agree with everything you say
>> above, there are some interesting problems....
> 
> Referring to the point Mark is making as a "problem" is a bit
> like saying that someone attempting to sell the Brooklyn
> Bridge has a "problem".  While the potential bridge purchaser
> may in fact very much desire to own the bridge, the "problem"
> is that the seller may not in fact have the right to sell it. 
> 
> That's really at the core of what Mark is arguing -- that
> various RFCs allocate single-label names for local use, and
> therefore that ICANN may not possess the right to sell that
> property to another party. 
> 
>> (1) ICANN is well aware of the problem you mention....
>> As I understand it, they have explicitly decided to ignore
>> that problem...
> 
> Someone attempting to sell the Brooklyn Bridge can also
> explicitly decide to ignore the "problem" of whether they in
> fact own it.  That won't make the "problem" go away. 
> 
> In this particular case, we are talking about RFCs that are
> included as requirements for purchase worth billions of
> dollars annually, as well as local names currently in local
> use by hundreds of millions of people. So we're not talking
> about selling a single Brooklyn Bridge here, but many. 
>  
>> (2) Regardless of what some of us may think about the
>> desirability (or not) of associating services with TLD names
> 
> The issue is not "desirability".  Someone might very much
> "desire" to purchase the Brooklyn Bridge.  It has many
> excellent qualities -- it is used by many people over the
> course of a day, it is a registered historical site making it
> of great interest to tourists, etc.   The "problem" is whether
> the seller can establish title. 
>   
>> So, much as I'd like it if we could say "Single label names
>> are local in scope...does not work"
> 
> Mark's point is that several RFCs already say this.  So what
> we have here isn't really an technical argument or one about
> "desirability" -- it's a property rights argument. 

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 a property rights or in some other way.  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".

So the "problem" isn't whether some string not listed in 2606
can be allocated, it is how it is used after it is allocated.
And _that_ situation has a lot more to do about "buyer beware"
and understanding of conflicting expectations about use than it
does about ownership. 

    john





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