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

Mark Andrews <Mark_Andrews@isc.org> Tue, 08 July 2008 01: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 8395B28C3AE; Mon, 7 Jul 2008 18:45:29 -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 41AB63A69B9 for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 18:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level:
X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599]
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 vIg4BcJstj5s for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 18:45:27 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by core3.amsl.com (Postfix) with ESMTP id 83C773A68DF for <ietf@ietf.org>; Mon, 7 Jul 2008 18:45:25 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m681jPff054747; Tue, 8 Jul 2008 11:45:26 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200807080145.m681jPff054747@drugs.dv.isc.org>
To: Ted Faber <faber@ISI.EDU>
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-reply-to: Your message of "Mon, 07 Jul 2008 18:32:42 MST." <20080708013242.GB10677@zod.isi.edu>
Date: Tue, 08 Jul 2008 11:45:25 +1000
Cc: Theodore Tso <tytso@MIT.EDU>, moore@network-heretics.com, 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> On Tue, Jul 08, 2008 at 10:18:25AM +1000, Mark Andrews wrote:
> > > That's at least as reliable as my (multi-dotted) home domain. :-)
> > >=20
> > > I'm not sure what's not to like here.  But then again, I may be blind.
> >=20
> > 	The point is that it is NOT reliable.  Whether it works
> > 	depends apon what names are matched in the search list.  It
> > 	does work for some people some of the time.  It does not
> > 	work for all of the world all of the time.  "hk" is not
> > 	globally unique.
> 
> That statement is also true for hk.com, ibm.com, google.com, or any
> other relative DNS name.
> 
> The site-dependent interpretation of the name is determined not by the
> presence of dot within the name but its absence from the end.  "hk." is
> as global as "hk.com." with respect to the search list; "hk" and
> "hk.com" are both relative names and their resolution is resolver
> dependent.
> 
> I don't buy "unreliable" as a diagnosis for that state of affairs.  "hk"
> operates exactly as any other DNS name with respect to search path.  An
> incautious user or clever DNS administrator can create a confusing state
> of affairs with or without the interior dot.
> 
> (As Bill Manning hinted, there may be other parts of the resolution code
> that are less reliable for names without a dot in them.  That I might
> buy as an argument for unreliability).=20
> 
> If you'd like to argue something more subjective like "confusing" or
> even "misleading," you'll find no resistance from me.
> 
> --=20
> Ted Faber
> http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
> asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
> SIG

	The point of going to heirachical names (RFC 921) is to
	remove abmiguity.  "tld"s don't meet the definition of a
	heirachical name.

	It is time that tld operators stopped mis-using the zones
	they operate.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf