[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 March 1500 UTC

[Julie Hedlund]

Dear Working Group members,

Please see below the notes from the meeting on 02 March at 1500 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-03-02+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie

Notes and Action Items:

Action Items:

2.7.2 Registrant Protections:

Recommendation xx (rationale 2): Provide TLDs with exemptions from the Code of Conduct (Specification 9) (including .Brand TLDs qualified for specification 13) with an exemption from COI requirements.
ACTION ITEMS:
-- Instead of “COI” say, “COI or its successor”.
-- Double negative: something other than the second “exemption”.  But exemption from the Code of Conduct also qualifies for an exemption from COI requirements.  Reword to “and also an exemption from COI requirements”.

c. New Issues Raised:
ACTION ITEM: Add Implementation Guidance that a background check is done if there is a change to key personnel or officers, or to the entity itself, prior to contract signing.

ACTION ITEM: Add to Role of Public Comments section: "ICANN must create a mechanism for the submission of information related to applicant background screening which may not be appropriate for public comment.  At a minimum, ICANN must confirm receipt and that the information is being reviewed."

ACTION ITEM: Ask ICANN Org: “Can a registry that is about to need an EBERO allowed to choose their EBERO provider?  Matters from a data protection standpoint.”

SSR2 Recommendation 26: Document, Improve, and Test the EBERO Processes
See: https://www.icann.org/en/system/files/files/ssr2-review-24jan20-en.pdf; page 50:
26.5. ICANN org should publicly document the ERERO processes, including decision points, actions, and exceptions.
ACTION ITEM: Include a reference to 26.5 and see how the rest of the recommendation evolves.   Note that the WG is monitoring the work of the SSR2.

2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization:

b. Deliberations and rationale for recommendations and/or implementation guidelines
ACTION ITEM: Change last sentence to, “Certain exemptions to the Code of Conduct were subsequently approved by the ICANN Board of Directors, particularly with Brand TLD registries (in Specification 13) as well as with respect to entities that restricted their TLDs to only themselves and/or their affiliates [and trademark licensees].” New text in brackets.

c. New issues raised:
ACTION ITEM: Change “should” to “may” in the last sentence in the section: “Though the group believes this issue [may] be explored in the future, it is not making a recommendation on this area at this time.”

2.5 Registrar Support for New gTLDs

Re: Granting a Code of Conduct exemption where a Registry Operator has made a good faith effort to recruit registrars to sell its TLD, but it has not been able to get registrars to do it
.
ACTION ITEM: Add this topic to the legal discussion.

Notes:

1. Review Agenda/Statements of Interest: No updates provided.

2. Review draft final recommendations – see the Working Document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing:

a. 2.7.2 Registrant Protections

-- Comment from Kathy Kleiman: Can we come up with a better term? "Registrant Protections" has always been confusing to me since the set of possible registrant protections is so much broader than anything we are talking about here. Perhaps "Technical Registrant Protections"?
-- Comment from Jeff Neuman: Not all of them are technical, such as funding for the EBERO.
Affirmation xx (rationale 1): The Working Group affirms existing technical registrant protections for registrants used in the 2012 round, including the EBERO and associated triggers for an EBERO event and critical registry functions. In addition, as described in section 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services, the substantive technical and operational evaluation is being maintained and therefore, protections against registry failure, including registry continuity, registry transition, and failover testing continue to be important registrant protections. The Working Group also supports the registrant protections contained in Specfication 6 of the Registry Agreement.

Discussion:
-- Not to reopen the debate, recognizing that this has been discussed… But EBERO has not proven effective in that the SLAM stats show there were several times a Registry should have been EBERO’d and was not. I think somewhere along the line the EBERO program needs to be reconsidered.
Understood, and the outcome of the analysis saved my skin a few times :) I just think the concept needs to evolve.
-- I would go a step further.  The EBERO program is a crutch that keeps failing registries from going out of business. I don't know of any other industry where unsuccessful business are propped up like this.  I might be wrong but .WED has been in EBERO since 2017.  I think its still there.

Recommendation xx (rationale 1): The Working Group supports recommendation 7.1.a. in the Program Implementation Review Report, which states: “Explore whether there are more effective and efficient ways to fund emergency back-end registry operator in the event of a TLD failure [other than requiring Continuing Operations Instruments].”

Recommendation xx (rationale 2): Provide TLDs with exemptions from the Code of Conduct (Specification 9) (including .Brand TLDs qualified for specification 13) with an exemption from COI requirements.

Discussion:
ACTION ITEMS:
-- Instead of “COI” say, “COI or its successor”.
-- Double negative: something other than the second “exemption”.  But exemption from the Code of Conduct also qualifies for an exemption from COI requirements.  Reword to “and also an exemption from COI requirements”.

c. New issues raised in deliberations since publication of the Initial Report, if applicable.

The Working Group notes ICANN org’s comments on the Working Group’s Initial Report and a recommendation in the Program Implementation Review Report which suggest that additional consideration should be given to whether background screening should be performed during Initial Evaluation or at the time of contract execution (see PIRR recommendation 2.2.a). Because (i) there may be a significant amount of time that has passed between the initial evaluation and the contracting stage, and (ii) the changes that may be allowed to applications with respect to joint ventures or other allowable changes, many members of the Working Group were supportive of the Background checks occuring at time of contract execution. While the Working Group does not have any specific recommendations in this regard, it anticipates that the issue will be further considered in the implementation phase.

Discussion:
-- Staff comment: Is there anything further we want to say about the discussion regarding Pre-Approved RSPs serving as EBERO? This is discussed in some depth in the Initial Report.
-- Staff comment: The Working Group may want to consider if there are any guiding principles to be considered during implementation.
-- From Jeff Neuman: Most of the EBERO stuff has to do with finding other funding models to fund the EBERO than having a COI. We have a recommendation above that seeks more study of that.
-- Consider a hybrid option as Implementation Guidance: if changes to key personnel, officers etc., or to the entity itself then the background check would have to be done before the contract signing.
-- Great to have another check if there is a change or just before contracting.  But, we cannot lose our gatekeeping check - it makes no sense to make folks go through an auction with another party that shouldn't even be there.
-- Is there a mechanism for ICANN to acknowledge the comments and respond to them?  But it shouldn’t be a public comment.
-- Concerned that there is no easy recourse to ICANN Org making "a mistake" in completing a background check.

ACTION ITEM: Add Implementation Guidance that a background check is done if there is a change to key personnel or officers, or to the entity itself, prior to contract signing.

ACTION ITEM: Add to Role of Public Comments section: "ICANN must create a mechanism for the submission of information related to applicant background screening which may not be appropriate for public comment.  At a minimum, ICANN must confirm receipt and that the information is being reviewed."

SSR2 Recommendation 26: Document, Improve, and Test the EBERO Processes
See: https://www.icann.org/en/system/files/files/ssr2-review-24jan20-en.pdf; page 50:
26.5. ICANN org should publicly document the ERERO processes, including decision points, actions, and exceptions. The document should describe the dependencies for every decision, action, and exception. 26.6. Where possible, ICANN org should automate these processes and test them annually. 26.7. ICANN org should publicly conduct EBERO smoke-testing at predetermined intervals using a test plan coordinated with the ICANN contracted parties in advance to ensure that all exception legs are exercised and publish the results. 26.8. ICANN org should improve the process by allowing the gTLD Data Escrow Agent to send the data escrow deposit directly to the EBERO provider.

Discussion:
-- Not sure what we can include from this recommendation.
-- Can a registry that is about to need an EBERO allowed to choose their EBERO provider?  Matters from a data protection standpoint.
-- ICANN makes that decision and it's one of the reasons that the EBERO providers are geographical diverse, or at least they used to be.

ACTION ITEM: Ask ICANN Org: “Can a registry that is about to need an EBERO allowed to choose their EBERO provider?  Matters from a data protection standpoint.”

ACTION ITEM: Include a reference to 26.5 and see how the rest of the recommendation evolves.  Note that the WG is monitoring the work of the SSR2.

b. 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization (time permitting - page 52)

b. Deliberations and rationale for recommendations and/or implementation guidelines

ACTION ITEM: Change last sentence to, “Certain exemptions to the Code of Conduct were subsequently approved by the ICANN Board of Directors, particularly with Brand TLD registries (in Specification 13) as well as with respect to entities that restricted their TLDs to only themselves and/or their affiliates [and trademark licensees].” New text in brackets.

c. New issues raised:

ACTION ITEM: Change “should” to “may” in the last sentence in the section: “Though the group believes this issue [may] be explored in the future, it is not making a recommendation on this area at this time.”

c. 2.5 Registrar Support for New gTLDs

Affirmation xx: The Working Group affirms existing practice that it is up to a registrar to determine which gTLDs it carries.

Discussion:
-- Lack of recommendations is not satisfactory.  Can we make exceptions for registry operators that have difficulty attracting ICANN accredited registrars so that they can become a registrar?
-- It’s not that they can’t become registrars.  Is the issue the exemption to the Code of Conduct?
-- It sounds like we are talking about granting a Code of Conduct exemption where a Registry Operator has made a good faith effort to recruit registrars to sell its TLD, but it has not been able to get registrars to do it
.
-- There will be concerns about gaming and what is a “good faith effort”.
-- Currently, you are always required to treat all registrars in a non-discriminatory manner, unless you also have Spec 13.   So the Code of Conduct exemption just means that you don’t need to have separate books for your registrar services.

ACTION ITEM: Add this topic to the legal discussion.

3. AOB: ICANN67 Topics: Applicant Support; Closed Generics; Community Applications; Global Public Interest; GAC Advice/Early Warning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200302/203f6d52/attachment-0001.html>