ICANN/GNSO GNSO Email List Archives

[council]


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

Re: [council] FW: Specification 13 : Letter to the GNSO

  • To: council@xxxxxxxxxxxxxx
  • Subject: Re: [council] FW: Specification 13 : Letter to the GNSO
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Thu, 08 May 2014 09:37:22 -0400
  • In-reply-to: <018101cf6abc$d5819930$8084cb90$@afilias.info>
  • List-id: council@xxxxxxxxxxxxxx
  • References: <OFEDAC87EF.4839AB5B-ON80257CC7.00773FEE@hsbcib.com> <885284E9BF6A4863AB7530FF2CE6DC00@ZaparazziL11> <CF83BA94.F9B4%jeff.neuman@neustar.us> <016301cf62e2$47c35bb0$d74a1310$@afilias.info> <OF6D56816B.37972768-ON80257CC8.00726D74-80257CC8.0072DE25@hsbcib.com> <01bb01cf632a$9782c620$c6885260$@afilias.info> <C6B1D7D52C8B45268815964C3370512F@ZaparazziL11> <008301cf6385$361d8c20$a258a460$@afilias.info> <1714D4FAACE04AA5AEAA6352CD2C447B@ZaparazziL11> <007701cf6a94$dc0a7290$941f57b0$@afilias.info> <536B7A57.6000104@acm.org> <018101cf6abc$d5819930$8084cb90$@afilias.info>
  • Sender: owner-council@xxxxxxxxxxxxxx
  • User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Hi,

Thanks for this bit of information.  So the case is more akin to the IGO
requests, where a non participant in the GNSO process makes a request
for exception.

Have we defined the GNSO interface for gTLD registries which are not
part of the RySG?  Seems like something else we may need to find a
process for.

Thanks

avri

On 08-May-14 08:55, Jonathan Robinson wrote:
> Avri,
> 
> Thanks for this comprehensive input.  One quick response to your question
> (from my experience as an RySG Councillor):
> 
> The RySG has been active in in working on evolution to accommodate new gTLDs
> (and all that this entails) for some time.
> But, to the best of my knowledge, the RySG does not have any clearly defined
> current or future relationship with the BRG.
> 
> 
> Jonathan
> 
> -----Original Message-----
> From: Avri Doria [mailto:avri@xxxxxxx] 
> Sent: 08 May 2014 13:37
> To: council@xxxxxxxxxxxxxx
> Subject: Re: [council] FW: Specification 13 : Letter to the GNSO
> 
> 
> Hi,
> 
> Thanks you for this additional information.
> 
> I am still inclined against this motion.  Some of my reasons.
> 
> - I do not think it is necessary as the Registry can tailor its
> Regsitry-Registrar agreement to its specific needs.  That, especially when
> combined with the lack of restrictions on VI, means they would not be
> blocked from making registrations according to their specification.
> This is a practice that community gTLD and geographical gTLDs, another of
> the emergent categories, will need to follow.
> 
> - I think the process needs to be followed.  It is perhaps unfortunate that
> ICANN or their ICANN experienced consultants did not better explain the
> ICANN consensus policy affect on contracts to the applicants, but their lack
> of understanding is not reason for abrogating the processes we are fighting
> hard to see maintained in other issues.  This BRG process has been going on
> for a while now, and we may have even been a good way through a PDP had the
> RySG (I am assuming they are part of the RySG, is that the case?) initiated
> a PDP process as soon as the problem became apparent.  So even if they could
> not have started 2 years ago, they might have 1 year ago.
> 
> - This is not a simple tweak to the policies, It is not similar to 'just'
> adding additional names to an already existing reserved name list.  This
> overturns an essential principle of the relationship between registrars and
> registries - the non discrimination clause. The unintended long term
> consequences of this precedent needs to be understood. Again that is what a
> PDP is for.
> 
> - I think that if this were an PDP we might find that the other emergent
> categories of new gTLD applicant might also benefit from carefully crafted
> exception processes.  For example I can imagine that geographical gTLDs
> mights want to focus on local registrars, and communities might want to
> focus on specific registrars - both of these categories also provide
> restricted registrations. I am sure that the idea that a Registry could pick
> 3 special registrars for their business, might be advantageous to other
> non-promiscuous gTLDs (i.e gTLDs that offer themselves to just any
> registrant).
> 
> We also have to take into account that what we are trying to work around is
> an artificial boundary imposed by Staff without a prior policy process.  At
> what point did the GNSO decide that a registry would be limited in the
> number of registrations it could make on its own behalf.
>  That limit, a policy to be certain, was imposed by staff unilaterally.
>  During the original policy discussions we did discuss the notion of a
> membership based organization giving free registrations to its members.
> This was assumed to be possible, though we did not get into the registration
> models - another lesson about the need to defining the minutia of a policy.
> Why are not talking about removing the limit of registrations a registry can
> use for its own purposes.  It could solve the BRG problem and would possibly
> help other registries as well.  Again this is an issue that could have been
> reviewed if we had engaged in a proper PDP process on the issue of single
> user gTLDs - a topic we have known about since the VI discussions.  One can
> argue that this problem is not because of the Equal Treatment rule but
> because of an arbitrary limit set by staff.
> 
> Rushing like this to satisfy an ICANN pressure group is something that we
> have to put a stop to, in my opinion.  I do not see how we can, as a council
> committed to protecting GNSO processes, approve this exception.
>  Recently we put the GAC request on IGO-INGO through PDP despite their
> strong reaction against it.   I do not understand how it is appropriate
> to give the BRG a policy process work-around we refused the GAC.  If nothing
> else we will be authorizing the Board to ignore the work of the PDP whenever
> convenient.
> 
> The Board does have the ability to decide that this is a necessary Temporary
> Policy. If that were to have been the solution the Board had chosen we could
> then have an adequate process for resolving any of the issues related to
> this issue.  Unfortunately, as I understand it, that is not the path they
> took, nor the path we are recommending.
> 
> avri
> 
> 
> On 08-May-14 04:09, Jonathan Robinson wrote:
>> All,
>>
>>  
>>
>> Please see attached letter received today from the BRG.
>>
>>  
>>
>> Thanks.
>>
>>  
>>
>> Jonathan
>>
> 
> 
> 



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