ICANN ICANN Email List Archives

[gnso-igo-ingo]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-igo-ingo] Re: [] RySG Recommendations

  • To: "GNSO IGO INGO (gnso-igo-ingo@xxxxxxxxx)" <gnso-igo-ingo@xxxxxxxxx>
  • Subject: [gnso-igo-ingo] Re: [] RySG Recommendations
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Tue, 23 Apr 2013 09:42:20 -0500

Hi,

Re the recommendations: my personal views and the views I will argue for within 
the NCSG while it debates its position:

> RySG Policy Recommendations
> 
> a.     As a basis for possible protection of full names:
>                         i.         Use the GAC lists of full names for the 
> IOC & RCRC at the top and second levels
>                        ii.         Use the GAC list of full IGO names (those 
> eligible for inclusion in the .int list) at the top and second levels

I still have not seen the legal reason for supporting this.  As we were told, 
while there may be jurisdictions within which some of these might be treated as 
protected, that is by no means universal.  In those areas where a registry and 
registrar is prevented by local law from offering such names they should not do 
so.  I have not seen a policy reason, other than placating the GAC, which says 
we have no right to make policy in this area, for creating policy around 
special privileges for these names.

Having said that, the pragmatics of the situation where the Board has already 
approved these special privileges, in a so-called temporary manner, I figure 
opposing this is a lost cause.

> b.     Require applicable IGOs to apply for protection of their full names at 
> the top and/or second levels prior to finalizing the list of qualifying 
> organizations that would receive protection

Against what standards would these applications be made?   If we are going to 
allow people to apply for special protection for their names we have to take 
the widest possible approach to this and allow every NGO and charitable 
institution the same privileges.

> c.     As a basis for possible protection of acronyms of IOC, RCRC and IGO 
> names, modify new gTLD rights protection mechanisms (TM Clearinghouse, URS & 
> UDRP) as applicable to include acronyms of the protected names from a. above 
> so that such acronyms could be included in both sunrise and claims processes 
> in the same way as trademarks in the TMCH.

While I support the inclusion of names into the TMCH for the organizations 
requesting special privileges, I do not accept the inclusion of acronyms.  As 
has been shown, these have too many other possible meanings and uses. 

I do support the use of URDP and URS by these organizations and support the 
expansion of UDRP and URS as needed to add these special protection privileges 
as a reason for use of UDRP and URS.

> d.     Provide an exception process whereby an organization not covered by 
> any protections but having legitimate rights could apply for a protected name

I do not support any form of exemption for names on a reserved list except the 
RSEP process.  Certainly within the RSEP process, the evidence of the 
privileged party should be taken into account, but only if it can be definitely 
shown and guaranteeed that no compensation either direct or indirect has been, 
or will be, given for the permission.  

> e.     Allow protected organizations to apply for their names at the top 
> level and/or second levels

I only support use of the RESP process as means of allowing a name on a 
reserved list to be registered.  

I do not support the creation of new mechansims for such reserved list 
registrations.

A question I ask, if we allow a designated agency to register 'its' reserved 
names, what is to stop it from then transferring that registration to a rich 
donor for a significant consideration.  Do we also need to put special 
condition in the IRTP process for these once reserved names?  Do we already 
have a defined process in the policy for a permanently non transferable name? 
Or would we need to create such a policy? (After years in the IRTP-x WGs I 
should know this but don't.  I know the state could probably be set, but could 
it be deemed permanent and immutable? )

> f.      Modify the TMCH to include protected organization full names.

I support this.

I thank the RySG for making the recommendations so easy to address.

avri


On 20 Apr 2013, at 13:28, Gomes, Chuck wrote:

>  
> Here are the RySG recommendations to the WG with regard to policy 
> recommendations.  David & I look forward to answering any questions and 
> discussing the recommendations further on list and in our meeting this coming 
> week.
>  
> 
> Chuck Gomes
> Vice President
> 
> cgomes@xxxxxxxxxxxx
> t: +1 530 676-1754  m: +1 703 362-8753
> VerisignInc.com
>  
> This message (including any attachments) is intended only for the use of the 
> individual or entity to which it is addressed, and may contain information 
> that is non-public, proprietary, privileged, confidential and exempt from 
> disclosure under applicable law or may be constituted as attorney work 
> product. If you are not the intended recipient, you are hereby notified that 
> any use, dissemination, distribution, or copying of this communication is 
> strictly prohibited. If you have received this message in error, notify 
> sender immediately and delete this message immediately.
>  
> 
> 
>  
>  
>  
> “This message (including any attachments) is intended only for the use of the 
> individual or entity to which it is addressed, and may contain information 
> that is non-public, proprietary, privileged, confidential and exempt from 
> disclosure under applicable law or may be constituted as attorney work 
> product. If you are not the intended recipient, you are hereby notified that 
> any use, dissemination, distribution, or copying of this communication is 
> strictly prohibited. If you have received this message in error, notify 
> sender immediately and delete this message immediately.”
> <IGO INGO PDP WG RySG Recommendations 20 Apr 2013.docx>





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy