[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 05 November 03:00 UTC

Thu Nov 5 23:32:06 UTC 2020

Noted Jamie, thanks for letting us know...

<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
Cheryl Langdon-Orr
about.me/cheryl.LangdonOrr
<https://about.me/cheryl.LangdonOrr?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>

On Fri, 6 Nov 2020 at 07:50, Jamie Baxter <jbaxter at spimarketing.com> wrote:

> Hey Jeff & Cheryl
>
>
>
> Apologizes for missing the call last night, but I listened to the
> recording today on ICANN ORG & FEES and wanted to offer support for Jeff’s
> suggestion that ICANN issue refunds by component (assuming excess) and not
> wait until the end of a subsequent procedure. This is key to preventing
> ICANN from using excess funds in one component for another and it could
> also help return more money sooner before applicants that don’t ultimately
> run a registry become a challenge to find.
>
>
>
> Jamie
>
>
>
>
>
> *From: *Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> on behalf of
> Julie Hedlund <julie.hedlund at icann.org>
> *Date: *Thursday, November 5, 2020 at 12:00 PM
> *To: *"gnso-newgtld-wg at icann.org" <gnso-newgtld-wg at icann.org>
> *Subject: *[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent
> Procedures PDP WG - 05 November 03:00 UTC
>
>
>
> Dear Working Group members,
>
>
>
> Please see below the notes from the working sessions on 05 November at
> 03:00 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-11-05+New+gTLD+Subsequent+Procedures+PDP.
>
>
>
>
> Kind regards,
> Julie
>
> ==
>
> *Notes and Action Items:*
>
>
>
> *Action Items:*
>
>
>
> Topic 15: Application Fees
> <https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmCT_gMRSkQ/edit#gid=1163822586>
>
>
>
> 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
> <https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586>
>
>
>
> 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+reports and
> review the following topics and comments:
>
>
>
> Topic 15: Application Fees
> <https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmCT_gMRSkQ/edit#gid=1163822586>
>
>
>
> 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
> <https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586>
>
>
>
> 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.*
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20201106/c8ba06c6/attachment-0001.html>