Following Jeff's note -- it could be even more challenging for an IDN applicant to come up with alternative, back-up string . -- Ching On Thu, Sep 19, 2024 at 4:19 PM Lars Hoffmann via SubPro-IRT < subpro-irt@icann.org> wrote:
Thank you, Mark and Jeff for your input on list. I would like to encourage others to add to the discussion as they see fit.
Some housekeeping: there is a full IRT meeting today (18:00-19:00 UTC), which will focus on the Registry Agreement. Unfortunately, I will not be able to join the call today. We had a look at the IRT agenda, and I suggest we continue the discussion on contention sets during next week Tuesday’s (24 September) meeting.
In the exchange below, Mark asks what the objective of the alternate string is. I believe the Board has put forward this proposal as a mutually acceptable solution (per Bylaws) to address ICANN77 GAC advice on avoiding auctions between commercial and non-commercial applicants. Also, Jeff echoes sentiments that many IRT members also voiced on this week’s call: concerns around an automatic switch to the alternate string in case the primary string is identical to another applied-for string. Therefore, already since Tuesday’s call, we are thinking through how we can address these concerns, with the goal of maintaining a predictable, simple, transparent, and fair program for all applicants. We hope to be able to share initial ideas with the IRT on Tuesday 24 September and look forward to a productive discussion then.
While the team continues to work on practical solutions based on the latest input we have from the Board, we are aware that additional input from Council, new GAC or ALAC advice, or more Board directions could all still impact the overall implementation approach to contention resolution. However, at this moment I believe it is imperative for the team to continue cooperating closely with the IRT and put together draft AGB language. This may mean that we will have to adapt/change our approach or draft language if/when we receive additional input from Council or Board regarding the implementation approach. Still, unless org and IRT continue our discussions and work on draft language, and adapt later as needed, there is every chance that our overall timeline will be impacted.
Thank you all and I am looking forward to another spirited discussion next week.
Very best. Lars
*From: *trachtenbergm--- via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *"trachtenbergm@gtlaw.com" <trachtenbergm@gtlaw.com> *Date: *Tuesday, 17 September 2024 at 17:08 *To: *"jeff@jjnsolutions.com" <jeff@jjnsolutions.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[SubPro-IRT] Re: Picking and Choosing Recommendations to Follow and not to Follow
Jeff,
I totally agree but you are also leaving out one obvious solution – simply forget about this new option that ICANN cooked up that was not included in the PDP and will create significant unnecessary complexity in both the policy development process and also in the application process where this will wreak havoc and will undoubtedly result in unending moves back and forth, gaming, disputes , and confusion. Not to mention the difficulty of explaining this to new applicants, in particular those who don’t regularly participate in ICANN including those from underserved regions. And what policy objective is this even in furtherance of? Delegating as many strings as possible? Since when is this policy approved by the GNSO?
Best regards,
*Marc H. Trachtenberg * Shareholder
Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 T +1 312.456.1020
M +1 773.677.3305 trac@gtlaw.com <trachtenbergm@gtlaw.com> | www.gtlaw.com [gtlaw.com] <https://urldefense.com/v3/__http:/www.gtlaw.com/__;!!PtGJab4!8iHkQhRYdW3OHFv...> | View GT Biography [gtlaw.com] <https://urldefense.com/v3/__https:/www.gtlaw.com/en/professionals/t/trachten...>
[image: Greenberg Traurig Logo]
*From:* Jeff Neuman via SubPro-IRT <subpro-irt@icann.org> *Sent:* Tuesday, September 17, 2024 9:58 AM *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] Picking and Choosing Recommendations to Follow and not to Follow
**EXTERNAL TO GT**
First, apologies I was not able to attend the meeting last night, earlier this morning. But in listening to the conversation, it sounds like ICANN is picking and choosing which SubPro Recommendations it is following and which they are not.
On the call Elaine was absolutely correct. Yes, the PDP did not want people to change their strings. But the PDP also did not state that people could list alternate strings and that they could be switched prior to reveal day. This is a new factor introduced into the equation by ICANN.
With this new factor being introduced, we now need to develop the best comprehensive solution or applicants and the community. If the PDP knew that you would be allowed to list alternate strings and changes would be made prior to reveal day, it is not a given that the PDP would have stuck to its recommendation to not allow the changing of strings after reveal day.
Applicants are going to be investing a LOT of money and resources applying for a new TLD. The amount of their investment cannot be overstated. I talk to potential applicants every day. They are thoughtful, innovative, entrepreneurial, and take this extremely seriously. But when the ICANN Board/Org sits in its silo trying to come up with rules, it does not have the benefit of considering the real practical business implications. (And by business, I also include non-profits).
For example, If I am electing to put in an application, I am committed to that string and that is one I know I can make work regardless of what anyone else applies for. If, however, I list an alternate string, I may be able to make that work, but not if someone else gets the primary string, and not if someone else has a separate but competing string, and therefore ICANN switching me automatically to the secondary string may not make sense for me or my business model.
For example, Lets say I apply for *.musicals*. And then I list as an alternate *.musicaltheater* (with the er). Sure, perhaps I can make .musicaltheater work if there is contention with .musicals. But if I knew that someone else applied for .musicaltheatre (with the "re" as opposed to the "er"), then there is no way I would want .musicaltheater (with the "er"). Yet, under the ICANN new rule, I would be forced into the alternate string.
NOTE: .theater and .theatre were BOTH allowed in the last round and were NOT found to be similar.
If I had known that there was a .musicaltheatre application (with the "re"), then perhaps I would rather stick to the original contention set. But if there was not a .musicaltheatre application, then I would want to go to my alternate .musicaltheater.
And it is not a satisfactory answer for ICANN to say, well that's just the way it is or then you shouldnt have listed an alternate. Applicants should not be treated like they are buying a $25 toy. They are spending $200k+ to apply, not to mention the time and money to draft the application, build a team, hire, get financing, etc.
So, if we agree to change the process to allow alternate strings, then we need to adjust to best possible solution and not Pidgeon hole in an old recommendation that did not have this important new change.
Sincerely,
Jeff
------------------------------
If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ 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.
