Re: [DNSOP] Public Suffix List

[Edward Lewis <[e-mail]>]

At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote:
>On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[e-mail]>
>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 [e-mail]  Mon Jun  9 07:17:42 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 23ACA3A6911;
	Mon,  9 Jun 2008 07:17:42 -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 8A8793A6C7C
	for <[e-mail]>; 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 <[e-mail]>;
	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 <[e-mail]>; 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 [e-mail])
Mime-Version: 1.0
Message-Id: <a06240803c472e87e44f2@[0.0.0.0]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Date: Mon, 9 Jun 2008 10:17:36 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6
Cc: Gervase Markham <[e-mail]>, [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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Errors-To: [e-mail]

At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote:
>On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[e-mail]>
>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                                                [phone]
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
DNSOP mailing list
[e-mail]
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                                                [phone]
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop