[DNSOP] FYI, more comments on IETF "not having members"

[Dean Anderson <[e-mail]>]

The frivolous, dishonest, and false statements in the January 15, 2008
IESG Appeal Response found at
[http://www.ietf.org/IESG/APPEALS/appeal-response-dean-anderson-01-15-2008.txt]
must be corrected.  Persons are begining to incorrectly claim that the
IETF has no members, and no ability to make official statements. In fact
numerous Official IETF documents refer to IETF members, and the IETF is
part of the Internet Society, Inc, a U.S. non-profit corporation.  The
ISOC is engaging in improper trade practices by misrepresenting its both
its incorporation status and its status as a part of a non-profit
membership corporation.

Dean Anderson
CEO
AV8 Internet, Inc


---------- Forwarded message ----------
Date: Mon, 9 Jun 2008 10:17:36 -0400
From: Edward Lewis <[e-mail]>
To: [e-mail]
Cc: Gervase Markham <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [DNSOP] Public Suffix List

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 defFrom [e-mail]  Mon Jun  9 10:59:33 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 A23D93A6B54;
	Mon,  9 Jun 2008 10:59:33 -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 EB4793A691F;
	Mon,  9 Jun 2008 10:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
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 K0tcxIHWNerT; Mon,  9 Jun 2008 10:59:30 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66])
	by core3.amsl.com (Postfix) with ESMTP id 877EE3A6C7B;
	Mon,  9 Jun 2008 10:59:24 -0700 (PDT)
Received: from sr22.av8.net (sr22.av8.net [198.3.136.5]) (authenticated bits=0)
	by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m59Hxd1E002932
	(version=TLSv1/SSLv3 cipheríH-RSA-DES-CBC3-SHA bits8 verify=NO);
	Mon, 9 Jun 2008 13:59:41 -0400
Date: Mon, 9 Jun 2008 13:59:38 -0400 (EDT)
From: Dean Anderson <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail], <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Cc: [e-mail], Gervase Markham <[e-mail]>, [e-mail]
Subject: [DNSOP] FYI, more comments on IETF "not having members"
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]


The frivolous, dishonest, and false statements in the January 15, 2008
IESG Appeal Response found at
[http://www.ietf.org/IESG/APPEALS/appeal-response-dean-anderson-01-15-2008.txt]
must be corrected.  Persons are begining to incorrectly claim that the
IETF has no members, and no ability to make official statements. In fact
numerous Official IETF documents refer to IETF members, and the IETF is
part of the Internet Society, Inc, a U.S. non-profit corporation.  The
ISOC is engaging in improper trade practices by misrepresenting its both
its incorporation status and its status as a part of a non-profit
membership corporation.

Dean Anderson
CEO
AV8 Internet, Inc


---------- Forwarded message ----------
Date: Mon, 9 Jun 2008 10:17:36 -0400
From: Edward Lewis <[e-mail]>
To: [e-mail]
Cc: Gervase Markham <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [DNSOP] Public Suffix List

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 dine 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 
scientific 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


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


efine 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 
scientific 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


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