Re: [DNSOP] Public Suffix List

[David Conrad <[e-mail]>]

Gervase,

On Jun 11, 2008, at 4:26 AM, Gervase Markham wrote:
> It's not true that we won't work on any other solution. This is what  
> we
> have now, and there have been no alternative proposals which (to my
> mind) look like producing anything workable in the short term.

I guess it depends on what you mean by 'workable'.

> Half this list seems to think that getting all the TLDs to agree on or
> do anything is an enterprise doomed to failure, and the other half  
> seem
> to think that we should be waiting for all the TLD operators to  
> agree to
> set up their own repositories of the data. There is a contradiction  
> there.

While I might agree that it is unlikely you'll get all the TLDs to  
agree on or do anything (they are a wildly varying bunch in pretty  
much every axis) I don't remember anyone suggesting you wait on the  
TLD operators to set up their own repositories.

What I do remember folks saying is that hardcoding a list in other  
contexts has caused lots of trouble in the past and that it is  
probably a mistake for you to do it in your product.  Some folks have  
even suggested alternatives (although I gather you do not consider  
them 'workable').

If I understand correctly, if there is no data (regardless of the  
solution), you get no change From [e-mail]  Wed Jun 11 10:07:57 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 35BEF3A6846;
	Wed, 11 Jun 2008 10:07:57 -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 ACA6C3A6846
	for <[e-mail]>; Wed, 11 Jun 2008 10:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.947
X-Spam-Level: 
X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5
	tests=[AWL=-0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4,
	SARE_LWSHORTT=1.24]
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 ovyq4nct8KxL for <[e-mail]>;
	Wed, 11 Jun 2008 10:07:54 -0700 (PDT)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190])
	by core3.amsl.com (Postfix) with ESMTP id 56A5E3A6845
	for <[e-mail]>; Wed, 11 Jun 2008 10:07:54 -0700 (PDT)
Received: from [10.0.1.198] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247])
	by virtualized.org (Postfix) with ESMTP id 556D123E87A;
	Wed, 11 Jun 2008 10:08:19 -0700 (PDT)
Message-Id: <[e-mail]>
From: David Conrad <[e-mail]>
To: Gervase Markham <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Wed, 11 Jun 2008 10:08:18 -0700
References: <[e-mail]>	<[e-mail]>
	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]>
X-Mailer: Apple Mail (2.924)
Cc: [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,

On Jun 11, 2008, at 4:26 AM, Gervase Markham wrote:
> It's not true that we won't work on any other solution. This is what  
> we
> have now, and there have been no alternative proposals which (to my
> mind) look like producing anything workable in the short term.

I guess it depends on what you mean by 'workable'.

> Half this list seems to think that getting all the TLDs to agree on or
> do anything is an enterprise doomed to failure, and the other half  
> seem
> to think that we should be waiting for all the TLD operators to  
> agree to
> set up their own repositories of the data. There is a contradiction  
> there.

While I might agree that it is unlikely you'll get all the TLDs to  
agree on or do anything (they are a wildly varying bunch in pretty  
much every axis) I don't remember anyone suggesting you wait on the  
TLD operators to set up their own repositories.

What I do remember folks saying is that hardcoding a list in other  
contexts has caused lots of trouble in the past and that it is  
probably a mistake for you to do it in your product.  Some folks have  
even suggested alternatives (although I gather you do not consider  
them 'workable').

If I understand correctly, if there is no data (regardless of the  
solution), you get no change inin behavior.   As such, doing a probe for  
policy data when it is needed would seem to be workable.  If there is  
no data available (for whatever reason), you get no change in  
behavior.  If there is data, you get the most up to date available.   
Whether or not you start with a static list that is then over-ridden  
by the response from the probe is an implementation choice that can be  
argued.

FWIW.

Regards,
-drc

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


 behavior.   As such, doing a probe for  
policy data when it is needed would seem to be workable.  If there is  
no data available (for whatever reason), you get no change in  
behavior.  If there is data, you get the most up to date available.   
Whether or not you start with a static list that is then over-ridden  
by the response from the probe is an implementation choice that can be  
argued.

FWIW.

Regards,
-drc

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