Re: [dbound] The Fate of DBOUND

Andrew Sullivan <> Wed, 16 November 2016 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8649A1295AE for <>; Wed, 16 Nov 2016 14:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PlWQOK8tyTAK for <>; Wed, 16 Nov 2016 14:07:02 -0800 (PST)
Received: from ( [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by (Postfix) with ESMTP id BF55012955E for <>; Wed, 16 Nov 2016 14:07:02 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A091010A06 for <>; Wed, 16 Nov 2016 22:07:10 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SvYa2_jXFMnl for <>; Wed, 16 Nov 2016 22:07:09 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 241A6106F6 for <>; Wed, 16 Nov 2016 22:07:08 +0000 (UTC)
Date: Wed, 16 Nov 2016 17:06:57 -0500
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [dbound] The Fate of DBOUND
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DNS tree bounds <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Nov 2016 22:07:04 -0000

On Wed, Nov 16, 2016 at 10:50:42PM +0900, Murray S. Kucherawy wrote:
> I would support this if there was with each (including Jiankang's draft)
> some indication of how the experiment would be run: Who's going to build
> the code, who's going to run services that include the new data, who's
> going to run services that try to use the new data, how will the
> effectiveness and operational cost be determined, who will collect the
> results and observations, to where will they be reported, etc.  I don't
> want Experimental to be used as some kind of open-ended consolation prize.
> (See also RFC2026 and

I don't think that's a reasonable interpretation of Experimental,
because I think it's too prescriptive, but I certainly intended to add
to the draft I've worked on some experiment parameters.  What I had in
mind was this:
    1.  What the difference is supposed to be in the presence or
    absence of a SOPA record.

    2.  What the necessary code and operational additions are.

    3.  What would qualify as a functional proof of utility.

    4.  What would qualify as a practical proof of utility (i.e. that
    this approach could in fact be used at Internet scale).

    5.  Considerations of additional utility that might be found, and
    what the consequences of that would be for the results of the

That is, I want the status to be experiment_al_, but not necessarily
"experiment".  There's no promise anyone _would_ do this experiment,
just that it is available for such uses.  I'm prepared to put a
deprecation date on the RRTYPE if people really feel that is
necessary, though the RRTYPE registry doesn't really have a way to do

I agree that experimental shouldn't be used as a consolation prize.
But my claim is that the approach John has advocated doesn't solve my
problem and that Casey's approach is too complicated to be practical.
Others have claimed that SOPA is not useful given the incentives in
the system.  All of these are empirical claims that could be answered
by trying the different approaches out, and I think that's what
"experimental" ought to mean.


Andrew Sullivan