The question is: Can we be part of two regions at the same time? So far the answers has been no. Eduardo Diaz ISOC-Puerto Rico -----Original Message----- From: na-discuss-bounces@atlarge-lists.icann.org [mailto:na-discuss-bounces@atlarge-lists.icann.org] On Behalf Of Danny Younger Sent: Friday, August 29, 2008 12:39 PM To: NA Discuss; Evan Leibovitch Subject: Re: [NA-Discuss] ICANN Geographic Regions Let's consider ICANN's current North American Region: American Samoa -- in Asia/Pacific Guam -- in Asia/Pacific Northern Mariana Islands -- in Asia/Pacific United States Minor Outlying Islands -- in Asia/Pacific United States Canada Puerto Rico -- in Caribbean region Virgin Islands, U.S. -- in Caribbean region Yes, it looks weird as part of the region is on the other side of the world but I think we need to get down to fundamental principles in our analysis. Ultimately I think that the local internet community should be the ones self-selecting in which ICANN region they wish to reside. The difficulty, of course, arrives when contemplating the creation of new regions. --- On Fri, 8/29/08, Evan Leibovitch <evan@telly.org> wrote:
From: Evan Leibovitch <evan@telly.org> Subject: Re: [NA-Discuss] ICANN Geographic Regions To: dannyyounger@yahoo.com, "NA Discuss" <na-discuss@atlarge-lists.icann.org> Date: Friday, August 29, 2008, 11:59 AM I have long thought that the ICANN methods for chopping up the world, both in process and result, have been drug-induced. Even the act of having the Caribbean put in LAC rather than NA seems strange. Under its regs, Puerto Rico and Guam are in NA but Jamaica is in LAC.
Many global bodies, from the UN to FIFA, have dealt with the touchy issues of regional groupings. ICANN should not go anywhere near re-inventing this wheel, but rather use other well-accepted norms created elsewhere.
Danny Younger wrote:
Concern over the proper formulation of the ICANN Geographic Regions has long been a significant part of At-Large structure-building considerations with the earliest recommendations dating back to the 2001 proposal of the At-Large Study Committee to create a Central/West/South Asia Region (CWSA) comprising India (.in), Pakistan (.pk), Afghanistan (.af), Kazakhstan (.kz), Uzbekistan (.uz), Kyrgyzstan (.kg), Turkmenistan (.tm), Tajikistan (.tj), Sri Lanka (.lk), Maldives (.mv), Iraq (.iq), Iran (.ir), Israel (.il), Syria (.sy), Jordan (.jo), Lebanon (.lb), Palestine Territories (.ps), Kuwait (.kw), UAE (.ae), Yemen (.ye), Oman (.om), Bahrain (.bh), Qatar (.qa), Saudi Arabia (.sa).
Of course, in such a structure Israel -- a significant global player in hi-tech in general and one of the more least-censored societies in that region -- would be aggressively silenced. (In most international groupings it's usually included in Europe.)
My point here is not the resolution of in what region to put Israel, so much as to demonstrate this problem as an example of the kind of political wrangling in which ICANN has absolutely no business engaging.
ICANN has enough on its plate without having to deal with the significant politics behind these issues, and is well advised to use existing standards created elsewhere rather than create its own. The inclusion of Israel in the Mideast region by the 2001 study committee, only lays bare that group's ignorance of the political nuances at play. This is not an indictment of the group so much as an illustration of ICANN's (fully understandable) unsuitability to create such boundaries on its own.
It's bad enough that ICANN touches into politics in regards to ccTLDs (ie, the intensive lobbying regarding ".eh"). We should be involved in such politics as little as is absolutely possible. It should be up to other bodies, not ICANN, to determine whether (for instance) Abkhazia requires its own TLD. Same goes for defining regional divisions; we're not the only ones needing to deal with the shifts in international influence.
The recent recommendations of the Westlake Consulting Team charged with the current ALAC review follow in this spirit by recognizing that ICANN’s geographic regional structure is not well aligned with global population distribution and is increasingly unrepresentative of world-wide Internet usage, leading Westlake to recommend increasing the number of NomCom appointees to the ALAC by two members, both of whom would be from Asia.
The analysis of this that we presented at Paris found this approach horribly flawed, not in the least by its exclusive use of unaccountable appointees -- with no mandate for community accountability -- to address the issue of regional imbalance. If countries are under-represented then fix the regions. Adding two NomComms without any other regional change comes across as the weakest possible answer to this question. If AP needs to be split, then split it.
(It's my personal hope that as At-Large matures that an effective ALAC can eventually be 100% representative. I fully accept that right now such level of maturity does not yet exist. But adding NomComms to ALAC without any corresponding ALS elected/accountable reps seems a step backwards.)
As any change in the total number or composition of ICANN geographic Regions will impact ICANN's At-Large Structures, we formally request that an at-large representative from each current ICANN Geographic Region be included in the Board-appointed community-wide working group to review the structure of ICANN's present Geographic Regions and related issues. I believe we ought to take a position that ICANN has no business re-inventing this wheel, and should find an existing diplomatically-created regional split that we can live with.
Like ALAC, ICANN itself needs to focus on its own resources on policy; volunteers are already spread too thin. Expending such scarce resources on political issues -- in which ICANN has even less experience or credibility than usual -- is an unnecessary diversion and needless vision creep.
- Evan
------ NA-Discuss mailing list NA-Discuss@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/na-discuss_atlarge-lists.ica... Visit the NARALO online at http://www.naralo.org ------ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.13/1641 - Release Date: 8/29/2008 7:07 AM