[SubPro-IRT] Application Fee FAQ

Sam Lanfranco samlanfranco at gmail.com
Fri Jun 14 09:22:58 UTC 2024


As an economist too prefer a refund to a credit, which only applies if an applcation is going forward.

I also support sealed bids. No strategic gaming. Applicants give it there best shot, and the envelopes are opened. No drama, full stop.

Sam Lanfranco


⁣Internet Elder, Internet Ecologist, 416 816-2852​

On Jun 13, 2024, 1:25 p.m., at 1:25 p.m., Justine Chew <justine.chew.icann at gmail.com> wrote:
>Perhaps, give applicants a choice depending on their respective
>circumstances? Or to waive the refund as someone suggested earlier.
>
>
>Justine
>---------
>
>On Thu, 13 Jun 2024, 16:48 Jeff Neuman, <jeff at jjnsolutions.com> wrote:
>
>> Just to add to the notion of a "Credit" vs. "Refund".  A significant
>> number of applicants either withdraw their applications or be
>eliminated
>> through contention, lack of success in the application process,
>advice,
>> etc.  A credit does no good for these applicants because they will
>have
>> nothing to credit against.
>>
>> I do not see a way around making this a refund as opposed to a
>credit.
>>
>> ------------------------------
>> *From:* SubPro-IRT <subpro-irt-bounces at icann.org> on behalf of
>Christa
>> Taylor <Christa at tldz.com>
>> *Sent:* Thursday, June 13, 2024 12:35 AM
>> *To:* Rubens Kuhl <rubensk at nic.br>; Next Round Policy Implementation
><
>> NextRound_PolicyImplementation at icann.org>; subpro-irt at icann.org <
>> subpro-irt at icann.org>
>> *Subject:* Re: [SubPro-IRT] Application Fee FAQ
>>
>>
>> Thank you Elisa and Lars,
>>
>>
>>
>> I apologize for not being able to attend due to time zone
>differences.
>>
>>
>>
>> I want to support the requests for more detailed costing information
>along
>> with some concerns.
>>
>>
>>
>> In November 2016, Work Track 1 was tasked with evaluating the
>accuracy of
>> cost estimates and reviewing the methodology used to develop the cost
>> model. However, after months of requests, ICANN was unable to provide
>any
>> information on the costs and methodology used in the 2009 application
>fees.
>> Consequently, we could not properly address the Implementation
>Guideline B
>> regarding the concept of differing application fees for different
>> applicants and the potential creation of new application types, which
>may
>> have necessitated a new costing analysis based on recommended changes
>> (section 4.2.17 at
>>
>https://community.icann.org/download/attachments/58735931/Section%204.2.17.pdf?version=1&modificationDate=1460741334000&api=v2
>> ).
>>
>>
>>
>> Since we were unable to attain the information, the working group
>wanted
>> to ensure the scenario would not occur in the future rounds and
>emphasized
>> the need for detailed and transparent disclosure of fees and
>methodologies
>> to the community.  The Final Report reflects this:
>>
>>    - Top 15: Application Fees: “*The development of the application
>fee
>>    must be fully transparent, with all cost assumptions explained and
>>    documented*” (p. 66).
>>    - Working Group Emphasis: * ICANN should be fully transparent
>about
>>    how the application fee is developed, explaining and documenting
>all cost
>>    assumptions (*p. 69).
>>    - Summary of Outputs: “*The development of the application fee
>must be
>>    fully transparent, with all cost assumptions explained and
>documented*”
>>    (p. 249).
>>
>>
>>
>> Two additional points:
>>
>>
>>
>> 1. Application Fees and Deterrence:  I understand wanting to be
>> conservative approach to ensure costs are recovered however, this
>should be
>> based on probabilities not extreme cases as provided with the 500 and
>1,000
>> volume levels.  Also, the scenarios presented suggest providing
>excess fees
>> as a ‘credit’, but we recommended the option of a refund if the
>amount
>> exceeded $1,000 (or another nominal amount) with a disbursement
>schedule
>> based on milestones to avoid delays. This would ensure that
>applicants
>> don't prepay their yearly ICANN fees, for an extended period, during
>a
>> critical time when those funds could be utilized to launch and
>support the
>> operation of their TLD(s).
>>
>>
>>
>> 2. The working group noted that only historical costs directly
>related to
>> implementing the New gTLD Program should be part of the cost
>structure for
>> determining application fees.
>>
>> *“The Working Group believes, however, that for subsequent procedures
>the
>> only historical costs that should be part of the cost structure in
>> determining application fees are those actual costs directly related
>to the
>> implementation of the New gTLD Program”.*  (p. 65).  "Org Shared
>> Services" do not align with this, as they are “*not directly
>attributable
>> to a program or project*”.  Additionally, it would be helpful to
>> determine whether the $70k per application in implementation fees
>also
>> includes past shared services amounts and, if they do, the amount
>included
>> within the $70k.
>>
>>
>>
>> Without relevant details and transparency on the costs, it becomes
>> difficult to understand the full picture, hinders analysis, and
>prevents
>> the attainment of useful insights that can be utilized in future
>rounds and
>> in the development of future policies.
>>
>>
>>
>> Apologies for the length, it was supposed to be a short email!
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Christa
>>
>>
>>
>> *From:* SubPro-IRT <subpro-irt-bounces at icann.org> *On Behalf Of
>*Rubens
>> Kuhl via SubPro-IRT
>> *Sent:* Wednesday, June 12, 2024 8:00 PM
>> *To:* Next Round Policy Implementation <
>> NextRound_PolicyImplementation at icann.org>; subpro-irt at icann.org
>> *Subject:* Re: [SubPro-IRT] Application Fee FAQ
>>
>>
>>
>>
>>
>>
>>
>> Em 12 de jun. de 2024, à(s) 09:01, Next Round Policy Implementation <
>> NextRound_PolicyImplementation at icann.org> escreveu:
>>
>>
>>
>> Dear IRT members,
>>
>>
>>
>> In preparation for tomorrow's IRT meeting
>> <https://community.icann.org/x/zIBAEw>, ICANN org has prepared the
>> attached FAQ which aims to address the various questions that have
>been
>> raised both in relation to the RSP fee as well as the gTLD evaluation
>fee.
>>
>>
>>
>> Best regards,
>>
>> Elisa
>>
>>
>>
>>
>>
>>
>>
>> Some comments about the FAQ:
>>
>>
>>
>> - In the RSP fee, it lacks a comparison to the USD 14k required for
>an
>> unknown RSP to be evaluated for serving 2012 gTLDs.
>>
>> - It’s not mentioned whether applicants will be allowed to commit to
>use
>> an evaluated RSP or can only choose already evaluated ones
>>
>> - In item 3, it’s mentioned that TMCH fees are not included. In 2012,
>> registries got their TMCH fees back after being initially charged, so
>in
>> effect, there was no additional payment of TMCH fees beyond the
>application
>> fee. Changing that is not supported by any SubPro recommendation.
>>
>> - As mentioned by Seb during the session, some organizations might
>have
>> challenges receiving the excess funding. So while it’s good to be the
>> default to return the excess, giving applicants the option to not get
>that
>> excess back solves for corner cases regarding tax or foreign exchange
>> regulations. Applicants would only  have to say they want it or not
>want it
>> (no lingering).
>>
>>
>>
>>
>>
>> About the fee for joint venture review, if joint venture ends up
>playing a
>> role in auctions, perhaps auction proceeds should pay for those.
>>
>>
>>
>> About the fee for lingering applications, I support the idea.
>Currently
>> there is an asymmetrical relationship between letting it linger
>> (Cranberries song playing in the background) and the Org costs. The
>hard
>> issue, though, is defining it, since there should be no prevention of
>the
>> use of accountability mechanisms or limited appeal processes created
>by
>> that cost, but that can’t also trigger an excessive use of such
>mechanisms
>> only to avoid the lingering fee.
>>
>>
>>
>> About the IDN Variant subsidy, agree with Edmon on changing its name,
>but
>> I also add that this could be funded from fee leftovers (either from
>> previous round or forecast of this round) or even Auctions leftovers.
>This
>> would be aligned with guidelines to such expenditures, I believe.
>While
>> this won’t change the application fee by any significant amount
>either way
>> (circa 1%), this would simplify the fee determination and also could
>back
>> ICANN claims to support multilingual development of the Internet.
>>
>>
>>
>>
>>
>> Rubens
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> SubPro-IRT mailing list
>> SubPro-IRT at icann.org
>> https://mm.icann.org/mailman/listinfo/subpro-irt
>>
>> _______________________________________________
>> 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.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>SubPro-IRT mailing list
>SubPro-IRT at icann.org
>https://mm.icann.org/mailman/listinfo/subpro-irt
>
>_______________________________________________
>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: <https://mm.icann.org/pipermail/subpro-irt/attachments/20240614/e83a70da/attachment-0001.html>


More information about the SubPro-IRT mailing list