- ispcp - lists.icann.org

WG: JAS - background info for our call
by KnobenW＠telekom.de July 13, 2011

July 13, 2011

Von: Thomas Rickert <rickert(a)anwaelte.de> Datum: 13. Juli 2011 12:48:59 MESZ An: ispcp(a)icann.org Blindkopie: Thomas Rickert <rickert(a)anwaelte.de> Betreff: JAS - background info for our call Dear colleagues, you may remember that I volunteered during our meeting in Singapore to look into the JAS topic and try find answers to our questions. Unfortunately, I had to leave the JAS session early due to other commitments, but read the report, the transcript and other material available. Since I assume this subject will be discussed during today's call, please find below some information that shall facilitate our discussion. To start with, the JAS group make very general suggestions on how to support needy applicants. I could not find any information on how the program shall be operationalized. This is certainly due to the fact that these practical questions are not part of the mandate and be delegated to ICANN staff to work on. However, I can now partially answer some of the questions we raised. We were of the opinion that only waiving part of the application fees does not help needy applicants. In fact, the JAS recommendation is that ICANN shall provide a multitude of support services in various areas, such as cost reductions, staggered fees, partial refund from auction proceedings, logistical assistance, technical help, legal and filing support, third parties support facilitated by ICANN (translation, technical support ...) etc. You find all these items in section 4 of the report, which is available at JAS Issues and Recommendations Draft Second Milestone ... <http://gnso.icann.org/drafts/second-milestone-report-jas-08may11-en.pdf> If all these programs were in place in due time, needy applicants could really benefit from that. That is the good news. It is also good that the JAS group is also requesting the applicant to demonstrate certain financial capabilities beyond the mere application fees, see sec. 3.2. These include part of the potential fees for extended evaluations and for registry operational costs. On the other hand, there are some worrying proposals in there, too. - Exemption or deferment of IPv6 implementation requirements as possible (sec. 4.1.1) - Reduction of the Financial Continued Operation Instrument Obligation to 6-12 months (sec 4.1.1) - Deferred requirement of DNSSEC (sec. 4.2) On the IPv6 question, Tony Harris asked a question during the session and I copy this part of the transcript below: >>TONY HARRIS: Good morning, my name is Tony Harris. I am a member of this group, although I have admittedly been absent for the last couple of months. I apologize. I have been working on a project out of the office. We had a meeting on Tuesday of the ISPCP constituency and reviewed the Second Milestone Report. There was one thing which interested us, as a constituency I'm talking now, and that was a mention of not requiring the applicants that are subject to this program to implement IPv6. That was a little surprising because, first of all, you may not have a choice because IPv4 addressing blocks are not all that abundant and they are slowly running out. And the second thing is, why would it concern a needy applicant registry? That is something which is the concern of the carrier or the Internet Service Provider who at some point would providing connectivity to the registry and/or the back office. And eventually it could also scale back to a concern of the back-office provider. But we fail to see -- to understand how it would affect the actual applicant, the needy applicant. At least on a technical basis. On a cost consideration, for example, in Latin America, you can obtain IP address -- IPv6 address blocks at no cost at all. It is considered for the foreseeable future to be experimental and necessary. And LACNIC is not charging for these blocks at this time. So we just -- I thought I would put this comment on the table since you are going to write the final report. It might be something worth revisiting because it doesn't seem to make much sense. Thank you. >>CARLTON SAMUELS: Thank you, Tony. Can I ask Eric Brunner Williams, who is a member of the team, to respond to that. Eric, you have the floor. >>ERIC BRUNNER WILLIAMS: Thank you very much, Mr. Chair. Tony, the requirement is in the Applicant Guidebook. It's a policy requirement which is independent of any particular constituency, or their views on the subject. It's something that's come out of GNSO consensus policy. Our recommendation is that it -- that the requirement is capable of being deferred because v6 is simply not available in parts of the world. Additionally, under ARIN 124, v4 addresses are reserved for critical infrastructure. We expect this proposal to be adopted also by RIPE and APNIC. Registries are a critical infrastructure, and so as we get to the exhaustion portion of the v4 allocation regime, these critical infrastructure elements are reserved -- have access to the reserved pool of v4 addresses. So I hope that makes sense out of it; that is, there are -- v6 is actually not pervasively available. We do not want the requirement to limit registries from being located in portions of the world where v6 is not available. And v4 capability -- v4 allocations are still available for critical infrastructure under the exhaustion regimes of at least one, if not more, of the RIRs. Thank you. >>CARLTON SAMUELS: Tony. >>TONY HARRIS: I just want to thank Eric for the response and I will relay it back to the constituency. Thank you very much for the clarification. While this was a helpful explanation, IMHO the remaining concern are: - Needy applicants will most probably not operate their own registry backend system, but use third parties's products for that or even outsource the whole operation to a registry backend provider. It can be expected that IPv6 as well DNSSEC will be included in all solutions that are offered by specialized companies. Waiving the requirement or deferring it would establish two classes of registries and thereby introduce and perpetuate a scheme discriminating needy applicants. Certainly, in areas of the world where IPv6 is not available, it cannot be used, but all registries should be IPv6 and DNSSEC ready. - A reduction of the Financial Continued Operation Instrument Obligation may result in stability issues if registries cannot properly fulfill their - primarily technical - contractual obligations towards ICANN. While it is well understood that needy applicants might not be able to demonstrate sufficient financial capabilities, ICANN should allocate funds available to help out if needed so that the stability of all registries is granted. - Any assistance by ICANN in the area of providing legal and filing support for needy applicants beyond the information that is publicly available (such as in the faq section of new gTLD program website) may result in unfair treatment of applicants. ICANN should not be confronted with allegations that needy applicants benefit from "insider knowledge" that other applicants to not get access to. Therefore, legal and filing support should be better provided by third parties and this can be financially supported. I am looking forward to talking to you later today. Thomas Rickert ____________________________________________________________ Thomas Rickert, Rechtsanwalt Schollmeyer & Rickert Rechtsanwaltsgesellschaft m.b.H. (i.e. law firm) Geschäftsführer / CEO: Torsten Schollmeyer, Thomas Rickert HRB 9262, AG Bonn Büro / Office Bonn: Kaiserplatz 7-9, 53113 Bonn, Germany Phone: +49 (0)228 74 898 - 0 Büro / Office Frankfurt a.M.: Friedrichstrasse 63, 60323 Frankfurt, Germany Phone: +49 (0)69 714 021 - 56 Zentralfax: +49 (0)228 74 898 - 66 mailto: rickert(a)anwaelte.de skype-id: trickert web: www.anwaelte.de <http://www.anwaelte.de/>

1 0

NCSG charter
by KnobenW＠telekom.de July 13, 2011

July 13, 2011

Council representation laid down in ch. 3 Kind regards Wolf-Ulrich <<Non-Commercial Stakeholder Group Charter - v5May 2011.pdf>>

1 0

RE: Conference call - correction
by Tony Holmes July 13, 2011

July 13, 2011

Dear ISPCP members The call will take place tomorrow WEDNESDAY 15TH at 15.00 UTC Call in details will be circulated - many thanks to Gisella for her great support in arranging this call. Tony From: Tony Holmes [mailto:tonyarholmes@btinternet.com] Sent: 12 July 2011 18:21 To: ispcp(a)icann.org Subject: Conference call Dear ISPCP members The next ISPCP call will now take place at 15.00 UTC on Friday 15 July. An agenda will be circulated in advance. Regards Tony

2 2

Updated agenda for conference call
by Tony Holmes July 13, 2011

July 13, 2011

The updated agenda for today's call is below. 1. New Constituencies - progress of NPOC 2. ATRT update (hopefully Olivier will be on the call) 3. GNSO toolkit - update on ISPCP preferences/liaison on meeting arrangements 4. ICANN budget and operational plan - representing within the CSG group 5. GNSO outreach task force 6. Update on Council issues 7. ISPCP summary from Singapore 8. Forthcoming elections 9. AoB Attached is a copy of the toolkit implementation report, a summary of the ISPCP meeting in Singapore and a copy of the Recommendation to broaden participation in the GNSO. All for discussion later. Tony

1 0

RE: [ispcp] Conference call
by Tony Holmes July 12, 2011

July 12, 2011

Hi Thomas I had the call programmed for the 15th? If its tomorrow, setting it up may be a problem now as ICANN do this for us. Regards Tony From: Thomas Rickert [mailto:rickert@anwaelte.de] Sent: 12 July 2011 19:57 To: Tony Holmes Cc: ispcp(a)icann.org Subject: Re: [ispcp] Conference call Dear Tony, just to make sure there's no misunderstanding: Hadn't we agreed on tomorrow? Friday is difficult for me, but I will try to make myself available. Best regards, Thomas Am 12.07.2011 um 19:21 schrieb Tony Holmes: Dear ISPCP members The next ISPCP call will now take place at 15.00 UTC on Friday 15 July. An agenda will be circulated in advance. Regards Tony

1 0

Conference call
by Tony Holmes July 12, 2011

July 12, 2011

Dear ISPCP members The next ISPCP call will now take place at 15.00 UTC on Friday 15 July. An agenda will be circulated in advance. Regards Tony

1 0

WG: [council] GNSO Council resolutions - Singapore 22 June 2011
by KnobenW＠telekom.de June 23, 2011

June 23, 2011

FYI Kind regards Wolf-Ulrich ________________________________ Von: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] Im Auftrag von Glen de Saint Géry Gesendet: Mittwoch, 22. Juni 2011 13:25 An: Council GNSO Betreff: [council] GNSO Council resolutions - Singapore 22 June 2011 Dear All, Ahead of the official Council minutes, please find the resolutions passed by the GNSO Council today, 22 June 2011 in Singapore: Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) on IRTP Part B addressing the following five charter questions: a. Whether a process for urgent return/resolution of a domain name should be developed, as discussed within the SSAC hijacking report (http://www.icann.org/announcements/hijacking-report-12jul05.pdf <http://www.icann.org/announcements/hijacking-report-12jul05.pdf> ); see also (http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm <http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm> ); b. Whether additional provisions on undoing inappropriate transfers are needed, especially with regard to disputes between a Registrant and Admin Contact (AC). The policy is clear that the Registrant can overrule the AC, but how this is implemented is currently at the discretion of the registrar; c. Whether special provisions are needed for a change of registrant when it occurs near the time of a change of registrar. The policy does not currently deal with change of registrant, which often figures in hijacking cases; d. Whether standards or best practices should be implemented regarding use of a Registrar Lock status (e.g. when it may/may not, should/should not be applied); e. Whether, and if so, how best to clarify denial reason #7: A domain name was already in 'lock status' provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status. WHEREAS this PDP has followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 30 May 2011; WHEREAS the IRTP Part B WG has reached full consensus on the recommendations in relation to each of the five issues outlined above; WHEREAS the GNSO Council has reviewed and discussed these recommendations. Resolved RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors: 1. Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC). To this end the language of section 4 (Registrar Coordination) and Section 6 (Registry Requirements of the Inter-Registrar Transfer Policy should be updated as follows: Transfer Emergency Action Contact (Append to Section 4) Registrars will establish a Transfer Emergency Action Contact (TEAC) for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes. Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN RADAR system. Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain. Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer. The losing registrar will report failures to respond to a TEAC communication to ICANN Compliance and the registry operator. Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section 6 of this policy and may also result in further action by ICANN, up to and including non-renewal or termination of accreditation. Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request. This documentation will be retained in accordance with Section 3.4 of the Registrar Accreditation Agreement (RAA). Users of the TEAC communication channel should report non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic tests of the Registrar TEAC communication channel in situations and a manner deemed appropriate to ensure that registrars are indeed responding to TEAC messages. (Append to Section 6) 6 iv. Documentation provided by the Registrar of Record prior to transfer that the Gaining Registrar has not responded to a message via the TEAC within the timeframe specified in Section 4. In addition, update section 6 to reflect that the registry, in case of a transfer undo, will reverse the transfer and reset the registrar of record filed to its original state ('In such case, the transfer will be reversed and the Registrar of Record field reset to its original state'). (IRTP Part B Recommendation #1) 2. Modifying section 3 of the IRTP to require that the Registrar of Record/Losing Registrar be required to notify the Registered Name Holder/Registrant of the transfer out. The Registrar of Record has access to the contact information for the Registrant and could modify their systems to automatically send out the Standardized Form for Losing Registrars ("Confirmation FOA") to the Registrant. (IRTP Part B Recommendation #5) 3. Modifying Reason for Denial #6 as follows: Express objection to the transfer by the authorized Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis and upon request by the authorized Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact to remove the lock within five (5) calendar days. (IRTP Part B Recommendation #6) 4. Deleting denial reason #7 as a valid reason for denial under section 3 of the IRTP as it is technically not possible to initiate a transfer for a domain name that is locked, and hence cannot be denied, making this denial reason obsolete. (IRTP Part B Recommendation #9 - part 1) RESOLVED (B), the GNSO Council recommends the promotion by ALAC and other ICANN structures of the measures outlined in the recent report of the Security and Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). In particular, the GNSO Council recommends that registrants consider the measures to protect domain registrar accounts against compromise and misuse described in SAC044, Section 5. These include practical measures that registrants can implement "in house", such as ways to protect account credentials and how to incorporate domain name registrations into employee or resource management programs typically found in medium and large businesses. It suggests ways that registrants can use renewal and change notifications from registrars as part of an early warning or alerting system for possible account compromise. The GNSO Council Chair will reach out to the ALAC and other ICANN structures to inform them of this recommendation and discuss how the GNSO may contribute to this promotion. (IRTP Part B Recommendation #2) Resolved (C), the GNSO Council acknowledges receipt of IRTP Part B Recommendation #7 and will consider this recommendation when it considers the Final Issue Report on the Current State of the UDRP. RESOLVED (D), prior to the consideration of approval of the recommendation which states: "denial reason #7 should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked", the GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation. RESOLVED (E), prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation. Resolved (F), the GNSO Council will consider IRTP Part B Recommendation #3 concerning the request of an Issue Report on the requirement of 'thick' WHOIS for all incumbent gTLDs at its next meeting on 21 July. RESOLVED (G), the GNSO Council requests an Issue Report on IRTP Part C, which should include: - "Change of Control" function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security. (IRTP Part B Recommendation #4) - Whether provisions on time-limiting Form Of Authentification (FOA)s should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed. - Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs. MOTION 2. RE. REVISION OF THE GNSO COUNCIL OPERATING PROCEDURES RELATING TO PROXY VOTING Made by: Wolf-Ulrich Knoben Seconded by: Stéphane van Gelder WHEREAS, the GNSO Council recently identified areas for improvement in the GNSO Council Operating Procedures that would simplify and clarify the procedures relating to proxy voting; WHEREAS, the GNSO Council tasked the Operations Steering Committee (OSC) with completing a revision to improve the procedures relating to proxy voting; WHEREAS, the OSC submitted to the GNSO Council on 14 June 2011 recommended revisions http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11… <http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11…> to the GNSO Council Operating Procedures to simplify and clarify the procedures relating to proxy voting; NOW THEREFORE, BE IT: RESOLVED, that the GNSO Council acknowledges receipt of the recommended revisions submitted by the OSC and directs Staff produce a redlined revision of the GNSO Council Operating Procedures incorporating the recommended revisions and to post this document for twenty-one (21) days in the ICANN Public Comment Forum. RESOLVED FURTHER, that the GNSO Council shall take formal action on these recommendations, including potential modification, as soon as possible after the conclusion of the public comment period. Please let me know if you have any questions. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

ASO Review
by alain.bidron＠orange-ftgroup.com June 22, 2011

June 22, 2011

As indicated yesterday during our ISPCP meeting, the ASO review is underway with an analysis made by an external consulting company. The initial report will be produced before the next meeting in Dakar. As a consequence if ISPCP wants to express its views on the ASO, it should be better done before our next physical meeting in Dakar. Herve Rannou from ITEMS international will be conducting the first part of the review. For those who are present here in Simgapore you can contact Herve at herve.rannou(a)items.fr Or Thomas Mackenzie at tmackenzie(a)items-int.eu and organize individual interviews with them. Regards Alain ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ********************************************************************************

1 0

FW: Commercial Stakeholder Group meeeting with the BOARD Tuesday, 21 June 2011 - 11:00-12:00
by Tony Holmes June 20, 2011

June 20, 2011

FYI -----Original Message----- From: Glen de Saint Géry [mailto:Glen@icann.org] Sent: 20 June 2011 11:51 To: Marilyn Cade ; Rosette, Kristina; Tony Holmes; J. Scott Evans; steve metalitz; 'Jaime Wagner - PowerSelf'; KnobenW(a)telekom.de; Benedetta BC Secretariat Cc: Gisella Gruber-White; Diane Schroeder; Glen de Saint Gery Subject: Commercial Stakeholder Group meeeting with the BOARD Tuesday, 21 June 2011 - 11:00-12:00 Dear Marilyn, Kristina, Tony, J.Scott, Steve, Jaime, Wolf-Ulrich, Please find the dial-in details for the Board /CSG meeting on Tuesday, 21 June from to 11:00am to 12:00 to be sent to your members who cannot attend the meeting physically. Please check the main schedule for the Adobe connect details: http://singapore41.icann.org/full-schedule Thank you very much. Kind regards, Glen Participant passcode: BCSG For security reasons, the passcode will be required to join the call. ____________________________________________________________________________ Dial in numbers: Country Toll Numbers Freephone/Toll Free Number ARGENTINA 0800-777-0519 AUSTRALIA ADELAIDE: 61-8-8121-4842 1-800-657-260 AUSTRALIA BRISBANE: 61-7-3102-0944 1-800-657-260 AUSTRALIA CANBERRA: 61-2-6100-1944 1-800-657-260 AUSTRALIA MELBOURNE: 61-3-9010-7713 1-800-657-260 AUSTRALIA PERTH: 61-8-9467-5223 1-800-657-260 AUSTRALIA SYDNEY: 61-2-8205-8129 1-800-657-260 AUSTRIA 43-1-92-81-113 0800-005-259 BELGIUM 32-2-400-9861 0800-3-8795 BRAZIL 0800-7610651 CHILE 1230-020-2863 CHINA CHINA A: 86-400-810-4789 10800-712-1670 CHINA CHINA B: 86-400-810-4789 10800-120-1670 COLOMBIA 01800-9-156474 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 ESTONIA 800-011-1093 FINLAND Land Line: 106-33-203 0-800-9-14610 FINLAND Mobile: 09-106-33-203 0-800-9-14610 FRANCE LYON: 33-4-26-69-12-85 080-511-1496 FRANCE MARSEILLE: 33-4-86-06-00-85 080-511-1496 FRANCE PARIS: 33-1-70-70-60-72 080-511-1496 GERMANY 49-69-2222-20362 0800-664-4247 GREECE 30-80-1-100-0687 00800-12-7312 HONG KONG 852-3001-3863 800-962-856 HUNGARY 06-800-12755 INDIA 000-800-852-1268 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY 39-02-3600-6007 800-986-383 JAPAN OSAKA: 81-6-7739-4799 0066-33-132439 JAPAN TOKYO: 81-3-5539-5191 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 MALAYSIA 1-800-81-3065 MEXICO 001-866-376-9696 NETHERLANDS 31-20-718-8588 0800-023-4378 NEW ZEALAND 64-9-970-4771 0800-447-722 NORWAY 47-21-590-062 800-15157 PANAMA 011-001-800-5072065 PERU 0800-53713 PHILIPPINES 63-2-858-3716 POLAND 00-800-1212572 PORTUGAL 8008-14052 RUSSIA 8-10-8002-0144011 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 SOUTH AFRICA 080-09-80414 SOUTH KOREA 82-2-6744-1083 00798-14800-7352 SPAIN 34-91-414-25-33 800-300-053 SWEDEN 46-8-566-19-348 0200-884-622 SWITZERLAND 41-44-580-6398 0800-120-032 TAIWAN 886-2-2795-7379 00801-137-797 THAILAND 001-800-1206-66056 UNITED KINGDOM BIRMINGHAM: 44-121-210-9025 0808-238-6029 UNITED KINGDOM GLASGOW: 44-141-202-3225 0808-238-6029 UNITED KINGDOM LEEDS: 44-113-301-2125 0808-238-6029 UNITED KINGDOM LONDON: 44-20-7108-6370 0808-238-6029 UNITED KINGDOM MANCHESTER: 44-161-601-1425 0808-238-6029 URUGUAY 000-413-598-3421 USA 1-517-345-9004 866-692-5726 VENEZUELA 0800-1-00-3702 Restrictions may exist when accessing freephone/toll free numbers using a mobile telephone. ---------------------------- Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

CSG breakfast with the Alac
by Tony Holmes June 20, 2011

June 20, 2011

Dear ISPCP members If you plan to attend the CSG/ALAC breakfast meeting in Singapore on Tuesday morning, please confirm by replying to this email. Thanks Tony

5 4