ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [ga] New TLD Paradigm

  • To: JFC Morfin <jefsey@xxxxxxxxxxxxxxxx>
  • Subject: RE: [ga] New TLD Paradigm
  • From: Hugh Dierker <hdierker2204@xxxxxxxxx>
  • Date: Sun, 27 Aug 2006 12:08:25 -0700 (PDT)
  • Cc: ga <ga@xxxxxxxxxxxxxx>
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vkJHT48Pps4jULDqRSBS0dlBKl7KI+unHlPNcUnUMH4nFB7t+Gz6B+XU7C63GB2+ZOaFAkopCpS6MfUu/j+B095yvv6NW2Jv2xfvuYlXlh5ZO/YSvv2vmmAWHE27QcBwu4+jPETA92Ro9rJ3nfxFhIZABTAuM0Brx/spm1PQOqo= ;
  • In-reply-to: <7.0.1.0.2.20060822184603.033240c8@club-internet.fr>
  • Sender: owner-ga@xxxxxxxxxxxxxx

Excellent point Jefsey. I believe the translanational lingual for us dotcommoners would be "what is in a word?". In jurisprudential precedent type legal ease the jurist are to follow a simple rule :-); If the language of a rule is ambiguous to a given situation then there is a paradigm in ranking as to apply interpretation to the rule.  Something along the lines of let's say. 1. Plain Meaning  2. Clear legislative Internt - almost or usually equal with the record involved in writing the rule. 3. Precedent - usually requiring at least a 2 out of all 4's on point. 4. Acknowledge Treatises, and the like, - say a Froomkin article, or Karl or you or so on.  
   
  So i hope you could agree with me and perhaps others that policy making type rules should not be decided like a "code" written in an engineering field where a mistypEd letter cand send the "code" into a frenzy or no show. 
  Policy type code writing should be based more on intent than exactness, wear an mistspelled work or art can destroy the reason for the existance.
   
  Especially when we speak in multicultural, multidisciplined and multilingual environs.
   
  e
   
  P.S. Any misspellings in the heretofore previously written missive abnaseam shall be completely the authors' intent and any rebroadcast of these comments is/are strictly acceptable either with or without the departed authority of the authors father.
   
  JFC Morfin <jefsey@xxxxxxxxxxxxxxxx> wrote:
  Dear Michael,
I am traveling and I have no way to print your text yet. I would like 
however to give you an opportunity to address the most important 
point I fear the document misses before I do it. I seached the text 
for "IDN", "lingual", "national", "ccTLD", "DNSSEC" and found 
nothing. May be my search did not work properly? So, I looked for 
ICANN and found 41 occurences. I looked for ISP and found it only on 
a COI point.

This is odd when you consider that:

- ICANN is confronted to the problem of national lingual versions of its gTLDs
- the name space must address the administration of the lingual TLDs 
and of their devolution
- the technology is unable to address the multilingual problem
- ICANN is only the US NIC
- the name space is shared between domain names, keywords and aliases 
(private keywords) and domain names are managed by TLD, private TLDs 
(within/from private nets and externets), ULDs (User Level Domains, 
what the users perceive as a TLD)
- the namespace can therefore only resolve in a stable way at the 
ISP/private net layer.
- the IAB mailing list on the Internet architecture evolution is dead 
while we see the emergence of various forms of Multi-Internetworking 
and recognised the "networks of the network of networks" reality, and 
the need of intergovernance of their governances.
- ICANN is still only the administration and the dissemination of a 
small Excel spreadsheet, while we start seeing Google heading the 
take over of the big Excel folder (840 pages ++) of the languages registries.
- etc.

I note that 5 years ago, ICANN published an Internet Coordination 
Policy document (ICP-3) where the solution (testing, and IETF 
involvement toward a possible multi-root situation) was very well 
documented (I carried that experiment for 2 years with more than 30 machines).



On 18:13 22/08/2006, Michael D. Palage said:
>Danny,
>
>Thanks for posting this to the GA list. Attached is a full copy of the
>paper.  Would welcome some lively and constructive dialog on the topic.
>
>Best regards,
>
>Michael
>
>
>-----Original Message-----
>From: owner-ga@xxxxxxxxxxxxxx [mailto:owner-ga@xxxxxxxxxxxxxx] On Behalf
>Of Danny Younger
>Sent: Tuesday, August 22, 2006 8:22 AM
>To: ga@xxxxxxxxxxxxxx
>Subject: [ga] New TLD Paradigm
>
>
>In advance of the upcoming Amsterdam session on new
>gTLDs, Michael Palage has submitted some interesting
>comments for consideration:
>
>[excerpt]
>
>39.     The current gTLD paradigm of Unsponsored
>Restrictive (.BIZ, .NAME, and .PRO); Unsponsored
>Unrestrictive (.COM, .NET, .ORG and .INFO); Sponsored
>(2000 - .MUSEUM, .COOP and .AERO), Sponsored (2003 -
>.TRAVEL, .JOBS, MOBI,  and .CAT) and legacy gTLDs
>(.INT, .EDU, .GOV and .MIL), does not scale in
>connection with the continued expansion of the root
>
>40.     As noted by several stakeholders, a number of the
>recently selected sTLDs should have been more properly characterized as
>gTLD given the sheer magnitude and ambiguity of the proposed
>"communities."
>
>41.     Further reinforcing the non-scalability of the
>current paradigm is the position of certain
>constituencies within the GNSO that only sponsored
>TLDs should be added to the root.
>
>42.     Should ICANN adopt a sTLD only approach toward the
>continued expanse of the name space, it will only lead
>to more applicants attempting to fit a square peg into
>a round hole, thus undermining the principles of
>predictability which is so important to this process.
>Moreover, any attempts by ICANN to adopt sTLDs only
>may unfairly benefit the existing unsponsored registry operators.
>
>43.     Therefore, a new paradigm must be proposed for the
>gTLD space which allows for meaningful expansion and competition, while
>at the same time taking into account the strong preference for the
>concept of sponsored/chartered TLDs as expressed by a portion of the
>community.
>
>44.     The proposed new paradigm  is one based upon the
>level of involvement that the registry operator
>exercises in connection with reviewing the
>registrant's qualifications. For the purposes of this discussion, a
>registry would fall into one of either two categories: Registrant
>Verified - where the registry operator verifies the qualifications  of
>the registrant prior to the domain name being added to the zone (a.k.a.
>"going live") and Registrant Unverified - where the registry operator
>undertakes no prescreening of qualifications involving the registrant.
>
>45.     For purposes of this discussion. The existing
>gTLDs would be classified as Registrant Verified based
>upon the screening protocols by the registry operator
>in connection with the registrants: .MUSEUM, .COOP,
>.AERO, .TRAVEL, .JOBS, and .CAT, whereas the following
>existing gTLDs would be classified as Registrant
>Unverified based upon the lack screening protocols by
>the registry operator prior to registration: .COM,
>.NET, .ORG, .INFO, .BIZ, .NAME, .PRO, and .MOBI.
>
>46.     It is also useful to note that all legacy gTLDs
>(.GOV, .EDU, .MIL, .INT and .ARPA) would all qualify
>as Registrant Verified.
>
>47.     Although many in the community have been strong
>advocates of sponsored TLDs because they believed they represented a
>minimal risk for abusive registrations, the sheer magnitude of some of
>the recently approved sponsored communities with potential registrants
>numbering in the billions serious calls into question their initial
>assumption.
>
>48.     Under this new proposed paradigm, there would be
>no limit to the number of Registrant Verified TLDs
>that ICANN would process. However, in connection with Registrant
>Unverified TLDs, ICANN would agree advance to allocate a set number of
>these TLDs over a given period of time, i.e. ten (10) Registrant
>Unverified TLDs over a five (5) year period of time. Given the scarcity
>of these Registrant Unverified TLDs, ICANN could use an auction or
>lottery mechanism .
>
>49.     Given the potential for public policy concerns by
>the GAC, all potential applicants/bidders would have
>to pay a fee to allow ICANN to pre-screen the
>application prior to active bidding.
>
>The complete document may reviewed from this page:
>http://forum.icann.org/lists/gtld-council/msg00180.html
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>

 

 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail.


<<< Chronological Index >>>    <<< Thread Index >>>