Re: [DNSOP] Public Suffix List

[Brian Dickson <[e-mail]>]

Gervase Markham wrote:
> The difference is that the public suffix list is an (attempt at an)
> expression of fact, not policy.

I think is where you are encountering resistance, even though you may 
not realize it.

What you are doing is *publishing* something, which alleges to be a 
factual list.

Who is on it, who is not on it, and who uses it and how, matter a great 
deal.

If the list is 100% complete and 100% accurate and 100% timely, there 
are no problems.
Any deviation from that situation, regardless of how much and in what 
manner the deviation occurs,
puts the publisher of alleged facts at risk.

And relying on authoritative sources to push data to you, is a reverse 
onus that hundreds of years of case
law quite likely present a formidable obstacle, if it becomes necessary 
to defend your choice.

Here's a concrete analogy that may be suitable for demonstrating the issue.

Imagine a magazine dedicated to "Tires". It publishes an article on 
"Tire Safety".
It contains a list of "Tires (manufacturer/model) safe to use at 180 km/h".
Is the list accurate? Timely? Complete?

If a reader bases a safety decision (buys tires, drives 180 km/h) that 
goes badly, then what?

What about recalls?

Also: Publishing a list may be even *riskier* than publishing a single, 
but erroneous, "fact".

E.g. what about manufacturers not listed?
They have been implicitly or even explicitly defamed, even if you 
include a footnote to the effect that "this list is not complete".
> IFrom [e-mail]  Wed Jun 11 09:32:37 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DD4553A67B2;
	Wed, 11 Jun 2008 09:32:37 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id ED8B23A6812
	for <[e-mail]>; Wed, 11 Jun 2008 09:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level: 
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vMc+4Ag+PY7n for <[e-mail]>;
	Wed, 11 Jun 2008 09:32:36 -0700 (PDT)
Received: from mx4.ca.afilias.info (vgateway.libertyrms.info [207.219.45.62])
	by core3.amsl.com (Postfix) with ESMTP id DB7603A67AD
	for <[e-mail]>; Wed, 11 Jun 2008 09:32:35 -0700 (PDT)
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90])
	by mx4.ca.afilias.info with esmtp (Exim 4.22)
	id 1K6TFt-0006kv-1j; Wed, 11 Jun 2008 12:33:01 -0400
Message-ID: <[e-mail]>
Date: Wed, 11 Jun 2008 12:32:51 -0400
From: Brian Dickson <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Gervase Markham <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<p06240800c474665e68d2@[10.20.30.249]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-SA-Exim-Mail-From: [e-mail]
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Gervase Markham wrote:
> The difference is that the public suffix list is an (attempt at an)
> expression of fact, not policy.

I think is where you are encountering resistance, even though you may 
not realize it.

What you are doing is *publishing* something, which alleges to be a 
factual list.

Who is on it, who is not on it, and who uses it and how, matter a great 
deal.

If the list is 100% complete and 100% accurate and 100% timely, there 
are no problems.
Any deviation from that situation, regardless of how much and in what 
manner the deviation occurs,
puts the publisher of alleged facts at risk.

And relying on authoritative sources to push data to you, is a reverse 
onus that hundreds of years of case
law quite likely present a formidable obstacle, if it becomes necessary 
to defend your choice.

Here's a concrete analogy that may be suitable for demonstrating the issue.

Imagine a magazine dedicated to "Tires". It publishes an article on 
"Tire Safety".
It contains a list of "Tires (manufacturer/model) safe to use at 180 km/h".
Is the list accurate? Timely? Complete?

If a reader bases a safety decision (buys tires, drives 180 km/h) that 
goes badly, then what?

What about recalls?

Also: Publishing a list may be even *riskier* than publishing a single, 
but erroneous, "fact".

E.g. what about manufacturers not listed?
They have been implicitly or even explicitly defamed, even if you 
include a footnote to the effect that "this list is not complete".
>f you are concerned that we will
> withhold changes or issue known-incorrect lists in order to conduct some
> sort of vendetta against a particular TLD, all I can say is "why on
> earth would we do that?"
>   

No malice is needed on your part, for publishing a list to cause 
problems, esp. for you and the publisher (Mozilla).
I think you might not have considered that, yet.

Conclusion:

Regardless of the benign intent of the list, publishing it means needing 
to keep it timely, accurate,
and complete, and that is why the notion of updates based on volunteered 
data from registries,
updated only when software updates are performed, is a particularly bad 
idea.

I happen to think that the idea of maintaining such a list is probably 
not a bad idea itself.

It is the means by which the list is built, and distributed, that are of 
great concern.

Brian
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


 If you are concerned that we will
> withhold changes or issue known-incorrect lists in order to conduct some
> sort of vendetta against a particular TLD, all I can say is "why on
> earth would we do that?"
>   

No malice is needed on your part, for publishing a list to cause 
problems, esp. for you and the publisher (Mozilla).
I think you might not have considered that, yet.

Conclusion:

Regardless of the benign intent of the list, publishing it means needing 
to keep it timely, accurate,
and complete, and that is why the notion of updates based on volunteered 
data from registries,
updated only when software updates are performed, is a particularly bad 
idea.

I happen to think that the idea of maintaining such a list is probably 
not a bad idea itself.

It is the means by which the list is built, and distributed, that are of 
great concern.

Brian
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop