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:
Thu, 16 Jun 2011 08:32:06 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (120 lines)
Thx for your elaboration. I understand that you fear solidifying ICANN 
further. I don't believe ICANN will ever be able to put itself beyond 
the political reaches of a critical mass of users*, but i see your 
point. I'll agree to disagree with regards to "harms" as i believe 
enlarging the namespace does in principle more good than harm. And ... i 
am curious, i admit.

Nicolas

* the problem of formulating a decentralized mechanism for DNS, a 
mechanism that has a chance of having a critical mass of user, is harder 
than demonstrating that one can go with his own bind. The social harbors 
fixed parameters and liabilities that calls for more than technical 
feasibility, if one wants to engineer it's (the social) course of 
action. Just sayin'

Nicolas


On 6/15/2011 3:33 PM, JFC Morfin wrote:
> At 04:28 15/06/2011, Nicolas Adam wrote:
>> 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.
>
> Nicolas,
> There is no dispute. There are facts. These facts are simple enough:
>
>
> 1. The Internet has grown into a very, very large network, beyond what 
> its IETF decentralized technology (RFC 3935) was expected to support. 
> However, it will continue to grow within the distributed world digital 
> ecosystem. This growth, among others, calls for a dramatic gTLD 
> enlargement that must converge with other network and service namespaces.
>
> The only way the community has been able to control this growth, so 
> far, is through a political, legal, and financial driven context that 
> is coordinated by ICANN.
>
> ----
>
> 2. We discovered 18 months ago - this is what permitted the IDNA2008 
> consensus - that the built-in power of the Internet technology is 
> quasi unlimited if the existing RFCs and code are read and used 
> (without a single coma/bit change) in a new "multiplication by 
> subsidiarity division" intricate network context.
>
> Highly professional and secure tools for this context are already 
> available to every Internet user for free (*). They can be made easy 
> to install in minutes. They are easy to extend for a better and 
> cheaper "Internet PLUS", but there is still no activated forum to 
> document the needed extended network layers: IESG and IAB have 
> identified them as external to the IETF area of responsibility.
>
> -----
>
> 3. The gTLD enlargement is part of the DNS and of the whole internet 
> growth. As such, it will speed up the transition from context (1) to 
> context (2) above.
>
>  ICANN has not yet considered or tested the implications of a blunt 
> introduction of this transition or the consequences of denying funded 
> gTLD projects. Under these circumstances a few times a $200,000 budget 
> makes more than what is needed to compete with ICANN in a technically 
> legitimate way and create havoc in the DNS commercial use.
>
> No community bottom-up process has considered it, discussed it, or 
> prepared plans. There is no defense discussed as yet against a blunt 
> introduction of the single authoritative virtual root even if sites to 
> document it are prepared. ICANN has not alluded to this transition, 
> not to its acceleration, neither in its existing and planned TLD 
> agreements nor in its Accountability Frameworks (ccTLD will be the 
> first ones to suffer). The GAC has not raised the issue publicly as yet.
>
> ----
>
> ICANN is informed, as it was adequately and actively represented at 
> the IETF/WG/IDNAbis, that it was proposed for them to take the 
> leadership in this area by their former Chair, and some GAC Members 
> discussed the issue informally.
>
> Therefore,
>
> - either ICANN plans to use the impending naming doom to its own 
> advantage. This would be committing suicide, except if this is to 
> prepare a crash, an undiscussed "Netkeeper Act" by governments and a 
> GAC takeover to "protect" TMs, ccTLDs, and gTLDs against "pollution".
>
> - or ICANN behaves responsibly and wants, before unleashing the gTLDs 
> enlargement, a bottom-up GNSO concern towards a general debate and a 
> consensual solution that will ensure full community support.
>
> In both cases, that are probably intertwienned together with Google's 
> own interests and capacity to take over a government/industry 
> controlled virtual root, we have to carefully review the situation 
> before committing ourselves. Being clever does not call for long 
> delays. Just some smart, reasonable and responsible quick thinking. 
> Before falling into a possible fatal trap or deciding a war at ICANN.
>
> jfc
>
>
> ----
>
> (*) I use my own Bind copy or another nameserver on my Windows PC, 
> with my own root file, and a db file that I maintain for my own root 
> names (TLDs). Faster, more secure, reliable, protected, and immortal 
> than any root server system when a mobile is more powerfull than the 
> largest mainframes of 1983. Cost of my TLD: $ 0 to be used by my TLD 
> users, by user: $ 0 and by registrant: $ 0.
>
>
>

ATOM RSS1 RSS2