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

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Avri,

Please see my responses below.

Chuck

> -----Original Message-----
> From: owner-gnso-igo-ingo@xxxxxxxxx [mailto:owner-gnso-igo-ingo@xxxxxxxxx]
> On Behalf Of Avri Doria
> Sent: Tuesday, April 23, 2013 10:42 AM
> To: GNSO IGO INGO (gnso-igo-ingo@xxxxxxxxx)
> Subject: [gnso-igo-ingo] Re: [] RySG Recommendations
> 
> 
> 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.
[Gomes, Chuck] As I think our document says, in our opinion there is not a 
definitive global legal reason, but there is quite a bit of legal evidence that 
some major jurisdictions provide various protections for the applicable 
organizations. Therefore, because this is a public policy issue, it seems 
reasonable to respect the advice of the ICANN advisory committee tasked with 
giving public policy advice.  With regard to letting each registry and 
registrar follow its own local laws, that would not provide a very predictable 
environment for registries, registrars, registrants or users, so it is our view 
that our recommendations provide more predictability while still being 
consistent with the principles and recommendations of the New gTLD PDP.

> 
> 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.
[Gomes, Chuck]  They would simply have to be on the GAC list.  The idea here is 
not to evaluate applications against specific standards but rather to only give 
protection to those listed organizations that actually want to have the 
protections and therefore not taking names out of commission if there is really 
not a desire for protection.  This would be a very simple process whereby an 
organization on the list would just request the protection offered by the 
policy.

> 
> > 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.
[Gomes, Chuck] We have the same concern; that is why we oppose direct 
protection like is proposed for the full organization names.  But we thought 
that this approach might be a reasonable approach to provide some protection 
for acronyms. Maybe this could be tweaked further.

> 
> 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.
[Gomes, Chuck] There is already precedent for an exception process with regard 
to 2-character second level domain names and this would not be much different 
than that.

> 
> > 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? )
[Gomes, Chuck] I am not aware of any such process that would prevent transfers. 
 There are requirements that deal with a situation where a legacy registration 
that was later disallowed are grandfathered until such time that they are 
deleted; such names would not be eligible for re-registration.  But I do not 
think that registrant transfers are disallowed.  

> 
> > 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>
>