Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

Andrew Sullivan <ajs@shinkuro.com> Mon, 09 November 2009 10:45 UTC

Return-Path: <ajs@shinkuro.com>
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 A41EB3A697B for <dnsop@core3.amsl.com>; Mon, 9 Nov 2009 02:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level:
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, 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 o+zt4ODa0AIS for <dnsop@core3.amsl.com>; Mon, 9 Nov 2009 02:45:02 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 278463A6967 for <dnsop@ietf.org>; Mon, 9 Nov 2009 02:44:32 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B8DED2FE8CA2 for <dnsop@ietf.org>; Mon, 9 Nov 2009 10:44:57 +0000 (UTC)
Date: Mon, 09 Nov 2009 05:44:55 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsop@ietf.org
Message-ID: <20091109104455.GB47598@shinkuro.com>
References: <20091105205921.GL17456@shinkuro.com> <8F5D82447C5F8BC6B50CD983@Ximines.local> <20091106193323.GZ17456@shinkuro.com> <558a39a60911070410p54bd1810n44ea845d2698b866@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <558a39a60911070410p54bd1810n44ea845d2698b866@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
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: Mon, 09 Nov 2009 10:45:03 -0000

On Sat, Nov 07, 2009 at 08:10:02PM +0800, James Seng wrote:
> "There is a genuine user problem here (though whether one should actually
> solve it is still an open question)."
> 
> It is a genuine user problem but I disagree with your latter statement.
> 
> It is not an open question it must be solved. It is a serious enough problem
> for Chinese that it must be resolve for the Chinese user. The open question
> is "how", not "if".

I understand that it is a serious problem.  But one solution is in
fact to solve this exactly the way we actually solved spelling
differences in English words: they're different zones, and we treat
them that way technically and use some non-technical policy rules to
solve the problem.

On this interpretation, the danger lies in acting as though there is a
mere technical solution for "variants".  Delegation (the "NS"
solution) just creates a new delegation, nothing more; and we ought to
be perfectly clear about that.  DNAME doesn't actually mirror an
entire tree, so it doesn't actually solve the variant problem for
real.  Therefore, if we want a complete solution to the problem of
variants, we need a new element in the DNS protocol.  It may require
server side processing, it may not work perfectly anyway, and it may
be subject to nasty subversions.

So, there is a clear benefit because there is a serious problem.  But
not all serious problems must be solved, because the solution can be
worse than the problem.  I don't _think_ the current example is a case
where the solution is worse than the problem; but I also don't believe
we have completely understood what exactly the problem is, whether
there is an actual technical problem here, and whether if there be a
technical problem we can invent or reuse any mechanism to solve it.
The proposals so far are, in my view, either completely wrong or just
mostly wrong.  (That includes using DNAME, by the way.)

A



-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.