Re: Update of RFC 2606 based on the recent ICANN changes ?

John C Klensin <john-ietf@jck.com> Mon, 30 June 2008 12:43 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 47FCA3A68E7; Mon, 30 Jun 2008 05:43:30 -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 6C3533A6881 for <ietf@core3.amsl.com>; Mon, 30 Jun 2008 05:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=2.700, BAYES_00=-2.599, GB_I_LETTER=-2]
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 YpLqd4ZT5oVw for <ietf@core3.amsl.com>; Mon, 30 Jun 2008 05:43:28 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AFB543A68E7 for <ietf@ietf.org>; Mon, 30 Jun 2008 05:43:27 -0700 (PDT)
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1KDIjB-0003Rh-HA; Mon, 30 Jun 2008 08:43:33 -0400
Date: Mon, 30 Jun 2008 08:43:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bill Manning <bmanning@ISI.EDU>, David Conrad <drc@virtualized.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <649DC89B6513C74E89023E29@[192.168.1.110]>
In-Reply-To: <20080630024615.GA7021@boreas.isi.edu>
References: <4C0AE13D-4CA6-4989-A6B0-555A014DE464@multicasttech.com> <74E3E26A-FCFB-45C1-989A-DD7EA5752974@virtualized.org> <6.2.5.6.2.20080627121824.02c55340@resistor.net> <BBB8E0B4-7E45-4BE9-B9DF-DEBE294585D6@multicasttech.com> <6.2.5.6.2.20080627140118.02a43fd8@resistor.net> <6F1CFDA0-A6E2-4257-8C72-0FCD1E117290@virtualized.org> <6.2.5.6.2.20080628201322.02e43268@resistor.net> <FBBF3BB9-D231-494A-AFBE-7F816DD1180C@virtualized.org> <20080630024615.GA7021@boreas.isi.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: SM <sm@resistor.net>, IETF Discussion <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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Sunday, June 29, 2008 7:46 PM -0700 Bill Manning 
<bmanning@ISI.EDU> wrote:

>>
>> I'm suggesting it would be helpful if there were an RFC
>> directing IANA   to establish a registry that contains both
>> labels and rules (e.g, no   all-numeric strings, no strings
>> that start with 0x and contain   hexadecimal values, the
>> string 'xn--', the 2606 strings, etc.) that   specify what
>> cannot be placed into the root zone.  As part of future
>> IANA actions, any time a protocol defines a new TLD (e.g.,
>> .local) an   entry should be placed into that registry.
>>
>> Would there be the downside to this?
>
> 	several come to mind...
>
> 	heres one.  wrt numeric strings, you have examples of the
> ambiguity 	in implementations on -how- to process non-base 10
> numbers.  but 	it is clear that hex encoding is -not- tossed
> out.  how 'bout octal? 	or base 36?  are numeric string
> representations now, after 30 years 	going to be outlawed? if
> so, on what basis?
>
> 	creating a useful RFC that creates a registry and maintains
> it in a timely 	fashion -in this century- seems a bedtime
> fable.

The other two things that seem to be getting lost in this 
discussion is that one can write all of the RFCs one like, but 
rules like this are ultimately useless unless ICANN agrees to 
them, presumably via the gNSO, one at a time, and via a PDP 
process.  The odds of the very-commercially-oriented gNSO 
agreeing to the IETF's being able to pull a name out of the 
potential namespace by simple IETF consensus (or less) are, IMO, 
around zilch.  Worse, as we move toward IDN TLDs, the odds are 
high that there will be no practical difference between an IDN 
gTLD and an IDN ccTLD other than the ability of the operator to 
shield itself from any potential ICANN enforcement action --even 
of agreements that were signed to get the domain-- by claiming 
national sovereignty and the rule that, in general, private 
bodies can't sue governments without the permission of those 
governments.

The complementary problem is that, in the present DNS 
environment in which typing errors are monetized, an effect of a 
reservation of "example.com" is registration of, e.g., 
"examlpe.com" and "exmaple.com" as placeholders, perhaps in case 
they draw enough traffic that someone would like to buy them 
(the web page for the first of these contains an explicit offer 
to sell it).

To at least some extent, our reserving a name and (if the use in 
plain-text examples, rather than, e.g., MIB examples actually 
drives non-trivial traffic toward those names) publicizing it 
makes spelling variations of that name more valuable.  I don't 
know if the gNSO would like that or not, but it seems to argue 
that we should be conservation about what names we reserve and 
thereby promote.

That has an interesting corollary: to the extent to which 
domains, especially web sites, consider unexpected access to be 
a potential profit source, rather than an annoyance, using 
someone else's domain name in an example may be "welcome free 
advertising", rather than a "rude intrusion".  One can argue 
against use of those names on either basis, but let's stop 
pretending that we have complete knowledge of what is going on 
here and of the consequences of our actions.

Perhaps we should ask ICANN to reserve all single-letter TLDs 
(in any script) for IETF use.  That would make the examples very 
clear, would avoid driving traffic to alternate sites (since we 
would "own" all of them) and would constitue a relatively closed 
list :-)

    john

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