Subject: [dbound] The Fate of DBOUND

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 17:28:39 +0900

Colleagues,

Your chairs have been meeting with our Area Directors at IETF 97 in Seoul
to discuss the fate of DBOUND.

We had our BoF in the spring of 2014 and the WG was formally approved the
following spring.  In the year and a half since, we have made almost no
progress toward a solution to either the combined or reduced problem
space.  Although we have a few proposals before us, we have seen no
convergence on any of them, nor has there been a sustained critical mass of
participants to work on our chartered goals.

At this point, we're not sure what else to try.  We are basically resigned
to the idea that DBOUND as currently constituted will not succeed in
producing something supported by IETF consensus.  We propose to concede and
ask our Area Directors to shut down the working group at the end of this
week, barring a convincing argument not to do so.  We can request that the
WG's list remain open for discussion of any of the current or future
proposals on the topic, and any participants that want to advance one or
more of them can do so via the ART area's current "dispatch" model.

Comments welcome.

-MSK and Pete, your co-chairs

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 16 Nov 2016 16:16:43 +0900

Andrew has suggested that SOPA be published as an experimental RFC, and 
Casey asked why shouldn't ODUP be published also. It would be a vast 
disservice if they were progressed differently, and if 
draft-levine-dbound-dns wasn't treated the same way.

Proposal: the WG stays open, there is a near-immediate WG Last Call on 
all three protocol documents in order to collect a last round of 
editorial and technical (not design) comments, and then all three are 
moved to Alexey for AD-sponsored as Experimental. That does include an 
IETF Last Call and IESG review, but Alexey can cover that. (This is 
assuming that Alexey is willing to do this.)

On 15 Nov 2016, at 21:59, Andrew Sullivan wrote:

> I spoke with Jeff tonight, and we would like to make a modest proposal
> as a way of closing the WG: that we polish off and publish the problem
> statement, in an effort at least to get something written down about
> what issues there are and what distinctions someone might want to
> make.

On this, I disagree with Andrew. The problem statement document hasn't 
been touched in over six months and I think has many use cases that 
probably do not have consensus. We would need to do a bunch more work 
(hopefully culling) that I don't think we have the energy to.

It is not the IETF way, but publishing a couple of related experimental 
protocols that have only their own internal problem statements seems 
better to me than hoping we have enough energy to agree on a single 
statement.

--Paul Hoffman

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 16 Nov 2016 16:10:27 +0800

From: Paul Hoffman
Date: 2016-11-16 15:16
To: [email-masked]
Subject: Re: [dbound] The Fate of DBOUND

>assuming that Alexey is willing to do this.)

I generally agree with Paul's suggestion.

https://tools.ietf.org/html/draft-yao-dbound-dns-solution-02 

is it possible to publish the draft above as the experimental one too?

Jiankang Yao

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 22:50:42 +0900

On Wed, Nov 16, 2016 at 4:16 PM, Paul Hoffman <[email-masked]> wrote:

> Proposal: the WG stays open, there is a near-immediate WG Last Call on all
> three protocol documents in order to collect a last round of editorial and
> technical (not design) comments, and then all three are moved to Alexey for
> AD-sponsored as Experimental. That does include an IETF Last Call and IESG
> review, but Alexey can cover that. (This is assuming that Alexey is willing
> to do this.)
>

I just had dinner and a beer with Pete so I sure wish I'd seen this first
so we could've discussed it.  Therefore, speaking only for myself at the
moment:

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
https://www.ietf.org/iesg/informational-vs-experimental.html.)

Absent that, we could consider Informational, or people can feel free to
avail themselves of the Independent stream or the DISPATCH path, or
whatever publication route they wish.  In the alternative, if somewhere
down the line it's clear critical mass has finally appeared, the group
could be rechartered and reactivated.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Nov 2016 13:09:58 -0800

On 11/16/2016 5:50 AM, Murray S. Kucherawy wrote:
> results and observations, to where will they be reported, etc.

Carrying this a bit further:

      Competing proposals get published when there is strong support for 
each and a failure to reconcile the support down to a single proposal.

      We have the latter condition, but I have missed the clear 
indication of the former.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Nov 2016 17:06:57 -0500

> https://www.ietf.org/iesg/informational-vs-experimental.html.)

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
    experiment.

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
that.

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.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2016 08:27:46 +0900

On Thu, Nov 17, 2016 at 7:06 AM, Andrew Sullivan <[email-masked]>
wrote:

> [...]

Mainly I base that on the one Experimental AD-sponsored draft I've had
published previously and what's written in that IESG statement.  I'm
anticipating what we'll be asked when sending any of these documents for
publication.  Maybe this IESG is softer than my past experience.

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 16 Nov 2016 16:36:55 -0800

On Wed, Nov 16, 2016 at 5:50 AM, Murray S. Kucherawy <[email-masked]>
wrote:

>> all three protocol documents in order to collect a last round of editorial
>> and technical (not design) comments, and then all three are moved to Alexey
>> for AD-sponsored as Experimental. That does include an IETF Last Call and
>> IESG review, but Alexey can cover that. (This is assuming that Alexey is
>> willing to do this.)
>>
>
> (See also RFC2026 and https://www.ietf.org/iesg/
> informational-vs-experimental.html.)
>

What about publishing an experimental design spec along with the four
drafts? That could put a framework around the entire process and perhaps
avoid some of the challenges that SPFbis had when trying to move from
experimental to standards track. The WG could become the manager of the
experiment for a designated duration and responsible for collecting and
publishing the results.

--Kurt