2020-11-05 New gTLD Subsequent Procedures PDP

Notes/ Action Items

Action Items:

Topic 15: Application Fees

Row 13 -- Dotzon GmbH re: IG 15.8 modification: excess fees must be returned to applicants

ACTION ITEM: Add that ICANN may want to spread out the cost. Not as Implementation Guidance.

Row 24 -- Christa Taylor (Individual) re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees

ACTION ITEM: Revise the language of the recommendation along the lines that Christa is suggesting: From Christa: “15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9.”

Row 23 – RySG re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees

ACTION ITEMS: Revise the Recommendation: 1) Change the refund to be refund or credit towards future fees where applicable; 2) If you can't find that entity or, you know, there's no entity to claim that refund, then it would go towards one of the purposes set forth and 15.9.

ACTION ITEM: Staff to check to see how the US47k was derived in the 2012 round.

Row 26 – ICANN Board re: Further examine concepts: excess fees, closure, round.

ACTION ITEM: Leadership will put suggested Implementation Guidance language out on the list for the WG to consider: Could provide Implementation Guidance to the IRT that if ICANN can determine its budget to cover historical, evaluation, and contingency costs, it could release refunds on a percentage basis depending on how many applications are final.

Row 27 – ICANN Org re: multiple comments

ACTION ITEM: Revise the Recommendation and Implementation Guidance to put 15.5, 15.6, and 15.7 directly into Recommendation 15.4.  Leave 15.8 as the only Implementation Guidance for Recommendation 15.4.

Topic 36: Base Registry Agreement

Row 12 -- Intellectual Property Constituency (IPC) and PETILLION Law Firm re: “Accordingly, the IPC advocates for strict limitations on exemptions from the base RA, if any, which must not weaken existing rights protection mechanisms or public interest commitments otherwise present in the RA.”

ACTION ITEM: Revise the recommendation to make it clear that consensus policy should not be the subject of individual RA negotiations.

Rows 17 and 29 – ALAC re: Enforce prohibition on fraudulent/deceptive practices in PIC or base RA/Answer to Community Question: Both PIC and RA

ACTION ITEM: Leadership will put the question out to the list for the WG to consider: “PICDRP does allow in theory "both options", but ALAC does not like the requirement that someone needs to allege and show how they have been harmed by the action. Does WG want to address this?

Row 18 – ICANN Org re: Concern about custom RAs; clear rationale for exemptions; request clarity from WG on recommendation 36.3 and provisions; lack of clarity concerning aspects of recommendation 36.4.

ACTION ITEM: Add language to Recommendation 36.3 that a clear rationale must accompany any exemption request.

Notes:

1. Updates to Statements of Interest: None provided.

2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reportsand review the following topics and comments:

Topic 15: Application Fees

Row 13 -- Dotzon GmbH re: IG 15.8 modification: excess fees must be returned to applicants

Leadership Comments: Should we provide more clarity around "cost recovery period"

Discussion:

-- It needs to consider expenses that go beyond one round i.e. systems.

-- For the next round we may want some note as IG an acknowledgement that ICANN will be developing new systems and they may want to space that out among new rounds.

-- Might be something that we recover over a period of time.

-- Cost recovery should be based on that particular round.  Could leave it to ICANN/IRT to determine how to do this.

-- On cost definition: from 2012 round, the answer has been that the costs are ongoing and there continues to be risk.

-- But we are making a number of changes to the evaluation process so how will ICANN know how much everything will cost this time?  Also the changes we make could result in more litigation and disputes. So is it really that easy to determine?

ACTION ITEM: Add that ICANN may want to spread out the cost. Not as Implementation Guidance.

Row 24 -- Christa Taylor (Individual) re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees

Leadership Comments: 15.5 - Already discussed 15.8 - Excess fees should have at least $1k go to 15.9 purposes. 15.9 - Excess fees could be a credit towards future ICANN Payments.  If the excess is less than $1 then the excess goes to something.  Could we say if there is some amount that was to hard to do a refund, then it should go to on of these other areas.

