RE: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
"Edmon Chung" <mail@edmon.asia> Mon, 07 July 2008 15:45 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 DFD0128C1AE; Mon, 7 Jul 2008 08:45:57 -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 68F5D3A69C2 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 16:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[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 UdDDpjFNMZp3 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 16:33:08 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id D216C3A69B9 for <ietf@ietf.org>; Fri, 4 Jul 2008 16:33:08 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1381399rvf.49 for <ietf@ietf.org>; Fri, 04 Jul 2008 16:33:16 -0700 (PDT)
Received: by 10.114.66.8 with SMTP id o8mr3803894waa.169.1215214395362; Fri, 04 Jul 2008 16:33:15 -0700 (PDT)
Received: from edmontz ( [222.166.211.221]) by mx.google.com with ESMTPS id v25sm985719wah.36.2008.07.04.16.33.11 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Jul 2008 16:33:13 -0700 (PDT)
From: Edmon Chung <mail@edmon.asia>
To: 'Vint Cerf' <vint@google.com>, 'John C Klensin' <john-ietf@jck.com>
References: <20080701223655.14768.qmail@simone.iecc.com> <C7F7E8A9-C844-4E1C-827D-189D4937BA6B@acm.org> <14AE948B18197467AE4D96A4@p3.JCK.COM> <558a39a60807021729m1fc299c2ted96064ce73228a7@mail.gmail.com> <D400669B-EA1C-4494-8094-20DC762F0EB5@acm.org> <558a39a60807031514ra9323c2n9395306e7865fef1@mail.gmail.com> <FA303A8B-80BC-4F75-B42E-47A6A28547A7@google.com> <392E87F9BBF8DC79E2167BA0@p3.JCK.COM> <C743C857-9DB3-4497-A9E3-8134E30D449B@google.com>
In-Reply-To: <C743C857-9DB3-4497-A9E3-8134E30D449B@google.com>
Subject: RE: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
Date: Sat, 05 Jul 2008 07:33:03 +0800
Message-ID: <1e1101c8de2e$4fe74e80$efb5eb80$@asia>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcjeDPYbG4Ba7cBjTJGcv/J+EXsDeAAIK7VQ
Content-Language: en-ca
X-Mailman-Approved-At: Mon, 07 Jul 2008 08:45:52 -0700
Cc: 'James Seng' <james@seng.sg>, idna-update@alvestrand.no, 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
Regarding single Unicode code-point labels at the TLD level, there was quite some discussion on this topic at the GNSO Reserved Names working group and then at the new gTLD discussion. The final recommendation from the GNSO was: "Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case-by-case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS. Single and two character labels at the second level and the third level if applicable should be available for registration, provided they are consistent with the IDN Guidelines." As for ASCII, the recommendation was: "We recommend reservation of single letters at the top level based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered." Edmon > -----Original Message----- > From: idna-update-bounces@alvestrand.no [mailto:idna-update- > bounces@alvestrand.no] On Behalf Of Vint Cerf > Sent: Saturday, July 05, 2008 3:33 AM > To: John C Klensin > Cc: James Seng; idna-update@alvestrand.no; ietf@ietf.org; Lyman Chapin > Subject: Re: Single-letter names (was: Re: Update of RFC 2606 based on the > recent ICANN changes?) > > john, > > my reaction was specific to IDN single character TLDs. In some > languages these are complete words. > > vint > > > On Jul 4, 2008, at 1:50 PM, John C Klensin wrote: > > > Vint, > > > > In the ASCII space, there have been three explanations offered > > historically for the one-character prohibition on top and > > second-level domains. I've written variations on this note > > several times, so will just try to summarize here. Of the > > three, the first of these is at best of only historical interest > > and may be apocryphal and the second is almost certainly no > > longer relevant. The third remains significant. > > > > (1) Jon has been quoted as suggesting that we could have > > eliminated many of the problems we now face with TLDs and > > simultaneously made the "no real semantics in TLD names" rule > > much more clear had we initially allocated "b".."y" as TLDs. > > Then, when someone asked for an assignment, it would have been > > allocated at random to one of those domains. While this has a > > certain amount of appeal, at least in retrospect, there is > > probably no way to get from where we are today to that model... > > unless actions taken in the near future so ruin the current DNS > > tree as a locus for stable and predictable references that we > > need to start over with a new tree. I don't think that a "have > > to start over" scenario is at all likely, but I no long believe > > it to be impossible. > > > > (2) There was an idea floating around for a while that, if some > > of the popular TLDs "filled up", one could create single-letter > > subdomains and push subsequent registrations down the tree a > > bit. For example, if .COM were declared "full", then "a.com", > > "b.com", etc., would be allocated and additional reservations > > pushed into subdomains of those intermediate domains rather than > > being registered at the second level. Until and unless the > > conventional wisdom that adding more names to .COM merely > > requires more hardware and/or bandwidth, that won't be a > > "filled up" point at which this sort of strategy could be > > triggered. Worse, trying to use single-letter subdomains as an > > expansion mechanism would raise political issues about putting > > latecomers at an advantage that would be, IMO, sufficient to > > completely kill the idea. In the current climate, I think the > > community would decide that it preferred a disfunctional DNS if > > that were ever the choice (see the "start over" remark above). > > > > (3) At least in the discussions that led up to RFC 1591, and > > probably much earlier, there were concerns about reducing the > > likelihood of false hits if the end user made single-character > > typing errors. With only 26 (or maybe 36) possible characters, > > it could just about be guaranteed that all of them would be > > registered and that _any_ typing error would yield a false > > match. That, in itself, has been considered sufficient to > > prohibit single-letter labels and, by extension, to be fairly > > careful about two-letter ones. There have been arguments on > > and off over the years as to whether this is a "technical" > > reason or an attempt to set policy. Even though the mismatches > > would obviously not cause the network to explode or IP to stop > > working, at least some of us consider the informational > > retrieval and information theoretic reasons to insist on more > > information in domain name labels in order to lower the risk of > > false positive matches to be fully as "technical" as something > > that would have obvious lower-level network consequences. > > Others --frankly especially those who see commercial advantage > > in getting single-letter names-- have argued that this position > > is just a policy decision in disguise. > > > > Note that, with slight modifications, the second and third > > arguments apply equally well to TLD allocations and to SLD > > allocations, especially in popular domains. > > > > The reasoning associated with the third case also applies to any > > other script that contains a fairly small number of characters. > > One could manage a long philosophical discussion as to whether > > there are sufficient characters in the fully-decorated > > Latin-derived collection to eliminate the problem, but an > > analysis of keyboard and typing techniques/ input methods for > > that range of characters would, IMO, yield the same answer -- > > single-letter domains are just not a good idea and two-letter > > ones near the top of the tree should be used only with great > > caution. > > > > On the other hand, the same reasoning would break down when > > confronted with a script that contains thousands of characters, > > such as the "ideographic" ones. There are enough characters > > available in those scripts that one can presumably not worry > > about single-character typing errors (and one can perhaps worry > > even less if the usual input methods involve typing > > phonetically, using a different script, and then selecting the > > relevant characters from a menu -- in those cases, the phonetic > > representations are typically more than a character or two long > > and the menu selection provides an extra check about false > > matches). > > > > john > > > > > > > > --On Thursday, 03 July, 2008 19:04 -0400 Vint Cerf > > <vint@google.com> wrote: > > > >> seems odd to me too, James. > >> > >> vint > >> > >> > >> On Jul 3, 2008, at 6:14 PM, James Seng wrote: > >> > >>>> At the moment, the condition is "no single Unicode code > >>>> point." To the extent that a single CJK ideograph can be > >>>> expressed using a single Unicode code point, this would > >>>> represent the situation to which you say you would object. I > >>>> will dig through my notes to find out why the "single > >>>> character" condition was adopted - > >>> > >>> Would you be able to explain why the condition is "no single > >>> Unicode code point"? Whats the technical basis for that? > > > > > > > > > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update _______________________________________________ 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