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-requirem...) 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.