- Gnso-newgtld-wg-wt2 - lists.icann.org

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

Feb. 16, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team - Track 2 - Legal/Regulatory Issues held on Thursday, 16 February 2017 at 21:00 UTC. Adobe Connect recording (audio and visual): <https://participate.icann.org/p3tw0auf0j4/?OWASP_CSRFTOKEN=35164ca55b0b4325 1de3126b2595278b4418e8a455ee85906e150b73fd5ffb72> https://participate.icann.org/p3tw0auf0j4/ The recordings of the calls are posted on the GNSO Master Calendar page: <http://gnso.icann.org/en/group-activities/calendar> 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> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Agenda Wiki page: <https://community.icann.org/x/qbPDAw> https://community.icann.org/x/qbPDAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 16 February 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team - Track 2 - Legal/Regulatory Issues on Thursday, 16 February 2017 at 21:00 UTC Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_q bPDAw <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ qbPDAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpC IgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_0 0&s=CbEFokLhGUykcmR11WlYaAcuXXmYo203oOQPftznlqA&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=Cb EFokLhGUykcmR11WlYaAcuXXmYo203oOQPftznlqA&e= Steve Chan:I'll work on that... Steve Chan:@Michael, all set to be able to display Module 6 Steve Chan:Available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_a pplicants_agb_terms-2D04jun12-2Den.pdf <https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_ applicants_agb_terms-2D04jun12-2Den.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfk bPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZ C0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=RgHTmU8ApAMiQEQnwHAvomYTRrlhRZOf8-vQEQ7 yDAs&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=Rg HTmU8ApAMiQEQnwHAvomYTRrlhRZOf8-vQEQ7yDAs&e= Jeff Neuman:If I remember correctly, ICANN displayed this and required express agreement with these when submitting an application Steve Chan:@Jeff, if I recall, it was built into TAS. Jeff Neuman:Right. So before you ould hit "Submit", you had to agree to the Ts and Cs. Rubens Kuhl:So an applicant can challenge a decision in court before it's final ? ;-) Jon Nevett:on 14, should be material hardship to applicant Rubens Kuhl:"May not assign applicant rights" is an interesting reading considering .web and .blog. Mike Rodenbaugh:typo in 14 near end, should be "hardship to Applicant"? Rubens Kuhl:Mike, Michael mentioned it. You and Jon are on point. Jon Nevett:Last sentence is ok Rubens Kuhl:"Any fees submitted" implies some sort of 100% refund. Did it happen ? Susan Payne:@rubens I don't think so Mike Rodenbaugh:First two sentences, if taken literally, makes the entire contract illusory... ICANN has no obligation unless it chooses. Jon Nevett:I don't often say this, but Alan +1!! Mike Rodenbaugh:+1 Alan. More than unusual... illusory, unfair. Rubens Kuhl:But if we specify it, it might generate a situation where something arises that justifies not approving, but was not foreseen. Mike Rodenbaugh:ICANN has relied on this language (though from Module 3) in IRP proceedings against my client Alan Greenberg:Ah com'on Jon, we have agreed on occasional things in the past. Jon Nevett:absolutely -- just kidding! Jeff Neuman:How so Mike? Mike Rodenbaugh:"Unfettered discretion" destroys the whole point of the Guidebook, which was to take that discretion away from the Board (after the .XXX debacle) Alan Greenberg:Admittedly less often nowadays... Cheryl Langdon-Orr (CLO):different circumstances exist in future 'rounds' Ifrom the one that this part of the module covers for the earlier one Jeff Neuman:this is not based on policy recommendations Mike Rodenbaugh:@Jeff they have relied on Sec. 5.1 (not Module 3) in Islam/halal matter Mike Rodenbaugh:see their latest brief, p.20 Susan Payne:Name collision? home etc? Rubens Kuhl:There is also GAC Advice, which is also a different module. Jim Prendergast:wonder where mail, corp and home fit in. Jeff Neuman:Agree with Susan that if there were a challenge by .home and .corp, this clause would be invoked Susan Payne:also what about any closed generics who have not agreed to open up? Steve Chan:For context it might useful to review the T&Cs from the very first Applicant Guidebook in 2008. The language is not dramatically different: https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.icann.org_en_top ics_new-2Dgtlds_terms-2D24oct08-2Den.pdf <https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.icann.org_en_to pics_new-2Dgtlds_terms-2D24oct08-2Den.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzg fkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ul WZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=0_BXkKKozVxdQf8RUi1aNP1e7SFK3xeuISXcq xEPWSk&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=0_ BXkKKozVxdQf8RUi1aNP1e7SFK3xeuISXcqxEPWSk&e= Jeff Neuman:@Susan, that is more clause 14 Rubens Kuhl:Covenant not to sue should actually be strengthned instead of removed. Steve Chan:And there was a Board resolution from Trondheim in 2010 that relates to this subject. Steve Chan:"The Board approves the inclusion of a broad waiver and limitation of liability in the application terms and conditions." - https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources _board-2Dmaterial_minutes-2D2010-2D09-2D25-2Den <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource s_board-2Dmaterial_minutes-2D2010-2D09-2D25-2Den&d=DwIFaQ&c=FmY1u3PJp6wrcrwl l3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m= WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=i3clxGkQDeJfsUxKHvWAHLqNRp90GU rRLmUAwo9AqgI&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=i3 clxGkQDeJfsUxKHvWAHLqNRp90GUrRLmUAwo9AqgI&e= Mike Rodenbaugh:@Jim I believe .home etc. are also in this netherworld of 'unfettered Board discretion' Mike Rodenbaugh:@Rubens I think I disagree strongly Susan Payne:@Jeff, sort of. that accounts for the changed position, but if the applicant has refused to open up they cannot proceed Jon Nevett:if ICANN had a fair dispute process, then I wouldn't disagree with Rubens as much Rubens Kuhl:@Mike, I understand why an US lawyer would prefer, so I think you might get why non-US applicants are not fond of it. Mike Rodenbaugh:please explain Rubens Kuhl:Home court advantage, using another meaning of the world "court". Mike Rodenbaugh:sorry but I don't understand. the covenant applies in any court. Rubens Kuhl:Jon, that's what WS2 is all about, I believe... and what WS2 fails to deliver, to possible activations of the Empowered Community. Jon Nevett:more than that Rubens Mike Rodenbaugh:It makes ICANN entirely unaccountable Rubens Kuhl:Which created a problem because then current accountability mechanisms only allowed procedural grounds. Alexander Schubert 2:we might add that speculator can't sue for private auction revenues either! Rubens Kuhl:And there might be substantive, not procedural issues, that might need to be challenged. Alexander Schubert 2:Rather applicant speculators can't sue ICANN for loss of private auction proceeds...... Trang Nguyen:@Mike: under the new Bylaws, IRP decisions are binding and enforceable in any court with proper jurisdiction (4.3.a.viii) Mike Rodenbaugh:resources are not an issue for ICANN wrt defending its actions in the New TLD Program. 1/3 of application fees setaside for that purpose... at least a hundred million dollars Rubens Kuhl:Fraud, neglience and grossful misconduct are likely already exclued by California law anyways... but mentioning it in writing is a good thing. Cheryl Langdon-Orr (CLO):exactly Jeff.., yes Trangie, thx for pointing that out Kevin Kreuser:I like Trangie - let's make that stick Mike Rodenbaugh:@Trang that refers to the procedure, not to the permissible content of such a decision... Susan Payne:agree Jon Mike Rodenbaugh:ICANN still argues that an IRP panel can't recommend any affirmative relief, but can only decide whether the Board violated Bylaws... Rubens Kuhl:Perhaps binding 3rd parties to ICANN Bylaws for those willing to become contractors to the program ? Rubens Kuhl:@Mike, most IRP panels disregarded that affirmative relief can't be awarded. But I believe one or two bought into JD standard argument to that. Mike Rodenbaugh:@Susan I think it's about half and half... Trang Nguyen:Ultimately, that's why the community asked the Board removal right, as the ultimate path of recourse. Mike Rodenbaugh:that is ridiculous Trang Nguyen:*for the Board.... Rubens Kuhl:@Trang the board removal is too much of a nuclear option to be considered in dealing with one single decision. The community might do that for a consistent pattern of misconduct. Trang Nguyen:The bylaws do provide for other paths...reconsideration, community IRP, the EC can take ICANN to court...these are the actions available to the EC under the new Bylaws. Jon Nevett:so they could double the application fee after receiving applications and not provide a refund? Jeff Neuman:Policy Statement: ICANN must strengthen its appeals mechanisms to include the ability for applicants to challenge the decisions of the ICANN staff, the ICANN Board, and/or any entities delegated decision making authority over the assignment, contracting and delegation of new gTLDs. Such appeals meachnism must include the ability to review those decisions on the merits and not only with respect to whether ICANN violated the Bylaws . Only with such an appeals process performed by an independent entity could ICANN then include a covenant not to sue in the Applicant Terms and Conditions. Rubens Kuhl:@Trang: is reconsideration still limited to procedural issues ? Jon Nevett:i don't think that recon is limited to procedural issues Trang Nguyen:@Rubens, the scope of the reconsideration process under the new bylaws has been expanded. Mike Rodenbaugh:yet remains untested Steve Chan:All, re: the drafting team Jeff is describing right now, there is only one volunteer at the moment. Trang Nguyen:...to include actions/inactions that contradict ICANN's Mission, Commitments, Core Values and/or established ICANN policy Rubens Kuhl:@Mike, all AGB changes will be definition be untested until the next procedure. Steve Chan:https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_do cument_d_1g-2DOoBec-5FQ6nnBofBvcTnfAotFh7yq07HUM7kxh62SYo_edit-23&d=DwIFaQ&c =FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa 0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=kFy_jxgaIgS7o YJ-XuKGAo_CoqsORcstDGWIqMU2sQY&e= Rubens Kuhl:(by definition) Jeff Neuman:I will also review again as a proofreading exercise Rubens Kuhl:@Trang, so the only difference from what Jeff suggested is Board Governance Commitee x Independent 3rd party making a call. Jon Nevett:could we table that? Jeff Neuman:I think the rest of the Ts and Cs are mostly legal boilerplate Jon Nevett:i'd like to take a closer look Mike Rodenbaugh:me too Jim Prendergast:and give people not on call chance to respond Jeff Neuman:of course....we are not making final decisions here....just trying to have a discussion and trying to elicit known issues now Trang Nguyen:@Jeff, could you please clarify the reference to "strengthen its appeals mechanisms" in your proposed policy language? Mike Rodenbaugh:Indemnity deserves a closer look, at least should be consistent with narrower release of claims and covenant not to sue Jeff Neuman:@Trang, I am talking about appeals of decisions under the guidebook...NOT accountability mechanisms Rubens Kuhl:@Jeff, in the part where there is a covenant not to sue, we could suggest reinforcing it so it really stands if/when someone actually files a lawsuit. Trang Nguyen:Got it....thanks, Jeff! Jeff Neuman:SO I can reword that part Mike Rodenbaugh:Sec. 10 obviously needs some clarification Jon Nevett:what if ICANN breaches the terms of the AGB? Jon Nevett:what if ICANN deliberately reveals applicants proprietary financial information? Jon Nevett:or negligently? Jeff Neuman:Revised Statement: ICANN must build into the new gTLD Program appeals mechanisms to include the ability for applicants to challenge the decisions of the ICANN staff, the ICANN Board, and/or any entities delegated decision making authority over the assignment, contracting and delegation of new gTLDs. Such appeals mechanism must include the ability to review those decisions on the merits and not only with respect to whether ICANN violated the Bylaws . Only with such an appeals process performed by an independent entity could ICANN then include a covenant not to sue in the Applicant Terms and Conditions. However, the covenant not to sue shall not apply to cases alleging fraud, negligence or misconduct. Rubens Kuhl:"Applicant may not assign applicant rights" could even be read as preventing applicants from getting some types of risk capital. Mike Rodenbaugh:More thinking needs to happen about the CNTS Jon Nevett:Section 10 was a big part of the .web issue Mike Rodenbaugh:'negligence' and 'misconduct' are really vague Jeff Neuman:I had originally gross negligence and wilful misconduct but Jon said that was too narrow Mike Rodenbaugh:I agree with Jon, but 'misconduct' can mean literally anything Susan Payne:no Rubens Kuhl:Doesn't that limit ICANN's options on legal firms ? Jeff Neuman:ok.....I will revise the statement again...stay tuned Jon Nevett:if ICANN is negligent in doing the evaluation, shouldn't there be some recourse? Rubens Kuhl:(Sec. 13) Susan Payne:@Rubens I don't think it does, it just means you cannot prevent them using JD by citing conflict Rubens Kuhl:Ok, then it's not a problem. Steve Chan:As a reminder, the language on screen is in summary. Mike Rodenbaugh:@Jon, it is pretty easy to allege negligence as to just about any action or inaction whatsoever Jeff Neuman:Further Revised: Revised Statement: ICANN must build into the new gTLD Program appeals mechanisms to include the ability for applicants to challenge the decisions of the ICANN staff, the ICANN Board, and/or any entities delegated decision making authority over the assignment, contracting and delegation of new gTLDs. Such appeals mechanism must include the ability to review those decisions on the merits and not only with respect to whether ICANN violated the Bylaws . Only with such an appeals process performed by an independent entity could ICANN then include a covenant not to sue in the Applicant Terms and Conditions. However, the covenant not to sue shall not apply to cases alleging fraud, negligence or wilful misconduct. Steve Chan:Here again is the link to the complete language: https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_a pplicants_agb_terms-2D04jun12-2Den.pdf <https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_en_ applicants_agb_terms-2D04jun12-2Den.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfk bPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZ C0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=RgHTmU8ApAMiQEQnwHAvomYTRrlhRZOf8-vQEQ7 yDAs&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=WM0d8ulWZC0TuPqSgB7jchPcrOgKmMQ-EY5HEGe4_00&s=Rg HTmU8ApAMiQEQnwHAvomYTRrlhRZOf8-vQEQ7yDAs&e= Jeff Neuman:Everyone please go to the CC2 Questions ASAP Rubens Kuhl:Jeff, on fraud/negligence, perhaps California law could be the basis for the phrase ? Jeff Neuman:and look at them to ake sure we have asked everything you wanted it to ask Jeff Neuman:@Rubens........Under California law, technically you can waive those rights...that is why i included them herer Steve Chan:@Michael, I think I'd prefer to send a reminder to the full WG, along with some explanation of timeline. Hope you don't mind? Terri Agnew:next call: New gTLD Subsequent Procedures Sub Team - Track 2 - Legal/Regulatory Issues will take place on Thursday, 02 March 2017 at 21:00 UTC for 60 minutes. Jeff Neuman:Agree this is a good stopping point. PLEASE Review the notes and let us know any other issues! Jeff Neuman:This was a great call. Lets not lose momentum Robert Burlingame:Thank you. Good discussions today. Jon Nevett:thanks all! Cheryl Langdon-Orr (CLO):good progress today... thanks all, bye for now Jeff Neuman:Thanks Michael. Susan Payne:thanks all Rubens Kuhl:Thanks all, bye!

1 0

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 16 February
by Julie Hedlund Feb. 16, 2017

Feb. 16, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 16 February. 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 16 February Agenda: 1. Welcome 2. SOI 3. Terms and Conditions 4. CC2 Questions 5. AOB Notes: 1. Terms and Conditions (slide 4) -- Part of the ABG -- module 6: https://newgtlds.icann.org/en/applicants/agb/terms-04jun12-en.pdf. -- Binding document. Background Information (Slides 5 and 6) >From the chat: Jeff Neuman: If I remember correctly, ICANN displayed this and required express agreement with these when submitting an application Steve Chan: @Jeff, if I recall, it was built into TAS. Jeff Neuman: Right. So before you ould hit "Submit", you had to agree to the Ts and Cs. Rubens Kuhl: So an applicant can challenge a decision in court before it's final ? ;-) Jon Nevett: on 14, should be material hardship to applicant. Mike Rodenbaugh: typo in 14 near end, should be "hardship to Applicant"? Mike Rodenbaugh: First two sentences, if taken literally, makes the entire contract illusory... ICANN has no obligation unless it chooses. Jon Nevett: I don't often say this, but Alan +1!! Rubens Kuhl: "May not assign applicant rights" is an interesting reading considering .web and .blog. Jon Nevett: Last sentence is ok. Rubens Kuhl: "Any fees submitted" implies some sort of 100% refund. Did it happen ? Susan Payne: @rubens I don't think so. Discussion Point 1 (slide 7) -- In regards to section 3 on ICANN reserving the right to determining not to proceed with any and all applications for new gTLDs. (See Section 3 of Module 6) -- Can see a rationale for ICANN having a right to reject anything. What seems to be the right to unilaterally reject a single application without a mention of why they can do that does sound unusual. -- Recommend that ICANN has some disgression within the confines of the policy and applicant guidebook. Shouldn't be as unfettered as it is now. It there is predictability there is no need for this. -- Relates to Work Track 3 as well on objections. -- Question: Does any GNSO policy provide recommendations that came out in the T&Cs? Answer: No. -- How they used this language -- makes them unaccountable whether the applicant has succeeded or not. -- Need a recommendation to ICANN that it needs to be accountable to decisions that they make within the scope of the AGB. >From the chat: Mike Rodenbaugh: First two sentences, if taken literally, makes the entire contract illusory... ICANN has no obligation unless it chooses. Jon Nevett: I don't often say this, but Alan +1!! Mike Rodenbaugh: +1 Alan. More than unusual... illusory, unfair. Rubens Kuhl: But if we specify it, it might generate a situation where something arises that justifies not approving, but was not foreseen. Mike Rodenbaugh: ICANN has relied on this language (though from Module 3) in IRP proceedings against my client. "Unfettered discretion" destroys the whole point of the Guidebook, which was to take that discretion away from the Board (after the .XXX debacle) Alan Greenberg: Admittedly less often nowadays... Cheryl Langdon-Orr (CLO): different circumstances exist in future 'rounds' Ifrom the one that this part of the module covers for the earlier one. Jim Prendergast: wonder where mail, corp and home fit in. Jeff Neuman: Agree with Susan that if there were a challenge by .home and .corp, this clause would be invoked Susan Payne: also what about any closed generics who have not agreed to open up? Steve Chan: For context it might useful to review the T&Cs from the very first Applicant Guidebook in 2008. The language is not dramatically different: http://archive.icann.org/en/topics/new-gtlds/terms-24oct08-en.pdf. And there was a Board resolution from Trondheim in 2010 that relates to this subject: "The Board approves the inclusion of a broad waiver and limitation of liability in the application terms and conditions." - https://www.icann.org/resources/board-material/minutes-2010-09-25-en. Discussion Point 2 -- Section 6: "Covenant not to sue ICANN" (Slide 8) -- This makes ICANN entirely unaccountable. -- In general, there is a strong need for a convenant excluding fraud and gross negligance. Previous case practically bankrupted ICANN. Include the ability to enforce an IRP/appeals mechanism. Also need to include an appeals mechanism (Work Track 3). -- ICANN needs to be more accountable to the applicants, but with a strong appeals mechanism then a covenant may not be so bad. -- Being negligent is not a violation of ICANN Bylaws. -- Need to be borders of what ICANN is, and is not, responsible for. -- Discuss policy recommendation language over email. >From the chat: Rubens Kuhl: @Mike, I understand why an US lawyer would prefer, so I think you might get why non-US applicants are not fond of it. Mike Rodenbaugh: please explain Rubens Kuhl: Home court advantage, using another meaning of the world "court". Mike Rodenbaugh: sorry but I don't understand. the covenant applies in any court. Rubens Kuhl: Jon, that's what WS2 is all about, I believe... and what WS2 fails to deliver, to possible activations of the Empowered Community. Jon Nevett: more than that Rubens Mike Rodenbaugh: It makes ICANN entirely unaccountable Trang Nguyen: @Mike: under the new Bylaws, IRP decisions are binding and enforceable in any court with proper jurisdiction (4.3.a.viii). Mike Rodenbaugh: @Trang that refers to the procedure, not to the permissible content of such a decision...ICANN still argues that an IRP panel can't recommend any affirmative relief, but can only decide whether the Board violated Bylaws... Rubens Kuhl: Fraud, neglience and grossful misconduct are likely already exclued by California law anyways... but mentioning it in writing is a good thing. Rubens Kuhl: Perhaps binding 3rd parties to ICANN Bylaws for those willing to become contractors to the program ? @Mike, most IRP panels disregarded that affirmative relief can't be awarded. But I believe one or two bought into JD standard argument to that. Jeff Neuman: Further Revised: ICANN must build into the new gTLD Program appeals mechanisms to include the ability for applicants to challenge the decisions of the ICANN staff, the ICANN Board, and/or any entities delegated decision making authority over the assignment, contracting and delegation of new gTLDs. Such appeals mechanism must include the ability to review those decisions on the merits and not only with respect to whether ICANN violated the Bylaws. Only with such an appeals process performed by an independent entity could ICANN then include a covenant not to sue in the Applicant Terms and Conditions. However, the covenant not to sue shall not apply to cases alleging fraud, negligence or wilful misconduct. Discussion Point 3 -- Section 14: In regards to section 14 that ICANN reserves the right to make reasonable updates and changes to the applicant guidebook and the application process (slide 9) -- The problem with this one, which was hard to explain, you are expecting them (applicants) to put a lot of resources behind it and expecting them to be bound by provisions that you don't know what they are. If the rules changed and the applicant withdrew they are not recompensed. -- One of the things we are working on in the overall issues is a mechanism for better predictability and a better change process. Then this section would be subject to that change process. Other Sections to Review: -- Section 5 -- Up for consideration (slide 5) -- Section 10 -- (slide 6) -- warrants looking at. Issue of applicant assigning rights hasn't been honored. 2. CC2 Questions -- Staff will circulate the link to the full WG. -- Some of our most important work to get as much feedback as possible.

1 0

Agenda for 16 February 2017, 21:00 UTC WT2 Meeting
by Michael Flemming Feb. 16, 2017

Feb. 16, 2017

Dear All, I hope February is going well for everyone. I am submitting the agenda for the 16 February WT2 meeting at 21:00 UTC. Just so everyone knows, from this week we will begin using the 21 UTC rather than the previous 20 UTC slot. We will try to make adjustments when this conflicts with other high interest meetings. >From this week we will begin looking at the Terms and Conditions (Module 6) of the Applicant Guidebook. The aim is to limit meeting time per this subject to this one meeting and continue any additional discussion through the mailing list. We will also be looking at CC2 questions, as well. Below is the agenda for the meeting. 1. Welcome 2. SOI 3. Terms and Conditions 4. CC2 Questions 5. AOB Please note the slides we will use in the meeting are attached. For further background material, please review Module 6 of the Applicant Guidebook. This can be found on the ICANN New gTLD microsite or in the link below. https://newgtlds.icann.org/en/applicants/agb/terms-04jun12-en.pdf I look forward to speaking with everyone during the meeting. Kind regards, Michael Flemming

2 1

Relative article in regards to Terms and Conditions of Applicant Guidebook
by Michael Flemming Feb. 15, 2017

Feb. 15, 2017