Re: From Christa: “15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9. This will help ICANN remain efficient while ensuring the costs related to the return of the fees do not exceed the resources required to return the excess to applicants. These funds could be used for items in Recommendation 15.9.”

Discussion:

-- Won't we know whether there is an excess for some time after the round as there could be potential disputes or litigation later which would normally be paid for from application fees.

-- We do recommend a separate work track or team for AS.

-- We could say that the IRT should work with the AS work track.

-- Could keep this at a high level. Just give guidance to the IRT.

-- There were metrics that we wanted developed by the IRT.

-- If we have an understanding of how USD47k was derived, then we can at least consider if that formula could be retained for IRT to work on.

ACTION ITEM: Revise the language of the recommendation along the lines that Christa is suggesting: From Christa: “15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9.”

Row 23 – RySG re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees

Leadership Comments: Move first $1k of excess fees (From each application) into contingency fund) Do we need to provide more information on determination of Applicant Support Fees -- maybe leave for the IRT? But is there a principle that we can rely on that was used the last time? Option: Maybe the percentage discount used in the 2012 round could be leveraged for future rounds.

Discussion:

-- Could start as a baseline from the 2012 round.

-- Could use the excess fees as credits for future services, instead of as a refund.

-- Could use the excess fees for those items mentioned in Recommendation 15.9, such as an education/awareness campaign.

-- Question: Why do we need to build a system to deal with unfixable refunds?  For non-profits by default they go to the Secretary of State of California. Answer: We think we’d rather have the funds go to the new gTLD program and specifically the purposes in Recommendation 15.9.

ACTION ITEMS: Revise the Recommendation: 1) Change the refund to be refund or credit towards future fees where applicable; 2) If you can't find that entity or, you know, there's no entity to claim that refund, then it would go towards one of the purposes set forth and 15.9.

ACTION ITEM: Staff to check to see how the US47k was derived in the 2012 round.

Row 25 -- GAC-France re: Concerns about fee floor

Leadership Comments: We believe this was intended, but transparency requirement to setting fees should apply to setting the Fee Floor as well.

ACTION ITEM: Revise the recommendation to apply the transparency requirement to both the establishment of the fee, as well as the establishment of the floor.

Row 26 – ICANN Board re: Further examine concepts: excess fees, closure, round.

Leadership Comments: Important to consider when a round is closed IF we are to refund applicants. Leadership believes that looking at a schedule of refunds, or a percentage basis rather than a full refund may be more palatable. (eg., once 50% of apps are "final", then an estimate of excess be determined and payment of 25% of the estimate is paid and then apply a scale after that point). Could set aside part of the payment for continency items and the rest could be available for refund.

ACTION ITEM: Leadership will put suggested Implementation Guidance language out on the list for the WG to consider: Could provide Implementation Guidance to the IRT that if ICANN can determine its budget to cover historical, evaluation, and contingency costs, it could release refunds on a percentage basis depending on how many applications are final.

Row 27 – ICANN Org re: multiple comments

Leadership Comments:

-- 15.2 ICANN Org wants a Uniform Charge regardless of whether a registry uses a pre-evaluated RSP. Although more complex from billing, it should be relatively easy. If applicant checks box for using a Pre-evaluated RSP, the fee is less.

-- 15.3 Historical Costs should not include any work not directly related to the next round. This means, for example, the NCAP project should not be billed to the next round, nor should any of the work of the CCT Review Team or the SubPro. Only true development costs, personnel costs, etc. once program is approved.

-- 15.4 - Leadership believes that 15.5, 15.6 and 15.7 are "musts", and 15.8 is should and therefore the first three are part of the recommendation.

-- 15.5 - WG is leaving it to ICANN/implementation as to who determines the "Floor". 15.5/6 Rationale - The WG is NOT saying that the Fee Floor should be the primary mechanism for enforcing the Bona Fide intention requirement. The WG does not believe the Fee Floor should be set at an artificially high amount.

