[governance] Fall ICANN meeting in Cairo - Rights discussion off the agenda ... ?

Mon May 26 11:42:31 EDT 2008

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