ICANN/GNSO GNSO Email List Archives


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

RE: [council] Registry Operators

Please forgive my frustration Kristina.  I should avoid responding at
night and wait until morning because I am definitely a morning person.

Let me try to explain my line of thought.

During the lengthy discussions about GNSO improvements as the BGC WG was
finalizing its recommendations a lot of time was spent on the question
of where suppliers in general should fit in the GNSO.  You will recall I
am sure that it was noted that ISPs are suppliers and the idea of
including them on the supplier side was considered.  Resellers are
another example.  During those discussions it was pointed out that all
suppliers are not situated similarly in terms of how they impacted with
regard to consensus policies.  Suppliers who have contracts with ICANN
as registries or registrars are required to implement applicable
consensus policies; other suppliers have no such obligation.  This in no
way means that other suppliers are not impacted by consensus policies
but they definitely do not incur new contractual requirements.

When it was initially decided to include the requirement to implement
consensus policies in registry and registrar agreements, it was fully
understood that this was a very unique contractual term.  It has been
pointed out many times over the years by various parties that any
parties who execute such agreements are committing themselves to abide
by policies that are unknown when they sign the agreements. Therefore,
some bounds were put around what could be a consensus policy (e.g., the
picket fence) to try to control the risk in a reasonable manner.  In the
development of existing voting rules in the Council, this same issue was
considered and that resulted in what we know today as weighted voting,
an effort to create some balance between those who are required to
implement consensus policies and those who do not.  There of course has
been a lot of objection to this, but in my opinion, before weighted
voting was put in place, the contracted parties had little influence
over policy development even though they were directly impacted.

Now to the point at hand.  If we had a supplier house that included
contracted and non-contracted parties, entities with no obligation to
fulfill consensus policies could have significant influence over those
who do.  Let's use the RySG as an example. Right now we have 14 members
who all have contracts with ICANN.  If we added potential new registry
operators as voting members, the RySG could be overwhelmed by those
without contracts and the 14 who are required to follow consensus
policies could end up having very little voice even though their
business models could be directly impacted. I believe that the BGC WG
and ultimately the full Board recognized the significance of this issue
in deciding to make a registry or registrar agreement a prerequisite to
membership in what we now know as the Contracted Party House.

None of this is new.  In fact, everything I have said has been said many
times over and that was the source of my frustration.

You were correct in your observation that ICANN controls who becomes a
member of the Contracted Party House because they are a party to the
contracts.  But as it stands now, ICANN also controls who becomes
members of the SGs in the Non-contracted Party House via SG and
Constituency Charter approval.  I seriously doubt that ICANN Staff speed
up or delay registry or registrar agreement execution because of wanting
to control the timing of when registries or registrars become eligible
to join a constituency and I don't believe there is any evidence to
support that.

I think the question at hand is where do potential registries and
registrars fit until they do execute contracts.  In the case of
potential registries, they are definitely welcome in the RyC (soon to be
RySG) as observers and I think the same is true for registrars.  Should
they be allowed in non-contracted party constituencies or SGs?  I am
sure that some organizations who may become registries already are
members of non-contracted party constituencies so it is a natural
occurrence.  Should new members who specifically want to become involved
to be a registry or registrar be admitted into those constituencies
until such time as they execute contracts?  That is a decision for those
constituencies and the Board in their approval of charters.  I
personally have tried to avoid trying to suggest what other
constituencies should do.

A side topic that we have not spent much time talking about is this:
Many organizations have multiple lines of business that fit into
different GNSO boxes.  For example, from an interest point of view,
VeriSign fits into the RyC, the CBUC and the IPC.  In the case of the
IPC, we have been allowed to participate; in the case of the CBUC, we
have not been allowed.  I support what the President Strategy Committee
recommends: organizations should be allowed to participate in multiple
constituencies but should only be allowed to vote in one. There are
chances that this issue will be expanded in a new way with new gTLDs if
registrars become registries.

Sorry for going on so long.  Hope this helps.


> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx 
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Rosette, Kristina
> Sent: Wednesday, July 15, 2009 12:22 AM
> To: Council GNSO
> Subject: RE: [council] Registry Operators
> I'll take that as an "I'm not", Chuck.  
> If you could, please, connect the dots for me. I don't 
> understand the connection you've drawn.  How would admitting 
> registry operators (or the IDN constituency or the Cities 
> constituency) to the RyC/RC Group affect the prior commitment 
> to be bound by consensus policy?  I'm definitely not getting it.
> Not sure of the point behind the lack of empathy/retread 
> comment.  I didn't start this thread and my question is one 
> that I don't believe I've ever raised or heard raised.
> -----Original Message-----
> From: Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx]
> Sent: Tuesday, July 14, 2009 11:02 PM
> To: Rosette, Kristina; Council GNSO
> Subject: RE: [council] Registry Operators
> It gets very frustrating to go through this same issue over 
> and over again.  There is a very clear reason why the RyC and 
> the RrC are restricted to those who have registry or 
> registrar agreements with
> ICANN: In those agreements, registries and registrars commit 
> in advance to implementing consensus policies that are within 
> the picket fence without having any knowledge of the details 
> of those polices.  That is a very exceptional situation in 
> the world of business contracting as I have to believe 
> attorneys know full well.  As a result of that 'blind'
> commitment, registries and registrars can be seriously 
> impacted by policy development actions of the GNSO.
> I can accept the fact that some may not have any empathy for 
> the contracted parties and may not like this but let's at 
> least not continue to retread ground that we have covered 
> many times before. 
> Chuck
> > -----Original Message-----
> > From: owner-council@xxxxxxxxxxxxxx
> > [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Rosette, Kristina
> > Sent: Tuesday, July 14, 2009 10:47 PM
> > To: Council GNSO
> > Subject: RE: [council] Registry Operators
> > 
> > 
> > Am I the only who is troubled by the fact that restricting 
> membership 
> > in the registrar and registry constituency to entities that 
> are ICANN 
> > contracted parties effectively gives ICANN control over 
> which entities
> > are and are not members and the timing by which entities become 
> > eligible for membership?
> > 
> > -----Original Message-----
> > From: owner-council@xxxxxxxxxxxxxx
> > [mailto:owner-council@xxxxxxxxxxxxxx]
> > On Behalf Of Bruce Tonkin
> > Sent: Tuesday, July 14, 2009 9:25 PM
> > To: Council GNSO
> > Subject: RE: [council] Registry Operators
> > 
> > 
> > Hello All,
> > 
> > 
> > > 
> > > 
> > > Agreed, it is an old, important issue that is still 
> unresolved and 
> > > must be resolved before the GNSO restructure can take place.
> > 
> > It is certainly worth considering further.
> > 
> > Membership of the registry and registrar constituency has generally 
> > been very clear - based on the legal entity being a 
> contracted party 
> > with ICANN as either a TLD manager or a gTLD registrar.  This 
> > information is publicly available on the ICANN website.
> > 
> > There are other parties involved in the process of the domain name 
> > value chain.
> > 
> > E.g
> > 
> > (1) Consultants - there are many consultants and lawyers 
> that provide 
> > services to the members of the registry and registrar 
> constituency or 
> > members of other constituencies - these consultants and 
> lawyers can be
> > split across the business constituency and the IP constituency.
> > 
> > (2) Internet Service Providers - while some purely provide 
> > connectivity
> > - many of these companies have moved into value added 
> services - and 
> > many are significant suppliers of domain names (either as 
> accredited 
> > registrars, or as resellers of accredited registrars).
> > 
> > (3) Other domain name resellers - e.g portals (e.g Yahoo), software 
> > companies (e.g Microsoft), search engines (e.g Google), web hosting 
> > companies - there are wide range of domain name resellers.  Some of 
> > thee are very large companies and supply large volumes (e.g over 
> > 100,000
> > names) of domain names to their customers.   At different 
> > times staff or
> > consultants/external lawyers of these companies have been 
> members of 
> > registrar, business constituency or IP constituency.
> > 
> > (4) Domainers - these companies operate a portfolio of 
> domain names - 
> > they often do not supply domain name registration services to other 
> > parties - but may sell some of their domain name licences from
> > time-to-time.   They may be accredited registrars (usually 
> to get the
> > lowest possible wholesale price for domains), or may simply be 
> > resellers.  Where they are not registrars - it is not clear what 
> > constituency that should be members of.  They would 
> probably consider 
> > themselves to be members of the business constituency - as they are 
> > "business users" of domain names (earn revenue from advertising, or 
> > from the future sale of the domain name licence), and not 
> involved in 
> > supplying domain name registration services to third parties.
> > 
> > For consultants or lawyers it is often complex as they may 
> have some 
> > customers/clients that are associated with the domain name supply 
> > industry and some customers/clients that are not.
> > 
> > In many cases large companies have different departments (or legal
> > subsidiaries) - e.g a legal department, network connectivity 
> > department, domains/hosting department -  and it can be 
> convenient to 
> > have staff members of different departments/subsidiaries to join 
> > different constituencies (e.g Registrar, ISP constituency, IP 
> > constituency).
> > 
> > So do you make the decision on the basis of the corporate entity 
> > (could be operating across multiple area of interest in the 
> GNSO), or 
> > on the basis of the individual (may work for a particular 
> department 
> > of a corporate, or may work for many clients).
> > 
> > Ultimately this will probably be hard to resolve.  Perhaps 
> the best to
> > hope for is that members of constituencies clearly define their
> > potential conflicts of interest.   This could be at a 
> corporate level
> > and at an individual level (e.g identify clients involved 
> in different
> > constituencies if a consultant).   It would also be useful 
> to require
> > this to happen at the beginning of establishing working 
> groups (not as
> > a method of exclusion - but to clearly state potential conflicts).
> > 
> > 
> > The reality is that many members of the GNSO community can 
> potentially
> > participate in multiple roles.   Trying to create very 
> tight exclusion
> > rules (e.g you can be a member of constituency x - provided 
> you have 
> > no other relationship with any member of another
> > constituency) may unnecessarily restrict participation.
> > 
> > Regards,
> > Bruce Tonkin
> > 
> > 
> > 
> > 
> > 
> > 
> > 

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