Home / Blogs

Registrar Stakeholder Group in GNSO Works Against the ICANN Multistakeholder Social Compact

Protect your privacy:  Get NordVPN  [73% off 2-year plans, 3 extra months]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

One of the essential features of the social compact that makes ICANN viable in its stewardship of the Domain Name system is that the operations of the Contracted Parties, i.e. Registrars and Registries, are governed by the cooperation of the contracted parties and the non-contracted parties, i.e. the stakeholders, in the creation of policy. In ICANN, contracts and other agreements are the method by which this policy is instantiated.

The Registrar Accreditation Agreement (RAA) is one of those agreements that are expressions of ICANN policy. The RAA is the method by which the behavior of registrars is regulated by the multistakeholder community. It is in the purview of the GNSO, all of the GNSO, to participate in discussions concerning any changes to be made to the RAA.

Because of the Registrars Stakeholder Group (RrSG) insistence, a working group chartered to investigate issues that needed to be reviewed for possible changes to the RAA recommended that instead of having the members of the GNSO community participate in multistakeholder discussions, representatives be able to participate as observers. To some, like me, this was already an affront to the GNSO multistakeholder mandate. But as this was a recommendation of the WG it was brought to a motion in the GNSO.

Instead of accepting the compromise hammered out in the WG that they were members of, the Registrars have flatly refused to accept the recommendations of the WG; they have refused to allow members of the GNSO Non Contracted Parties to participate in these discussion even in the diminished role of observers. They have also rejected giving the rest of the ICANN community any view into their discussion with the staff. This is a rejection, I believe, of the fundamental nature of ICANN, and is a threat to ICANN’s ability to meet its Affirmation of Commitments (AOC) mandate for transparent and accountable governance.

Not only have the Contracted Parties prevented the acceptance of a Working Group Report that recommends adding observers to the group, they have stated flatly and unequivocally, that even if the GNSO were to succeed in a motion to allow Observers, they would not agree and would not participate in any discussion that included observers.

Swallowing their pride at this rebuff, the GNSO Non Contracted parties, i.e. the Commercial and Non-Commercial Stakeholders, have now put a motion on the table that includes a still further diminished role:

...

Whereas, a GNSO Council motion recommending that Staff adopt the process specified as Process A in the Final Report to develop a new form of RAA with respect to the High and Medium Priority topics described in the Final Report did not pass;

Whereas, the GNSO Council desires to approve an amended version of the process specified as Process B in the Final Report to develop a new form of RAA with respect to the High and Medium Priority topics described in the Final Report.

NOW THEREFORE, BE IT:

RESOLVED, that the GNSO Council recommends that Staff adopt an amended version of the process specified as Process B in the Final Report to develop a new form of RAA with respect to the High and Medium Priority topics described in the
Final Report. As amended herein, Process B entails:

1. The prioritized list of topics as set forth in the Final Report is sent to the GNSO Council and ICANN Staff for identification of any topics that would require consensus policy development rather than RAA contract amendment. This step shall be completed not later than sixty (60) days after the date of this resolution.

2. ICANN Staff will schedule a public consultation, to be held at the first ICANN public meeting that occurs after completion of the review in Step 1, to provide members of the ICANN community with the opportunity to articulate their support of and/or objection to the High and Medium Priority topics described in the Final Report.

3. Within thirty (30) days after the public consultation described in Step 2, negotiations begin with the Negotiating Group consisting of ICANN Staff and the Registrar Stakeholder Group (as a whole).

4. The Negotiating Group shall provide, for public comment, written reports monthly on the status and progress of the negotiations. Such reports shall include proposed text under consideration and identify items and text agreed upon by the Negotiating Group. The monthly report shall identify (a) topics identified in the Final Report as High or Medium Priority and that were not determined in Step 1 as requiring consensus policy development; and (b) proposed amendments put forth by any Stakeholder Group, Constituency, and/or Advisory Committee (collectively, the “Rejected Topics and Amendments”), if any, that have been rejected by the Negotiating Group.

5. The Negotiating Group reviews public comments received and continues negotiations as necessary. Steps 4 and 5 shall repeat as necessary; provided, however, that the full final draft of the new RAA must be posted for public comment not later than September 17, 2012.

6. Subject to the date requirement in Step 5, ICANN Staff and the Registrar Stakeholder Group shall determine when the full final draft of the new RAA is ready to be posted for public comment. The full final draft of the new RAA that is posted for public comment shall be accompanied by a detailed written explanation, approved by both Staff and the Registrar Stakeholder Group, that sets forth the basis for the rejection of all Rejected Topics and Amendments.

