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

[Jonathan Robinson]

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 at acm.org] 
Sent: 08 May 2014 13:37
To: council at gnso.icann.org
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
>