[governance] Fall ICANN meeting in Cairo - Rights discussion

Mon May 26 12:18:34 EDT 2008

Depends on what you take  "ICANN's activities" to mean.
My personal opinion is mine, and not the issue here.

Rather, I wanted to clear up any misconception that the discussion 
referred to  indicated a lack of CONCERN about freedom of expression and 
access to the Internet, because no-one indicated that, but rather the 
disagreement with your position reflected a concern that the issue was 
outside ICANN's focus.
Whether it is outside the remit or not is up for discussion, and we may 
agree or disagree on it, but it is unfair to the people who were not in 
agreement with your position to misrepressent their views and say they 
were not concerned about censorship and repression in Egypt.

Jacqueline

Robert Guerra wrote:
>
> On 26-May-08, at 11:17 AM, Jacqueline A. Morris wrote:
>
>> This is IMO far more an issue for the IGF than for ICANN's technical 
>> remit.
>
>
> Well, if we go by ICANN's bylaws....
>
> http://icann.org/general/bylaws.htm#XI
>
> 4. At-Large Advisory Committee
>
>
> 4a. The role of the At-Large Advisory Committee ("ALAC") shall be to 
> consider and provide advice on the activities of ICANN, insofar as 
> they relate to the interests of individual Internet users.
>
> - Individual internet users in Egypt are active online (see refs 
> below). Recent media reports seem to indicate that  issues of freedom 
> of expression online and censorship are of concern to Internet users 
> in Egypt.
>
> Ref -
> http://www.globalvoicesonline.org/-/world/middle-east-north-africa/egypt/
>
> http://www.globalvoicesonline.org/2008/05/16/egypt-torture-for-bloggers-and-activists/ 
>
> Egyptian bloggers, cyberactivists and activists on the ground continue 
> to pay the price for speaking up...
>
> Egyptians Take One Step Toward Change, One Step Back
> http://www.worldpoliticsreview.com/article.aspx?id=2108
>
> Egypt's Facebook Revolution
> http://newsweek.washingtonpost.com/postglobal/islamsadvance/2008/05/egypts_facebook_revolution.html 
>
>
>
> I don't want people to complain - after the fact - and given the 
> issues that "might" arise, I think it prudent to raise the issues well 
> in advance of the meeting taking place. Is it not within "scope" and 
> "mission" to seek assurances from  ICANN and the organizers of the 
> meeting  that the standard practice of allowing for "open 
> registration" and technical  specifications in the Meetings RFP (see 
> below) in regards to connectivity be met ?
>
>
> regards
>
> Robert
> -- 
> Ref:
>
> http://icann.org/meetings/rfp/rfp-2007.htm
>
> IV. Basic Requirements the Local Host Must Meet
>
> Please note that these elements are required to hold a successful 
> meeting and are not simply recommendations. If the local host finds a 
> need to modify these arrangements, the changes must be approved by 
> ICANN in advance of the meeting.
>
> [snipped]
>
>
> B. Network Infrastructure
>
> Due to the nature of the conference and its attendees the Network 
> infrastructure is an essential and critical aspect of the meeting. 
> Attendees MUST be able to reliably send and receive both encrypted and 
> unencrypted data freely. The importance of adequate and reliable 
> systems cannot be expressed enough. The network must be fully 
> operational from Day 0 until Day 8. The following information has been 
> included to assist the ICANN meeting staff in the solicitation of 
> offers from IT vendors.
>
> Bandwidth and Internet Requirements:
>
>  1. BANDWIDTH: External bandwidth (Internet Transit) must be in the 
> form of dedicated circuits of at least 10mbps capacity and must 
> include redundant paths. Preference may be given to proposals that 
> contain higher capacity and more detailed redundancy planning.
>  2. ADDRESSING: At least a /22 (1024 addresses) of publicly routable 
> IPv4 address space must be made available for use during the 
> conference. Using RFC1918 space and/or NAT (Network Address 
> Translation) has been known to cause problems and is strongly 
> discouraged. However, if using RFC1918 or NAT space is the only way to 
> facilitate our technical requirements, then a letter explaining IN 
> DETAIL the issue/solution is mandatory and must be approved by the 
> ICANN Technical Staff prior to the proposal being accepted.
>  3. ADDRESSING: Though not required, offering IPv6 addresses to the 
> conference attendees IN ADDITION to the required IPv4 address space 
> would be desired. Preference may be given to proposals that offer both 
> addressing solutions.
>  4. ROUTING: The conference routers/gateways must be configured with a 
> minimum of filters so as not to affect tunnelling software used by the 
> conference attendees. Only filters that are required to protect the 
> network must be in place. ICANN reserves the right to approve or 
> disapprove any filters used at the conference. Any known filtering 
> that will occur at the meeting should be described in your proposal.
>  5. SERVICE LEVEL: Access to high-level support by the transit 
> provider must be available 24 hours a day for the duration of the 
> conference by the local host support staff. Troubleshooting transit 
> and bandwidth issues often takes place at odd times so as to not 
> impact the conference.
>
> Local Infrastructure Requirements:
>
>  1. DIAGRAM: In order to be considered to provide technical service to 
> the ICANN meeting, the IT vendor must provide a diagram (JPG or PDF) 
> to the ICANN technical staff detailing the local infrastructure of the 
> meeting. This is to include the switched network, the wireless 
> network, and core infrastructure (servers) that will make up the local 
> infrastructure.
>  2. DHCP: All addressing of the attendees hosts must be accomplished 
> through DHCP. All DHCP server(s) must reside within the local 
> infrastructure.
>  3. RESERVED IP: A small range of IP addresses (32 addresses) must 
> remain available to make static assignments hosts if necessary. This 
> would include any servers, printers and/or any other host (to be 
> determined by ICANN technical staff)
>  4. SMTP: An SMTP server is required to allow the conference attendees 
> to send email. Email relay must be allowed from the IP address 
> range(s) of the conference and an IP range further specified by the 
> ICANN staff.
>  5. DNS: At least two recursive (caching) DNS servers must be 
> available. At least one of these servers must reside WITHIN the local 
> infrastructure. The other may reside at the transit provider(s) but 
> must be topologically close to the conference network. Reverse 
> delegation (in-addr.arpa) must be used on the network block(s) being 
> used at the meeting.
>  6. WIRELESS: 802.11(b and/or g) must be available throughout the 
> meeting venue. This includes the main meeting room, board and staff 
> workrooms, smaller meeting rooms, "Internet Café"/terminal room, 
> common areas, hotel lobby and bar, etc. Where possible, wireless or 
> high-speed wired access should be offered in guest rooms.
>  7. WIRELESS: The SSID of the conference MUST be: ICANN and MUST NOT 
> be WEP/WPA enabled.
>  8. MONITORING: Monitoring of traffic MUST be restricted to ONLY that 
> necessary for network maintenance and diagnostics. Any monitoring 
> tools MUST be made available upon request.
>  9. PROXY: ICANN requires that the IT vendor NOT use proxies in any 
> form. If you feel that you are unable to provide services without 
> using a proxy, please send a detailed explanation during the vendor 
> selection process. ICANN MUST approve of the use of proxies. If the 
> local host is aware that proxies are required in their locale, ICANN 
> must be notified during the proposal process.
> 10. HARDWARE: Replaceable backups of critical services hardware should 
> be standing by (DHCP, DNS, SMTP, etc). The ability to replace critical 
> equipment within one hour of the problem being detected is required.
> 11. SERVICE LEVEL: The local hosts shall provide adequate qualified 
> staffing for the setup, running and teardown of the network 
> infrastructure. A technical representative MUST be onsite from 7am-9pm 
> daily. IF a problem arises there MUST be a representative that can be 
> contacted immediately and be onsite within 30 minutes of the 
> initiation of the phone call during hours outside of those stated above.
> 12. INFRASTRUCTURE: Keep it simple. Keeping the network infrastructure 
> as a simple, straightforward network increases the probability of 
> network uptime and reliance.
>
>
> ____________________________________________________________
> You received this message as a subscriber on the list:
>     governance at lists.cpsr.org
> To be removed from the list, send any message to:
>     governance-unsubscribe at lists.cpsr.org
>
> For all list information and functions, see:
>     http://lists.cpsr.org/lists/info/governance

____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance