NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nicolas Adam <[log in to unmask]>
Reply To:
Nicolas Adam <[log in to unmask]>
Date:
Tue, 14 Jun 2011 22:28:32 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
Still, and keeping in mind that the link between your two last messages 
was not clear nor a given, what you quote now and what you quoted then 
are (what i take to be, from your reference of them) assertions of 
efficient principles: namely that subsidiarity and decentralization work 
best for scalability, interoperability, flexibility, et. al.

Now i am not going to dispute that. Nor will, i think, anyone who would 
favor gTLD enlargement (but i might be astray on this last assertion and 
it is possible that some people like ICANN for it's centralizing 
potentialities).

But you were nevertheless implying "harm". And while i do see an 
alternative, i do not see harm proceeding from the current 
gTLD-enlarging path.  I do not see anything that wouldn't be 
fundamentally changed anyhow by the alternative solution you introduce 
me to, and i certainly does not see harm being done, irreparable or 
otherwise, by a gTLD enlargement.

Just so you know: if you build it, i will come. But in the meantime, is 
there actual harm in enlarging it?

Nicolas

On 6/14/2011 8:06 PM, JFC Morfin wrote:
> At 20:30 14/06/2011, Nicolas Adam wrote:
>> Dear JFC
>> Would you care to elaborate instead of asserting stuff peremptorily 
>> (and implicitly, and vaguely) please?
>
> I am neither peremptory nor vague. I gave you the RFCs and I_D. The 
> ICANN gTLD book is vague and administrative. It deals with 
> Intellectual Property, not with Internet Protocols.
>
> I keep explaining that we consensually agreed at IETF the RFCs 
> 5890-5895, under Vint Cerf chairmanship, and that IAB published the 
> RFC 6055. These RFC exemplify that diversity is supported by 
> subsidiarity in the Internet architecture. It means that the largest 
> the system is, the weaker are the (de)centralized solutions; and the 
> stronger are locally distributed deployments. Supporting 256 ICANN 
> constained TLDs can be centralized. Not over priced gTLD sales against 
> free root names like ".FRA" I technically documented.
>
> I brought my support to the consensus of the RFCs I quote because they 
> imply that the DNS can support an unlimited diversity of TLDs, 
> supported by billions of users as a unique virtual root.  At the IUCG 
> ([log in to unmask]) mailing list and site we started documenting the 
> resulting architecture.  Then we put it on hold in a responsible 
> manner because ICANN was not ready to consider this situation (Vint 
> Cerf wanted them to take it over - they did not want). Then IETF 
> declined to take care of this is area because it is beyond the IETF 
> Internet area. This kept the situation stable a few months more.
>
> But as soon as ICANN starts selling K$ 250 TLDs, they will break the 
> market equilibrium. Technology will update quickly and thousands of 
> free virtual root names will mushroom. A root name is a TLD by anyone 
> for everyone under his/her own terms and conditions. It will take some 
> time, but this will be the end of ICANN because ICANN has not prepared 
> itself to the change of the Internet Use that it is going to trigger.
>
> Technically no one needs a root server system to use the Internet, 
> either by ICANN or open-roots. I dont for years. What users only need 
> is a home DNS nameserver and the lists of the TLD/Root Names they want 
> to use. This can be entirely free, will bring new services, speed, 
> security, reliability and quality. This should have been a progress 
> from the onset However, since ICANN did not prepared it, it will be 
> initial confusion. ICANN still wants to lead and sell a root file 
> while it should be prepared and ready to serve the virtual root system.
>
> jfc

ATOM RSS1 RSS2