If no, please explain

[[note: “¶¶” == new paragraph]] The Applicant Support Program (ASP) is an integral part of the New gTLD Program. Its ability to meaningfully support needy applicants levels the playing field for underdeveloped communities, and its promise to connect the next billion people is critical to the overall success of the program. ¶¶ The general construct of the ASP is greatly improved from 2012. However, one critical flaw could jeopardize the progress made and result in wasting millions of dollars of ICANN funds committed to the cause. This Achilles Heel pertains to the support provided to ASP supported applicants to successfully navigate the contention resolution process. I will focus my comments on a suggestion with minimal changes to the AGB to fix this flaw. ¶¶ The current Draft AGB includes “Bid Credits” which offer ASP supported applicants “up to a 35% discount applied to the amount due to be paid by the winning supported applicant” (not to exceed a monetary value of USD 1.75 million per application). This is supposed to increase the ability for an ASP supported applicant to win in the last resort auction. Unfortunately, based on the winning auction bids experienced in the 2012 round and the examples provided in the Draft AGB (p. 155), ASP supported applicants would have to pay hundreds of thousands, potentially millions of dollars to win in the auctions (the amounts in the examples provided in the Draft AGB were USD 585,000 and USD 4.8 million respectively). These amounts are out of reach for most, if not all, ASP supported applicants based on the ASP eligibility criteria. Therefore, the “Bid Credits” are effectively tokenism. ¶¶ This not only eliminates an ASP applicant in cases of contention, but also increases the uncertainty to an untenable level for a needy applicant when deciding whether or not to apply. More specifically, the application fee — even when discounted — amounts to a substantial sum for a needy applicant such as an NGO or a micro business in underdeveloped regions. This is especially acute if, at the end of the day, there is a significant risk of financial loss when they are forced to compete in an auction against much better-resourced commercial applicants, with only partial refund available. ¶¶ To rectify this issue, this comment suggests a simple adjustment to the Draft AGB by allowing ASP supported applicants to submit their Replacement String within the first 3 days of the 14-day Replacement Period to avoid contention (even if it means selecting a less desirable string). In alignment with the process already in place, the Replacement String must not be identical to the original applied-for string or Replacement String of any other applicant. This is fair and has no impact on other open commercial applicants (because the string must be less interesting to them in the first place) and prevents gaming by ASP supported applicants. This also addresses the operational concern raised regarding the potential for ASP supported applicants to cause delays in administrative processing (see “End Notes” for a more detailed explanation). ¶¶ Furthermore, even if ASP supported applicants end up selecting Replacement Strings that conflict with each other, they would enter into auctions of last resort on equal footing (since all participants in such auctions would be financially-constrained applicants, the winning bids for such auctions would likely be a much smaller amount, rather than millions in the case of auctions with open commercial applicants). This would meaningfully reduce the risks and ensure the success of the ASP for needy applicants, while upholding the “goals of fostering diversity, encouraging competition, and enhancing the utility of the DNS.” ¶¶ To implement the above suggestion, just one sentence need to be added to the Draft AGB at the end of the second paragraph under Section 4.1.2 Replacement String Eligibility (p. 122): ¶¶ ===== (…after submitting the application.) For supported applicants (eligibility based on the ASP), should their string be found to be in preliminary contention on Reveal Day, a new Replacement String may be submitted during the first 72 hours (3 days) of the Replacement Period. ===== ¶¶ In the case that the ICANN Board deems it necessary to further protect against a situation where an ASP supported applicant submits a Replacement String that is later contested, an additional sentence could be added to the Draft AGB at the end of paragraph 3 under Section 4.1 Replacement Strings (p. 121) as follows: ¶¶ ===== (…must remain in contention with .AHCHOO.) If a supported applicant (eligibility based on the ASP) chooses to submit a Replacement String that is subsequently found to be in contention as described above, the supported applicant’s application will be eliminated. ===== ¶¶ This will effectively dissuade any abusive behaviour from ASP supported applicants and be fair to all applicants involved. ¶¶ All other provisions of the Draft AGB can remain unaffected. ¶¶ The suggested changes align with the spirit of all SubPro and implementation discussions and do not violate any policy recommendations (thus should not require any policy reconsiderations), while effectively addressing a critical issue for the usefulness of the ASP. ¶¶ These observations and suggestions are the result of discussions with potential ASP applicants and address a real concern for resource-strapped aspirants for which the ASP was intended. ¶¶ As a long-time participant at ICANN, I understand the importance of upholding the integrity of the process in stating my interests. I am making a disclosure here that both myself and my employer DotAsia are supporting ASP applicants in the program. Nevertheless, allow me to stress that while I am understandably interested in seeing ASP applicants we support succeed, as a staunch supporter of the ICANN processes, my primary concern is that the ASP be effective and successful for all ASP applicants and for the New gTLD program overall to be successful. ¶¶¶¶ Sincerely, Edmon Chung ¶¶¶¶¶¶ PS. End Notes: According to recordings, this issue was only briefly discussed by the SubPro IRT, in consideration of the GAC advice regarding concerns for non-profit organizations, and was summarily dismissed with allusions to potential gaming concerns, the impact it could have on processing times and the overall timeline. The issue was not resolved, nor addressed in any of the previous Public Comment periods. ¶¶ On potential gaming, it is crucial to understand that ASP supported applicants are prohibited from submitting strings that are identical to other applicants. This prevents any undue advantages. Furthermore, if an ASP supported applicant submits a Replacement String within the initial 3 days of the Replacement Period and is later found to be in contention due to various reasons like Singular/Plural Notification, String Similarity Evaluation, String Confusion Objection, etc., they will be disqualified from entering into auction. Thus, there is no excuse for engaging in any further gaming tactics. ¶¶ Based on the estimation of 1000 applications: time between the close of the application period and the Replacement Period is estimated at 56 days (p. 45 in Draft AGB), resulting in an operational estimate of ~20 being processed per day. As there are a max of 45 ASP applicants (according to the current allocation to the program), the ASP Replacement Strings should be completed within a few days (it is understood that other factors mean processing time is not linear, however with the experience gained by then, it can be reasonably anticipated that the additional administrative processing for the few ASP applicants – much less than 45 in all likelihood – who may need to submit Replacement Strings). Perhaps even in time to be added to the “full list of applied-for strings” during the second week of the 14-day Replacement Period. This way, others can also see them, further reducing concerns on gaming.