Re: [DNSOP] new draft about idn tld variants implementation
Mark Andrews <marka@isc.org> Fri, 16 October 2009 05:32 UTC
Return-Path: <marka@isc.org>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70BA3A67F3 for <dnsop@core3.amsl.com>; Thu, 15 Oct 2009 22:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MRl7N2FkPYWQ for <dnsop@core3.amsl.com>; Thu, 15 Oct 2009 22:32:46 -0700 (PDT)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id C82893A6782 for <dnsop@ietf.org>; Thu, 15 Oct 2009 22:32:45 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D438EE6059; Fri, 16 Oct 2009 05:32:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9G5WgS0036223; Fri, 16 Oct 2009 16:32:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200910160532.n9G5WgS0036223@drugs.dv.isc.org>
To: Sebastian Castro <sebastian@nzrs.net.nz>
From: Mark Andrews <marka@isc.org>
References: <004a01ca4d9a$9b866920$63c0ab73@YaoJK> <20091015204405.GJ6184@shinkuro.com> <4AD7FC8E.40202@nzrs.net.nz>
In-reply-to: Your message of "Fri, 16 Oct 2009 17:54:38 +1300." <4AD7FC8E.40202@nzrs.net.nz>
Date: Fri, 16 Oct 2009 16:32:42 +1100
Sender: marka@isc.org
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] new draft about idn tld variants implementation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2009 05:32:46 -0000
In message <4AD7FC8E.40202@nzrs.net.nz>, Sebastian Castro writes: > Andrew Sullivan wrote: > > Dear colleagues, > > Dear colleagues, > > my reply to Andrew inline (I don't cover all points tho) > > > > > > > (3) is not, so far, an argument we have been hearing from the root > > nameserver operators. But in any case, this is a load and > > provisioning issue, and is not an argument that can properly be made > > about whether a given technology as such should be selected for a > > given purpose. It is rather a consideration that needs to be taken > > into account when someone makes a decision to support variant labels. > > It is an important operational consideration, and operational > > constraints have to be taken into account when making deployment > > decisions. That's an issue to be debated in the root server > > operators' fora, or at ICANN, but not here I think. > > I think it's a valid concern about the load at the root servers and > agree it doesn't correspond here to discuss it. If ICANN/root_operators > decide to implemente the IDN TLD variants by using DNAME, every query > for a name under the variant will go to the roots. No they won't, only non-DNAME aware resolvers will go back to the roots. DNAME aware resolvers will perform the synthesis locally using the cached DNAME. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [DNSOP] new draft about idn tld variants implemen… Yao Jiankang
- Re: [DNSOP] new draft about idn tld variants impl… Ray.Bellis
- Re: [DNSOP] new draft about idn tld variants impl… Andrew Sullivan
- Re: [DNSOP] new draft about idn tld variants impl… Mark Andrews
- Re: [DNSOP] new draft about idn tld variants impl… YAO Jiankang
- Re: [DNSOP] new draft about idn tld variants impl… Sebastian Castro
- Re: [DNSOP] new draft about idn tld variants impl… Mark Andrews
- Re: [DNSOP] new draft about idn tld variants impl… Alfred Hönes
- Re: [DNSOP] new draft about idn tld variants impl… Niall O'Reilly
- Re: [DNSOP] new draft about idn tld variants impl… Chris Thompson
- Re: [DNSOP] new draft about idn tld variants impl… Andrew Sullivan
- Re: [DNSOP] new draft about idn tld variants impl… Alfred Hönes
- Re: [DNSOP] new draft about idn tld variants impl… Chris Thompson
- Re: [DNSOP] new draft about idn tld variants impl… joao damas
- Re: [DNSOP] new draft about idn tld variants impl… YAO Jiankang
- Re: [DNSOP] new draft about idn tld variants impl… Paul Hoffman
- Re: [DNSOP] new draft about idn tld variants impl… YAO Jiankang