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 17: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 E6C403A6882; Fri, 4 Jul 2008 10:49:48 -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 813B13A681C for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 10:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.16
X-Spam-Level:
X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=1.123, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 NoqT3VaZOa25 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 10:49:46 -0700 (PDT)
Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by core3.amsl.com (Postfix) with ESMTP id 1A1173A67D9 for <ietf@ietf.org>; Fri, 4 Jul 2008 10:49:46 -0700 (PDT)
Received: from BLU137-W50 ([65.55.116.74]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 10:49:50 -0700
Message-ID: <BLU137-W50030593690ADECA1032C7939B0@phx.gbl>
X-Originating-IP: [24.16.124.122]
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 10:49:50 -0700
Importance: Normal
In-Reply-To: <E709066D4201B0B9202841FC@p3.JCK.COM>
References: <200807032314.m63NEY56048085@drugs.dv.isc.org> <E709066D4201B0B9202841FC@p3.JCK.COM>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jul 2008 17:49:50.0908 (UTC) FILETIME=[5BA5BFC0:01C8DDFE]
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="===============0697589901=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>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. 
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf