<div dir="ltr"><div>Hi members,</div><div><br></div><div>As you will see in the discussion on the thread below, the SubPro IRT is having an issue with interpreting what "<b><i>protection</i></b>" of an IGO and INGO Identifier mean in the Protection of IGO and INGO Identifiers in All gTLDs consensus policy and is seeking advice from the GNSO Council in its role as GNSO Policy Manager. </div><div><br></div><div>Two interpretations have been presented to the GNSO council for advice and the options are below. As a result, the council has asked each SG/C to discuss the options and provide their feedback as to which of the options they believe aligns with the intent of the consensus policy.</div><div><br></div><div>As you will also see in the forwarded thread, the longstanding NCSG position has been Option 1, but keen to hear your thoughts before we respond to the council with our normal position.</div><div><br></div><div><b>Option 1: Reserved Names are only protected based on who can apply for them, <br>but go through String Similarity Evaluation like any other applied-for string if it is <br>applied-for. </b><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>a. Only entities for which Reserved Names are reserved for can apply for them, </div><div>based on the process noted in AGB. </div><div>b. Reserved Names will not be given any protection against similar strings, i.e.: </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>i. If redcross and re̱dcross are both applied for, they will be put in contention </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>set and any one of these could move forward based on which way </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>contention is resolved. </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>ii. If redcross is not applied for in the current round, and re̱dcross is applied </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>for, then re̱dcross can proceed based on first-come-first-served basis. </div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>1. If re̱dcross is delegated, redcross cannnot be delegated in </div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>subsequent rounds, as it will be found confusingly similar to </div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>re̱dcross. </div><div><br></div></blockquote></blockquote></blockquote><b>Option 2: Reserved Names are protected based on who can apply for them, and <br>also protected against other applied-for strings which are found confusingly <br>similar during String Similarity Evaluation, as explained below. </b><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">a. Only entities for which Reserved Names are reserved for can apply for them, <br>based on the process noted in AGB. <br>b. Reserved Names will be given protection against similar strings, i.e.: </blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>i. redcross and re̱dcross are both applied for, redcross will be able to </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>proceed but re̱dcross will not be able to proceed. They will not be put in a </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>contention set. </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>ii. If redcross is not applied for in the current round, and re̱dcross is applied </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>for, then re̱dcross cannot proceed due to the protection for redcross </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>during string similarity evaluation. </div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>1. The string redcross can be applied for (by an eligible organization) </div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>and delegated in subsequent rounds as no similar string can be </div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>delegated. </div></blockquote></blockquote></blockquote><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Remain blessed,<br></div>Tomslin</div></div></div></div></div></div></div></div></div></div></div></div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">farzaneh badii</strong> <span dir="auto"><<a href="mailto:farzaneh.badii@gmail.com">farzaneh.badii@gmail.com</a>></span><br>Date: Thu, 25 Sept 2025 at 04:57<br>Subject: Re: [NCSG-PC] Discussion in SubPro IRT headed to Council<br>To: Emmanuel Vitus <<a href="mailto:emmanuelvitus@gmail.com">emmanuelvitus@gmail.com</a>><br>Cc: ncsg-pc <<a href="mailto:ncsg-pc@lists.ncsg.is">ncsg-pc@lists.ncsg.is</a>><br></div><br><br><div dir="auto">Yes. Manju’s position is the well established NCSG position. We even delayed the red cross policy approval at the council a few years ago to express our objection to reserving so many names for NGOs and INGO. </div><div dir="auto"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="verdana, sans-serif" style="font-family:verdana,sans-serif;color:rgb(0,0,0)">Farzaneh </font></div></div></div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 24, 2025 at 2:48 PM Emmanuel Vitus <<a href="mailto:emmanuelvitus@gmail.com" target="_blank">emmanuelvitus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div>
<div>
<p dir="auto">Thank you Juan and Pedro. I had shared my note earlier and I just want to clarify my view in light of the new explanation.<br></p></div></div><div><div>
<p dir="auto">I support Option 1 as the approach most consistent with policy. My main concern remains equity. Smaller NGOs must not be left without protection while larger ones have the means to defend themselves. That is why accessible objections, fee relief and transparency are essential so the system does not tilt toward the richer actors.</p>
<p>Best,</p>
</div>
</div><div dir="auto">Emmanuel </div><div dir="auto"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Typed with thumbs, powered by caffeine. Please excuse typos & brevity!</div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 24 Sep 2025 at 18:35 Juan Manuel Rojas via NCSG-PC <<a href="mailto:ncsg-pc@lists.ncsg.is" target="_blank">ncsg-pc@lists.ncsg.is</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div id="m_-2686327586996747872m_1279193190579239878m_-7693426313232295968yiv0902619900">Hi everyone, <div><br clear="none"></div><div>Thanks for this fruitful discussion. My only concern with Option 1 is that protection is only for those Reserved Names, such as redcross and IOC. Any other string wouldn't be protected. </div><div>I mean, this approach could be narrow for protecting just what is already protected. </div><div><br></div><div>Option 2 doesn’t silence applicants, it prevents confusingly similar strings from being delegated in cases where the risk of user harm is very high (e.g., phishing, fraud, reputational damage targeting humanitarian or global public-interest names). This is about protecting end users, not expanding rights unnecessarily.</div><div><br></div><div>It also avoids putting the entire burden on INGOs/NGOs to constantly monitor applications and file objections — a process that favors those with resources and excludes smaller organizations. Applying string similarity checks to reserved names simply makes their protection meaningful and consistent with ICANN’s existing goal of avoiding user confusion.</div><div><br></div><div>At the beginning I was in favor of option 1, but I asked inside IRT about if other names would be protected, such as msf or scouts or greenpreace but it was a negative answer. </div><div><br></div><div>Best,</div></div></blockquote></div></div></blockquote><div><br></div><div><br></div><div dir="ltr" class="gmail_attr">From: <strong class="gmail_sendername" dir="auto">Pedro de Perdigão Lana</strong> <span dir="auto"><<a href="mailto:pedrodeperdigaolana@gmail.com">pedrodeperdigaolana@gmail.com</a>></span><br>Date: Wed, 24 Sept 2025 at 22:39<br>Subject: Re: [NCSG-PC] Discussion in SubPro IRT headed to Council<br>To: Johan Helsingius <<a href="mailto:julf@julf.com">julf@julf.com</a>><br>Cc: <<a href="mailto:ncsg-pc@lists.ncsg.is">ncsg-pc@lists.ncsg.is</a>><br></div><br><br><div dir="ltr"><div>Hi all,</div><div><br></div><div>Jumping in to recognize Juan's arguments and concerns, which makes a lot of sense, especially when we think about non-commercial organizations. However, <b>I would also go with option 1</b>, and my main argument would be this phrase: "This option could close off opportunities for legitimate, unrelated applicants who might use the string for a different purpose". The way I see it, it really applies against option 2 - the movement to expand IP rights to provide more ambiguity on what is being protected has led, way too many times, to abuse and overreach by right-holders. </div><div><br></div><div>The positive effects (towards NGOs, SMEs, market competition, etc) are historically invoked to argue for those expansions, but then the new rights tend to be used by those who have enough resources to push, bit by bit, the boundaries of the framework, especially against those who can't really fight back. I also respectfully believe it does not make things simpler; the idea of similarity creates a lot of complexity in practical implementation (and this is where the boundaries can be pushed).</div><div><br></div><div>Cordially,</div><div><br clear="all"></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2"><b>Pedro de Perdigão Lana</b><br></font></font></span><div><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2"><a href="https://www.nic.br/" target="_blank">Lawyer</a>, </font></font></span><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2"><font size="1"><font size="2"><font size="1"><font size="2"><a href="https://www.gedai.com.br/" target="_blank">GEDAI/UFPR</a> Researcher</font></font></font></font></font></font></span></div><div><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2">PhD Candidate (UFPR), LLM in Business Law (UCoimbra)</font></font></span><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2"><font size="1"><font size="2"></font></font></font></font></span></div><div><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2"></font></font></span></div><div><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2">Coordination/Board/EC @</font></font></span><span style="font-family:"times new roman",serif"><font size="1"><font size="2"> </font></font></span><span style="font-family:garamond,"times new roman",serif;color:rgb(0,0,0)"><a href="https://www.isoc.org.br/" target="_blank">ISOC Brazil</a>,</span><span style="font-family:garamond,"times new roman",serif;color:rgb(0,0,0)"><font size="1"><font size="2"> </font></font><font size="2"><a href="https://www.ncuc.org/" target="_blank">NCUC</a> & <a href="https://community.icann.org/display/gnsononcomstake/Home" target="_blank">NCSG </a>(ICANN) and </font></span><span style="font-family:garamond,"times new roman",serif;color:rgb(0,0,0)"><font size="1"><font size="2"><a href="https://br.creativecommons.net/" target="_blank">CC Brazil</a></font></font></span><span style="font-family:garamond,"times new roman",serif;color:rgb(0,0,0)">.</span><span style="font-family:garamond,"times new roman",serif"><font size="1"><font size="2"><br></font></font></span></div><div><span style="font-family:garamond,"times new roman",serif"></span></div><div><font size="1"><span style="font-family:garamond,"times new roman",serif">This message is restricted to the sender and recipient(s). If received by mistake, please reply informing it.</span></font></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 24 de set. de 2025 às 06:09, Johan Helsingius via NCSG-PC <<a href="mailto:ncsg-pc@lists.ncsg.is" target="_blank">ncsg-pc@lists.ncsg.is</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree 100% with this. Thank you Manju for expressing it so<br>clearly.<br><br> Julf<br><br><br>On 24/09/2025 10:51, Manju wrote:<br>> Hi,<br>><br>> Respectfully, I disagree with Juan's assessment.<br>> I think we should support option 1. My reasons are:<br>><br>> *Freedom of speech*<br>> NCSG always advocates for freedom of speech in the domain space. The<br>> protection offered to the INGOs and NGOs were merely 'exact match'.<br>> Extending the protection to string similarity is out of proportion and<br>> might harm the right of free speech of other applicants.<br>><br>> *IRT should not make new policy.*<br>> Some claim that extending protection from exact match to string<br>> similarity is NOT making new policies. I disagree. The policy said<br>> 'exact match'. If the WG meant to protect the strings from visual<br>> similarities, it should and would have suggested so.<br>><br>> *Mechanisms available for INGOs/NGOs other than string similarity reviews.*<br>> Some argue that without the string similarity reviews, others might be<br>> able to apply and get strings that are visually similar to IGO/INGO<br>> names, and IGO/INGO will lose the chance to apply for their names as a<br>> result. This is not true. The INGOs and NGOs can always resort to the<br>> objection process if they identify strings that are 'confusingly similar<br>> visually, aurally, or in meaning' to their names.<br>><br>> Please keep in mind that the IGO/INGOs whose names are listed and<br>> protected are the global rich ones, they have the resources and money to<br>> monitor the applications and go through the objection processes to<br>> protect their names if they wish so. They already enjoy special<br>> treatment than the other hundreds of thousands of smaller non-global<br>> NGOs. In NCSG, we should aim to protect all scales of NGOs, not<br>> only excessive protection for the international ones.<br>><br>><br>> My 2 cents.<br>><br>><br>> Best,<br>> Manju<br>><br>> On Tue, Sep 23, 2025 at 7:51 PM Tomslin Samme-Nlar<br>> <<a href="mailto:mesumbeslin@gmail.com" target="_blank">mesumbeslin@gmail.com</a> <mailto:<a href="mailto:mesumbeslin@gmail.com" target="_blank">mesumbeslin@gmail.com</a>>> wrote:<br>><br>> Thanks so much for clarifying, Juan.<br>><br>> I would like to hear from the rest of PC what their thinking is. I<br>> believe we need to have a position before October 9th.<br>><br>> Remain blessed,<br>> Tomslin<br>><br>><br>> On Tue, 23 Sept 2025 at 12:54, Juan Manuel Rojas <<a href="mailto:jumaropi@yahoo.com" target="_blank">jumaropi@yahoo.com</a><br>> <mailto:<a href="mailto:jumaropi@yahoo.com" target="_blank">jumaropi@yahoo.com</a>>> wrote:<br>><br>> Hi Tomslin,<br>><br>> Thank you for raising these important questions<br>><br>> On your first question: Option 2 does not create new policy, but<br>> reflects an implementation choice. The SubPro Final Report<br>> already calls for reserved names to remain protected and for<br>> string similarity reviews to prevent delegation of confusingly<br>> similar strings where user confusion is likely. Option 2 simply<br>> applies that protection to names already on the Reserved List,<br>> which I see as consistent with the policy’s intent and critical<br>> to preserving trust and predictability in the DNS.<br>><br>> On your second question: expanding the Reserved Names list to<br>> include additional INGOs would indeed be a new policy<br>> recommendation. My suggestion is not a reinterpretation of<br>> existing policy, but an invitation for discussion. Instead, my<br>> intent was to flag this as an idea that could be relevant for<br>> future consideration, particularly from the perspective of NCSG<br>> and other non-commercial stakeholders, who may be<br>> disproportionately affected by misuse of their names or missions.<br>><br>> Of course, my proposal is not one of the options currently<br>> before the Council. It was raised during discussions in the IRT,<br>> and I thought it was important to share it here, not as<br>> something to be decided now, but as context and as a potential<br>> consideration for the future.<br>><br>> The intent was simply to highlight that, when we think about<br>> string protections and predictability, we might also need to<br>> think about globally recognized non-commercial organizations<br>> whose missions could be harmed by misuse of their names. My hope<br>> is that sharing this idea now can help inform our thinking as we<br>> look ahead and continue to advocate for the interests of those<br>> we represent.<br>><br>> *JUAN MANUEL ROJAS, M.Sc.*<br>> Director - MINKA DIGITAL Colombia<br>> NPOC Chair - NCSG/GNSO<br>> M.Sc. Information Technology<br>><br>> Registered Linux User No.*533108.*<br>> <a href="http://www.jmanurojas.com/" rel="noreferrer" target="_blank">http://www.jmanurojas.com</a> <<a href="http://www.jmanurojas.com/" rel="noreferrer" target="_blank">http://www.jmanurojas.com</a>><br>> /<br>> /<br>> -----BEGIN GEEK CODE BLOCK-----<br>> Version: 3.1<br>> GIT d- s: a+ C+++ UL P+ L+++ !E !W+++ !N !o K+++ w-- !O M- V PS+<br>> PE-- Y+ PGP+ t+ 5 X++ R tv+ b+ DI D G e+++(+++)>+++ h+ r++ y+<br>> ------END GEEK CODE BLOCK------<br>><br>><br>><br>><br>><br>><br>><br>> El lunes, 22 de septiembre de 2025, 09:22:50 p.m. GMT-5, Tomslin<br>> Samme-Nlar <<a href="mailto:mesumbeslin@gmail.com" target="_blank">mesumbeslin@gmail.com</a><br>> <mailto:<a href="mailto:mesumbeslin@gmail.com" target="_blank">mesumbeslin@gmail.com</a>>> escribió:<br>><br>><br>> Hi Juan,<br>><br>> Thanks for this information.<br>><br>> You say you prefer option #2. My question to you as the expert<br>> is, does it or does it /not/ create new policy? I believe the<br>> answer to that question may quicken our position.<br>><br>> Secondly, you are proposing expanding the list of reserved<br>> names. Again, is that in the approved INGO policy or is that a<br>> new policy recommendation from you? This also doesn't appear to<br>> be on the options tabled to council.<br>><br>> Below is council support staff's analysis of the question.<br>> Please let us know if they got it wrong.<br>><br>> *"the proper option should flow out of the Council’s assessment<br>> of the underlying question. I believe that the underlying<br>> question is:____*<br>><br>> *____*<br>><br>> * */What does it mean for the full name identifiers to be<br>> “protected,” but available for the relevant organization via<br>> an exception procedure? /____*<br>><br>> *//____*<br>><br>> *There are two interpretations:____*<br>><br>> *____*<br>><br>> * *Protected only means that no organization other than the<br>> relevant organization can apply for the exact match of the<br>> full name identifier, full stop. This implies that an<br>> unrelated third party could apply for a confusingly similar<br>> string, thereby preventing the relevant organization from<br>> securing their protected string in the future - (option 1).____*<br>> * *Or, protected means that no organization other than the<br>> relevant organization can apply for the exact match of the<br>> full name identifier AND the ability for the relevant<br>> organization to secure their protected string should<br>> persist. This implies that unrelated third parties would<br>> need to be prevented from securing confusingly similar<br>> strings (i.e., include the protected strings in string<br>> similarity) - (option 2).____*<br>><br>> *____*<br>><br>> *These are the competing interpretations of Board-adopted<br>> recommendations, which are reproduced below (note, I’ve only<br>> included the recs for the Red Cross Red Crescent Movement, but<br>> there are similar recs for the International Olympic Committee<br>> and IGOs). To try and answer Paul’s specific question, option 2<br>> is what implementing staff believes aligns with the intent of<br>> the PDP’s recommendations and is therefore not a policy change<br>> or new policy (setting aside the fact that a majority of the IRT<br>> disagrees with the staff’s interpretation).____*<br>><br>> *____*<br>><br>> *Recommendation 3.1.1:____*<br>><br>> *Top-Level protections of Exact Match, Full Name Scope 1<br>> identifiers of the Red Cross Red Crescent Movement are placed in<br>> the Applicant Guidebook section 2.2.1.2.3, Strings “Ineligible<br>> for Delegation”.____*<br>><br>> *Recommendation 3.1.2:____*<br>><br>> *For Red Cross Red Crescent Movement identifiers, if placed in<br>> the Applicant Guidebook as ineligible for delegation at the Top-<br>> Level, an exception procedure should be created for cases where<br>> a protected organization wishes to apply for their protected<br>> string at the Top-Level."*<br>><br>><br>> Remain blessed,<br>> Tomslin<br>><br>> On Tue, 23 Sept 2025, 10:17 Juan Manuel Rojas via NCSG-PC,<br>> <<a href="mailto:ncsg-pc@lists.ncsg.is" target="_blank">ncsg-pc@lists.ncsg.is</a> <mailto:<a href="mailto:ncsg-pc@lists.ncsg.is" target="_blank">ncsg-pc@lists.ncsg.is</a>>> wrote:<br>><br>> Dear all,<br>><br>> As many of you know, though perhaps not everyone, the staff<br>> of the Subsequent Procedures (SubPro) Implementation Review<br>> Team (IRT) has asked to address concerns about the ongoing<br>> discussion on “String Similarity” and its relationship to<br>> “Reserved Names.” The IRT and staff have not yet been able<br>> to reach agreement on this topic. It was presented during<br>> the last Council meeting by ICANN staff and the Council<br>> liaisons.<br>><br>> To provide some context about the disagreement: staff has<br>> proposed two options to address the issue of Reserved Names<br>> such as “redcross” and “olympic”:<br>><br>> Option 1: Eligibility-Only Protection<br>> Reserved Names are restricted by eligibility to apply but<br>> do not receive additional protection in the string<br>> similarity evaluation. This means that if a confusingly<br>> similar string (e.g., “re̱dcross”) is applied for first, the<br>> Reserved Name itself could be blocked or placed into<br>> contention in a later round. Ultimately, only one of the<br>> strings can be delegated.<br>><br>> Option 2: Eligibility & Similarity Protection<br>> Reserved Names are restricted by eligibility and are<br>> protected during string similarity evaluations, which blocks<br>> confusingly similar strings from delegation. This option<br>> provides stronger protection for end-users by preventing<br>> potentially confusing names from proceeding. For example, if<br>> “redcross” is applied for by an eligible entity, “re̱dcross”<br>> cannot be delegated.<br>><br>> During these discussions, a third idea has emerged:<br>><br>> Option 3: Automatic Delegation for Exact Match<br>> Exact-match Reserved Names requested by eligible entities<br>> (such as the Red Cross or IOC) would bypass both the String<br>> Similarity Review and the String Confusion Objection (SCO)<br>> processes, resulting in automatic approval whenever applied<br>> for by the designated organizations. However, this option<br>> has been considered out of scope for the IRT and is<br>> therefore not currently under discussion.<br>><br>> Here is my analysis of the two main options:<br>><br>> Option 1 (Preferred by the IRT):<br>><br>> *<br>><br>> Under Option 1, anyone could apply<br>> for .scout, .msf, .greenpeace, etc.<br>><br>> *<br>><br>> The burden would be on WOSM, MSF, or any other INGO to<br>> file Community Objections or use other Rights Protection<br>> Mechanisms (RPMs) to stop misuse.<br>><br>> *<br>><br>> This approach is expensive and reactive, and puts INGOs<br>> in a weak position if they miss deadlines or cannot<br>> afford legal fees.<br>><br>> *<br>><br>> The Subsequent Procedures PDP did not recommend<br>> expanding protections beyond exact matches of reserved<br>> names.<br>><br>> *<br>><br>> Blocking similar-but-not-identical strings could be seen<br>> as policy overreach by staff or the Board, effectively<br>> rewriting community consensus.<br>><br>> *<br>><br>> This option could close off opportunities for<br>> legitimate, unrelated applicants who might use the<br>> string for a different purpose.<br>><br>> *<br>><br>> It allows applicants to apply and make their case but<br>> leaves the resolution to objections and contention<br>> procedures.<br>><br>> *<br>><br>> Broad protections may reduce competition and concentrate<br>> control over generic strings.<br>><br>> Option 2 (Suggested by the Board):<br>><br>> *<br>><br>> Delegating two very similar strings (e.g., redcross and<br>> re̱dcross) could mislead users.<br>><br>> *<br>><br>> Confusion could lead to fraud, phishing, or reputational<br>> harm — not just to rights holders but to the DNS<br>> ecosystem as a whole.<br>><br>> *<br>><br>> Blocking such strings preemptively helps ICANN avoid<br>> politically sensitive controversies.<br>><br>> *<br>><br>> Option 2 keeps things simple: if the protected name is<br>> ineligible, its confusingly similar variant is also blocked.<br>><br>> *<br>><br>> Applicants know up front that certain names are not<br>> available, which improves predictability.<br>><br>> My Proposal:<br>> Option 2 already prevents confusingly similar strings<br>> from being delegated to unrelated applicants — but only for<br>> strings that are already on the Reserved Names list (e.g.,<br>> Red Cross, Olympic).<br>><br>> I propose expanding the list of protected names to include<br>> globally recognized INGOs, such as WOSM (World Organization<br>> of the Scout Movement) and MSF (Médecins Sans Frontières /<br>> Doctors Without Borders), as examples. Once these INGOs are<br>> on the reserved list, their names and visually confusable<br>> strings would be automatically protected, and they could use<br>> the existing exception procedure to apply for their own string.<br>><br>> This is not about over-blocking or granting unlimited<br>> protections. It is about ensuring that globally recognized<br>> INGOs have a fair, safe, and predictable pathway to<br>> participate in the next round of new gTLDs.<br>><br>> *JUAN MANUEL ROJAS, M.Sc.*<br>> Director - MINKA DIGITAL Colombia<br>> NPOC Chair - NCSG/GNSO<br>> M.Sc. Information Technology<br>><br>> Registered Linux User No.*533108.*<br>> <a href="http://www.jmanurojas.com/" rel="noreferrer" target="_blank">http://www.jmanurojas.com</a> <<a href="http://www.jmanurojas.com/" rel="noreferrer" target="_blank">http://www.jmanurojas.com</a>><br>> /<br>> /<br>> -----BEGIN GEEK CODE BLOCK-----<br>> Version: 3.1<br>> GIT d- s: a+ C+++ UL P+ L+++ !E !W+++ !N !o K+++ w-- !O M- V<br>> PS+ PE-- Y+ PGP+ t+ 5 X++ R tv+ b+ DI D G e+++(+++)>+++ h+<br>> r++ y+<br>> ------END GEEK CODE BLOCK------<br>></blockquote></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div id="m_-2686327586996747872m_1279193190579239878m_-7693426313232295968yiv0902619900"><div><br clear="none"><div id="m_-2686327586996747872m_1279193190579239878m_-7693426313232295968yiv0902619900ymail_android_signature"><a rel="nofollow noopener noreferrer" shape="rect" id="m_-2686327586996747872m_1279193190579239878m_-7693426313232295968yiv0902619900ymail_android_signature_link" href="https://mail.onelink.me/107872968?pid=nativeplacement&c=US_Acquisition_YMktg_315_SearchOrgConquer_EmailSignature&af_sub1=Acquisition&af_sub2=US_YMktg&af_sub3=&af_sub4=100002039&af_sub5=C01_Email_Static_&af_ios_store_cpp=0c38e4b0-a27e-40f9-a211-f4e2de32ab91&af_android_url=https://play.google.com/store/apps/details?id=com.yahoo.mobile.client.android.mail&listing=search_organize_conquer" target="_blank">Yahoo Mail: Search, Organize, Conquer</a></div> <br><br clear="none"> <div id="m_-2686327586996747872m_1279193190579239878m_-7693426313232295968yiv0902619900yqt31318"></div></div></div>_______________________________________________<br>
NCSG-PC mailing list<br>
<a href="mailto:NCSG-PC@lists.ncsg.is" target="_blank">NCSG-PC@lists.ncsg.is</a><br>
<a href="https://lists.ncsg.is/mailman/listinfo/ncsg-pc" rel="noreferrer" target="_blank">https://lists.ncsg.is/mailman/listinfo/ncsg-pc</a><br>
</blockquote></div></div>
_______________________________________________<br>
NCSG-PC mailing list<br>
<a href="mailto:NCSG-PC@lists.ncsg.is" target="_blank">NCSG-PC@lists.ncsg.is</a><br>
<a href="https://lists.ncsg.is/mailman/listinfo/ncsg-pc" rel="noreferrer" target="_blank">https://lists.ncsg.is/mailman/listinfo/ncsg-pc</a><br>
</blockquote></div></div>
_______________________________________________<br>
NCSG-PC mailing list<br>
<a href="mailto:NCSG-PC@lists.ncsg.is" target="_blank">NCSG-PC@lists.ncsg.is</a><br>
<a href="https://lists.ncsg.is/mailman/listinfo/ncsg-pc" rel="noreferrer" target="_blank">https://lists.ncsg.is/mailman/listinfo/ncsg-pc</a><br>
</div></div></div>