ACTION ITEM: Revise the Recommendation and Implementation Guidance to put 15.5, 15.6, and 15.7 directly into Recommendation 15.4.  Leave 15.8 as the only Implementation Guidance for Recommendation 15.4.

Topic 36: Base Registry Agreement

General Leadership Comment: Should be noted that ALL constituencies and SGs of GNSO (except IPC) either support the section or have no opinion. And IPC only objection is on negotiating exceptions to RPMs.

Row 10 -- National Association of Boards of Pharmacy (NABP) re: apply to all subsequent TLDs; Category 1 Safeguards should apply to Registry Operators

Leadership Comments: Leadership believes that this relates the fact that Safeguards only require provisions in a Registry-Registrar Agreement, but may not necessarily not require enforcement.

Row 11 -- Swiss Government OFCOM re: RA operational criteria should be binding

Leadership Comments: Do we want to take up this issue or is it a broader issue (like DNS Abuse) that if reviewed, should be done in a wholistic manner?

Row 12 -- Intellectual Property Constituency (IPC) and PETILLION Law Firm re: “Accordingly, the IPC advocates for strict limitations on exemptions from the base RA, if any, which must not weaken existing rights protection mechanisms or public interest commitments otherwise present in the RA.”

Leadership Comments: Does the WG want to make a statement saying that the, the working group does not believe that a consensus policy should be the subject of individual negotiations?

Discussion:

-- We didn’t put this out for public comment, but it’s not controversial.  When we talked about flexibility in our recommendation we don’t think anyone thought this meant that someone could negotiate out of consensus policies. 

-- You could hypothetically have a situation where a registry wanted to negotiate out of a non-consensus policy, such as indemnity.

ACTION ITEM: Revise the recommendation to make it clear that consensus policy should not be the subject of individual RA negotiations.

Rows 17 and 29 – ALAC re: Enforce prohibition on fraudulent/deceptive practices in PIC or base RA/Answer to Community Question: Both PIC and RA

Leadership Comments: PICDRP does allow in theory "both options", but ALAC does not like the requirement that someone needs to allege and show how they have been harmed by the action. Does WG want to address this?

ACTION ITEM: Leadership will put the question out to the list for the WG to consider: “PICDRP does allow in theory "both options", but ALAC does not like the requirement that someone needs to allege and show how they have been harmed by the action. Does WG want to address this?

Row 18 – ICANN Org re: Concern about custom RAs; clear rationale for exemptions; request clarity from WG on recommendation 36.3 and provisions; lack of clarity concerning aspects of recommendation 36.4.

Leadership Comments: 1. A Rationale should be provided with an exemption request. This seems like a clarification. 2. ICANN Org wants to know why process was not clear. Response: WG found that although exemptions could be granted, few if any were granted and there was no criteria explaining what could and what could not be accepted. 3. Re - 36.4: As pointed out in the .Feedback case, ICANN did not believe it had the right to terminate the Agreement based on Fraud even when it was found by an independent party. Its not outside any organization's remit to cancel a contract based on fraud. If it wants to rely on a third party to make that determination, ICANN could always take the issue to Court for a declaratory judgment if it wants. 4. Re - Applicability to existing TLDs, that can be said of everything we add. But existing TLDs are not within our scope.

Discussion:

-- Question: From ICANN Org – “Is there an identified set of provisions that could be sought an exemption from versus others that were more fundamental and could not, or is it just open ended -- anybody who wants to propose an exemption or negotiate any provision can just send ICANN a request with a rationale, depending on which it is, those are very different processes to try to build.”  Answer: Jeff Neuman -- Once we exclude the consensus policies I don't think that was intended to exclude any other provisions that could be requested or changes that can be requested.  We're pretty much asking, ICANN can you tell us what that process is and be clear and transparent about it. The recommendation was not intended to just cover the provisions that already have the built-in exemption.  It was intended for other provisions, but not intended to negotiate consensus policies.

ACTION ITEM: Add language to Recommendation 36.3 that a clear rationale must accompany any exemption request.