Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00

Suzanne Woolf <woolf@isc.org> Tue, 08 March 2011 10:40 UTC

Return-Path: <woolf@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D83B3A6842 for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 02:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 bjDHy5rRTgEH for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 02:40:08 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id F38E13A683B for <dnsext@ietf.org>; Tue, 8 Mar 2011 02:40:06 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8A14A5F983B; Tue, 8 Mar 2011 10:41:06 +0000 (UTC) (envelope-from woolf@isc.org)
Received: by bikeshed.isc.org (Postfix, from userid 10265) id 0C310216C22; Tue, 8 Mar 2011 10:41:05 +0000 (UTC)
Date: Tue, 8 Mar 2011 10:41:05 +0000
From: Suzanne Woolf <woolf@isc.org>
To: Alex Bligh <alex@alex.org.uk>
Message-ID: <20110308104105.GB88549@bikeshed.isc.org>
References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> <7C043A33C72339E8A1FB6659@nimrod.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7C043A33C72339E8A1FB6659@nimrod.local>
User-Agent: Mutt/1.4.2.3i
Cc: dnsext@ietf.org
Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2011 10:40:18 -0000

On Tue, Mar 08, 2011 at 09:24:17AM +0000, Alex Bligh wrote:
> --On 7 March 2011 17:33:07 -0800 Doug Barton <dougb@dougbarton.us> wrote:
>
> I am not sure Nick is missing the point. We do not *know* that users want
> to use the variant labels on the RHS of NS and MX records (beyond the
> obvious truism that it would be nice to do everything). I am guessing that
> most users want to use the variant labels in URLs and email addresses, and
> that's it.

+1 on the point that we don't know. The problem statement draft is the
attempt to capture the landscape but if you've read the -00 it's
fairly clear we don't know *that* much.

> Suzanne Woolf is attempting to gather some matrix of requirements and
> balance them against disruption. Until such point (that might be never),
> all we've got is different proposed solutions with different functionality.
> What you're saying is that CLONE (apparently) allows the RHS of an NS
> record to be a variant too, which differentiates it from (e.g.) a
> CNAME/DNAME combination.

The -00 of the problem statement draft has been out for a couple of
weeks and we hope to ship a -01 before the Prague cutoff. I think Alex
and Doug have both sent comments, and more are welcome but we need
anything for the -01 in the next few days.

(I don't think I'll have time to read CLONE and add a description for
the -01, but if someone wants it in there alongside the attempts to
describe shadow zones and the assorted xNAMEs, send text.)

> Out of interest, /why/ is a variant being on the RHS of an NS or MX record
> useful? This is never visible to end users, and in the majority of use
> cases thus far brought up, the RHS of the NS or the MX record gets to be
> one user-illegible string beginning "xn--" rather than another illegible
> string beginning "xn--".

There have been a couple of comments from apps folks on this,
particularly Patrik Faltstrom, suggesting a possible use case in which
the alias is part of a resolution chain, i.e. underlying a URI. This
argument supposes that some user-illegible strings are nonetheless
useful for applications and application-facing services.


Suzanne