Dear All, Prior to our call this Thursday to discuss the T&Cs (Module 6) of AGB, there was a suggestion to share this article in regards to the most recent episode of the .africa court case. The previous ruling that stated the "covenant not to sue" was unenforceable, has now been overturned in the latest ruling on the case. As such, by this ruling, the covenant is now enforceable. http://domainincite.com/21529-africa-to-finally-go-live-after-judge-denies-… My own understanding and interpretation of this is as it resonates in the article, the covenant not to sue ICANN is enforceable. However, I would very much like to hear back from our participants with a more legal background on this. I don't think this is case closed for us on the T&Cs, but perhaps will provide for better discussion material this Thursday. Any thoughts? Regards, Michael Flemming

5 4

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

Feb. 2, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team - Track 2 - Legal/Regulatory Issues held on Thursday, 02 February 2017 at 20:00 UTC. Adobe Connect recording (audio and visual): <https://participate.icann.org/p8dnk5nag5m/?OWASP_CSRFTOKEN=3301ff0f1fff3dfc 78bdba634380b2dc21423ab6ed922f1b623118fc8ae11f01> https://participate.icann.org/p8dnk5nag5m/ 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> http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Agenda Wiki page: https://community.icann.org/x/prPDAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 02 February 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team - Track 2 - Legal/Regulatory Issues call on Thursday, 02 February 2017 at 20:00 UTC. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_p rPDAw <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_ prPDAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpC IgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=T6p4UvBXSCVwUHKVMQH4VeG2AKTS_nazmTXmhKIxnS o&s=hjDsSi7w-Zdrpb43IhiqlwJnuRG0L5nQtNJvuXuds2s&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=T6p4UvBXSCVwUHKVMQH4VeG2AKTS_nazmTXmhKIxnSo&s=hj DsSi7w-Zdrpb43IhiqlwJnuRG0L5nQtNJvuXuds2s&e= Phil Buckingham:can u call me again . I ve lost you . Terri Agnew:@Michael, I have been unable to dial out to you on the telephone number you provided alexander.gay:Looks like neither the CIA nor the Kurdish PKK could apply...... Gg Levine (NABP):Says nothing about how registry is to be run. Mary Wong:Hi! Mary Wong:Here's Paul Paul McGrady:Sorry to join late Jeff Neuman:Paul: Did you file a reconsideration request or any other type of appeal? Phil Buckingham:Good point , Heather .. I ll follow up with the GDD Steve Chan:Note, there is a section of the Program Implemenation Review Report (PIRR) that touches on Background Screening (section 2.2): https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system _files_files_program-2Dreview-2D29jan16-2Den.pdf <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste m_files_files_program-2Dreview-2D29jan16-2Den.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrw ll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m =T6p4UvBXSCVwUHKVMQH4VeG2AKTS_nazmTXmhKIxnSo&s=xerXvz68yRfQ2Jhnilcv181Ae5D7h s2ZZvP0Tr3tid4&e> &d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXh FzL7ar9Qfqa0AIgn-H4xR2EBk&m=T6p4UvBXSCVwUHKVMQH4VeG2AKTS_nazmTXmhKIxnSo&s=xe rXvz68yRfQ2Jhnilcv181Ae5D7hs2ZZvP0Tr3tid4&e= Susan Payne:can we have ability to scroll the slides? Susan Payne:thnx Terri Agnew:everyone can scroll slides themselves Steve Chan:@Michael, we will take the question back to GDD. Phil Buckingham:So it has only to be one "director " who is disqualified that means the whole application is thrown out ? Jeff Neuman:Have there been any cases where ICANN required a change request to cure any deficiencies in the background checks Christa Taylor:I think the business model around a TLD is completely seperate from background screening Steve Chan:The nature of the applying entity may play a role, however, Jeff Neuman:There were llots of ways to get around the cybersquatting background check. UDRPs are generally against entities, not the people who are principals in that entity. Thus, if an individual is a principal in a company that was subject to 10 cybersquatting cases, that individual would not faill the background check if he or she were part of a new gTLD application. Jeff Neuman:not just worked for it, but was an owner of it or other principal Phil Buckingham:when we are talking about criminal history - does that even include a driving ban . Needs to be defined more clearly.next time . Steve Coates:What is criminal in one place may not be in another. Cheryl Langdon-Orr (CLO):agree Jeff Cheryl Langdon-Orr (CLO):it's the eastern Australian whip bird Michael Robert Burlingame (Pillsbury):Agree Jeff re not just protection for registrants Steve Coates:Have to drop off. Apologies. Paul McGrady 2:I can't. sorry Cheryl Langdon-Orr (CLO):finish what we can Susan Payne:do we get to do a CC3 at some point for further topics? avri doria:hope not Susan Payne:ok, so we definitely need to ask about closed generics then Jeff Neuman:@susan - yes. And if you review the questions and have additional ones, please submit them :) Terri Agnew:The next two WT2 calls will take place on: New gTLD Subsequent Procedures Sub Team - Track 2 - Legal/Regulatory Issues will take place on Thursday, 16 February 2017 at 21:00 UTC AND Thursday, 02 March 2017 at 21:00 UTC for 60 minutes. Both email/ calendar invites will be sent today for place holder. We will also send reminder email day before each call. Susan Payne:when is CC2 due to go out? Paul McGrady 2:So sorry all. I have to drop. Christa Taylor:Sorry I'm out of time. Also need to drop. Have a great day everyone. Cheryl Langdon-Orr (CLO):bye Robert Burlingame (Pillsbury):Thank you everyone. Jeff Neuman:Thanks everyone :) Susan Payne:thanks all Cheryl Langdon-Orr (CLO):thanks all bye for now alexander.gay:Bye! avri doria:bye

1 0

Actions/Discussion Notes: Work Track 2 SubTeam Meeting 02 February
by Julie Hedlund Feb. 2, 2017

Feb. 2, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 02 February. 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 02 February 1. Registrant Protections -- Background Screening Background Information: See slides 4-9. Question: Are the background checks a sufficient mechanism for protecting registrants? Yes/No/Other (slide 10) -- Paul McGrady had a specific issue he wanted to discuss relating to cybersquatting -- item (m) on slide 8. If you look at the public comments he had questions about the background screening that in his view was not applied. Not sure if there was a formal dispute, but we should look at the comments that there made and whether we would need some clarification in this language. Short answer is we don't know if the background checks were sufficient because ICANN didn't follow the AGB. If ICANN isn't going to follow the vetting process no amount of improvements will help. Did not file a reconsideration request. -- Interested to know if Paul's case is the only instance of this type of difficulty. Can we get those data? -- The amount of information that ICANN requested created a stressful process, but not aware of any specific examples. Could ask for as much data as possible. >From the chat: Phil Buckingham: Good point , Heather .. I ll follow up with the GDD Steve Chan: Note, there is a section of the Program Implementation Review Report (PIRR) that touches on Background Screening (section 2.2): https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf Question: Has ICANN ever come across an applicant with an individual found to be involved in any of the activities in a-m? If so, were any of those applicants disqualified from the application process because of the background screening? If so, out of how many found, how many were disqualified. (slide 11) Action Item: Ask ICANN for data on the results of the background checks. Staff will take the question back to GDD. -- Good question to ask ICANN staff in the aggregate without getting any identifying information. Might not get any responses from the question in the community. -- Believe the answer is zero because ICANN presented stats throughout the process on the status. Think that is public. -- Change the question? Ask how many applicants were required to provide additional information with regard to these background checks. -- Is what we are driving at here is how seriously ICANN took the answer of "no". Are we worried about the fact that everyone answered "no"? Not sure where we are going with this? More responsibility on ICANN? On the applicant? -- Another reason to ask the question is whether ICANN followed what was in the applicant guidebook. Are these sufficient mechanisms? -- If the number is zero that zero doesn't really tell us anything. We should be asking if ICANN can produce the process flow they went through. -- Change the first question to ask ICANN to provide us with numerical information, what areas ICANN looked at, and what checks were carried out. -- Steve Chan (Staff): Formulate what we are trying to understand. In terms of how to answer it would e good to get data to understand that question, but not make the data request prescriptive. >From the chat: Jeff Neuman: Have there been any cases where ICANN required a change request to cure any deficiencies in the background checks? Christa Taylor: I think the business model around a TLD is completely seperate from background screening Steve Chan: The nature of the applying entity may play a role, however. Question: Do the requirements for background screening in regards to 1) general business diligence and criminal history ; and 2) history of cybersquatting behavior prove sufficient? (slide 12) -- Question is: when ICANN carried out the process did anything come up? -- One of the issues: If I am a Sr. VP of a company (owner or other principle) ABC and ABC had 10 cybersquatting cases it loses if I go on to found a company that applies for a TLD I don't fail the background because I am not implicated as an individual. -- Also, does one person who was found responsible for cybersquatting cause a company with which he is associated to fail the background check? -- Potentially a missing question: Have you had a contract with ICANN terminated or are being terminated for compliance issues? Could expand on that question -- not sure where to put it. -- It does make another good criteria to add -- substitute for (o) and change current (o) to (p) -- "Have you or your company been part of an entity found in breach of contract with ICANN?" >From the chat: Jeff Neuman: There were lots of ways to get around the cybersquatting background check. UDRPs are generally against entities, not the people who are principals in that entity. Thus, if an individual is a principal in a company that was subject to 10 cybersquatting cases, that individual would not faill the background check if he or she were part of a new gTLD application. Phil Buckingham: when we are talking about criminal history - does that even include a driving ban . Needs to be defined more clearly.next time. Steve Coates: What is criminal in one place may not be in another. Question: Could it be considered that the background screening is unnecessary for TLDs where Registrant Protections may not be necessary, such as Brand TLDs or those operating with a Code of Conduct exemption? (slide 13) -- Such as where registrants are not applicable for those TLDs. -- In ALAC the answer would be "yes" that it is a concern and should be questioned further. -- It is not just registrants that are protected by the background screening, it is ICANN as an organization. Don't want to enter into a contract with someone who has a conviction. >From the chat: Robert Burlingame (Pillsbury): Agree Jeff re not just protection for registrants. 2. CC2 Questions (slide 16) -- Built on what we have already discussed. -- Need to use the opportunity to see detailed feedback in areas not covered. Topics to cover (slides 17-19) -- Will there be a CC3? The plan is not to do a CC3, but we will have a preliminary report that will go out for public comment. Keep up a calendar indicating what we hope to cover through Copenhagen. -- Steve Chan (staff): Can share the calendar with the full group. On CC2, we haven't covered all the topics. The questions will have to be agreed upon by the full group. -- When is CC2 due to go out? The drop dead date is before ICANN58, but we are targeting middle or late February (such 20 February). >From the chat: Susan Payne: do we get to do a CC3 at some point for further topics? avri doria: hope not Susan Payne: ok, so we definitely need to ask about closed generics then Jeff Neuman: @susan - yes. And if you review the questions and have additional ones, please submit them :)

1 0

Agenda for 02 February 20:00 UTC WT2 Meeting
by Michael Flemming Feb. 2, 2017

Feb. 2, 2017

Dear All, Once again, I am late in sending this out. However, better late than never, please find our agenda and materials for the call at 20 UTC on 2 February 2017. 1. Welcome 2. SOI 3. Registrant Protections - Background Screening 4. CC2 Question Discussions: Where should we concentrate our questions and what type of questions should we have? 5. AOB I was hoping to get to the Terms and Conditions this week, but CC2 takes priority over that at the current time. While we have had little input over email for Registrant Protections, I felt it necessary to take today's meeting and focus on the Background Screening as well as CC2. We will only be introducing the CC2 topics on today's call, with the goal to solidify the questions over email. I know that there are many calls, but once again, I encourage everyone to participate today and to provide input over the mailing list. Kind regards, Michael Flemming

1 0

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