Re: [DNSOP] Public Suffix List
Edward Lewis <Ed.Lewis@neustar.biz> Mon, 09 June 2008 14:17 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 23ACA3A6911; Mon, 9 Jun 2008 07:17:42 -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 8A8793A6C7C for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 07:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.375
X-Spam-Level:
X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 XIbuN8YQow9u for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 07:17:39 -0700 (PDT)
Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 6C78F3A699D for <dnsop@ietf.org>; Mon, 9 Jun 2008 07:17:39 -0700 (PDT)
Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m59EHbIK079719; Mon, 9 Jun 2008 10:17:38 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240803c472e87e44f2@[0.0.0.0]>
In-Reply-To: <op.uchiir0cvqd7e2@killashandra.oslo.opera.com>
References: <484CFF47.1050106@mozilla.org> <0A0401AF-0DDF-491A-8118-4945DEE64DE7@frobbit.se> <op.uchiir0cvqd7e2@killashandra.oslo.opera.com>
Date: Mon, 09 Jun 2008 10:17:36 -0400
To: yngve@opera.com
From: Edward Lewis <Ed.Lewis@neustar.biz>
X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6
Cc: Gervase Markham <gerv@mozilla.org>, 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org
At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote: >On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <patrik@frobbit.se> >wrote: > >> The problem with any such mechanisms is that the barrier of entry for >> new players (that does not match the currently used list -- including >> non-upgraded software) is increased. More than what people think. > >That is why my subtld-structure draft is suggesting that TLD profiles be >downloaded at regular intervals (and at need) from a repository, in order >to make it possible to add new TLDs or new registry-like domains under a >TLD, and to prevent problems with old software. My drafts also suggest a >rule-of-thumb fallback in case a TLD is unknown. This thread is going to go around in circles for quite a while. There's a history of the IETF wanting to define something without fixed boundaries. DNS names is one, IPv6 addresses is another. But when it comes to operations, having fixed boundaries makes mass production much easier. E.g., in IPv6, IETFer's (as we know, the IETF doesn't have any official statement source and no members, so I refer to those in the debate that brandish IETF credentials) would say that the days of classful addressing are behind us, so IPv6 addresses ought to be treated as nothing but a string of 128 bits. But RIR policy writers wanted to know whether to recommend /48's, /54's, /32's, etc. for certain types of uses. ("Uses" not users.) Shifting back to DNS, there's not going to be a scientifiFrom dnsop-bounces@ietf.org Mon Jun 9 07:17:42 2008 Return-Path: <dnsop-bounces@ietf.org> X-Original-To: dnsop-archive@optimus.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 23ACA3A6911; Mon, 9 Jun 2008 07:17:42 -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 8A8793A6C7C for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 07:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 XIbuN8YQow9u for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 07:17:39 -0700 (PDT) Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 6C78F3A699D for <dnsop@ietf.org>; Mon, 9 Jun 2008 07:17:39 -0700 (PDT) Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m59EHbIK079719; Mon, 9 Jun 2008 10:17:38 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: <a06240803c472e87e44f2@[0.0.0.0]> In-Reply-To: <op.uchiir0cvqd7e2@killashandra.oslo.opera.com> References: <484CFF47.1050106@mozilla.org> <0A0401AF-0DDF-491A-8118-4945DEE64DE7@frobbit.se> <op.uchiir0cvqd7e2@killashandra.oslo.opera.com> Date: Mon, 9 Jun 2008 10:17:36 -0400 To: yngve@opera.com From: Edward Lewis <Ed.Lewis@neustar.biz> X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Cc: Gervase Markham <gerv@mozilla.org>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote: >On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <patrik@frobbit.se> >wrote: > >> The problem with any such mechanisms is that the barrier of entry for >> new players (that does not match the currently used list -- including >> non-upgraded software) is increased. More than what people think. > >That is why my subtld-structure draft is suggesting that TLD profiles be >downloaded at regular intervals (and at need) from a repository, in order >to make it possible to add new TLDs or new registry-like domains under a >TLD, and to prevent problems with old software. My drafts also suggest a >rule-of-thumb fallback in case a TLD is unknown. This thread is going to go around in circles for quite a while. There's a history of the IETF wanting to define something without fixed boundaries. DNS names is one, IPv6 addresses is another. But when it comes to operations, having fixed boundaries makes mass production much easier. E.g., in IPv6, IETFer's (as we know, the IETF doesn't have any official statement source and no members, so I refer to those in the debate that brandish IETF credentials) would say that the days of classful addressing are behind us, so IPv6 addresses ought to be treated as nothing but a string of 128 bits. But RIR policy writers wanted to know whether to recommend /48's, /54's, /32's, etc. for certain types of uses. ("Uses" not users.) Shifting back to DNS, there's not going to be a scientic differentiation between one zone and another. During the DNSSEC development days we wanted to declare some zones as "widely delegated" (such as .com) from other zones - to alleviate the issues we see with NSEC, NSEC3, etc. that are apparent still now. There's nothing in DNS to differentiate, at a protocol level, one zone from another, but at the operational end of the stick, there are many differentiators (like whether the administration interface is on paper or via EPP). I doubt that you'll find any repository that can be used to register "registry-like" zones. The DNS lacks anything like a RADB, RPSL, etc., mechanism employed by the routing infrastructure. Partly because, unlike IP addresses, there is no organizational link through all parts of the Domain administrations. ICANN does not have it's "thumbs" on all the TLDs - many ccTLDs do not operate under any agreement with ICANN. I admire and respect the effort of web browser implementers to try to improve their code to make it harder to abuse. Even if the desired tactic is on target, it may still fail because the information is just not available. Worse is broken security which will just frustrate the users and make the situation even more fertile for abuse (through uncertainty and confusion). The domain name industry is more complex than one would think. It's not technical, it's a market place with operators, wholesalers, resellers, etc. I think the answers to building a domain's reputation lie more in what happens at an ICANN meeting than an IETF meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop fic differentiation between one zone and another. During the DNSSEC development days we wanted to declare some zones as "widely delegated" (such as .com) from other zones - to alleviate the issues we see with NSEC, NSEC3, etc. that are apparent still now. There's nothing in DNS to differentiate, at a protocol level, one zone from another, but at the operational end of the stick, there are many differentiators (like whether the administration interface is on paper or via EPP). I doubt that you'll find any repository that can be used to register "registry-like" zones. The DNS lacks anything like a RADB, RPSL, etc., mechanism employed by the routing infrastructure. Partly because, unlike IP addresses, there is no organizational link through all parts of the Domain administrations. ICANN does not have it's "thumbs" on all the TLDs - many ccTLDs do not operate under any agreement with ICANN. I admire and respect the effort of web browser implementers to try to improve their code to make it harder to abuse. Even if the desired tactic is on target, it may still fail because the information is just not available. Worse is broken security which will just frustrate the users and make the situation even more fertile for abuse (through uncertainty and confusion). The domain name industry is more complex than one would think. It's not technical, it's a market place with operators, wholesalers, resellers, etc. I think the answers to building a domain's reputation lie more in what happens at an ICANN meeting than an IETF meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
- [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Antoin Verschuren
- Re: [DNSOP] Public Suffix List bert hubert
- Re: [DNSOP] Public Suffix List Antoin Verschuren
- Re: [DNSOP] Public Suffix List Elmar K. Bins
- Re: [DNSOP] Public Suffix List Edward Lewis
- Re: [DNSOP] Public Suffix List bert hubert
- Re: [DNSOP] Public Suffix List bert hubert
- Re: [DNSOP] Public Suffix List Patrik Fältström
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Patrik Fältström
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Wes Hardaker
- Re: [DNSOP] Public Suffix List Edward Lewis
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Andrew Sullivan
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Andrew Sullivan
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Brian Dickson
- Re: [DNSOP] Public Suffix List Peter Koch
- Re: [DNSOP] Public Suffix List Eric Brunner-Williams
- Re: [DNSOP] Public Suffix List Eric Brunner-Williams
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Kim Davies
- Re: [DNSOP] Public Suffix List Paul Hoffman
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Joe Abley
- Re: [DNSOP] Public Suffix List Phil Regnauld
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Andrew Sullivan
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Doug Barton
- Re: [DNSOP] Public Suffix List Paul Hoffman
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Adrien de Croy
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Wes Hardaker
- Re: [DNSOP] Public Suffix List Dean Anderson
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Paul Hoffman
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Doug Barton
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Mark Foster
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Mark Foster
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jelte Jansen
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Joe Baptista
- Re: [DNSOP] Public Suffix List - Please move disc… Mark Nottingham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… Edward Lewis
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… bmanning
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… Joe Baptista
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List - Please move disc… Ted Lemon
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List Brian Dickson
- Re: [DNSOP] Public Suffix List - Please move disc… Joe Baptista
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List SM
- Re: [DNSOP] Public Suffix List Dean Anderson
- Re: [DNSOP] Public Suffix List - Please move disc… Antoin Verschuren
- Re: [DNSOP] Public Suffix List - Please move disc… Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List - Please move disc… Antoin Verschuren
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Niall O'Reilly
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Brian Dickson