Re: [dbound] On (not) moving forward

["Paul Hoffman" <[e-mail]>]

First off, I wasn't suggesting that the volunteers running the current 
solution stop" was much of a risk: it was just the biggest risk I could 
see for the the WG closing without standardizing on one of the proposed 
new solutions. Mozilla has a good reason to keep doing the work.

On 28 Mar 2016, at 6:26, Murray S. Kucherawy wrote:

> On Mon, Mar 28, 2016 at 1:49 AM, Gervase Markham <[e-mail]> 
> wrote:
>
>> On 24/03/16 00:24, Paul Hoffman wrote:
>>> - If the WG closes without standardizing on one of the proposed new
>>> solutions, the highest risk is that the volunteers running the 
>>> current
>>> solution stop.
>>
>> That's a fairly small risk; as the data is open, someone else could 
>> just
>> start. In this unlikely event, there would perhaps be a risk of
>> fragmentation (multiple competing sources of truth).
>>
>
> I think there's a risk of fragmentation already.  Someone who doesn't 
> like
> a choice you make about an entry that gets added (or omitted) could 
> start
> doing their own now.  There certainly are a lot of DNSBLs around, for
> example.  Then people would have to decide which PSL they want use, or 
> how
> to aggregate the results after consulting both.

Murray's point is a good one, but that's not necessarily much of a 
negative risk. If the "main" PSL continues to be updated, anyone 
choosing a fork of the PSL has to have a good reason to do so. I can 
think of some good reasons that might come up, but as we all know, the 
chance that even a well-maintained fork could overtake the main one in 
under a decade are slim.

Having said that: if this WG adopts one *or even multiple* of the 
proposals as Experimental RFCs. and even if just a handful of zone 
maintainers adopt some of them, Mozilla could use those as input to its 
own PSL. If Mozilla chooses not to do that, forking the PSL at 
https://github.com/publicsuffix/list and using the scraped data would be 
a very low-effort work, and if people coalesced around one fork, Mozilla 
might say "hey, that's a good idea" or a contingent of users would just 
use the fork.

This might be a good enough reason for DBOUND to move forward with a 
different charter. Instead of picking one solution for Standards Track 
with the too-little energy that we seem to have, we could:

- Informally help the authors to get the four drafts down to two or 
three

- Get some more review so that the authors can put more "why this 
proposal might not work for you" sections in their documents

- Send them all to the IETF as Experimental at the same time

I know that some people find this kind or resolution to IETF efforts to 
be a failure. Because these could be input to the PSL, or to a popular 
fork of the PSL if needed, I think this is actually worth our time and a 
bit more effort.

If others like this idea, I'm willing to work on charter text. If others 
thing I'm crazy, I'm willing to sit here quietly.

--Paul Hoffman