Re: Single DNS root

"JFC (Jefsey) Morfin" <jefsey@jefsey.com> Thu, 01 September 2005 03:21 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfdW-0008R0-JR; Wed, 31 Aug 2005 23:21:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfdU-0008Qh-AT for ietf@megatron.ietf.org; Wed, 31 Aug 2005 23:21:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05106 for <ietf@ietf.org>; Wed, 31 Aug 2005 23:21:05 -0400 (EDT)
Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAffM-0004nR-EP for ietf@ietf.org; Wed, 31 Aug 2005 23:23:04 -0400
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EAfdK-0007ZN-DU; Wed, 31 Aug 2005 20:20:58 -0700
Message-Id: <6.2.3.4.2.20050901012427.04c6e6a0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 01 Sep 2005 02:49:52 +0200
To: IETF General Discussion Mailing List <ietf@ietf.org>, Harald Tveit Alvestrand <harald@alvestrand.no>, Paul Hoffman <paul.hoffman@vpnc.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <C9F748BE2C84DBBDC3C48190@B50854F0A9192E8EC6CDA126>
References: <p0620071abf3a39e7c365@[172.17.33.112]> <87k6i3rnwc.fsf@windlord.stanford.edu> <431577A3.5080902@peter-dambier.de> <086e5646420e7121920d06ad4ac4287a@karoshi.com> <C2D94E2C-6180-4AB7-B44F-CEFF8646F25B@let.de> <C9F748BE2C84DBBDC3C48190@B50854F0A9192E8EC6CDA126>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc:
Subject: Re: Single DNS root
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Harald and Paul,
May be time to stop 3683ing this issue. Major moves in the naming 
area are probable in the year to come (PADs - shared root under UN - 
National TLDs, CENTR move.); while an ICANN request of update of RFC 
2826 stays unanswered or opposed for four years.

On 17:25 31/08/2005, Paul Hoffman said:
>At 3:24 PM +0200 8/31/05, Peter Dambier wrote:
>>the Public-Root is not an alternative root but a solution.
>
><http://public-root.com/tlds.htm>

It also confuses Registries and Registrars (cf. presentation of ccTLDs)

>makes it very clear that this set of root-like servers intends to 
>answer affirmatively and authoritatively for TLDs that the 
>real/generally-accepted
>root servers would say do not exist. From the material on that page, 
>it is also likely that, in the future, the NS records returned by 
>these root-like servers for some TLDs will be different than those 
>returned by the real/generally-accepted root servers.

There is an USG/ICANN contract over IANA functions confirmed by RFC 
2860. Not to make any politics let call it "legacy" root as results 
from the 1984 agreement (RFC 920, claimed source of the ICANN 
legitimacy). The resulting "legacy top zone" - through server 
declarations - is already larger than documented by its root file.

>In other words, the statement "the Public-Root is not an alternative 
>root but a solution" seems dishonest  when one reads the material at 
>the site describing the service.

Correct. The "Public-Root" is technically a decentralised root file. 
It is not a "solution".

At 13:44 31/08/2005, Harald Tveit Alvestrand wrote:
>Anyone who wishes to avail themselves of this service would be well 
>advised to read RFC 2826 - "IAB Technical Comment on the  Unique DNS Root".

Harald, RFC 2826 has been used and partly out-dated by the 2001 
response ICANN (http://www.icann.org/icp/icp-3.htm ) you ignored for 
practical reasons I accept, but none one commented. It calls for an 
experimentation to document the evolution we face today unprepared. 
When there is more than an unique authoritative root file.

I lead such an experimentation for two years, along with the ICANN 
criteria. Most of my positions you oppose have been tested and 
validated there. I am sure would you run a similar test-bed, our 
strategies could still oppose, but our understandings of the network 
architectural evolution would be similar.

>When IETF documents refer to the DNS, I think it's a safe bet that 
>they are intending to refer to the system under the single root that 
>most people regard as "the root".

May be, but this is wrong. We are to face the balkanisation vs. 
compartmentalisation reality. Chinese law and US Statements of 
Principles have enforced a new situation leading to sovereign 
alt-roots. We can say "obey RFC ....", be disregarded and get 
balkanisation. Or we can work on solutions adapted to the current 
evolution, imagine a distributed root system (no big deal) and 
possibly obtain a unique authoritative root matrix. A few months from 
now it will practically be too late.

Harald, we are in direct competition over the language root. "my" 
solution there can survive a balkanisation of the IANA, not yours. So 
it is a common interest to quickly review and document the evolution 
of the name root before it is too late for you and a pain for others.

>I don't think any of the fundamentals have changed in the last 5 years.

This _IS_  the problem. You have not seen and acknowledged the change 
(first act: Tokyo 2000, call for the first change in RFC 920 status 
quo), leading to (2001) considering the obsolescence of these 
"fundamentals". In that area nothing has changed since 1984 on the 
internet root side, while the Internet _has_changed_ into the 
international network it only interfaced in 1984.

This change is not trivial, it must be matched by a serious "how to".

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf