January 2017 - Gnso-newgtld-wg-wt2

WT2 Meeting Time Rotation Consideration
by Michael Flemming Jan. 31, 2017

Jan. 31, 2017

Until now, the majority of our WT2 Meetings have taken place on Thursdays at 20 UTC. This meeting slot has proven useful as our attendance has not faltered too much up until now. However, for some of our members, including myself, 20 UTC can also be a rather difficult time to attend these meetings. For this reason, I would like to make the proposal to begin looking at a rotation for WT2 meetings. Other Working Tracks have been rotating meetings at a 3:00 UTC, 15:00 UTC, and 20:00 UTC schedule. I think it would be useful to begin using this rotation or one at a similar time slot. If others wouldn't have a problem with this rotation, then I would like to have a Doodle Poll sent out to begin adjusting the already scheduled meeting time on February 2nd at 20 UTC. Any thoughts? Kind regards, Michael Flemming

5 6

Registrant Protections Discussion
by Michael Flemming Jan. 31, 2017

Jan. 31, 2017

At our last meeting on January 19th at 20 UTC we introduced the Registrant Protections (EBERO, COI, and When Registrants don't apply topics). While these topics are vast and much can be discussed, we are unable to spend all of our time discussing during our bi-weekly hour meetings. Therefore, I would like to continue this discussion over email. I attach here the same presentation material we used in the meeting in order to provide everyone with the necessary background information. However, I have pulled out the questions from the presentation and listed them below. These same questions will be copied to the Issues Area Working Document <https://docs.google.com/document/d/1YsbOmz06YbXBkUQpj1rljVo-bTH-Br5Ju6cVJvp…>. Perhaps it is easier, however, to have a discussion on a consistent email thread. Key feedback will also be moved to the document. I invite everyone to provide their opinion to the questions below. *Critical Registry Functions:* *Are the current Critical Registry Functions still sufficient or do changes need to be made? * *Has any registry gone above the Emergency Threshold before?* *Has the level of the Emergency Threshold ever been reached that would initiate an emergency escalation or EBERO?* *COI:* *Are the cost measurements for the COI still sufficient to cover the critical functions for EBERO?* *Is the time period for the COI sufficient (i.e. 6 years from the execution date of the RA)?* *Are the requirements for the Letter of Credit still sufficient?* *Can other models besides the Letter of Credit and the Cash Escrow Deposit be considered for the COI requirements?* *In regards to TLDs like Brand TLDs and Code of Conduct exempt TLDs where Registrants may not be necessary to protect:* *Should more relevant rules be established for certain specific cases or categories of TLDs?* Below are additional questions I would like to add on material we were not able to cover in the last meeting. These are kind of last minute additions and the questions could probably be refined. *In regards to Background Checks on applicants:* *Are the background checks a sufficient mechanism for protecting Registrants?Do the requirements for Background Checks in regards to (1) General business diligence and criminal history and (2) History of cybersquatting behavior prove sufficient and/or necessary for TLDs where Registrant Protections may not be necessary?* I have a few other additional questions I would like to ask, but need more time to formulate them. Please let me know your thoughts. Kind regards, Michael Flemming

1 2

recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues 19 January 2017
by Terri Agnew Jan. 19, 2017

Jan. 19, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues held on Thursday, 19 January 2017 at 20:00 UTC. The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Agenda Wiki page: https://community.icann.org/x/oLbDAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 19 January 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues on Thursday, 19 January 2017 at 20:00 UTC. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Heather Forrest:Thanks, Terri - good morning to you Steve Chan:Sure, just say next slide, and I can move it forward for you. Jeff Neuman:Principle D is from the 2007 GNSO Policy Rubens Kuhl:While at NTAG, applicants concluded that ICANN COIs likely violated international guidelines against money laundring. I still think it is true. Trang Nguyen:@Rubens, I believe the issue was around the specific criteria in the AGB that states: The LOC ust name ICANN or its designee as the beneficiary." Many banks, U.S. and international viewed the "designee" as problematic because most if not all banks need to perform certain checks on the beneficiary, and they cannot do that for an un-named beneficiary. ICANN issued an advisory (https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_… ) stating that it would be acceptable to name only ICANN as the beneficiary provided that the LOC is fully transferable. Trang Nguyen:Nonetheless, COIs were an issue for most applicants. Q50 received the most number of clarifying questions, by far. 82% of apps received a CQ on Q50. Kurt Pritz:My understanding is that If a Donuts rgistry went into EBERO, the registery would no longer be registering names, therefore the DPML would no longer be critical Jeff Neuman:@Kurt - Is that an argument that the SRS is not a critical function? Rubens Kuhl:Jeff, the SRS is still required to update already registered domains. Rubens Kuhl:But any policy layer is not critical. Jeff Neuman:@Rubens - correct.....that is the critical part, but not the rest of the SRS Rubens Kuhl:DPML, registrant verification and all other systems, processes and human resources that are in the policy layer are not critical. Kurt Pritz:@Jeff - no. It was an argument that we need not augment the existing core set with DPML. There might be renewals in an EBERO environment, does that require SRS? Jeff Neuman:I want to make sure we capture Trang's statistics for the recprd Steve Chan:@Jeff, I believe Trang's statistics are from the Program Implementation Review Report, but it's also captured in the notes. Rubens Kuhl:Kurt, from a pratical standpoint I think it would be better for EBERO both not accept renewals and do not expire domains. Kurt Pritz:@ Rubens The hoped for ending is that someone else picks up the EBERO operated registry. If domains are not renewed or expired, would that complxity deter a successor from standing up Kristina Rosette (Amazon Registry):@Steve and Julie: Joined late because earlier call ran long. Can you include me among those who ran into issues with the COI during the application process? Thanks. Cheryl Langdon-Orr (CLO):that needs teasing out then Jeff Julie Hedlund:@Kristina: I've added you. Alexander Schubert:i heard nothing for 10 minutes. are the phone and audio bridged? Michael Flemming:Yes Alex Michael Flemming:Alexandre* Kurt Pritz:It is a complicated area but I don't know of and haven't heard any evidence that indicates augmenting the critical functions list Cheryl Langdon-Orr (CLO):I am Alexander Schubert:seems dialing in is required to hear everybody? Cheryl Langdon-Orr (CLO):hearing via phone Alexander Alexander Schubert:but hearing works fine. i hear most people - just a few not. Rubens Kuhl:Option D. Alexander Schubert:one would think both systems are bridged? Trang Nguyen:@Michael, I do not know if an EBERO has ever been officially triggered. We could check if that's a request from this WT. Trang Nguyen:Yes, will do. Jeff Neuman:@Trang, do you need that in a letter? Rubens Kuhl:@Trang, from IANA root zone journals I follow I believe it was never triggered... but that would only reveal actual transition, not possilble events where EBERO has been called to duty but RO went back online before a transition happened. Cheryl Langdon-Orr (CLO):I would go with Jeff's formulation with the ask ICANN Trang Nguyen:I think I understand the ask. Will have to take this back internally and see what information we can provide. Kristina Rosette (Amazon Registry):To be clear, the intention is to ask "yes/no" and "If yes, on how many occasions?" without seeking identity of the RO, the issue, or which EBERO transitioned, correct? Michael Flemming:Yes Jeff Neuman:@Kristina - yes....but also to find out if the threshold was reached, but ICANN did not bring up an EBERO (And why or why not) Jeff Neuman:But no attribution to any registry or EBERO Kristina Rosette (Amazon Registry):@Jeff: thanks. Christa Taylor:Rubens, we can't hear you. Can you speak up? Kurt Pritz:If the COI is eliminated, this question on cost measurements does not matter much Rubens Kuhl:There seems to be a disconnection between bridge audio and AC audio... if you are in the same side you end up hearing who talked. Weird. Michael Flemming:But th cost analysis would be the same, regardless, no? Even if we do get rid of the COI, the cost would still come up somewhere. Rubens Kuhl:What I said is that EBERO has a readiness cost and an activation cost. Those costs that are COI-funded seems to only cover activation cost, not readiness cost. ICANN pays EBERO providers so they are ready even without incidents. Michael Flemming:There would still be a cost* Rubens Kuhl:Full disclosure: we have a contract clause in our back-end contracts to not take down TLDs that have not paid. their dues We can "snitch" them to ICANN, but won't take them down. Kurt Pritz:The slide says ICANN "will initiate an Energency Escalation" - it doesn't say "will transfer to an EBERO" - so if the slide reflects the contract then transfer is not mandatory Kristina Rosette (Amazon Registry):I've always understood that Emergency Escalation is completely different from transfer to EBERO. Kristina Rosette (Amazon Registry):Section 7 of Spec. 10 sets out exactly what an Emergency Escalation is and how it differs if initiated by ICANN vs. by Registrars Jim Prendergast:the contracted party is the front end. not the back end. Jeff Neuman:@Jim - yes. Which is why we may want to come up with a different model Jeff Neuman:It would be good to create a small team try and explore alternate models Rubens Kuhl:I think ICANN said that if a registry survived 5 years, it looks solid enough. Trang Nguyen:I was not with ICANN during the AGB development process, so don't really know how the 6 years were arrived at in Spec 8. Christa Taylor:A pooled insurance type of structure based on data could be an straight forward solution. As long as the data and the algoriithm are conservative it could be a viable option Christa Taylor:If the business completely failed and went bankrupt without any notice, one would think that the back-end provider could take it over with the renewal revenues to help offset the costs. Christa Taylor:There is no 'cash cow' fund Jeff Neuman:@Christa - There may be some legalities of the creation of an insurance fund. Christa Taylor:@Jeff perhaps the wrong term but trying to convey the idea Kurt Pritz:The reaction of the backend to not being paid could be governed by a backend certification program (!!) Heather Forrest:Apologies, all - I have to drop off now for the Council meeting. Kristina Rosette (Amazon Registry):Yes, Paul McGrady gave a rather "spirited" presentation of the many ways heading down any kind of "insurance model" could create problems for ICANN Trang Nguyen:@Christa, in your suggested model, would there be different buy-in amounts based on number of DUMS, or would all TLDs be expected to contribute evenly to the insurance fund? Christa Taylor:+1 Kurt it could be part of it Jeff Neuman:But there are other ways including the appointment of "permanent EBEROs" and figuring out an amount that would compensate them for the expected amount of failures per year. Then using Registration fees to cover those costs Kristina Rosette (Amazon Registry):Can be considered or should be considered? Christa Taylor:@Trang needs more thought - could be DUM or another combination of DUM and minimals Terri Agnew 2:Phil, we are unable to hear you, please check your mute button Rubens Kuhl:Business failures can have a high correlation with selling domains for pennies, so the outlook of future registration fees may not be as good... Phil Buckingham 2:sorry iwas on mute . Cheryl Langdon-Orr (CLO):had to drop phone for my next ICANN call Jeff Neuman:I believe that snce we now have a number of years under our belt, we could could use that data to seek proposals from EBEROs (past or futuree) to see if there is a fixed annual fee that they could be paid for the year to cover any eventuality (given that an EBEROs obligations are very limited) Cheryl Langdon-Orr (CLO):will stay in AC Rubens Kuhl:EBERO without COI could be a best of both worlds option. Rubens Kuhl:Also have to drop the audio bridge... see ya. Cheryl Langdon-Orr (CLO):agree Rubens Cheryl Langdon-Orr (CLO):but happy to explore new funding options Kurt Pritz:I agree with Rubens also. Here is a trial balloon on COI: Eliminate the COI. ICANN to fund the EBERO and temporarily maintain an abandon registry out of its regular revenue stream. This is because: (1) no registries have required EBERO intervention to date so projected incidents (and costs) should be low; (2) COI was problematic to implement on many levels (clarifying questions, different laws, etc); (3) the fees from 1000+ new registries, which is a number greater than expected, should cover costs, ICANN did not have this money when writing the Guidebook;(4) the cost of maintaining the existing registry functions is relatively low; (5) the most likely failure is a single registry business failure and the development of the backend registry marketplace would tend to guarantee that data is preserved in the event of a failure and any transition is straightforward. Phil Marano (Mayer Brown):Protections vis-a-vis .Brand TLDs and their licensees can be dealt with through other contractual means, and might not need not be mandatory for registry operators who are not in the business of selling domain names. Kurt Pritz:sorry for all that Christa Taylor:+1 Jeff Cheryl Langdon-Orr (CLO):bye guys need to leave Kurt Pritz:I don't think as policy makers, we need to get into detailed costs. We just need to say that the COI was problematic and now it can be funded separately for a number reasons. The topic of use of auction funds or left-over funds is a differnet discussion Jeff Neuman:@kurt said it better than me .... but same concept :) Robert Burlingame:Thank you everyone. Christa Taylor:Agreed Kurt. The costs would be very useful Christa Taylor:Good day all! Trang Nguyen:Thanks, all!

1 0

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 19 January
by Julie Hedlund Jan. 19, 2017

Jan. 19, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 19 January. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording. See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings. Please also see the attached slides referenced below. Excerpts from the chat room are included below for ease of reference. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 19 January 1. Registrant Protections -- Introduction [reading from slide 2] Question: How many applied or were an applicant and had a problem -- show of hands: 4 hands: Michael Flemming, Jeff Neuman, Rubens Khul, Heather Forrest, Kristina Rosette Principle D, Risk assessment and contingencies, application scoring [from slide 2] 2. Critical Registry Functions [reading from slides 3 and 4] Question: Are the current critical registry functions still sufficient or do changes need to be made? Yes/No/Other -- On overall registrant protections -- one was the notion of being able cover if a registry failed. Is there any protection other than those 5 functions where a backup registry need to take over, or are the 5 functions enough? -- There was the discussion on whether critical registry functions would need the additional functions of RCEP. -- It may be different for different types -- may need to have core critical functions regardless of how your TLD is characterized, and a "if this, then that" set. -- We do consider whether or not the COI is necessary for different categories. Really like the idea of overarching functions. -- Bring up the notion operation of a shared registration system -- in the chat if an EBERO is ever called up -- not responsible for adding new names. The problem with renewals some registries validate renewals as the validate new registration. -- Operation of certain systems that are critical. If there is a policy that affects renewals then EBERO won't be able to do it. >From the Chat: Jeff Neuman: Principle D is from the 2007 GNSO Policy Rubens Kuhl: While at NTAG, applicants concluded that ICANN COIs likely violated international guidelines against money laundering. I still think it is true. Trang Nguyen: @Rubens, I believe the issue was around the specific criteria in the AGB that states: The LOC ust name ICANN or its designee as the beneficiary." Many banks, U.S. and international viewed the "designee" as problematic because most if not all banks need to perform certain checks on the beneficiary, and they cannot do that for an un-named beneficiary. ICANN issued an advisory (https://newgtlds.icann.org/en/applicants/advisories/loc-beneficiary-require…) stating that it would be acceptable to name only ICANN as the beneficiary provided that the LOC is fully transferable. Trang Nguyen: Nonetheless, COIs were an issue for most applicants. Q50 received the most number of clarifying questions, by far. 82% of apps received a CQ on Q50. Kurt Pritz: My understanding is that If a Donuts rgistry went into EBERO, the registery would no longer be registering names, therefore the DPML would no longer be critical. Jeff Neuman: @Kurt - Is that an argument that the SRS is not a critical function? Rubens Kuhl: Jeff, the SRS is still required to update already registered domains. Jeff Neuman: @Rubens - correct.....that is the critical part, but not the rest of the SRS. Rubens Kuhl: But any policy layer is not critical. Rubens Kuhl: DPML, registrant verification and all other systems, processes and human resources that are in the policy layer are not critical. Kurt Pritz: @Jeff - no. It was an argument that we need not augment the existing core set with DPML. There might be renewals in an EBERO environment, does that require SRS? Jeff Neuman: I want to make sure we capture Trang's statistics for the record. Steve Chan: @Jeff, I believe Trang's statistics are from the Program Implementation Review Report, but it's also captured in the notes. Rubens Kuhl: Kurt, from a pratical standpoint I think it would be better for EBERO both not accept renewals and do not expire domains. Kurt Pritz: @ Rubens The hoped for ending is that someone else picks up the EBERO operated registry. If domains are not renewed or expired, would that complxity deter a successor from standing up Kristina Rosette (Amazon Registry): @Steve and Julie: Joined late because earlier call ran long. Can you include me among those who ran into issues with the COI during the application process? Thanks. Cheryl Langdon-Orr (CLO): that needs teasing out then Jeff. Kurt Pritz: It is a complicated area but I don't know of and haven't heard any evidence that indicates augmenting the critical functions list. 3. Emergency Thresholds [reading from slide 5] Question: Has any registry gone above the Emergency Threshold? Yes/No/Other/Ask ICANN for data Three questions: reached the threshold before, or has EBERO been used? If someone went above the threshold and EBERO wasn't used, then why? -- Need the data from ICANN but without attribution. Action Item: Ask ICANN 1) has the Emergency Threshold been breached 2) has EBERO been triggered? 3) If someone went above the threshold and EBERO wasn't used, then why? >From the Chat: Rubens Kuhl: Option D. Alexander Schubert: one would think both systems are bridged? Trang Nguyen: @Michael, I do not know if an EBERO has ever been officially triggered. We could check if that's a request from this WT. Trang Nguyen: Yes, will do. Jeff Neuman: @Trang, do you need that in a letter? Rubens Kuhl: @Trang, from IANA root zone journals I follow I believe it was never triggered... but that would only reveal actual transition, not possilble events where EBERO has been called to duty but RO went back online before a transition happened. Cheryl Langdon-Orr (CLO): I would go with Jeff's formulation with the ask ICANN. Trang Nguyen: I think I understand the ask. Will have to take this back internally and see what information we can provide. Kristina Rosette (Amazon Registry): To be clear, the intention is to ask "yes/no" and "If yes, on how many occasions?" without seeking identity of the RO, the issue, or which EBERO transitioned, correct? Michael Flemming: Yes Jeff Neuman: @Kristina - yes....but also to find out if the threshold was reached, but ICANN did not bring up an EBERO (And why or why not). Jeff Neuman: But no attribution to any registry or EBERO. Kristina Rosette (Amazon Registry): @Jeff: thanks. 4. Cost Coverage [reading from slide 8] Question: Are these cost measurements still sufficient to cover the critical functions for EBERO? Yes/No/Other -- There is the activation part and the readiness part. You have two parts not just one. The COI looks at the activation costs. -- This came from an RFI for entities that were interested in being an EBERO and from those responses ICANN asked for cost estimates on what they were charge ICANN to serve in that capacity. There were at least 10 responses. ICANN synthesized the responses. -- What true amounts would be to bring up an EBERO and how much ICANN would need to fund an EBERO provider. Rather than doing one COI per each registry, find a way to fund it so that you know the costs would be covered. -- The contract already states that once the threshold is breached the emergency Escalation will take place. Is this amount correct for the contract? -- We are contractually bound to agree that ICANN has the right at its discretion to move this to an EBERO, but ICANN decide to or not. If a technical backend -- a registry that said my EPP was down and I'll have it up in 30 hours there is no way ICANN is going to call up an EBERO. We should be discussing this in terms of a technical failure by a business that may or may not be the registry. -- The contract language is up for interpretation: "Emergency Escalation" may not mean EBERO. -- If you took the limited amount in a COI by itself it may not cover the costs of an actual transition. But if you look at what EBERO is paid and combined with the eventual release of COI funds to the registry that may be enough to fund the cost. How can we make sure that in the case of a technical failure that registrants are protected by having a provider in place to operate the critical functions of a registry until a decision can be made. We should explore other mechanisms to fund the program other than via a COI process, which is difficult to maintain and ensure that ICANN can receive the funds. The problem may be with the backend operator and not the registry. -- The COI was as much of a headache for ICANN as for the operators. Should also consider AGB as it relates to COI. -- Seems like we should be looking at setting up a fund made up of application fees and fixed fees. >From the chat: Kurt Pritz: If the COI is eliminated, this question on cost measurements does not matter much. Michael Flemming: But the cost analysis would be the same, regardless, no? Even if we do get rid of the COI, the cost would still come up somewhere. Rubens Kuhl: What I said is that EBERO has a readiness cost and an activation cost. Those costs that are COI-funded seems to only cover activation cost, not readiness cost. ICANN pays EBERO providers so they are ready even without incidents. Michael Flemming: There would still be a cost* Rubens Kuhl: Full disclosure: we have a contract clause in our back-end contracts to not take down TLDs that have not paid. their dues We can "snitch" them to ICANN, but won't take them down. Kurt Pritz: The slide says ICANN "will initiate an Energency Escalation" - it doesn't say "will transfer to an EBERO" - so if the slide reflects the contract then transfer is not mandatory. Kristina Rosette (Amazon Registry): I've always understood that Emergency Escalation is completely different from transfer to EBERO. Kristina Rosette (Amazon Registry): Section 7 of Spec. 10 sets out exactly what an Emergency Escalation is and how it differs if initiated by ICANN vs. by Registrars. Jim Prendergast: the contracted party is the front end. not the back end. Jeff Neuman: @Jim - yes. Which is why we may want to come up with a different model Jeff Neuman: It would be good to create a small team try and explore alternate models Rubens Kuhl: I think ICANN said that if a registry survived 5 years, it looks solid enough. Trang Nguyen: I was not with ICANN during the AGB development process, so don't really know how the 6 years were arrived at in Spec 8. Christa Taylor: A pooled insurance type of structure based on data could be an straight forward solution. As long as the data and the algoriithm are conservative it could be a viable option. Christa Taylor: If the business completely failed and went bankrupt without any notice, one would think that the back-end provider could take it over with the renewal revenues to help offset the costs. Christa Taylor: There is no 'cash cow' fund Jeff Neuman: @Christa - There may be some legalities of the creation of an insurance fund. Christa Taylor: @Jeff perhaps the wrong term but trying to convey the idea 5. Continued Operations Instrument -- Letter of Credit [reading from slide 12] Questions: 1. Are the requirements for the Letter of Credit still sufficient? Yes/No/Other 2. Can othe rmodels besides the Letter of Credit and the Cash Escrow Deposit be considered for the COI requirements? Yes/No/Other >From the chat: Kurt Pritz: The reaction of the backend to not being paid could be governed by a backend certification program (!!) Heather Forrest: Apologies, all - I have to drop off now for the Council meeting. Kristina Rosette (Amazon Registry): Yes, Paul McGrady gave a rather "spirited" presentation of the many ways heading down any kind of "insurance model" could create problems for ICANN Trang Nguyen: @Christa, in your suggested model, would there be different buy-in amounts based on number of DUMS, or would all TLDs be expected to contribute evenly to the insurance fund? Christa Taylor: +1 Kurt it could be part of it Jeff Neuman: But there are other ways including the appointment of "permanent EBEROs" and figuring out an amount that would compensate them for the expected amount of failures per year. Then using Registration fees to cover those costs Kristina Rosette (Amazon Registry): Can be considered or should be considered? Christa Taylor: @Trang needs more thought - could be DUM or another combination of DUM and minimals.' Rubens Kuhl: Business failures can have a high correlation with selling domains for pennies, so the outlook of future registration fees may not be as good... Jeff Neuman: I believe that snce we now have a number of years under our belt, we could could use that data to seek proposals from EBEROs (past or futuree) to see if there is a fixed annual fee that they could be paid for the year to cover any eventuality (given that an EBEROs obligations are very limited) 6. Considering When Registrant Protections don't apply [reading from slide 15] Question: Should more relevant rules be established for certain specific cases or categories of TLDs? -- There are some where registrants are brand licensees -- there are possibly some shades of gray where some need protection or not. -- If you went to existing EBERO or other providers that could provide those services ask what it would take to compensate you for an entire year with no questions asked you would get an amount that was high. >From the chat: Rubens Kuhl: EBERO without COI could be a best of both worlds option. Cheryl Langdon-Orr (CLO): agree Rubens Cheryl Langdon-Orr (CLO): but happy to explore new funding options Kurt Pritz: I agree with Rubens also. Here is a trial balloon on COI: Eliminate the COI. ICANN to fund the EBERO and temporarily maintain an abandon registry out of its regular revenue stream. This is because: (1) no registries have required EBERO intervention to date so projected incidents (and costs) should be low; (2) COI was problematic to implement on many levels (clarifying questions, different laws, etc); (3) the fees from 1000+ new registries, which is a number greater than expected, should cover costs, ICANN did not have this money when writing the Guidebook;(4) the cost of maintaining the existing registry functions is relatively low; (5) the most likely failure is a single registry business failure and the development of the backend registry marketplace would tend to guarantee that data is preserved in the event of a failure and any transition is straightforward. Phil Marano (Mayer Brown): Protections vis-a-vis .Brand TLDs and their licensees can be dealt with through other contractual means, and might not need not be mandatory for registry operators who are not in the business of selling domain names. Kurt Pritz: sorry for all that.

1 0

Re: [Gnso-newgtld-wg-wt2] WT2 - Jan 19th, Thursday Meeting at 20:00 UTC Topic EBERO ( Emergency Back End Operator ) , COI ( Continuing Operations Instrument ) and LOC ( Letter of Credit) Data Escrow ( if time).
by Phil Buckingham Jan. 19, 2017

Jan. 19, 2017

Hi Everyone, Michael, thanks for circulating the agenda. If you could look at the agenda before the call that would be much appreciated, although I do appreciate time is of the essence in preparation for Namescon. We have put a question(s) at the end of each topic . Perhaps you would consider these questions ( and your answer ) beforehand , in preparation, so we could do a hands up / consensus vote on each .during the call. I would be particularly interested to establish if anybody, who encountered problems with Q50/ COI ./LOCs would be prepared to discuss on these on the call ( for their own application(s) and clients ) and what they feel would be an acceptable solution(s) to implement for R2. If you could let me know beforehand …… Many thanks. Kind Regards, Phil Phil Buckingham From: gnso-newgtld-wg-wt2-bounces(a)icann.org [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Michael Flemming Sent: Thursday, January 19, 2017 2:10 AM To: gnso-newgtld-wg-wt2(a)icann.org Subject: Re: [Gnso-newgtld-wg-wt2] WT2 - Jan 19th, Thursday Meeting at 20:00 UTC Dear All, Once again I am circulating the agenda in time for tomorrow's meeting on 19 January, 2017 at 20:00 UTC. My apologies as I was unable to get the slides out earlier. In the attachment is the material we will be covering and the slides we will be using. Phil and I look forward to meeting with everyone tomorrow. Kind regards, Michael Flemming On Fri, Jan 13, 2017 at 9:04 AM, Michael Flemming <flemming(a)brightsconsulting.com> wrote: Dear All, Please note the agenda for the meeting 19 January 2017, Thursday at 20 UTC. 1. Welcome 2. Updated SOI 3. Registrant Protections 4. AOB We didn't get to the Registrant Protections before the end of the meeting yesterday. Therefore, it was felt very strongly that we should have a follow up meeting next week to cover Registrant Protections. The good news is that our slides are already prepared. After I make a few edits I will circulate them today. All background material should be included. On the other hand I hope to begin discussing CC2 questions over email. I look forward to the meeting next week and hope everyone will be ready for constructive discussion. Kind regards, Michael Flemming -- Sent from my mobile.

1 0

WT2 - Jan 19th, Thursday Meeting at 20:00 UTC
by Michael Flemming Jan. 19, 2017

Jan. 19, 2017

Dear All, Please note the agenda for the meeting 19 January 2017, Thursday at 20 UTC. 1. Welcome 2. Updated SOI 3. Registrant Protections 4. AOB We didn't get to the Registrant Protections before the end of the meeting yesterday. Therefore, it was felt very strongly that we should have a follow up meeting next week to cover Registrant Protections. The good news is that our slides are already prepared. After I make a few edits I will circulate them today. All background material should be included. On the other hand I hope to begin discussing CC2 questions over email. I look forward to the meeting next week and hope everyone will be ready for constructive discussion. Kind regards, Michael Flemming -- Sent from my mobile.

1 1

recording, Attendance & AC Chat for New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues 12 January 2017
by Terri Agnew Jan. 12, 2017

Jan. 12, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues held on Thursday, 12 January 2017 at 20:00 UTC. The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Wiki page: https://community.icann.org/x/FwSbAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 12 January 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues call on Thursday, 12 January 2017 at 20:00 UTC. Terri Agnew:agneda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Jim Prendergast:15 - the magic number Jeff Neuman:phil can you hit mute until you speak :) Terri Agnew:Please remember to mute when not speaking Terri Agnew:everyone can scroll themselves Jeff Neuman:It should be noted that there were MANY discussions between the GAC and the Board on Geographic and geopolitical names between the 2009 recommendation and what was eventually put into the Guidebook. But NO policy development process was ever commenced to discuss those protections during that time period Susan Payne - Valideus 2:we are dealing at 2nd level here though aren't we, or am I mistaken? whereas CWG-CTN is top level Michael Flemming:Second level Cheryl Langdon-Orr (CLO):yes understand it is 2nd level Cheryl Langdon-Orr (CLO):but the concerns I have heard raised reflect in Top andb2nd... Rubens Kuhl:Note that there are dissenting views regarding use of RSEP to release reserved names. ICANN is currently adopting such view, but some think it should be a different process, even in current policy guidance. Michael Flemming:I made a note on that Rubens, but you sum it up so sweetly. Cheryl Langdon-Orr (CLO):note in my time in suDA Board I fought to and succeeded to release Lower level names so I am not 'anti' Susan Payne - Valideus 2:OK, thanks Cheryl, understood. But in terms of what has been discussed in the CWG, we have only been talking about 2nd level Cheryl Langdon-Orr (CLO):understand that Susan Alan Greenberg:Sorry to be late. Cheryl Langdon-Orr (CLO):even in our Work in the most recent CWG whose name itself is specified separation of the levels N in community understanding and and concerns has always been a 'challenge' Cheryl Langdon-Orr (CLO):agree Jeff Rubens Kuhl:.com and .net are pretty old namespaces... new namespaces might require introductory measures, like sunrise. Legacy gTLDs are benchmarks, but a grain of salt in comparing is required. Kristina Rosette (Amazon Registry):Support creation of drafting team (which may not be smaller given interest), but agree on creating subteam avri doria:i still have not graduated beyond what was in the original GNSO policy of 2007. and that is a lost casue (personal opinion) Rubens Kuhl:One issue in allowing Brand TLDs is what happens if the TLD is repurposed to not be a Brand TLD, which is a registry operator option at anytime without consulting, just informing, ICANN. avri doria:i find having difrent such rules for different categories very problematic (again personal view) Mary Wong:For clarity (including for WT members not on the call), what is the specific focus and brief for the Drafting Team, and what will be its anticipated timeline to deliver its proposal? Susan Payne - Valideus 2:support drafting team too. I think it wouldmbe helpful for those who join to familiarise themselves with how we got from the policy to the AGB as not all of us are probably familiar with the full history Kristina Rosette (Amazon Registry):We should make clear that GAC representatives are welcome to participate.. Cheryl Langdon-Orr (CLO):one of many similar concerns Rubens... yes avri doria:Susan, that was easy, without going back to the GNSO the BoardStaff decided. Cheryl Langdon-Orr (CLO):indeed Kristina avri doria:I think they know they are welcome, but alwasy good to mention it again Jeff Neuman:Lets confirm the 2009 policy on this Kristina Rosette (Amazon Registry):Support confirming 2009 policy on gTLD Reserved Names (2nd & 3rd levels ASCII and IDN) Susan Payne - Valideus 2:sorry, audio issues Rubens Kuhl:Looking at collision lists, some popular legacy TLDs (both gTLDs and ccTLDs) deserve a bit of care. While I also support confirming the 2009 policy, this is a factor that new gTLD operators should assess and hopefully make informed decisions. Rubens Kuhl:I don't see possibility of human confusion, but some name collisions can occur. Rubens Kuhl:Due to suffix appending. Cheryl Langdon-Orr (CLO):and name collision needs to be avoided Cheryl Langdon-Orr (CLO):SAC90 Phil Buckingham 2:steve , emily - before i start , can one of you do the scrolling of the powerpoint . much appreciated. Christa Taylor:+1 Susan on the ship has sailed Steve Chan:@Phil, sure thing. Phil Buckingham 2:thanks Susan Payne - Valideus 2:yes, agree Phil Buckingham 2:+1 Alan - impossible Christa Taylor:Agree with Alan Michael Flemming:Can you hear me? Christa Taylor:no Julie Hedlund:Can't hear you Michael. avri doria:i go as far as to call it unreasonable (again personal view) avri doria:there are only 7 in the US? Christa Taylor:+1 Avri Rubens Kuhl:Jeff, just type s*** etc. ;-) avri doria:ah the s-word, the f-word ... modern Merican speak Jeff Neuman:s***, f***, p***. m************, c***, t****, and one other that escapes me for now Jeff Neuman::) avri doria:https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org… Susan Payne - Valideus 2:p***?? Jeff Neuman:oh yes c********** Steve Chan:FYI, the language Michael is reading is from the base registry agreement. Mary Wong:There is ongoing implementation of Board-adopted GNSO PDP recommendations regarding a few names for the Red Cross movement and names of IGOs. Jeff Neuman:I agree on this category and the IGOs Mary Wong:Per Alan, other Red Cross names are still under discussion. Cheryl Langdon-Orr (CLO):agree Susan Rubens Kuhl:One organisation that I don't believe deserves any special treatment is IOC. Rubens Kuhl:"I don't want to be buried in a Pet Cemetery,I don't want to live my life again." Mary Wong:@Michael, to add - what I said (i.e. long list currently now reserved under Spec 5) also applies to IGOs. The only reserved protections approved so far for IGOs are their names. Their acronyms are now on the list only on an interim basis. Cheryl Langdon-Orr (CLO):good point Jeff Rubens Kuhl:Which would allow the International Sugar Organization to get ISO.<something> instead of the International Standards Organization... Cheryl Langdon-Orr (CLO):agree again Susan Mary Wong:All, note that in the current implementation for Red Cross, IOC and IGOs - there will be an Exception procedure for the protected organization. Jeff Neuman:@alan - you would not believe the pushback we get from GDD to release names where express consent via letters on letterhead are provided Cheryl Langdon-Orr (CLO):thx Mary Phil Buckingham 2:it seems unlikely we will start Reg Protections tonite / today . How many would be up for a call next Thursday 19 same time . Call s in namescon week are canx Alan Greenberg:@Rubens, there is nothing on the table that would prohibit thee Standards Organization from registering ISO, All that is being propossed is that the character strings go into the trademark clearinghose so that a flag would be raised when the name is registerd. Susan Payne - Valideus 2:fine by me phil Terri Agnew:At this time the next call is scheduled for: New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues will take place on Thursday, 02 February 2017 at 20:00 UTC. Phil Buckingham 2:thanks terry Phil Buckingham 2:terri Emily Barabas 2:The leadership sync is on Wed. The slot at 20:00 UTC on Thursday is free. Alan Greenberg:All options ar eok with me. Jeff Neuman:ouch Michael Flemming:That is actual joy Cheryl Langdon-Orr (CLO):my calender needs updating then Steve Chan:2000UTC on 19 February does precede the GNSO Council meeting however. Jeff Neuman:Thanks all! Christa Taylor:Thank-you Susan Payne - Valideus 2:thanks all Phil Buckingham 2:well done Michael

1 0

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 12 January
by Julie Hedlund Jan. 12, 2017

Jan. 12, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 12 January. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording. See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings. Please also see the attached slides referenced below. Excerpts from the chat room are included below for ease of reference. In addition, the discussion follows the Google doc at: https://docs.google.com/spreadsheets/d/1WgsYlUpKI_QGuIOlOxtu4uBBj8ZWgD0bTw8…. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 12 January Remaining Reserved Names and the Second Level [See slide 2] Geographic and geopolitical -- AGB did create reservations and currently the only authorization process that has been established is through the use of RCEP (Registry Service Evaluation Process). Probably not the most applicable process. -- GAC has taken the initiative of publishing a list of country and territory names -- around 16 or so names. -- Need to discuss whether we would suggest changes to policy. -- The ABG lists the reservations but the policy itself does not. Should we change policy to be consistent with the AGB? -- Any change to policy should be in line with the AGB and its lists of reservations. Also not the current GAC listing of names with country approval. Ensure that the list can be added to in a very easy way. Could recommend a PDP just on this aspect, but concern that this could become a significant roadblock. -- We are talking about the second level, not the top level. -- At a minimum we should agree whether we will stand by the 2009 policy recommendations or note that there is a gap between what happened with the AGB. Questions: 1) Need to confirm our agreement with the policy on geopolitical names (not geographic) -- the controversial names, and our understanding that going forward we will only deal with country and territory names and not say that any should be reserved. 2) If country and territory names are protected are we starting from the list in the AGB, which wasn't policy. If we stick to the list other negotiations between the governments and ICANN wouldn't apply. 3) Express whether the 2009 policy needs to be adjusted and make recommendations to the full PDP WG on what we should do with country and territory names. -- Suggestion: No need for restrictions for any TLD, but especially for BRAND TLDs -- harmonization with .com and .net. If we could make a clarification on that it would be beneficial. -- Probably a good issue for a smaller drafting team to consider. Need to handle it very carefully. -- Need to have participation from GAC on the Drafting Team. Can invite the GAC members on the list. Action Item: Send a call for volunteers for a Drafting Team on this topic. We can only issue a call to Sub Team members, but ensure that it is clear that GAC/ccNSO members on the Sub Team are encourage to join. >From the chat: Jeff Neuman: It should be noted that there were MANY discussions between the GAC and the Board on Geographic and geopolitical names between the 2009 recommendation and what was eventually put into the Guidebook. But NO policy development process was ever commenced to discuss those protections during that time period. Susan Payne - Valideus 2: we are dealing at 2nd level here though aren't we, or am I mistaken? whereas CWG-CTN is top level Michael Flemming: Second level Cheryl Langdon-Orr (CLO): yes understand it is 2nd level Cheryl Langdon-Orr (CLO): but the concerns I have heard raised reflect in Top andb2nd... Rubens Kuhl: Note that there are dissenting views regarding use of RSEP to release reserved names. ICANN is currently adopting such view, but some think it should be a different process, even in current policy guidance. Michael Flemming: I made a note on that Rubens, but you sum it up so sweetly. Cheryl Langdon-Orr (CLO): note in my time in suDA Board I fought to and succeeded to release Lower level names so I am not 'anti' Susan Payne - Valideus 2: OK, thanks Cheryl, understood. But in terms of what has been discussed in the CWG, we have only been talking about 2nd level Cheryl Langdon-Orr (CLO): understand that Susan. Even in our Work in the most recent CWG whose name itself is specified separation of the levels N in community understanding and and concerns has always been a 'challenge'. Cheryl Langdon-Orr (CLO): agree Jeff Rubens Kuhl: .com and .net are pretty old namespaces... new namespaces might require introductory measures, like sunrise. Legacy gTLDs are benchmarks, but a grain of salt in comparing is required. Kristina Rosette (Amazon Registry): Support creation of drafting team (which may not be smaller given interest), but agree on creating subteam Rubens Kuhl: One issue in allowing Brand TLDs is what happens if the TLD is repurposed to not be a Brand TLD, which is a registry operator option at anytime without consulting, just informing, ICANN. avri doria: i find having difrent such rules for different categories very problematic (again personal view) Mary Wong: For clarity (including for WT members not on the call), what is the specific focus and brief for the Drafting Team, and what will be its anticipated timeline to deliver its proposal? Susan Payne - Valideus 2: support drafting team too. I think it wouldmbe helpful for those who join to familiarise themselves with how we got from the policy to the AGB as not all of us are probably familiar with the full history. Kristina Rosette (Amazon Registry): We should make clear that GAC representatives are welcome to participate.. gTLD Reserved Names: -- Change policy or leave it as is? [reading policy from the chart] -- In 2001 when .biz, .info, etc. were signed we (Neustar others) were required to reserve .com.info, .biz.travel, etc. because of confusion, but agreed that there would be no confusion in the future so no reservations. -- Yes, we want to confirm the 2009 policy that says there should be no reservations. -- It's impossible to reserve because of the expanding list of TLDs. >From the chat: Rubens Kuhl: Looking at collision lists, some popular legacy TLDs (both gTLDs and ccTLDs) deserve a bit of care. While I also support confirming the 2009 policy, this is a factor that new gTLD operators should assess and hopefully make informed decisions. I don't see possibility of human confusion, but some name collisions can occur. Due to suffix appending. Cheryl Langdon-Orr (CLO): and name collision needs to be avoided Controversial Names: -- Current policy is that there should not be a category of Controversial Names that are reserved at 2nd and 3rd levels ASCII and IDN. -- There is no dispute policy mandated (and their isn't one). If we do want to confirm the 2009 policy we edit it and either remove the part about the dispute policy or stay that registries can determine the eligibility of their registrants in their own TLDs. -- Original thinking was that there could be a global dispute policy, but since the category was never created the dispute policy wasn't created. But a registry can make a rule to restrict controversial names in their registry. Registries already have that right. IOC and RCRC, and IGOs: -- No reservations originally, but later occurred and is included in the base registry agreement. -- Current active discussion between the Board and GAC on the reservation of country names (used within each country). -- Perhaps we shouldn't be looking at this while there are open discussions -- but could look at it if it hasn't been resolved elsewhere. -- For adopted policy it is just a few names. That list could change in the near future. There are other names that are on hold on a interim basis. -- Suggestion: Leave it be; don't revisit it. -- If reservations are in place we should state that there should be a mechanism for the release of those names to that specific organization. -- There is no mechanism for release of those names when the organization is consenting to their release. -- Allowing release to the right people is logical, but at the time they came out those people didn't care. >From the chat: Mary Wong: There is ongoing implementation of Board-adopted GNSO PDP recommendations regarding a few names for the Red Cross movement and names of IGOs. Jeff Neuman: I agree on this category and the IGOs. Mary Wong: Per Alan, other Red Cross names are still under discussion. Mary Wong: @Michael, to add - what I said (i.e. long list currently now reserved under Spec 5) also applies to IGOs. The only reserved protections approved so far for IGOs are their names. Their acronyms are now on the list only on an interim basis. Mary Wong: All, note that in the current implementation for Red Cross, IOC and IGOs - there will be an Exception procedure for the protected organization.

1 0

WT2 - Jan 12th, Thursday Meeting at 20:00 UTC
by Michael Flemming Jan. 12, 2017

Jan. 12, 2017

Dear All, Please note the agenda for the meeting this Thursdayt 20 UTC. 1. Welcome 2. Updated SOI 3. Remaining Reserved Names at the Second Level 4. Registrant Protections 5. AOB I will try to provide background material or at least a link to the excerpt to the Issue Report for the Registrant Protections tomorrow. We will likely be continuing the heart of our conversation over email because the number of meetings is restricted to the one this Thursday. Kind regards, Michael Flemming

2 1

Fwd: [Meeting Invite] New gTLD Subsequent Procedures Sub Team – Track 2
by Michael Flemming Jan. 10, 2017

Jan. 10, 2017

There seems to be a number of participants that did not receive the invitation for the meeting this Thursday. Therefore, I am forwarding this in the hopes that those who do not have this in their calendar may add it. Regards, Michael Flemming Dear All, The call for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues will take place on *Thursday, 12 January 2017 at 20:00 UTC.* 12:00 PST, 15:00 EST, 20:00 London, 21:00 CET For other times: http://tinyurl.com/hdpfxmb Adobe Connect room: https://participate.icann.org/newgtldsubteams/ You can connect your audio by following instructions in the pop up in the AC room, or use the Connect Me option below (also sent in the calendar invitation). Kind regards Michelle DeSmyter *You're Invited.* You've been invited to a GlobalMeet® phone only meeting. *Have the meeting call you.* Click the Connect Me link below. *No need to dial-in.* *Connect Me *[toolbar.conferencinghub.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__toolbar.conferencinghu…> *Not at your computer?* You can join by dialing one of the access numbers below. *Mobile:* tel://1-719-457-6209,*,,8650457825# <//1-719-457-6209,*,,8650457825> *Phone Only Controls:* https://toolbar.conferencinghub.com/pmc/pmc.aspx?conf= It9YhUoAI2rfs1zIA%2bAx3QmQT6tWBqeXWSFdqGVekIsztvtH9f% 2fwTmVoUoGQcXIjam6xqRJSb%2ft1Xa1F2iFDtJK8Rimw5MHjUZDWRcl3kja N7ZyZiz2RZ%2f8F4gxhagi8[toolbar.conferencinghub.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__toolbar.conferencinghu…> *Primary Access Number:* 1-719-457-6209 <(719)%20457-6209> *Guest Passcode:* 865 045 7825 *Additional Access:* USA 1-719-457-6209 <(719)%20457-6209> Canada, Calgary +1 403 407 5793 <(403)%20407-5793> Canada, Montreal +1 514 669 5928 <(514)%20669-5928> Canada, Toronto +1 647 426 9172 <(647)%20426-9172> Canada, Vancouver +1 604 222 7836 <(604)%20222-7836> Argentina (toll free) 0800 666 2649 Argentina (toll free) 0800 800 1223 Argentina, Buenos Aires +54 (0) 11 5172 6003 <+54%2011%205172-6003> Australia (toll free) 1 800 804 786 Australia, Brisbane +61 (0) 7 3015 0535 <+61%207%203015%200535> Australia, Melbourne +61 (0) 3 8687 0553 <+61%203%208687%200553> Australia, Sydney +61 (0) 2 8017 6064 <+61%202%208017%206064> Austria (toll free) 0800 8866 3413 Austria, Vienna +43 (0) 1 25302 1785 <+43%201%20253021785> Bahrain (toll free) 800 04212 Bahrain, Manama +973 1619 8739 <+973%201619%208739> Belarus (toll free) 8 820 0011 0341 Belgium (toll free) 0800 39279 Belgium, Brussels +32 (0) 2 400 6928 <+32%202%20400%2069%2028> Brazil (toll free) 0800 887 0233 Brazil, Rio de Janeiro +55 21 2730 6944 <+55%2021%202730-6944> Brazil, Rio de Janeiro +55 21 4560 0072 <+55%2021%204560-0072> Brazil, Sao Paulo +55 11 3351 7036 <+55%2011%203351-7036> Brazil, Sao Paulo +55 11 4935 7169 <+55%2011%204935-7169> Bulgaria (toll free) 00800 111 4950 Bulgaria, Sofia +359 (0) 2 491 6045 <+359%202%20491%206045> Canada (toll free) 1 855 950 3717 <(855)%20950-3717> Chile (toll free) 171 800 835 783 Chile (toll free) 800 363 514 Chile, Santiago +56 (0) 2 2666 0696 <+56%202%202666%200696> China (national) +400 613 8103 China, Beijing +86 10 5667 0003 <+86%2010%205667%200003> China, Shanghai +86 21 2039 7081 <+86%2021%202039%207081> Colombia (toll free) 01 800 518 0646 Colombia (toll free) 01 800 755 0102 Colombia, Bogota +57 1 508 8137 Croatia (toll free) 0800 805 940 Cyprus (toll free) 800 97424 Czech Republic (toll free) 800 701 532 Czech Republic, Prague +420 225 986 554 <+420%20225%20986%20554> Denmark (toll free) 80 70 35 86 Denmark, Copenhagen +45 32 72 78 10 <+45%2032%2072%2078%2010> Egypt (toll free) 0800 000 0593 Estonia (toll free) 800 011 1589 Estonia, Tallinn +372 622 6551 <+372%20622%206551> Fiji (toll free) 00800 3322 Finland (toll free) 0800 772 236 Finland, Helsinki +358 (0) 9 2310 1677 France (national) 0811 655 100 France (toll free) 0800 946 531 France, Paris +33 (0) 1 70 37 16 56 <+33%201%2070%2037%2016%2056> Germany (national) 01801 003 899 Germany (toll free) 0800 588 9170 Germany, Frankfurt +49 (0) 69 2222 10612 <+49%2069%20222210612> Germany, Munich +49 (0) 89 2030 31207 <+49%2089%20203031207> Greece (toll free) 00800 128 913 Greece, Athens +30 211 181 3824 <+30%2021%201181%203824> Hong Kong +852 3018 9111 <+852%203018%209111> Hong Kong (toll free) 800 901 787 Hungary (toll free) 068 001 9673 Hungary, Budapest +36 1408 8953 Iceland (toll free) 800 9847 India (toll free) 000 800 1008 367 India, Bangalore +91 (0) 80 6127 6710 <+91%2080%206127%206710> India, Chennai +91 (0)44 6688 6061 <+91%2044%206688%206061> India, Delhi +91 (0) 11 6641 1394 <+91%2011%206641%201394> India, Mumbai +91 (0)22 6187 5028 <+91%2022%206187%205028> Indonesia (toll free) 001 803 016 2541 Indonesia (toll free) 007 803 321 8927 Ireland (national) 1890 907 630 Ireland (toll free) 1800 937 649 Ireland, Dublin +353 (0) 1 526 9421 <+353%201%20526%209421> Israel (toll free) 1809 213 168 Israel, Tel Aviv +972 (0)3 721 7943 <+972%203-721-7943> Italy (toll free) 800 146 094 Italy, Milan +39 02 3600 8006 <+39%2002%203600%208006> Italy, Rome +39 06 8750 0676 <+39%2006%208750%200676> Japan (mobile) 0120 632 611 Japan (toll free) 0120 305 211 Japan, Chiba +81 (0) 43 321 6881 <+81%2043-321-6881> Japan, Fukuoka +81 (0) 92 290 6881 <+81%2092-290-6881> Japan, Hiroshima +81 (0) 82 558 6881 <+81%2082-558-6881> Japan, Nagoya +81 (0) 52 850 6881 <+81%2052-850-6881> Japan, Osaka +81 (0) 6 4560 2410 <+81%206-4560-2410> Japan, Sapporo +81 (0) 11 234 6881 <+81%2011-234-6881> Japan, Sendai +81 (0) 22 708 6881 <+81%2022-708-6881> Japan, Shizuoka +81 (0) 54 902 6881 <+81%2054-902-6881> Japan, Tachikawa +81 (0) 42 841 6881 <+81%2042-841-6881> Japan, Tokyo +81 (0) 3 4560 1270 <+81%203-4560-1270> Japan, Toyama +81 (0) 76 408 6881 <+81%2076-408-6881> Japan, Urawa +81 (0) 48 698 6881 <+81%2048-698-6881> Japan, Yokohama +81 (0) 45 677 6881 <+81%2045-677-6881> Kazakhstan (toll free) 8800 333 7554 Latvia (toll free) 8000 4418 Latvia, Riga +371 6601 3627 Lithuania (toll free) 8800 31449 Lithuania, Vilnius +370 5205 5468 Luxembourg +352 2088 1749 <+352%2020%2088%2017%2049> Luxembourg (toll free) 800 28433 Malaysia (toll free) 1 800 816 152 Malaysia,Kuala Lumpur +60 (0) 3 7724 8010 <+60%203-7724%208010> Mexico (toll free) 01 800 054 0370 Mexico (toll free) 01 800 733 4102 Mexico, Guadalajara +52 33 4162 4504 <+52%2033%204162%204504> Mexico, Mexico City +52 55 4777 2658 <+52%2055%204777%202658> Mexico, Mexico City +52 55 8421 0326 <+52%2055%208421%200326> Mexico, Monterrey +52 81 4162 5648 <+52%2081%204162%205648> Morocco (toll free) 0800 091 296 Morocco, Casablanca +212 (0) 520 48 0022 Netherlands (toll free) 0800 020 2597 Netherlands, Amsterdam +31 (0) 20 716 8345 <+31%2020%20716%208345> New Zealand (toll free) 0800 452 947 New Zealand, Auckland +64 (0) 9 929 1825 <+64%209-929%201825> New Zealand, Christchurch +64 (0) 3 974 2596 <+64%203-974%202596> New Zealand, Wellington +64 (0) 4 909 4674 <+64%204-909%204674> Nigeria, Lagos +234 1 277 3944 <+234%201%20277%203944> Norway (toll free) 800 56081 Norway, Oslo +47 21 00 48 15 <+47%2021%2000%2048%2015> Panama (toll free) 00 800 226 3770 Panama (toll free) 00800 223 1390 Panama, Panama City +507 8 335 913 Peru (toll free) 0800 55 092 Peru (toll free) 0800 78102 Peru, Lima +51 (0) 1 700 9571 Philippines (toll free) 1 800 111 013 99 Philippines, Manila +63 (0)2 395 3426 <+63%202%20395%203426> Poland (toll free) 00 800 121 4356 Poland, Warsaw +48 22 295 3570 <+48%2022%20295%2035%2070> Portugal (toll free) 800 784 442 Portugal, Lisbon +351 21 316 4093 <+351%2021%20316%204093> Qatar (toll free) 00 800 100 491 Romania (toll free) 0800 801 035 Romania, Bucharest +40 (0) 21 529 3992 <+40%2021%20529%203992> Russia (toll free) 8 800 500 9241 Russia, Moscow +7 495 646 9181 <+7%20495%20646-91-81> Saudi Arabia (toll free) 800 844 6641 <(800)%20844-6641> Saudi Arabia (toll free) 800 850 0219 <(800)%20850-0219> Singapore +65 6622 1957 <+65%206622%201957> Singapore (toll free) 800 616 3192 <(800)%20616-3192> Slovakia (toll free) 0800 002 002 Slovakia, Bratislava +421 (0)2 3321 5498 Slovenia (toll free) 0800 81193 Slovenia, Ljubljana +386 1600 8695 South Africa (toll free) 0800 999 434 South Africa, Johannesburg +27 (0)11 589 8321 <+27%2011%20589%208321> South Korea (toll free) 00798 6136 1454 South Korea, Seoul +82 (0) 2 6007 0079 <+82%202-6007-0079> Spain (toll free) 900 828 035 Spain, Barcelona +34 93 800 1946 <+34%20938%2000%2019%2046> Spain, Madrid +34 91 114 6653 <+34%20911%2014%2066%2053> Sweden (toll free) 0200 125 588 Sweden, Stockholm +46 (0) 8 5065 3956 Switzerland (toll free) 0800 740 360 Switzerland, Geneva +41 (0) 22 595 4795 <+41%2022%20595%2047%2095> Switzerland, Zurich +41 (0) 44 580 7207 <+41%2044%20580%2072%2007> Taiwan (toll free) 0800 666 596 Taiwan, Taipei +886 (0) 2 2650 7329 <+886%202%202650%207329> Thailand (toll free) 001 800 6136 1473 Turkey (toll free) 00800 4488 26642 Turkey, Istanbul +90 212 375 50 49 <+90%20212%20375%2050%2049> UAE (toll free) 8000 3570 2662 UK (03) +44 (0)330 336 6002 <+44%20330%20336%206002> UK (national) 0844 581 8062 UK (national) 0845 351 2782 UK (toll free) 0800 358 6385 Ukraine (toll free) 0800 500 896 Uruguay (toll free) 0004 019 0152 USA /Canada (toll free) 1-866-398-2885 <(866)%20398-2885> Venezuela (toll free) 0 800 162 7451 Vietnam (toll free) 1800 9226

2 1