Robert, I am tired of explaining over and over again things which are CLEAR, crystal as they say: I'm not subscribed here as @icann.org, or @government.bg, or @president.bg, or whatever else you want to divert the conversation to. Way back when I was on the board of ICANN the same stupid alusions were used to make as if I spoke on beahlf of ICANN (you probably remember, or at least know that one cannot speak on behalf of an organization he or she serves on the board of, unless authorized). This will be as stupid as me asking you every time if you speak as yourself, or as Privaterra, or whatever other affiliation you might have. Now, the fact that you may have interest in privacy, does not respond to Evan's questions, and I guess that's why you are diverting the conversation. Please, get back to constructive mode, and stop with the silly questions "in what capacity I speak". Veni On 5/25/08, Robert Guerra <lists@privaterra.info> wrote:
(as some of you might have seen - the issue of user rights and censorship are of keen interest to me. As such, I responded quickly before reviewing the text of the email. am resending with minor corrections)
Veni:
On 25-May-08, at 2:29 PM, Veni Markovski wrote:
This is a clear example of how AL issues are being replaced with nonAL issues.
a quick question -
Are you saying this in your personal capacity, or is it "ICANN" saying that issues of freedom of expression, censorship and online surveillence are not "issues for At-Large" to care about.
ALAC's bylaws would seem to indicate that my questions and request for comments from the at-large community are - well within - the scope of ALAC
From the ICANN 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). To exercise our role, then we need to learn about the regions where internet users are active and bring their comments and opinions to ICANN. Reports and contacts with users in Egypt indicate that issues of freedom of expression online and censorship are one of their key concerns.
Ref - http://del.icio.us/internetfreedom/egypt
Egyptians Take One Step Toward Change, One Step Back World Politics Review, 13 May 08 http://www.worldpoliticsreview.com/article.aspx?id=2108
Egypt's Facebook Revolution http://newsweek.washingtonpost.com/postglobal/islamsadvance/2008/05/egypts_f...
When most people log onto Facebook, the thought of fomenting revolution is pretty far from their minds. But in the Middle East, and most recently in Egypt, Facebook has become an important platform for dissent in countries that routinely clampdown on liberal activists, and where the mosque has traditionally been the only outlet for venting political frustration.
-- Section 4j para 3:
4j. The ALAC is also responsible, working in conjunction with the RALOs, for coordinating the following activities:
3. Promoting outreach activities in the community of individual Internet users;
I have asked [now numerous times] what (if any) outreach efforts have been developed to engage and recruit ALS's from Egypt and/or the middle east. Engaging internet users and possible ALS's from Egypt is well within the scope of ALAC's mission.
And a way to imitate discussion on a mailing list. As to point 2, do you have experience that people who wanted to attend an ICANN meeting were not allowed to? Do you have information for censorship of access at inewtrnational meetings in Cairo?
I want to be proactive and seek from ICANN and the organizers of the meeting assurances that the standard practice of allowing for "open registration" and meeting the specifications in the Meetings RFP (see below) in regards to connectivity have been met.
I don't want people to complain - after the fact - and given the issues that "might" arise, I think it prudent to ask well in advance of the meeting taking place.
And do you know how the local host will react to a declaration about a "problem" which may not even exist for the meeting.
as for issues - i am keen that there not be any. It is well documented that censorship and limitations to freedom of expression exist online in Egypt. Representative Edward J. Markey (D-MA) published a rather public statement the other day in which he and other congressional representatives seem to indicate that ICANN promotes free speech principles . If such is not the case, then well - he should be so informed by worldwide internet users.
http://markey.house.gov/index.php?option=content&task=view&id=3342&Itemid=12...
Or it is only a question of being active on the list?
well - as you can see from the montly stats, i'm not the most active person on here... The mission and focus of my ALS - privaterra - is that of providing technical and policy advice to NGOs (particularly human rights and social justice organizations) regarding IT security and internet governance.
As such, I am well familiar with the issue of "internet users" in the MENA (middle east & north africa region) . With little to no activity of ALS's from the region - i am keen to make sure their voices and concerns are taken into consideration by at-large and ICANN as a whole. Seeing the meeting is months away - I would like to recommend that ALAC, at-large and ICANN take proactive steps to not only engage the Egyptian meeting organizers, but also internet users from Egypt . We are missing representation from that part of the world - and as such, am keen that their voices, issues and concerns be made by their own representatives.
outreach and engagement - is well within the ICANN bylaws? Or do you think otherwise?
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.
On 5/25/08, Robert Guerra <lists@privaterra.info> wrote:
I'll repeat two specific items that I mentioned in my original message to the list on the topic. That being, that I would like to consult the at-large community on two specific items:
1. raise the issue of limitations to freedom of expression and censorship that takes place en Egypt, and if the at-large community would be interested in raising this - key issue for internet users in Egypt .
2. seek assurances from ICANN that the meeting will be open to all internet users that wish to attend the meeting and that the internet available at the meeting will be uncensored
I await further comments and/or suggestions.
regards
Robert
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge-lists.icann.org
At-Large Official Site: http://atlarge.icann.org
-- Sent from Gmail for mobile | mobile.google.com