Re: [DNSOP] Public Suffix List

David Conrad <drc@virtualized.org> Mon, 09 June 2008 18:55 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@lists.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6813A6C5B; Mon, 9 Jun 2008 11:55:50 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E09B3A6A70 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 11:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.534
X-Spam-Level:
X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 MIzsVVgr9AE4 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 11:55:48 -0700 (PDT)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id C0A733A682C for <dnsop@ietf.org>; Mon, 9 Jun 2008 11:55:48 -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 341C223820D; Mon, 9 Jun 2008 11:56:08 -0700 (PDT)
Message-Id: <9C47AC3F-A0EA-48BB-9B28-DFD2C4855EB3@virtualized.org>
From: David Conrad <drc@virtualized.org>
To: Gervase Markham <gerv@mozilla.org>
In-Reply-To: <484D5B88.3090902@mozilla.org>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Mon, 9 Jun 2008 11:56:05 -0700
References: <484CFF47.1050106@mozilla.org> <484D1533.4060300@spaghetti.zurich.ibm.com> <484D1883.4060002@mozilla.org> <666CCACE-71F0-485D-9C9F-0C3E0C965ADA@virtualized.org> <484D52EC.1090608@mozilla.org> <C5894EBB-D4AA-40AD-8A38-2F4CD8A07D66@virtualized.org> <484D5B88.3090902@mozilla.org>
X-Mailer: Apple Mail (2.924)
Cc: dnsop@ietf.org, ietf-http-wg@w3.org
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: dnsop@ietf.org
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:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

Gervase,

On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote:
>> I'm curious: have you consulted with the various TLD-related
>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD,  
>> etc.) on
>> how to solve this problem?
>
> No. What do you think they'd say that hasn't been said in this thread
> already?

You're talking about essentially creating a registry of their registry  
policies and distributing it statically via your product.  I would  
imagine they might be interested and might even have some useful input  
to provide.  Some might even think it rude (even Microsoftian :-)) not  
to ask.  But perhaps I've been at layer 9 too long.

Just to be clear, my understanding of the situation is that you are  
proposing to ask that every TLD who has a zone in which the public can  
register to notify you of that fact so that you can distribute and use  
a list of these registries within your product, relying on Mozilla's  
update/upgrade functionality to update and maintain this list.   
Explicit in this proposal is that the registries notify you every time  
they add a new 'public registry' or change the status of an existing  
'public registry'.  Failure to update a registry could have negative  
impact on customers of the TLD due to, for example, being unable to  
set cookies. Is this an accurate summary?

Regards,
-drc

P.S. If you do send your message to the technical contacts for all the  
TLDs, expect quite a few bounces.  It seems keeping whois data up to  
date is a challenge for many TLD admins.  Having a bit of experience  
dealing with the various TLD administrators, this might be seen as  
cautionary towards what you're proposing to do.

P.P.S. Before anyone asks, IANA policies disallow IANA from initiating  
a change and require all changes to be confirmed by the TLD admins --  
IANA could harass people to update their info, but the TLD AC and TC  
must take action for a change to occur.  This turns out to be quite a  
stumbling block.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop