August 2019 - Gnso-epdp-team

Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
by Alan Greenberg Sept. 2, 2019

Sept. 2, 2019

Amr, as few points. 1. This use case is NOT about content. It is true that the user request *MAY* have been triggered by content of a web site. But it could equally well have been triggered by an e-mail received. Or just the semantics of the domain name. A registrar *might* choose to use any web content as a basis for responding positively or negatively to such a request for access, but it could also use its own database of its customer information to determine if the registrant is a legal person. What the registrar does in resolving an access request will not be dictated by any ICANN policy and is purely up to its business practices. 2. I really do not understand the concept if us "rejecting" a use case. We were asked to identify potential use cases and we did. You captured the validity of the case at the end of your message: "there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar". Any EPDP rejection notwithstanding, a user may still request access to information about a registrant that she believes may be a legal person. And a registrar/registry may ultimately agree to grant that access - or not. Therefore it *IS* a user case, albeit perhaps one you don't like. Nothing in this use case presupposes that access will be granted, nor does it presume that such a use will be handled in anything but a manual mode with the registrar performing the "balancing" as dictated by GDPR. Alan At 28/08/2019 03:30 PM, Amr Elsadr wrote: Hi Brian, I'm not sure that it makes a difference - wether disclosure can or cannot be presupposed as an outcome. If we, as a Team developing gTLD policy recommendations, tackle an issue concerning web content, reach a conclusion (any conclusion) on it, send a recommendation to the GNSO Council, which is adopted and then sent to the ICANN Board, which adopts it yet again, then what is the outcome? To me, the answer to that question would be that the EPDP Team, the GNSO Council and the ICANN Board have all contributed to creating contractual obligations on Contracted Parties that ICANN should have no business creating. To me, this is also a means of pulling topics out-of-scope of ICANN's mission in to it, because although this scope is defined by the Bylaws, there are also Bylaws granting the GNSO responsibility for developing gTLD policy. Would create a bit of a messy constitutional sort of situation, I think. Also, at some point in the future, the Consensus Policy we are in the process of developing recommendations for will be reviewed, and amendments may be sought. Reviewing Consensus Policies could potentially be initiated by either the GNSO or GDD (if you're following the current Council conversation on reviews of implemented Consensus Policies). So even if we are not presupposing any outcome of disclosure in this use case now, we open the door to further policy development on this topic at some point in a future iteration. On a topic that should have been flagged as out-of-scope of ICANN's mission to begin with!! Ideally, we would not submit any recommendations concerning web content at all. If we did, it'd be nice to know that there are checks and balances in place that initiate some kind of course correction. For instance, the GNSO Council or the ICANN Board would respond saying, wait a minute, why are you sending us a policy recommendation on a topic outside of ICANN's scope?! Speaking for myself, unfortunately, I very much doubt that would happen. It's probably also noteworthy that even if we, as an EPDP Team, reject this use case, and do not address the topic in our recommendations, there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar, as you suggest. Our use of these use cases should focus on helping respondents to disclosure requests understand how best to deal with whatever disclosure requests they receive. We can't cover every single potential use case anyway, so the ones we do work out should at least provide some guidance on how to deal with unforeseen circumstances. With that in mind, I believe there is value in addressing this use case, and rejecting it, as opposed to not looking at it at all. This is my personal perspective, and apologies if it was slightly lengthier than it needed to be, but you asked. ;-) Thanks. Amr ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 28, 2019 8:25 PM, King, Brian <Brian.King(a)markmonitor.com> wrote: Hey Amr and all, I can’t speak authoritatively for ALAC’s intent, but I read this use case as allowing internet users to request (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc. I think we’re merely talking about allowing an internet user to ask the question, without presupposing any access outcome. Does that change your perspective? I’m sympathetic to concerns raised about the bounds of ICANN’s remit, and I might find those concerns more persuasive if we were talking about guaranteed access in this case. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> On Behalf Of Amr Elsadr Sent: Tuesday, August 27, 2019 7:28 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg> Cc: gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Hi, The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission. Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services. My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. �, and like I said�, I do don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway. Thanks. Amr On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hello All, The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear. I attach the updated user case, which is also available through the google doc Best Hadia el-Miniawi From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Tara: Responses inline below: The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Because the issue is not decided. Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law. Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears. Same comment as above. <Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

5 7

Zero Draft Google Doc?
by Mueller, Milton L Aug. 31, 2019

Aug. 31, 2019

I had an understanding that we would soon be given a Google doc of the zero draft that would allow us to comment on it. It could be my oversight but I have not seen that disseminated yet. Since we were expected to provide comments by Thursday I would hope it will come soon. Dr. Milton L Mueller Georgia Institute of Technology School of Public Policy [IGP_logo_gold block]

3 2

Zero-Draft Doc- Assessment of the data being requested
by farzaneh badii Aug. 31, 2019

Aug. 31, 2019

I don't know if this has been flagged and I know that the zero draft is frozen for now but I believe the diagram about the assessment of the data requested Step 2, is not correct. It says that if the data is non-EEA data may be released with no balancing test performed. In phase one we agreed that the contracted parties can make geo diff if they want. The ones that do not do geo diff should definitely follow the disclosure policy we are coming up with and perform the balancing test regardless of EEA or non-EEA data. I don't think they should just release the data. As we argued, ICANN's policies are global. If disclosure is global, data protection has to be global too. Farzaneh

5 6

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Thursday, 29 August 2019 at 20:00 UTC
by Terri Agnew Aug. 30, 2019

Aug. 30, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 29 August 2019 at 20:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/EY3kBg> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call, observers can join via audio cast, listen to the recordings and read the transcript afterwards. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Thursday, 29 August 2019 at 14:00 UTC
by Terri Agnew Aug. 30, 2019

Aug. 30, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 29 August 2019 at 14:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/pKajBg> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call, observers can join via audio cast, listen to the recordings and read the transcript afterwards. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Fwd: [GNSO-EPDP-Lead] Zero draft ready for sharing
by Janis Karklins Aug. 30, 2019

Aug. 30, 2019

Dear EPDP Team, Please find attached for your review the zero draft as well as an accompanying diagram. As you know, our staff support team has developed this document at the request of leadership to serve as a starting point for our deliberations in LA. As noted in the document, this paper aims to represent views that appeared to have been broadly shared or are based on the current status of work but these do NOT represent formally agreed to EPDP Team positions. Further review and discussion during the LA F2F meeting will need to confirm whether there is support for these policy principles, building blocks and implementation guidance and if not, how these should be modified to achieve general support. The paper also identifies a number of questions that are intended to aid the EPDP Team in further detailing its intent. I hope you will review this document with this background in mind. During Thursday’s extraordinary meeting, the staff support team will walk you through the document and there will be an opportunity to share initial reactions which I expect will be focused on how to constructively use this document as the basis for our LA deliberations. As you may recall, the next steps are as follows: - Extraordinary EPDP Team meeting to present zero draft and get initial reactions from EPDP Team: Thursday 29 August at 20.00 UTC (note, this meeting will be in addition to the regular EPDP Team meeting at 14.00 UTC) - Conduct survey to assess which aspects of the zero draft are of most concern and as such should be prioritized for the F2F meeting: Monday 2 – Wednesday 4 September. - Confirm priority items for F2F meeting and confirm ‘homework’ for F2F meeting: Thursday 5 September (regular EPDP Team meeting) We hope this approach will allow us to get the most out of our F2F time and will result in significant progress towards delivering our Initial Report. Thanks, JK

4 3

Updated LEA 1 Use case
by LEWIS-EVANS, Christopher Aug. 30, 2019

Aug. 30, 2019

OFFICIAL Please find the attached LEA 1 use case as mentioned yesterday. Many Thanks Chris This use case is provided by myself to enable the work of the ePDP and are not representative of a GAC position. This information is supplied in confidence by NCA, and is exempt from disclosure under the Freedom of Information Act 2000. It may also be subject to exemption under other UK legislation. Onward disclosure may be unlawful, for example, under data protection legislation. Requests for disclosure to the public must be referred to the NCA FOI single point of contact, by email on PICUEnquiries(a)nca.gov.uk. All E-Mail sent and received by NCA is scanned and subject to assessment. Messages sent or received by NCA staff are not private and may be the subject of lawful business monitoring. E-Mail may be passed at any time and without notice to an appropriate branch within NCA, on authority from the Director General or their Deputy for analysis. This E-Mail and any files transmitted with it are intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please contact the sender as soon as possible.

1 0

Notes and action items - EPDP Team Meeting #17 - 29 August 2019
by Caitlin Tubergen Aug. 29, 2019

Aug. 29, 2019

Dear EPDP Team, Below, please find the notes and action items from today’s EPDP Team extraordinary meeting. As a reminder, the next EPDP Team meeting will be Thursday, 5 September at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #17 Thursday, 29 August 2019 at 20.00 UTC Action Items Support Staff to populate the zero draft into a Google Doc, and invite team members to provide any additional comments or expressions of concern by Thursday, 5 September 2019. Comments will be used to create the 0.1 draft for discussion in Los Angeles. Please find the Google doc here: https://docs.google.com/document/d/1TKw8tOe0qgkXgBNLjVxb7l7tu20UF9t-/edit#. Support Staff to distribute a survey which will allow EPDP Team Members to rank topics or add topics they wish to discuss in Los Angeles. Support Staff to provide a list of issues that need to be further explored and invite Team Members who would like to draft an issue write-up for that topic. Based on the collective write-up, the Team could begin discussing the issue in Los Angeles or beyond. (An example would be financial considerations.) Please find the table here: https://docs.google.com/document/d/12DH3LoKyqLKzpxOo7fhqaXkKWDs0jFmN/edit. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #17 Proposed Agenda Thursday, 29 August 2019 at 20.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · Please state your name before speaking for transcription purposes. · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) · No objections to the agenda. 3. Overview of Zero Draft in Preparation for F2F Meeting · Support Staff tried to capture elements, principles, and building blocks from Phase 2 deliberations as well as Phase 1 deliberations. · The group will need to review whether the elements need to be removed or translated into requirements. · There is also a flow chart, in which the elements of an SSAD are described visually. It is broken down into the demand side (third party requestor), the supply side, and the system itself (the technical part). · There is also a more detailed evaluation of a possible 6(1)(f) analysis. · The diagram also allowed EPDP Leadership to show where the different building blocks fit and where there may still be gaps. · In each of the building blocks, it shows which topic in the worksheet it relates to. Questions highlighted in yellow are the questions identified in putting together this zero draft. · At the end of the document, there is also implementation guidance provided. · This zero draft is nothing but the proposal for the beginning of further work. If approved by the Team, we will continue to build upon it and structure the discussion in Los Angeles based upon it. EPDP Team Feedback: · As a starting point for the meeting in Los Angeles, this is a viable document. One thing that should be added to it would be a discussion about accreditation and possibly eliminate the discussion of user groups (building block C) - that may come out of the discussion of accreditation. · Thank you to staff for putting this draft together. It is easy to trace back where the building blocks came from. Regarding building a schedule around the F2F meeting - the items in the draft are items the Team is already covered. What is more interesting are the items not covered - the focus on LA should be what is not currently covered in the zero draft. No objections with using this as a starting point. · User groups / authentication and outside counsel input should be focus for F2F meeting · Building Block C could be a useful discussion in Los Angeles, and should be left in. · It might be helpful to allow updates to the zero draft to reflect discussions between now and LA. And agreed that it would be important to flag topics not covered & defined such as what does automation mean · Is the intention of this document to come up with a general and abstract policy? It may be helpful to work on some standardized scenarios where concrete scenarios are written up and where we determine that disclosure under certain circumstances is OK. Consider adding three building blocks: contingency planning, legal building block to cover arrangements that need to be executed from the parties involved, and a periodic evaluation of the system. Should the zero draft be frozen? · Yes. · Action: Support Staff to populate the zero draft in a Google Doc, and invite team members to provide any additional comments or expressions of concern by Thursday, 5 September 2019. Comments will be used to create the 0.1 draft for discussion in Los Angeles. Following F2F, we will produce a 1.0 draft. · Action: Support Staff will distribute a survey which will allow EPDP Team Members to rank or add topics they wish to discuss in Los Angeles. · Some building blocks are in preliminary stages - the Team will need to work on issues that have not been more fully explored yet. · Support Staff to put forward a list of issues that need to be further explored - invite Team Members who would like to draft an issue write-up for that topic. Based on the collective write-up, the Team could begin discussing the issue in Los Angeles or beyond. (An example would be financial considerations.) · The goal of the write-ups is that it is easier to have a starting point for group discussion rather than starting with nothing and drafting by committee. · The ranking will be based on building blocks and policy principles. There will also be an additional question to ask for topics that are missing and must be discussed. · The first batch of questions for Bird & Bird will be sent to Bird & Bird today. .

1 0

Question in preparation of the LA F2F meeting
by Janis Karklins Aug. 29, 2019

Aug. 29, 2019

Dear EPDP Team, In planning for our F2F meeting in Los Angeles in September, I wanted to test the idea of carving out time as part of our agenda to meet with ICANN’s CEO and/or the Strawberry Team to get an update on the status of their activities in relation to the UAM based on the TSG model. As the questions that ICANN org is preparing for DPAs are expected to also help inform the EPDP Team’s deliberations, it may be of interest to get an update on the status as well as expected timeline and sharing any question from EPDP team directed to DPAs. Similarly, there may be further questions that the EPDP Team has for ICANN’s CEO that may impact the team’s decision-making further down the line, for example, in relation to the liability ICANN org is expected or willing to take on in a potential UAM. If there is interest in such an engagement, I would like to propose that we start a google doc that allows for the collection of specific questions so we can make sure that any engagement is structured to achieve a constructive outcome. I look forward to receiving your feedback. JK

9 13

Meeting Invitation: Observers GNSO Temp Spec gTLD RD EPDP - Phase 2 call | Thursday, 05 September 2019 at 14:00 UTC
by Terri Agnew Aug. 29, 2019

Aug. 29, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 05 September 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 07:00 PDT, 10:00 EDT, 16:00 Paris CEST, 19:00 Karachi PKT, 23:00 Tokyo JST, (Friday) 00:00 Melbourne AEST For other times: https://tinyurl.com/y6go5d23 Agenda Wiki: https://community.icann.org/x/Uo7kBg The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream02 <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream02.m3u <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> If needed, an option to join via telephone has been added for this meeting. Passcode: EPDP 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 RIO DE JANEIRO: 55-21-40421490 0800-7610651 BRAZIL SAO PAULO: 55-11-3958-0779 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 CROATIA 080-08-06-309 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 ESTONIA 800-011-1093 FINLAND 358-9-5424-7162 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 36-1-700-8856 06-800-12755 INDIA INDIA A: 000-800-852-1268 INDIA INDIA B: 000-800-001-6305 INDIA INDIA C: 1800-300-00491 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY MILAN: 39-02-3600-6007 800-986-383 ITALY ROME: 39-06-8751-6018 800-986-383 ITALY TORINO: 39-011-510-0118 800-986-383 JAPAN OSAKA: 81-6-7878-2631 0066-33-132439 JAPAN TOKYO: 81-3-6868-2631 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 8002-9246 MALAYSIA 1-800-81-3065 MEXICO GUADALAJARA (JAL): 52-33-3208-7310 001-866-376-9696 MEXICO MEXICO CITY: 52-55-5062-9110 001-866-376-9696 MEXICO MONTERREY: 52-81-2482-0610 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 1800-111-42453 POLAND 00-800-1212572 PORTUGAL 8008-14052 ROMANIA 40-31-630-01-79 RUSSIA 8-10-8002-0144011 SAUDI ARABIA 800-8-110087 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 0800-002066 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 TURKEY 00-800-151-0516 UNITED ARAB EMIRATES 8000-35702370 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 VIETNAM 120-11751 Thank you. Kind Regards, Terri

1 0