7. The GNSO Council shall review the full final draft of the new RAA, consider public comments, and vote on approval of the draft new RAA. A Supermajority vote of the GNSO Council is required to approve the new RAA.

8. If the GNSO Council approves the new RAA, the new RAA goes to Board for approval.

9. If the GNSO Council does not approve the new RAA, the new RAA is sent back to the Negotiating Group with appropriate feedback for reconsideration. Repeat from step 7.

In other words, no observers, but at least honest and complete reporting and review.

It is reported that the Registrars, along with their partners in the Contracted Parties House the Registries, will reject even this watered down notion of transparency, accountability and community input. The Registrars insist on negotiating with ICANN Staff in a secret back room with no one watching and without treports and review. No transparency and no accountability will be allowed; the Registrars are above such petty considerations.

This goes against every ICANN requirement for transparency and accountability. This also goes against the fundamental ICANN bargain that allows the contracted parties to have a voice in their regulation in exchange for the participation of those who are affected by the contracts—the Commercial and Non Commercial Users of the DNS as well as the ICANN community at large.

In refusing so absolutely, the Registrars are challenging the fundamental agreements that give ICANN legitimacy and precipitating a real crisis in the multistakeholder fabric of ICANN.

The basis of the Registrar refusal, as I understand it, is that the contract is between the Registrars and ‘ICANN’. As such having a bunch of interlopers observing, having a opinion, and possibly even commenting, is something they will just not abide. No discussion or compromise on this issue will be brooked.

There have been several startling statements of this refusal that have been made verbally and that can be found in various meeting transcripts. One clear example is the statement was made on the GNSO list:

Begin forwarded message:

From: “Tim Ruiz”

Date: 8 March 2011 22:41:09 PST
Cc: [email protected]
Subject: RE: [council] RAA Motion

As I’ve tried to point out before, this is a waste of time. The RAA is between ICANN and Registrars and only they will decide how the process takes place. And as was made clear to the RAA WG, Registrars will not engage if observers are present. All the Council should do at this point is thank the WG and let Registrars and Staff take from it there.

Tim

So the questions comes down to:

Who is ICANN?

The easiest and most complete answer:

ICANN is us.

ICANN is not just the President/CEO.
ICANN is not just the Operational Staff.
ICANN is not just the Registrar Support Staff.
ICANN is not just the General Counsel.

ICANN is the multistakeholder organization as defined by the Articles of Incorporation, the Bylaws and even the Registrar Accreditation Agreement.

If you go to About ICANN on the web site you see:

ICANN was formed in 1998. It is a not-for-profit public-benefit corporation with participants from all over the world dedicated to keeping the Internet secure, stable and interoperable. It promotes competition and develops policy on the Internet’s unique identifiers.

You will also see an organizational chart that shows that ICANN Staff is but one part of ICANN.

In the Bylaws one sees that:

Except as otherwise provided in the Articles of Incorporation or these Bylaws, the powers of ICANN shall be exercised by, and its property controlled and its business and affairs conducted by or under the direction of, the Board.

ICANN and its constituent bodies shall operate to the maximum extent feasible in an open and transparent manner and consistent with procedures designed to ensure fairness.

In carrying out its mission as set out in these Bylaws, ICANN should be accountable to the community for operating in a manner that is consistent with these Bylaws, and with due regard for the core values set forth in Article I of these Bylaws.

In other words, in all it does ICANN is governed by its bylaws, which include accountability to its community as one of the constituent parts defined in the bylaws.

Also, in all it does ICANN is governed by its commitment to transparency. Secret negotiations without observers or review are not transparent by any definition of the word.

In the Articles of Incorporation it says:

4. The Corporation shall operate for the benefit of the Internet community as a whole, carrying out its activities in conformity with relevant principles of international law and applicable international conventions and local law and, to the extent appropriate and consistent with these Articles and its Bylaws, through open and transparent processes that enable competition and open entry in Internet-related markets. To this effect, the Corporation shall cooperate as appropriate with relevant international organizations.

Again, the primary importance of openness and transparency in its operations consistent with the Bylaws.

It is also interesting interesting to note that the current versions of the Registrar Accreditation Agreement (RAA) says:

2.3 General Obligations of ICANN. With respect to all matters that impact the rights, obligations, or role of Registrar, ICANN shall during the Term of this Agreement:

2.3.1 exercise its responsibilities in an open and transparent manner;

2.3.2 not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition;

2.3.3 not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registrar for disparate treatment unless justified by substantial and reasonable cause; and

2.3.4 ensure, through its reconsideration and independent review policies, adequate appeal procedures for Registrar, to the extent it is adversely affected by ICANN standards, policies, procedures or practices.

So ICANN is committed to transparent operation in all matters related to the registrars. That is, no secrets. Not only is it illegitimate for the Registrars to demand a private negotiation with ICANN Staff, it is against the rules for ICANN Staff to agree to such a situation.

This quote from the RAA also indicates, by its reference to reconsideration and independent review, that the RAA process is part of other ICANN processes and not some special exception to normal ICANN processes.

The RAA is an agreement between the Registrars and the Internet Corporation for Assigned Names and Numbers, the California non-profit, public benefit corporation. The nature of that non-profit, public benefit organization is defined in the Bylaws, and neither the Registrars nor ICANN Staff can subvert that definition, and the rights of the stakeholders, without risking the destruction of one of the most fundamental bases of ICANN.

I hope that the Registrars find the wisdom to end their destructive behavior. I also hope the ICANN Staff has the sense not to enter into secret negotiations with the Registrars that exclude the rest of ICANN - the community that makes ICANN what it is.

As things stand now, I believe that the Registrars’ attitude on the process of negotiating changes to the Registrar Accreditation Agreement (RAA) is the greatest threat currently faced by ICANN. This is an issue that will not go away. It may be another year or two until the RAA under discussion comes up for approval by the GNSO, but the destruction being done by the Registrar Stakeholder Group to the fabric of the ICANN multistakeholder social compact will remain a topic between now and then, and will need to be one of the focal points of the next Affirmation of Commitments on Accountability and Transparency.

By Avri Doria, Researcher

Filed Under

Comments

RAA, the multistakeholder model and ICANN's Social Compact: a response to Contracted Party House co Avri Doria  –  Apr 12, 2011 9:49 PM

During the recent GNSO Council meeting, two members of the GNSO council, one from the Registrar Stakeholder Group (RrSG), and one from the Registries Stakeholder Group (RySG) criticized unnamed blogs for their position on the RAA discussion.  Of course I cannot be sure that they were referring to this blog entry, but since my blog was guilty of the omissions they discussed, I decided I ought to respond to the points they made.

First an RrSG Council member questioned why a blog that criticized the Registrars for excluding the members of the Non Contracted Parties House (NCPH) from discussions on the RAA had not also complained about being excluded in the negotiations over the .xxx contract, which was recently signed by ICANN.  For a moment, my first reaction was that this comment was a glib bit of derision, but then I realized that such would be out of character for a member of the GNSO Council.  So I decided to treat the comment seriously.

Part of my criticism of the RAA process is the RrSG’s insistance on negotiating only with ICANN Staff and without transparency.  I guess the implication was that the .xxx contract was negotiated only with ICANN Staff and without transparency.  Of course in one respect nothing could be further from the truth, ICM Registry has been through the ICANN gauntlet with every single detail of the their application, reviews and contract having been under the most critical of scrutiny.  But in one sense, the criticism may have been valid, certainly the members of the GNSO Council were not included as participants or even observers in the contract discussion between the ICM Registry and ICANN Staff. And maybe there is a point that needs to be explored about the modalities by which the GNSO council can participate in the process of reviewing contracts that affect the policy by which a registry operates.  A little more about this later as part of my response to the second comment.

The RySG council member criticized the bloggers for not having responded to the “Contracted Parties’ Statement on RAA to GNSO Council” in their blogs.  I have to confess I had not even read it and am ashamed to say I had not even known it existed.  Having been publicly admonished, albeit indirectly as a member of an unidentified group, I asked the RySG council member who had complained for a pointer to the statement and read it.

In this statement the CPH indicated that the critics were confused about the difference between an appropriate role for GNSO Policy making, i.e, within the picket fence, and an inappropriate role; i.e third parties in discussing contractual conditions.  While I admit that the role of the NCPH, in fact of the entire GNSO Council is different in discussing contractual conditions within the picket fence and other contractual conditions, the difference is not one of whether there is a role for the GNSO council but one of timing.  In the case of contractual condition within the picket fence, policy decisions become applicable as soon as the Policy Development Process (PDP) is completed, after Board action.  With other contractual conditions, those outside the picket fence, they only becomes applicable once the contract is signed.  Whether it is the RAA or contractual conditions pertaining to the Registry contracts, policy decisions only become applicable when the contract is signed.  The point is, the GNSO council is never a third party when discussing contractual conditions that pertain to the CPH, it is a integral part of the second party in the negotiations.

The application of the PDP to Registry contractual conditions was seen with the Contractual Conditions PDP, commonly referred to as PDP06: Policies for Contractual Conditions for Existing Registries.  While the registries Constituency protested all the way through this PDP about how it was not a legitimate PDP, it was found to indeed be a legitimate activity for the GNSO Council. From the Task Force Report Council Report to the Board on PDP Feb-06 posted on 4 October 2007:

1.11   On 27 September 2006, ICANN’s General Counsel responded to an inquiry from the Chair of the GNSO Council regarding the effect of GNSO policy recommendations on ICANN’s existing registry agreements. This communication stated that: “It is possible for the GNSO to recommend, and the Board to approve, consensus policy that would change all existing gTLD registry contracts, but that is dependent on both the policy and the impacted contracts, which have some variations between registries.” This memo also noted that the policy recommendations arising out of PDP Feb 06 “could be useful in negotiating future agreements and might impact amendments to existing agreements, even where consensus policy might limit the impact of such advice or policy on current agreements.”

The PDP Feb06 council recommendation then went on to make a set of recommendations that would apply to future Registry contracts.  The Board in its resolution (2008.01.02), wrote:

the Board accepts the GNSO’s recommendations on contractual conditions for existing gTLDs, and directs staff to implement the recommendations as outlined in the Council Report to the Board for PDP Feb-06.

That is not only did the GNSO Council make recommendations on contractual conditions outside the picket fence, but the ICANN General Counsel indicated that consensus policy was applicable and the Board endorsed the consensus policy recommendations through their resolution.  The indication from this result is that contractual conditions of a

ll kinds

are indeed within the policy purview of the GNSO Council.  There is no reason why the same reasoning, and hence process, would not be relevant to the negotiations on the RAA. 

A further data point is the inclusion of the draft Registry contract for new registries in the Draft Applicant Guidebook for the new gTLD program.  In this case, the entire community is party to reviewing and commenting on future contractual conditions.  This is totally appropriate as it is a manifestation of the ICANN Social Compact: when it comes to contractual regulation of Registries by ICANN, the community is an integral part of ICANN each with their roles and responsibilities.  This Social Compact applies as much to the Registrars, where the RAA must be recommended by the GNSO Council before being approved by the ICANN Board.

What might be under question is the modality of the community’s involvement in each of its roles and responsibilities.  In terms of the GNSO council, when dealing with Registrar and Registry issues, the PDP is the most common form of participation.  That may indeed be the error that occurred in the RAA discussions and the WG recommendations.  Instead of asking to be observers, the recommends should have included initiating a PDP on the non picket fence RAA conditions.  Instead the members of the NCPH in the GNSO Council got rebuffed even when requesting regular reports and the ability to comment.

Having considered the objections of the two GNSO Council members from the CPH, I feel I must reiterate my claim that in rejecting participation of the NCPH and the rest of the ICANN community in the discussion of the RAA, the CPH is abrogating the ICANN Social Compact, is going against the By-laws and is threatening the legitimacy of ICANN’s mandate to regulate Registries and Registrars through contractual conditions, both inside and outside of the picket fence. 

I do thank the RySG and RrSG Council members for making me take a second look at the issue and for causing me to realize that there were essential similarities in the case of Registry contractual conditions discussed in PDP Feb-06 and the Registrar Accreditation Agreements.  I continue to call for the RrSG to reconsider its refusal in this case.  I also suggest that the GNSO Council and others in ICANN,  review the modalities by which the GNSO council can fulfill its appropriate role and responsibilities in the discussion of ongoing contractual conditions discusions related to existing registry contracts including and especially at renewal time.  This should not be a difficult question as the PDP is the agreed upon method by which the GNSO discusses policy and makes recommendations.  I note that the modalities of the PDP include the use of the PDP for both issues within the picket fence and issues not within the picket fence.

Finally the CPH statement focuses on the expenses borne by the Registrars in fulfilling the mandates of the the RAA.  This is a very good point and those expenses are a very good and important consideration in considering improvements.  Economic analysis and impact should be part of every PDP and I do not for a second recommend that the economic or operational perspective of Registrar not be considered as part of this policy process.  In fact, this too is an essential part of the ICANN Social Compact: that the organization being regulated is included in the policy making process alongside the users and registrants.  The Registrars and the ‘full implementation burden_financially and operationally’ are a critical component in any PDP discussing the RAA and should be duly considered in any recommendations made to changing the RAA.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

DNS

Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC

Cybersecurity

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global