Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment

Suzanne Woolf <woolf@isc.org> Mon, 14 February 2011 16:56 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 08C423A6A0F for <dnsext@core3.amsl.com>; Mon, 14 Feb 2011 08:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 JO7a69iv41Ey for <dnsext@core3.amsl.com>; Mon, 14 Feb 2011 08:56:45 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 0357C3A6A57 for <dnsext@ietf.org>; Mon, 14 Feb 2011 08:56:45 -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.pao1.isc.org (Postfix) with ESMTPS id B5CD2C9427; Mon, 14 Feb 2011 16:57:05 +0000 (UTC) (envelope-from woolf@isc.org)
Received: by bikeshed.isc.org (Postfix, from userid 10265) id A9D76216C22; Mon, 14 Feb 2011 16:57:05 +0000 (UTC)
Date: Mon, 14 Feb 2011 16:57:05 +0000
From: Suzanne Woolf <woolf@isc.org>
To: Andrew Sullivan <ajs@shinkuro.com>
Message-ID: <20110214165705.GA76894@bikeshed.isc.org>
References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org> <F5CC3C0B5F464E63A4154F62B9BFFDD1@ics.forth.gr> <20110214071047.GA64679@bikeshed.isc.org> <15CC617D3D244626A6B31600701E9A81@ics.forth.gr> <20110214163742.GC71863@shinkuro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110214163742.GC71863@shinkuro.com>
User-Agent: Mutt/1.4.2.3i
Cc: dnsext@ietf.org
Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment
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: Mon, 14 Feb 2011 16:56:46 -0000

On Mon, Feb 14, 2011 at 11:37:43AM -0500, Andrew Sullivan wrote:
> But in
> between those events very little discussion on the topic seems to have
> happened.  Moreover, when we do have discussion it tends to focus on
> existing proposals: "Do BNAME", for instance.  But the problem we have
> is that we cannot tell whether BNAME (or any other proposal) actually
> addresses the particular problems people have.  So either we get a
> clear and broadly agreed-upon statement of the problem we are trying
> to solve, or we don't solve the problem (because if we can't say what
> it is, I think that means we don't know).

With all due respect, I'm not sure this is the most (or at least only)
useful razor for where we are at the moment.

I went back and looked at the problem statement draft after being
forced to put it aside for other things for some time. What I'm seeing
is that it has a couple of examples, and could benefit from more, and
needs to more clearly state the potential protocol issues around
application awareness, special processing, etc....

But the other thing we haven't talked about much is the actual
requirements for solutions. We did once (in Anaheim maybe?) but IIRC
only the once.

The main piece that the -00 will have that the previous individual
submission versions didn't, I think now, will be the list of what we
think a solution should look like....not in the protocol details of
behavior, I agree we won't know those without finer details of the
problems (probably plural) we're talking about....but in the sense of
things like:

* A solution must not break DNSSEC;
* A solution must not (should not?) require client changes to be useful;
* A solution must not change existing behavior of established RRtypes and
  protocol (which would make "fix CNAME" a non-starter);
* A solution should clearly either be less work than existing techniques, or
  solve some specific case (such as the canonicalization of email
  addresses that Vaggelis mentioned) that isn't otherwise solvable, so there's
  some incentive for deployment....
* A solution should not be specific to the root zone;

etc.

best,
S.